November 2003 - Libraries

Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 08 Jul '04

08 Jul '04

Libraries people, There are currently two ways to create and communicate with external processes: - System.Cmd.system (very basic, doesn't give you access to the process's output but you can use shell primitives to redirect its input/output). - Posix.runProcess (can specify Handles for the process's input/output, but it doesn't create pipes so you can't actually communicate with the subprocess using these Handles.). - POpen.popen (can specify an input String, and gives you lazy output Strings. No interactive communication is possible.) Ok, *three* ways. System.Cmd.system, Posix.runProcess, POpen.popen, and shell-haskell. Er. *Four* ways. David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and lets you communicate interactively with the sub-process via Handles. It could do with a way to specify the environment and working directory of the sub-process (ala POpen and runProcess), but apart from that it seems to be the most flexible of the four. It could be simplified slightly by using one Handle rather than two for stdin/stdout. We should think about what functionality we want to provide in the core libraries. My preference would be to go for a full version with three pipes (like shell-haskell) and perhaps one or two more specialised versions covering common cases (I don't know what these should be, though). What do people think? Cheers, Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of David Sankel Sent: 06 May 2003 03:06 To: haskell(a)haskell.org Subject: [ANNOUNCE] shell-haskell 1.0.0 =================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.com/shell-haskell for details. David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 10

RE: How to best add logging/debugging code?
by Simon Marlow 28 Nov '03

28 Nov '03

> Hmm. This suggestion has the potential to confuse the casual user > even more. Consider > > debug s x = trace (s++": "++show x++"\n") x > f x = debug ("entered f") (... g y ...) > g y = debug ("entered g") (...) > main = ... f ... > > With the current definition of 'trace', although the formatting is > ugly, the user (correctly) sees that the evaluation of f is entered > before g. > > entered f: entered g: val_g_y > val_f_x The current implementation of Debug.Trace does indeed do this, but the behaviour can be altered by changing the buffering mode of stderr. Try it: import System.IO import Debug.Trace main = do hSetBuffering stderr (BlockBuffering Nothing) trace ("a" ++ trace "b" "") (return ()) AFAIK, it's been this way for a long time. Cheers, Simon

1 0

Re: How to best add logging/debugging code?
by Ross Paterson 28 Nov '03

28 Nov '03

On Thu, Nov 27, 2003 at 02:19:53PM +0000, Malcolm Wallace wrote: > Apart from changing the evaluation order of expressions, trace has > other drawbacks, noted I think by Lennart(?) but I can't remember > exactly where. One issue is this: > > Consider an expression where the printable argument to 'trace' causes > the evaluation of another expression which itself is defined using > 'trace'. The nested 'trace' outputs will appear interspersed with > each other. In recursive definitions this can become quite painful > to disentangle. Perhaps trace should be redefined: trace msg v = foldr seq (old_trace msg v) msg

2 1

"(±¤°í)´ëÇÑ¹Î±¹-ÀÎÅÍ³ÝÀÇ ÁöÃàÀ» Èçµé°ÔµÉ ¸Å¿ì ³î¶ó¿î»ç½Ç ÇÑ°¡Áö¸¦ ÀüÇÕ´Ï´Ù.@"
by ��ģ�� 23 Nov '03

23 Nov '03

1 0

RE: Treating POSIX signals as exceptions?
by Simon Marlow 17 Nov '03

17 Nov '03

> On Tue, Nov 11, 2003 at 09:39:05AM -0000, Simon Marlow wrote: > > Hmm, there is clearly a choice between having a signal spawn a new > > thread or raise an asynchronous exception, and it's not at all clear > > which is best. > > > > But, since we can implement either using the other one, it doesn't > > really matter too much which one is primitive. > > While either could be implemented in terms of the other, the choice of > which to use for the default handlers will change the behavior of the > program dramatically, simply because it determines whether > bracket cleans up in the presense of signals. So, essentially you're saying that BY DEFAULT, the behaviour should be that certain signals raise an exception (in the main thread only)? It's not clear to me that this should be the default behaviour. If it is, you'd probably want a way to turn it off - the withSignals API doesn't provide a way to turn it off, apart from 'block'. I'd be much happier to just provide the tools for now; if it turns out later that virtually everyone is beginning their programs with 'withSignal sigINT...', then we can possibly make it the default later. > In darcs, I really have no interest in dealing with signals, > I just want to > make sure my temporary files are cleaned up even if the user > hits ^C. If > the default signal handler uses exceptions, this will happen for free. > Currently, my only choice for the former purpose is to use > something like > withSignal. > > I guess the problem is that as far as I can tell, there is no way to > implement a "correct" bracket along with the existing POSIX signal > implementation, since there's no way to find out what the > current handler > is, which means bracket can't install its own handler without > messing up the current handler. Hmm, I don't think I understand this. bracket is just fine as it is; it's just the signal handler which needs to raise an exception, right? Cheers, Simon

