Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org
You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. Re: Signals and external bindings... (Edward Z. Yang) 2. Re: Issue installing reactive-banana-5.0.0.1 (Miguel Negrao) 3. Re: Signals and external bindings... (Brandon Allbery) 4. Re: Signals and external bindings... (Antoine Latter) 5. Re: Signals and external bindings... (Brandon Allbery) 6. Re: Signals and external bindings... (Mike Meyer) ---------------------------------------------------------------------- Message: 1 Date: Fri, 04 May 2012 14:12:55 -0400 From: "Edward Z. Yang" <ezy...@mit.edu> Subject: Re: [Haskell-beginners] Signals and external bindings... To: Mike Meyer <m...@mired.org> Cc: beginners <beginners@haskell.org> Message-ID: <1336154962-sup-9615@ezyang> Content-Type: text/plain; charset=UTF-8 It is a tricky subject, but not insurmountable. http://blog.ezyang.com/2010/08/interrupting-ghc/ http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/ffi.html#ffi-interruptible http://blog.ezyang.com/2010/11/its-just-a-longjmp-to-the-left/ Cheers, Edward Excerpts from Mike Meyer's message of Wed May 02 13:00:41 -0400 2012: > I've just finished a QAD project in Python, and expect them to ask > me to build the production version of the same project. I'd like to > switch to Haskell, but (again, for those who noticed) have some > questions I'd like answered. > > One problem I ran into is that I use Unix signals to control the > various processes. In CPython, this causes a problem with extension > code because the python signal handler at the C level just note the > signal, then wait to run the Python "signal handler" the next time the > interpreter. Since my extensions are doing the heavy lifting, they > often run for long periods (by which I mean 10s of minutes). Meaning > the signal is ignored for long periods. > > Since I expect to such extensions (the wrappers are available) and > want to leave the control mechanisms in place, I'd like to know if I'm > going to have similar problems in Haskell. > > Thanks, > <mike ------------------------------ Message: 2 Date: Fri, 4 May 2012 19:15:45 +0100 From: Miguel Negrao <miguel.negrao-li...@friendlyvirus.org> Subject: Re: [Haskell-beginners] Issue installing reactive-banana-5.0.0.1 To: beginners@haskell.org Message-ID: <7a36ef86-5828-47a4-b9e9-16c86ec8e...@friendlyvirus.org> Content-Type: text/plain; charset=windows-1252 Hi, >> Is any generality lost because of this or are the approaches >> equivalent ? > > Once you have a timer, you can make a behavior > > time :: Behavior t Time > > that indicates the current time and thus allows you to write functions that > depend on the current clock time, just like in Conal's papers. > > In other words, the approaches are largely equivalent. > > The thing is just that different GUI or audio frameworks tend to have > different implementations of timers and reactive-banana can't decide which > one is more appropriate. For instance, Henning Thielemann uses ALSA-timers in > his reactive-balsa package > > http://hackage.haskell.org/package/reactive-balsa-0.0 > > At some point, I intend to offer some common time-related functionality (for > example as in the Wave.hs example) for different backends. Ok, I see, yes make sense. One other question, is it possible in reactive-banana to define ?recursive? event streams. For instance consider a stream which receives numbers between 0.0 and 1.0. If the last outputted value was between 0.8 an 1.0 then output 1-x otherwise output x. After that it only leta numbers through if they are between 0.0 and 0.2 or between 0.8 and 1.0. This looks like: | x V --------------------------- | y > 0.8 |<--------------y----------------| | | | -------------------------- | | | | | yes | no | V V | 1-x x | | / | V / | -------------- | | | | | V | ---------------------------------------------------- | | select values between 0.0 and 0.2 | | | and 0 8 and 1.0 | | | || | ---------------------------------------------------- | | | |------------------------------------------------------------ | y | V best, Miguel Negr?o ------------------------------ Message: 3 Date: Fri, 4 May 2012 14:19:37 -0400 From: Brandon Allbery <allber...@gmail.com> Subject: Re: [Haskell-beginners] Signals and external bindings... To: Mike Meyer <m...@mired.org> Cc: beginners@haskell.org Message-ID: <CAKFCL4V+kNwczQC3d=L+=3tj7vec=hrxfpug8pbwfuw2gxm...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@mired.org> wrote: > But I realized I never got a more fundamental question answered: when > does a signal handler written in Haskell run? Is it like C, in that it > runs when the signal arrives, even if I'm currently executing some > wrapped C code, and I have to deal with funky rules about what it can > do? Or is it like Python, and it will run the first time the Haskell > runtime gets control after the signal arrives? I'm not sure it *does* run. That is, I don't think a Haskell-based signal handler is even possible. When I talk about Haskell's signal handlers, I mean C handlers within the GHC runtime. 1. The GHC runtime only protects garbage collection from signals, it doesn't protect anything else. In particular, unless memory allocation is somehow atomic, a signal arriving while something is doing an allocation dare not itself do any allocation ? which means it can do very nearly nothing. 2. Registering a Haskell-based signal handler would be a special case of arranging for C to call into Haskell code (since that is in fact what it would be doing; the real signal handler is C invoked from an assembler trampoline). As things currently work, this can only be done from calls to C which suspend the Haskell runtime in a known safe state; asynchronous signals don't provide any way to arrange this, any more than they insure C's malloc() arena is consistent or etc. If a Haskell-hosted signal handler mechanism were to be provided, it would have to be done by invoking the handler from the next run of the event loop. The existing signal handlers work this way already, as I mentioned already; the actual signal handler writes a byte doen a pipe, and the runtime acts on it from its event loop. This is because there is so little that is safe to do from any signal handler, and even less that is safe within the context of GHC's runtime. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20120504/b019d623/attachment-0001.htm> ------------------------------ Message: 4 Date: Fri, 4 May 2012 14:55:54 -0500 From: Antoine Latter <aslat...@gmail.com> Subject: Re: [Haskell-beginners] Signals and external bindings... To: Brandon Allbery <allber...@gmail.com> Cc: beginners@haskell.org Message-ID: <CAKjSnQE5G_UpjJQ4duzn6imp5xA7L3NFh=H8A=fzjs9ieba...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, May 4, 2012 at 1:19 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@mired.org> wrote: >> >> But I realized I never got a more fundamental question answered: when >> does a signal handler written in Haskell run? Is it like C, in that it >> runs when the signal arrives, even if I'm currently executing some >> wrapped C code, and I have to deal with funky rules about what it can >> do? Or is it like Python, and it will run the first time the Haskell >> runtime gets control after the signal arrives? > > > I'm not sure it *does* run. ?That is, I don't think a Haskell-based signal > handler is even possible. ?When I talk about Haskell's signal handlers, I > mean C handlers within the GHC runtime. > Well, there is this: http://www.haskell.org/ghc/docs/latest/html/libraries/unix-2.5.1.0/System-Posix-Signals.html#g:4 But it's bit short on what exact semantics it provides. It looks like it uses this chunk of code on GHC (on Posix systems): https://github.com/ghc/ghc/blob/376210565e4dff2679246c6ebbcdbb3163c9e8a5/rts/posix/Signals.c Antoine ------------------------------ Message: 5 Date: Fri, 4 May 2012 16:18:54 -0400 From: Brandon Allbery <allber...@gmail.com> Subject: Re: [Haskell-beginners] Signals and external bindings... To: Antoine Latter <aslat...@gmail.com> Cc: beginners@haskell.org Message-ID: <CAKFCL4V5N4FQ1gWDyAEky8LUfOV6TogO8Gd-c7-ovULUdwT4=q...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Fri, May 4, 2012 at 3:55 PM, Antoine Latter <aslat...@gmail.com> wrote: > On Fri, May 4, 2012 at 1:19 PM, Brandon Allbery <allber...@gmail.com> > wrote: > > On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@mired.org> wrote: > >> But I realized I never got a more fundamental question answered: when > >> does a signal handler written in Haskell run? Is it like C, in that it > > > > I'm not sure it *does* run. That is, I don't think a Haskell-based > signal > > handler is even possible. When I talk about Haskell's signal handlers, I > > mean C handlers within the GHC runtime. > > Well, there is this: > > > http://www.haskell.org/ghc/docs/latest/html/libraries/unix-2.5.1.0/System-Posix-Signals.html#g:4 OK, looks like that does what I said in my final paragraph (which was written based on the runtime Signals.c source). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20120504/9fc83db8/attachment-0001.htm> ------------------------------ Message: 6 Date: Fri, 4 May 2012 23:24:12 -0400 From: Mike Meyer <m...@mired.org> Subject: Re: [Haskell-beginners] Signals and external bindings... To: beginners@haskell.org <beginners@haskell.org> Message-ID: <20120504232412.2f0ff...@bhuda.mired.org> Content-Type: text/plain; charset=UTF-8 On Fri, 4 May 2012 14:19:37 -0400 Brandon Allbery <allber...@gmail.com> wrote: > On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@mired.org> wrote: > > But I realized I never got a more fundamental question answered: when > > does a signal handler written in Haskell run? Is it like C, in that it > > runs when the signal arrives, even if I'm currently executing some > > wrapped C code, and I have to deal with funky rules about what it can > > do? Or is it like Python, and it will run the first time the Haskell > > runtime gets control after the signal arrives? > I'm not sure it *does* run. That is, I don't think a Haskell-based signal > handler is even possible. When I talk about Haskell's signal handlers, I > mean C handlers within the GHC runtime. Ok, now we're just having vocabulary issues. "Signal handler" is used to mean two different things: 1) Code that runs in the context provided by the OS for handling the signal. As you say, this is typically written in C, and has a bunch of restrictions on what it can and cannot do. 2) Code that someone writes to be run in response to a signal from the OS. In C (and presumably C# and C++), the two are identical. The restrictions may well cause you to write handler-1 code that will be set an notice of some kind to run code in your main context when it's convenient. The latter is technically handler-2 code, but calling such a signal handler isn't common. > 1. The GHC runtime only protects garbage collection from signals, it > doesn't protect anything else. In particular, unless memory allocation is > somehow atomic, a signal arriving while something is doing an allocation > dare not itself do any allocation ? which means it can do very nearly > nothing. I have to wonder how the boehm gc handles such things? > If a Haskell-hosted signal handler mechanism were to be provided, it would > have to be done by invoking the handler from the next run of the event > loop. The existing signal handlers work this way already, as I mentioned > already; the actual signal handler writes a byte doen a pipe, and the > runtime acts on it from its event loop. This is because there is so little > that is safe to do from any signal handler, and even less that is safe > within the context of GHC's runtime. Well, one is provided, and implemented as you describe. Given a non-trivial runtime for the language, it seems you either have to do that, or provide a handler-1 environment with so many restrictions that you can't do anything useful, or write a handler-1 that runs the handler-2 once the runtime becomes available again. I guess my question was "which of those two does haskell do", and the answer is the latter. The languages that do the latter all seem to mask the fact that you're writing handler-2 code: the API is similar to the OS API, and the handler-1 code is pretty much invisible. Thanks, <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------------------------------ _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners End of Beginners Digest, Vol 47, Issue 5 ****************************************