October 2004 - Glasgow-haskell-users

RE: runInteractiveProcess is broken
by Simon Marlow 18 May '05

18 May '05

I can't repeat this, it works here: *Main> test1 ExitSuccess *Main> test2 Just ExitSuccess (after changing /usr/bin/sleep to /bin/sleep). The only thing I can think of is that you somehow have a SIGCHLD handler that calls wait(), but I don't see where that can be happening. GHC doesn't have any other mechanism for calling wait(), so I don't understand how the zombies are disappearing before waitForProcess is called. Maybe run it through strace and send us the output? Cheers, Simon On 26 October 2004 19:00, Peter Simons wrote: > Neither of these functions returns the return code of the > external process as promised: > > import System.IO hiding ( catch, try ) > import System.Process > import Control.Concurrent > > sleep :: Int -> IO () > sleep n = threadDelay (abs(n) * 1000000) > > test1 :: IO () > test1 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- waitForProcess pid > print rc > > -- *Main> test1 > -- *** Exception: waitForProcess: does not exist (No child > processes) > > test2 :: IO () > test2 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- getProcessExitCode pid > print rc > > -- *Main> test2 > -- Nothing > > I'm using the ghc from CVS-HEAD on Linux/x86. > > Peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

getUserEntryForName weirdness
by Peter Simons 06 Nov '04

06 Nov '04

Is anyone else seeing this on his system? getUserEntryForName [] >>= print . userName "wasabi" "wasabi" happens to be the last entry in the /etc/passwd file, and that is what I get every time I query for an user that doesn't exist. The source code promises an exception, but I don't get one. Peter

5 6

RE: Double -> CDouble, realToFrac doesn't work
by Simon Peyton-Jones 05 Nov '04

05 Nov '04

| Hmmm, this is a little bit of a dark corner in the H98 report, but there are | probably other people on this list who know better than me. :-] The problem | is that 'realToFrac' is defined as 'fromRational . toRational', so the first | question is: How is 'toRational' supposed to handle NaN? One thing coming to | my mind is '0 :% 0', but this is normally a value which can't be constructed. | So the next question is: Would this be allowed? +Infinity and -Infinity could | be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational' | could handle these values specially. But I can't believe that this has been | discussed for the first time. SPJ? Malcolm? I don't recall a discussion about this, and a quick search in my mail archive didn't turn up anything except the enclosed from George Russell. I'm pretty ignorant about the dark corners of numerics, but it does seem bad that passing through Rational loses information. Perhaps the Report should specify normalised representations for +Inf, -Inf and NaN as Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates). If someone wants to try this out, and send us a patch for the Rational library, we could incorporate it. And so far as the report goes, perhaps the Errata could contain a note identifying the issue, and suggesting a solution. It's a bit late to *specify* a solution unless we are really sure about it. Simon -----Original Message----- From: George Russell [mailto:ger@informatik.uni-bremen.de] Sent: 25 February 2000 10:19 To: glasgow-haskell-users(a)haskell.org Subject: Floating-point nitpicking: floor(Inf) and floor(NaN) floor(Inf) and floor(NaN) do not appear to be defined in Standard Haskell. (They both come down to "properFraction" which is only defined for Ratio.) This differs from (for example) the Standard ML Basis Library, where it is specified that floor(Int) should raise Overflow and floor(NaN) should raise Domain. Hence Hugs and GHC do different things. Hugs returns floor(Inf) = 0 and floor(NaN) = 0 GHC returns floor(Inf) = very very large integer and floor(NaN) = even larger integer. (This is because the GHC implementation of properFraction simply ignores the case of Inf/NaN and treats the artificially high exponent encoded in those floating-point numbers as if it were a real one.) My own opinion is that Standard ML is right here and that floor(x) should raise an exception (In Haskell terms, fail) when x does not correspond to a real number. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Sven Panne | Sent: 08 August 2004 17:02 | To: Hal Daume III | Cc: GHC Users Mailing List; Malcom Wallace | Subject: Re: Double -> CDouble, realToFrac doesn't work | | Hal Daume III wrote: | > [...] | > Prelude Foreign.C> (0 :: CDouble) / 0 | > NaN | > Prelude Foreign.C> (0 :: Double) / 0 | > NaN | > Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble | > -Infinity | > | > yikes! the NaN got turned into a -Infinity!!! | > | > aside from manually checking for 'strange' Double/CDouble values and | > wrapping realToFrac, is there a better way? also, does this count as a | > bug? | | Hmmm, this is a little bit of a dark corner in the H98 report, but there are | probably other people on this list who know better than me. :-] The problem | is that 'realToFrac' is defined as 'fromRational . toRational', so the first | question is: How is 'toRational' supposed to handle NaN? One thing coming to | my mind is '0 :% 0', but this is normally a value which can't be constructed. | So the next question is: Would this be allowed? +Infinity and -Infinity could | be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational' | could handle these values specially. But I can't believe that this has been | discussed for the first time. SPJ? Malcolm? | | When you compile the stuff above with optimizations on, you get what you've | expected, thanks to RULES which shortcut the route via Rational completely. | | Cheers, | S. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 3

Is it safe to call getProcessExitCode more than once?
by Peter Simons 30 Oct '04

30 Oct '04