2 1

RE: Treating POSIX signals as exceptions?
by Simon Marlow 17 Nov '03

17 Nov '03

> Well, bracket doesn't work with concurrent programs even in > the absense of > signals (except in the main thread) so you don't lose > anything there. If > you write a concurrent program and want its threads to clean > up, you always > have to code that yourself, for example using a bracket in > the main thread. If you're referring to the fact that non-main concurrent threads aren't required to terminate before the program terminates, then I think you're placing the wrong emphasis by saying that "bracket doesn't work with concurrent programs". It works fine. Are there any situations in which the cleanup action in a bracket might not run? Sure: * the bracket is in a non-main thread and the program terminates * SIGKILL, SIGSEGV, etc. * Out of memory (should be an exception, but isn't) * Power failure * etc. etc. should we therefore say that bracket doesn't work? I argue not. Cheers, Simon

1 0

RE: Time library discussion (reprise)
by Simon Marlow 15 Nov '03

15 Nov '03

> On Tue, 11 Nov 2003 12:44:59 -0000 > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > > > This has been demonstrated - recently by Juanma > Barranquero's library > > posted to the Haskell list, > > I think you're referring to Stefan Karrmann's library. I just did a > couple comments about it. Oops! My apologies. > IMHO, Haskell should have a simple module which allowed to manipulate > dates and times in UTC (and convert to/from localtimes, and perhaps > MJD/JD), and, as an extension, a TAI module for the (probably > very few) > people who needs that kind of precision. Let's talk in concrete terms. Could you propose an API for what you have in mind for the basic UTC functionality? Presumably, without TAI support, the library will be unable to do accurate calendar calculations at the second level (i.e. "add S seconds to time T"), although it will be able to do larger scale calendar calculations (i.e. adding days, months, etc.). Or maybe you provide the second-level calculations but document that they don't take into account leap seconds? > I know that I've been programming quite a few years and I've never > needed to know TAI times, nor ignoring the leap seconds have been a > problem. And, till very recently, I was working for a VoIP carrier, so > you can bet we manipulated dates, times and durations > *constantly*. I'm > not saying there aren't problem domains where that level of > precision is > required. Just they're not that common, I think. Ok, it's useful to have someone with experience of actually using this stuff for Real Work. As always, I'm happy to go along with a concensus if one can be reached. Cheers, Simon

5 6

Re: Treating POSIX signals as exceptions?
by David Roundy 15 Nov '03

15 Nov '03

