[Chicken-users] reentrant signal handler?
Hi, I know that the chicken core is not re entrant. In that context, what's the usual practice for writing posix signal handler in chicken? See example program below. If you type something, it will simply echo it. You can type 'show' to print the a global flag. Ctrl-C will set the flag to true. If you hit ctrl-c rapidly, you'll send it into a loop consuming 100% cpu. (ctrl-\ to quit it) Am I correct that the signal handler written in scheme will be invoked asynchronously? How would one write this program in chicken correctly? Maybe there's a way to do an atomic operation to set the flag? Thanks, fungsin. (declare (uses extras regex posix utils srfi-13)) (require 'regex) (require 'posix) (require 'utils) (require-extension loop) (define *user-interrupted?* #f) (set-signal-handler! signal/int (lambda (signo) (set! *user-interrupted?* #t))) (loop for l = (read-line) while (and l (not (eof-object? l))) if (string= l "show") do (print *user-interrupted?*) else if (string= l "exit") do (exit 0) else do (write-line l)) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Chicken OSless
> Shawn Rutledge <[EMAIL PROTECTED]> writes: >> I'm curious whether or not there's been work on running Chicken's >> binaries on a OSless piece of hardware. I've been trying to convince >> my boss that it would be worth while investigating dynamic languages >> for embedded systems. > I never tried but wondered about it too. > I was thinking it would be very hard to use Scheme on a > Harvard-architecture chip like an Atmel. There could be an > interpreter, but anything new you define would have to go in SRAM > (all 4K of it, in the case of the ATmega's). You cannot execute > machine instructions out of SRAM, and you cannot write new > instructions to the Flash at runtime, Can't you? IIRC, there's support for the SPM instruction in some of the ATmega parts. It seems that it's used to allow for firmware update. Flash typically has somewhat low endurance (10 ^3 .. 10 ^4 write cycles) to be used as the main memory, though. > so the only choice would be to interpret some kind of VM instructions > that are stored in SRAM, or interpret Scheme directly, or some kind > of tokenized representation. [...] > But I'm thinking of the use case where the embedded system is on a > network and you connect and feed it some S-expressions to evaluate. > For a standalone fixed-purpose system though, if you can compile the > whole program ahead of time, there are big chunks of implementation > that you don't need anymore, right? It's just static (unchanging) > machine code being executed, like any other microcontroller program > except less efficient. :-) There's Schlep [1], though it's not a Scheme implementation. [1] http://www.swiss.ai.mit.edu/~jaffer/Docupage/schlep.html ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken OSless
On Thu, May 1, 2008 at 10:00 AM, John Van Enk <[EMAIL PROTECTED]> wrote: > I'm curious whether or not there's been work on running Chicken's binaries > on a OSless piece of hardware. I've been trying to convince my boss that it > would be worth while investigating dynamic languages for embedded systems. I never tried but wondered about it too. I was thinking it would be very hard to use Scheme on a Harvard-architecture chip like an Atmel. There could be an interpreter, but anything new you define would have to go in SRAM (all 4K of it, in the case of the ATmega's). You cannot execute machine instructions out of SRAM, and you cannot write new instructions to the Flash at runtime, so the only choice would be to interpret some kind of VM instructions that are stored in SRAM, or interpret Scheme directly, or some kind of tokenized representation. And what about having a combined RAM/ROM symbol table? The approach for handling them would be completely different between the two, but you would want them to appear to work the same. But it might just barely be possible if all the libraries you could possibly want are precompiled and stored in Flash, and only a small script is executed out of SRAM at runtime. Seems insane anyway, though. On an ARM with enough RAM it would be OK though. You could start with TinyScheme; it's so small and simple (purely an interpreter) and the code is relatively easy to read. Compiling on a system without an OS would be rather challenging. :-) If you had a direct Scheme-to-Arm compiler (like Chez) it might make more sense. It would probably be faster and save memory to compile first and then throw away the source code, rather than interpreting at all. But I'm thinking of the use case where the embedded system is on a network and you connect and feed it some S-expressions to evaluate. For a standalone fixed-purpose system though, if you can compile the whole program ahead of time, there are big chunks of implementation that you don't need anymore, right? It's just static (unchanging) machine code being executed, like any other microcontroller program except less efficient. :-) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken OSless
Hello All, I'm curious whether or not there's been work on running Chicken's binaries on a OSless piece of hardware. I've been trying to convince my boss that it would be worth while investigating dynamic languages for embedded systems. -- /jve ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken release 3.2.0 now available
Hi Ivan and folks, On Thu, 01 May 2008 08:45:01 +0900 Ivan Raikov <[EMAIL PROTECTED]> wrote: >Release 3.2.0 of Chicken is now available. It is based on > development snapshot 3.1.10, except it does not include the > precompiled header option. This release includes some minor bug > fixes, and two new units srfi-69 and data-structures, which have been > factored out of unit extras. Release 3.2.0 also eliminates the last > vestiges of lexicographic version comparison in chicken-setup, so now > egg version dependencies should be handled correctly. Debian packages > with release 3.2.0 will be available shortly. Thanks for all the good work, Ivan and folks! I've successfully built and installed chicken 3.2.0 and a couple of egg on the following platforms: Linux PPC (gcc 4.1.3) Linux x86 (gcc 4.1.3) Linux x86_64 (gcc 4.1.2) Linux Alpha (gcc 2.95.4) Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
