On Sep 29 2011, Alan Post wrote:
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'll do so. But I have to call this a day for today.
Some sad news: it looks as if things are much better now on Linux/AMD64
but the Sheeva Plug seems to still loose on i/o. I even got the feeling
that it might loose more than before. (Which could be a hint for the
days to come.)
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