[moving to libraries] I've made a few modifications to your SigException modle... On Tue, Nov 11, 2003 at 09:39:05AM -0000, Simon Marlow wrote: > Hmm, there is clearly a choice between having a signal spawn a new > thread or raise an asynchronous exception, and it's not at all clear > which is best. > > But, since we can implement either using the other one, it doesn't > really matter too much which one is primitive. While either could be implemented in terms of the other, the choice of which to use for the default handlers will change the behavior of the program dramatically, simply because it determines whether bracket cleans up in the presense of signals. In darcs, I really have no interest in dealing with signals, I just want to make sure my temporary files are cleaned up even if the user hits ^C. If the default signal handler uses exceptions, this will happen for free. Currently, my only choice for the former purpose is to use something like withSignal. I guess the problem is that as far as I can tell, there is no way to implement a "correct" bracket along with the existing POSIX signal implementation, since there's no way to find out what the current handler is, which means bracket can't install its own handler without messing up the current handler. Having block work for protecting areas of the code where unexpected termination could cause data corruption would also be handy, although this could already be done with blockSignals and unblockSignals. > I've attached a more robust implementation of your withSig. This one: > > - doesn't suffer from race conditions around the point at which > the signal handler is installed > > - it uses a datatype for the signal exception (Typeable can be > derived these days) > > - it allows several threads to request notification of the same > signal > > - it doesn't support nesting use of withSig with the same signal. > (that could be added, but I'm not sure it's worth it). I've added (but not tested) support for nesting of withSig. It seems like it's worthwhile just so you can't get weird errors caused by nesting withSig. > > Is there any reason all of System.Posix.Signals couldn't be done in > > this manner? Have the RTS always add a handler for each signal, which > > just throws an exception. Off the top of my head, all we'd need is one > > function > > > > acceptSignals :: IO () -- tells RTS to send signal exceptions to this > > You can implement this too using the module I attached. Well, this would only make sense if the default behavior was to treat signals as exceptions. Otherwise the system wouldn't know *which* signals to send as exceptions to this thread, and any that aren't caught wouldn't be handled by the default handler. > I guess we should provide this in the POSIX library. Would you like to > play around with the API and submit it for inclusion? I've modified it a bit. As I said above, I added support for nested withSignals. I also added a catchSignal function. It was either that or export a type and let the user use catchDyn, and it seemed cleaner to simply export a function. It still doesn't do what I'd really like, which is add default handlers for signals. I'd really like a withSignalsAsExceptions :: IO a -> IO a which would add an exception-throwing handler for *every* signal type (perhaps every asynchronous signal type...), and then run the default handler for any uncaught signals. Even better if main was automatically run in a withSignalsAsExceptions environment. If we had this function, we wouldn't need withSig (since every signal would generate exceptions). We would need additional functions to indicate which threads should get the signal exceptions, although by default they could just go to the main thread. The catch is that this withSignalsAsExceptions would need to have a handler for every signal type, which is more work than I'm willing to put in at the moment. I'm attaching my modified SigException.hs. -- David Roundy http://www.abridgegame.org

2 2

Check out this dermal patch, smrfbeg
by Haskell 14 Nov '03

14 Nov '03

1 0

Re: time since the epoch
by Stefan Karrmann 14 Nov '03

14 Nov '03

Dear Juanma, thanks for your remarks. Juanma Barranquero (Mon, Nov 10, 2003 at 10:54:22AM +0100): > On Fri, 7 Nov 2003 19:55:47 +0100 > Stefan Karrmann <sk(a)mathematik.uni-ulm.de> wrote: > > > I've inserted 'convert = (uncurry cFromTai) . cToTai'. > > Great, thanks. > > > A fixed and checked version is appended and carbon copied to > > <haskell-libs-developers(a)lists.sourceforge.net>. > > What's haskell-libs-developers? I thought libraries' development was > carried over on libraries(a)haskell.org... (And shouldn't we be discussing > Tai.lhs there, BTW :) Well, the original thread was on this list. I'm moving it to libraries(a)haskell.org now. > I'm attaching a patch (diff -u2) with a few small changes: I've included it. > More coments: > > - I'm sending you the patch throw the Haskell list because previous > attempts of sending to your e-mail address failed. I'm using ASK as a spam killer. Do you have problems with it? > - Are you very fond of the literate style? I ask because unlit'ing it > would allow adding Haddock coments, which would be nice. I've given it a try, but my comment marking could be improved. > - I'm not sure I like depending on a leapseconds table hardcoded in the > source, even if it changes slowly. Wouldn't it be better to have the > data in a file and load it through unsafePerformIO? (And isn't > loading configuration data one of the few "good" examples of use of > unsafePerformIO, after all? :) Well, I included the two as examples. The empty one is correct for all times before 1970-01-01. That's more than ten billion years. > - I get a warning with -Wall: > > Warning: Defined but not used: > TimeDiff, days_from_MJD2unixEpoch, days_from_unixEpoch2MJD', > hours_per_day, isodelta, isomoveDHM, isomoveS, isomoveYM, > libtaiEpoch, month_per_year, test, test2 Some values are only for testing and debugging while others are experimental, e.g. TimeDiff and friends. > Several of these are neither used nor exported. ??? Regards, -- Stefan Karrmann

2 1