What will happen if I call getProcessExitCode for the same process twice? Will that block? Cause an error? Or return the same child's exit code again? I assume the function is (under Unix) based on wait(2), right? In that case, how does the following warning from the manual page translate to Haskell? ERRORS ECHILD if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.) The reason I am asking is because I want to avoid zombie processes by doing a "catch-all" getProcessExitCode for every process I spawn through a finalizer. I'd just like to know whether it's safe before I do it. :-) Peter

4 8

Syntax error in happy/doc/happy.xml
by Peter Simons 30 Oct '04

30 Oct '04

Index: happy/doc/happy.xml =================================================================== RCS file: /cvs/fptools/happy/doc/happy.xml,v retrieving revision 1.7 diff -b -u -r1.7 happy.xml --- happy/doc/happy.xml 29 Oct 2004 08:26:53 -0000 1.7 +++ happy/doc/happy.xml 30 Oct 2004 12:18:32 -0000 @@ -1777,11 +1777,11 @@ <para> There is some support for monadic parsers. The "tree decoding" mode - (see <xref linkend="sec-glr-semantics-tree">) can use the + (see <xref linkend="sec-glr-semantics-tree"/>) can use the information given in the <literal>%monad</literal> declaration to monadify the decoding process. This is explained in more detail at - <xref linkend="sec-glr-semantics-tree-monad">. + <xref linkend="sec-glr-semantics-tree-monad"/>. </para> </listitem> </varlistentry>

1 0

Calling Haskell from .Net
by David Lo 29 Oct '04

29 Oct '04

Dear all, I'm new in Haskell. I need to port a haskell application written by someone else to be called by a .Net C# application. Please kindly advise on which option to pursue. Maybe on how to convert haskell code to dll or how to let C++ code (in dll format) to call Haskell. Any helps will really be appreciated. Best Regards, David

1 0

Patchy GHC support for a week
by Simon Marlow 28 Oct '04

28 Oct '04

Just to let everyone know that Simon PJ and myself will be away for the rest of this week and the next, and will probably have intermittent network connectivity, so it might take us a while to respond to messages. Cheers, Simon

1 0

--make et al not in flags.sgml?
by Ian Lynagh 27 Oct '04

27 Oct '04

Hi, Is there a reason --make and friends aren't in flags.sgml? This means they don't end up in the man page I generate. I've attached a patch that adds an entry for them, text mostly stolen from elsewhere in the docs. Thanks Ian

1 0

RE: Process library and signals
by Simon Marlow 27 Oct '04

27 Oct '04

My apologies if I misinterpreted your comments. There appear to be some use cases and conventions here that I'm not altogether familiar with. So basically you're saying that if runProcess is to be used in a system()-like way, that is the parent is going to wait synchronously for the child, then the parent should be ignoring SIGQUIT/SIGINT. On the other hand, if runProcess is going to be used in a popen()-like way, then the parent should not be ignoring SIGQUIT/SIGINT. The current interface doesn't allow for controlling the behaviour in this way. So the current signal handling in runProcess is wrong, and should probably be removed. What should we have instead? We could implement the system()-like signal handling for System.Cmd.system only, perhaps. Cheers, Simon On 26 October 2004 23:38, Glynn Clements wrote: > Having looked at the latest version of the Process library, it appears > that my earlier comments about signal handling may have been > misinterpreted. > > First, my comments regarding the handling of SIGINT/SIGQUIT were > specific to system(). The C system() function ignores these signals in > the parent while the child is executing. However, this doesn't > necessarily apply to other functions; e.g. popen() doesn't ignore > these signals, and runProcess probably shouldn't either. > > With system(), the parent blocks until the child is finished, so if > the user presses Ctrl-C to kill the "currently executing" process, > they probably want to kill the child. If the parent wants to die on > Ctrl-C, it can use WIFSIGNALED/WTERMSIG to determine that the child > was killed and terminate itself. > > OTOH, with popen(), the parent continues to run alongside the child, > with the child behaving as a "slave", so the parent will normally want > to control the signal handling. > > Ideally, system() equivalents (e.g. system, rawSystem) would ignore > the signals in the parent, popen() equivalents (e.g. > runInteractiveProcess) wouldn't, and lower-level functions (e.g. > runProcess) would give you a choice. > > Unfortunately, there is an inherent conflict between portability and > generality, as the Unix and Windows interfaces are substantially > different. Unix has separate fork/exec primitives, with the option to > execute arbitrary code between the two, whilst Windows has a single > primitive with a fixed set of options. > > Essentially, I'm not sure that a Windows-compatible runProcess would > be sufficiently general to accurately implement both system() and > popen() equivalents on Unix. Either system/rawSystem should be > implemented using lower-level functions (i.e. not runProcess) or > runProcess needs an additional option to control the handling of > signals in the child. > > Also, my comment regarding the signals being "reset" in the child was > inaccurate. system() doesn't reset them in the sense of SIG_DFL. It > sets them to SIG_IGN before the fork(), recording their previous > handlers. After the fork, it resets them in the child to the values > they had upon entry to the system() function (i.e. to the values they > had before they were ignored). The effect is as if they had been set > to SIG_IGN in the parent after the fork(), but without the potential > race condition. > > Thus, if they were originally ignored in the parent before system() > was entered, they will be ignored in the child. If they were at their > defaults (SIG_DFL) before system() was entered, they will be so in the > child. If they had been set to specific handlers, system() will > restore those handlers in the child, but then execve() will reset them > to SIG_DFL, as the handler functions won't exist after the execve().

2 1