chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too


From: Jörg F. Wittenberger
Subject: Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too
Date: Wed, 06 Nov 2013 19:20:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Am 06.11.2013 19:11, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 06:00:34PM +0100, "Jörg F. Wittenberger" wrote:
Now I cam confused.

True, there are 256 possible signal handlers in ##sys#signal-vector
How could those be addressed/used at all?
The timer interrupt signal has value 255.  I'm sure there must be UNIXen
out there which use nonstandard signals of higher numbers than 32.
For example, the Linux signal(7) manual on the box which serves
call-cc.org mentions that there are real-time signals which are numbered
33 through 64.

Yeah, maybe. Dunno. Maybe they can be used. That never happened in my code.

timer is handled special everywhere anyway.

   The manpage for
signal(7) on my NetBSD box shows 32 signals.  That means the pending
signals
won't ever fit in a fixnum on a 32-bit machine.
You're right: somehow it seems to have escaped me that attaching the
type tag on the way from C to Scheme would reduce the number of bits
avail.  (Otherwise I've been working from my "sure knowledge" that there
are only 32 signals, which in turn would fit into a single word.)
It could be worse, you could be losing one more bit, depending on what
happens to the sign bit when you're shifting unsigned signal numbers
into a signed signal bitmask (how this stuff is defined in the C spec
confuses me no end).



Still probably.

Things could hardly be worse: it fact those don't matter for me in practice at all at the moment anymore.

Because:

till now I just removed my .o files and tested how those modifications which came in from the git pull to master effected the code.

Now I ran a full recompile. To the effect that some macro expansion has been changed to the worse.

It's somehow related to code, which uses Petrofsky extraction (replacing some hon-hygienic macros I've been using before). This used to compile perfectly for several month. Now it returns some #<unspecified>

which means that I have no working code at all anymore using chicken more recent than July 23rd (my last "follow git").

Dunno what changed.  Its all so bad I could cry endlessly.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]