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

[Jörg F . Wittenberger]

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

PS: The Excuse

Since I've only recently reached the state of affairs that I can expose
the Chicken-compiled version of Askemos to the net without keeping an
eye on the firewall, I did so far not even dare to change the time
representation for a reason unrelated to Chicken.  So far the only
Scheme for which there was a working implementation of Askemos/BALL
was RScheme.  Therefore the network ran all public nodes on RScheme.
Now the DHT is updated in byzantine agreement, whereby a "current time"
(which is not the current-time from Chicken) is going to be part of
the checksum the agreement in being run on.  One of the closest-to-worst
cases which could hit me would be, if due to some hypothetical rounding
error representing the same time value for the checksum would occasionally
result in a different representation under RScheme and Chicken.
(Which in turn would make the update fail.  If all that byzantine agreement
relates stuff does not make any sense to you:  take the idea of
http://code.google.com/p/upright/ - you find an API where you plug in
you application code (one single step that is).  Now forget upright
and java.  Plug in a single step of a Scheme interpreter.  You've
got it?)  I did not dare to even try floats.  Too floating this ground.