Re: [Chicken-users] another egg

[Jörg F . Wittenberger]

Hi Coalan,

other users (especially egg authors) please read on, most of this
message is intended for you, not so much addressing Coalan.

Am 04.01.2016 um 15:54 schrieb Caolan McMahon:
> Hey Jörg,
> 
> Thanks for the updates.

Great to learn that you are still around here and caring for the egg.

If you like those changes, please pull them in.  This would have the
advantage to reduce clutter/pollution of the eggs listing.

Pls. notify the list.  If you pull those changes in Mario should _not_
include mine into the coop as it would become obsolete soon.  If you
don't I'd ask for inclusion into the coop anyways.

> I think I probably found things more
> complicated writing this module because of wiring-pi calling callbacks
> from other threads (hence pulling in concurrent-native-callbacks etc).

At least you found out that you need to use concurrent-native-callbacks!

   (((What I did is just a very light weight, specialized
      implementation of the same concept.  Plus: drop the use of the
      eggs you summarized under the "etc" lable.)))

After all use of `define-external` and superficial testing might have
left you with the impression that this would have been good enough.

NB: 1st point I'm stressing that here to raise QA awareness wrt. other
egg authors, since I've been bitting by that one elsewhere before.

However: I do not (yet) understand why you mean by "other threads" in
this context.  Other pthreads or other srfi-18 threads from CHICKEN?  If
the latter: I fail to see so far how this could come into play. (Am I
missing something?)  If the former: that would be the same as with
signal handler callable from any other thread. See the related ticket
http://bugs.call-cc.org/ticket/1232 which is open at this time.  The use
of concurrent-native-callbacks should – according to my understanding
chicken-hackers pls. correct me if I'm wrong at that – NOT actually
effect/fix this.  (But may appear to do so under circumstances/by chance
as it changes to much of the code CHICKEN produces.)

> I'm currently using this library without hitting the 'case' issue you
> pointed out...

This begs the (academic) how that's possible that this did work for you.

To illustrate "case misuse" issue at hand:

The code which did not work for me (and which I called "obviously
wrong") looked like this:

(case <x>
  (('a) 1)
  (('b) 2)
  (else (error "s*t")))

while the – let's call it "correct" version would be:

(case <x>
  ((a) 1)
  ((b) 2)
  (else (error "s*t")))

Which is: you should NOT quote the symbols in `case` (here 'a and 'b) in
case if you want to compare <x> to those symbol.

> not the first obviously broken code I've had 'work' in
> CHICKEN 4.10. Starting to think I'm losing it!

@chicken-hackers: How does it come this is working for Coalan?  I'm
using "master" from three days ago, which is something like 4.10.1.  But
I doubt there are any recent changes related.

@-users:  After all: Scheme as a tradition of being a GIGO-language.
(Garbage-In-Garbage-Out)  Thus "broken code" often has undefined
results.  It MAY be working anyway.

/Jörg

> Caolan
> 
> On 4 January 2016 at 13:27, Jörg F. Wittenberger
> <address@hidden> wrote:
>>
>>
>> Hi all,
>>
>> yet another egg I put together, which may be interesting to you (and may
>> go the coop):
>>
>> http://askemos.org/chicken-eggs/raspberry-pi-gpio-small.release-info
>>
>> This is a (supposed to be) API compatible version of the
>> raspberry-pi-gpio egg.
>>
>> Maybe these modifications should simply be folded into the latter.
>> That's a matter of choice.  (A choice left to Caolan McMahon, the author
>> of the latter.)
>>
>> Why did I feel the alternative may be good?
>>
>> * The `-small` suffix was chosen because of the reduced dependency list:
>> no dependencies except for CHICKEN core.
>>
>> * Throwing together those modifications took me about as much wall clock
>> time as chicken-install spent on installing the original one including
>> those dependencies.
>>
>> * Roughly half the code size.
>>
>> * Not jumping through various call should always be faster than doing
>> so.  Thus I'd _expect_ less runtime overhead, which may be important
>> when controlling sensors.
>>
>> * Not needing those dependencies should make debugging simpler.
>>
>> (* Besides: I wonder how the original could ever have worked.  The
>> example from the documentation runs into >>Error: uncaught exception:
>> "Unknown mode"<< for an obvious misuse of `case`.)
>>
>> Have fun
>>
>> /Jörg