Re: [Chicken-users] Eggs metafile needs another property - doesn't it?
* Jörg F. Wittenberger [160105 21:18]: > Argh, wait... > > Am 05.01.2016 um 21:09 schrieb Jörg F. Wittenberger: > > Hi all, > > > > I need to specify a certain - not yet available - version of chicken > > itself as the minimum requirement for an egg to work for real. > > as I sent the message I re-read > http://wiki.call-cc.org/Metafile%20reference > once more and stumbled upon what I've been looking for: > > (platform ID ...) > > using `chicken-4.11` should do the trick, shouldn't it? The documentation may be misleading. A couple of eggs use the depends clause: big-chicken/trunk/big-chicken.meta: (depends (chicken "4.2.6") regex) gazette-tools/trunk/gazette-tools.meta: (depends big-chicken matchable miscmacros htmlprag srfi-19 http-client html-parser sxpath regex ssax) heap-o-rama/trunk/heap-o-rama.meta: (depends (chicken "4.5.7")) henrietta/trunk/henrietta.meta: (depends (chicken "4.5.8") regex) operations/trunk/operations.meta: (depends (chicken "4.0.4")) sequences/trunk/sequences.meta: (depends fast-generic (chicken "4.6.3") srfi-42) sp/trunk/sp.meta: (depends big-chicken honu matchable miscmacros typed-records) HTH, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Eggs metafile needs another property - doesn't it?
Argh, wait... Am 05.01.2016 um 21:09 schrieb Jörg F. Wittenberger: > Hi all, > > I need to specify a certain - not yet available - version of chicken > itself as the minimum requirement for an egg to work for real. as I sent the message I re-read http://wiki.call-cc.org/Metafile%20reference once more and stumbled upon what I've been looking for: (platform ID ...) using `chicken-4.11` should do the trick, shouldn't it? Sorry for the noise. > (((Backgground: Hacking away on this RPi gpio egg I created a version > which exacerbates an issue I fixed the other day - see ticket 1232. To > improve at the real-time behavior there is a real-time thread doing > nothing but wait for signal delivery. – Is there a better way to do > this??? – Now signals are more or less sure to arrive _not_ at the > chicken thread, which will mess up the memory management.))) > > As this is not the only egg not working for older chicken versions I > guess we should have a property like `min-chicken-version` to make sure > users do not get trapped. > > Any thoughts? > > Best Regards > > /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Eggs metafile needs another property - doesn't it?
Hi all, I need to specify a certain - not yet available - version of chicken itself as the minimum requirement for an egg to work for real. (((Backgground: Hacking away on this RPi gpio egg I created a version which exacerbates an issue I fixed the other day - see ticket 1232. To improve at the real-time behavior there is a real-time thread doing nothing but wait for signal delivery. – Is there a better way to do this??? – Now signals are more or less sure to arrive _not_ at the chicken thread, which will mess up the memory management.))) As this is not the only egg not working for older chicken versions I guess we should have a property like `min-chicken-version` to make sure users do not get trapped. Any thoughts? Best Regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] another egg
Hi all, for the time being (as we shall not have yet another gpio egg). There is a 1.1.0 version of the raspberry-pi-gpio-small egg now here: http://askemos.org/chicken-eggs/raspberry-pi-gpio-small.release-info latest source here: http://askemos.org/chicken-eggs/raspberry-pi-gpio-small/raspberry-pi-gpio-small.tar.gz This one changes the API in a backward compatible way (see the README). The important part: the pin values and the time when the interrupt occurred are now obtained within the interrupt service routine. This gives much better precision. Also I observed that it is all too easy to read the wrong value from the pin, since it may change multiple times during the delay between the interrupt time and CHICKEN eventually handling it. Best /Jörg Am 05.01.2016 um 11:20 schrieb Caolan McMahon: >> 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. > > Sounds good, I'll pull in your changes rather than us adding more gpio > eggs. Reducing the dependencies alone is worth doing since I expect > many people will just compile on the raspberry pi rather than set up a > cross-compiler. Please could you email me a git format-patch? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using fmt and numbers eggs together
On Sun, Jan 3, 2016 at 1:48 AM, Peter Bex wrote: > On Sat, Jan 02, 2016 at 11:40:47AM -0500, Sudarshan S Chawathe wrote: > > I seem to get incorrect output and errors in some cases when using the > > fmt and numbers eggs together. A brief transcript illustrating the > > problem is included below. In brief: > > > > * (fix 30 2/3) doesn't behave as indicated in the docs. > > > > * Some large numbers cause errors. > > > > When not using the numbers egg, fmt's behavior seems to be as expected > > (given Chicken's implementation of numbers without the 'numbers' egg). > > > > Is this a known limitation of fmt with 'numbers'? > > I'm afraid so. As far as I know the only way to fix this is to add a > hard dependency on numbers to fmt. This may not be desirable depending > on what you're using fmt for. > > This is a result of the second class treatment that extended numbers get, > and will be fixed in CHICKEN 5, due to integration of the full numeric > tower into core. > Note this is in contrast to how 'numbers' used to work, where loading it overloaded all numeric operations globally. The fmt documentation still reflects this previous behavior. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] another egg
> 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. Sounds good, I'll pull in your changes rather than us adding more gpio eggs. Reducing the dependencies alone is worth doing since I expect many people will just compile on the raspberry pi rather than set up a cross-compiler. Please could you email me a git format-patch? Just so you know, it may be a few days before I have time to test this code out, busy week for me. I expect to have some raspberry pi gadgets arriving though, so I'll have an incentive to try this out :D >> 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. Just to be clear, I'm not implicating CHICKEN 4.10 just yet ;) I'll look into it when I test your patch. The other example I alluded to was this issue: http://bugs.call-cc.org/ticket/1232 In that egg there was an obviously broken cond that passed the tests just fine in CHICKEN 4.10.0 and (rightfully) failed for the CHICKEN 4.10.1 dev snapshot... very odd. -Caolan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
