Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

On Thu, Sep 29, 2011 at 10:20:28PM +0200, Jörg F. Wittenberger wrote:
> On Sep 29 2011, Alan Post wrote:
> >>Hence my question how to clean up the API.  Default to possibly useless
> >>re-calling the handler (while it assumes possibly having missed a signal
> >>and hence re-check everything)?  Provide a modified API which covers
> >>both cases? ...
> >>
> >
> >It may have been posted before I was really attending to this
> >conversation.  I can't find it in my archive.  Would you mind
> >sending it to me again?
> 
> Not at all.
> 
> Given the doubt whether or not this conversation pertains to the before
> mentioned issue https://bugs.call-cc.org/ticket/668 I'm not sure:
> should we take this conversation private for a while or not.
> 
> The situation is: right now I'm running from a modified chicken.
> Changes have been made to
> a) the signal handling
> b) the finalizer_list and list constructors as posted recently
> c) the scheduler and srfi-18 (ages ago)
> d) for historic reasons: the time representation (see below for an excuse)
> 
> At least for (d) there is no reason for you to swallow that one.
> 
> (c) might fix a bug - risky enough if your code relies on it -- or it
> may introduce one my code relies on.
> 
> The note to take to the chicken community: it's a nice feature in a way,
> that chicken needs only on .h and on .c file plus your code.  But this
> features now shows it's downside: it's hard to merge independent changes.
> It's hard to track the common ground.
> 
> However (c) does have some overlap with (a) - which would be what you
> are interested in to begin with.  We will not be able to reconcile without
> manual intervention.
> 
> Worse: (a) and (d) do overlap in runtime.c and chicken.c (for what the
> excuse is worth)...
> 
> Alan, what would be the best?  Several postings on the list detailing
> the changes (good for documentation; needs manual integration always;
> thereby forcing code review)?  A full diff from current git to my
> current state of affairs (watch out for excuses below!)?
> 
> /Jörg
> 

Fun!  I'd rather look at an isolated a), even if it doesn't compile,
than try to digest the rest of this too.

If you can just send me the parts of your tree that pertain to a),
even if that patch does not result in code that compiles, that would
help me the most.

It's ok if, for instance, I get a patch that leads off into b, c, or
d and you just fail to include that.

Will you do this?  I am curious to see your signal handling patch.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du