November 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

Re: Bug in touchForeignPtr?
by Benjamin Franksen 30 Nov '04

30 Nov '04

[re-sending because I got no response yet] On Tuesday 23 November 2004 13:06, Simon Marlow wrote: > On 22 November 2004 17:28, Benjamin Franksen wrote: > > However, what I don't understand is why touchForeignPtr is not > > honored in my example program: Note that the output text lines from > > the finalizers appear *before* the last action in the program (which > > is a second getChar). The finalizers *are* called by the GC, and > > still the order is wrong. > > Note that the GC only starts the finaliser thread. The program can > still terminate before this thread has run to completion I repeat: the program is not yet even near termination when the finalizers get executed (in teh wrng order). Here is the example program again (with 3 lines added to the end of main to illustrate the point): import Foreign hiding (newForeignPtr) import Foreign.Concurrent import System.Mem (performGC) type A = ForeignPtr Int type B = ForeignPtr Bool newA :: IO A newA = do (pa::Ptr Int) <- malloc newForeignPtr pa $ do putStrLn "before finalizing A" free pa putStrLn "after finalizing A" newB :: A -> IO B newB fpa = withForeignPtr fpa $ \pa -> do (pb::Ptr Bool) <- malloc newForeignPtr pb $ do putStrLn "before finalizing B" free pb putStrLn "after finalizing B" touchForeignPtr fpa main = do a <- newA b <- newB a getChar performGC getChar putStrLn "Program still not terminated, please hit <enter> again!" getChar putStrLn "Program termination will now be initiated." And this is the output: franksen@linux: .../foreigntouchbug > ./a.out <enter> before finalizing A after finalizing A before finalizing B after finalizing B <enter> Program still not terminated, please hit <enter> again! <enter> Program termination will now be initiated. Ben

1 0

RE: -fno-monomorphism-restriction
by Simon Peyton-Jones 30 Nov '04

30 Nov '04

Christian This isn't a bug. See Section 4.5.5 of the Haskell Report, http://haskell.org/onlinereport/decls.html in the second bullet under the sub-heading "Motivation". Your (bi, las) binding is essentially the same as the (n,s) binding in that bullet. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Christian Maeder | Sent: 29 November 2004 16:31 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List | Subject: Re: -fno-monomorphism-restriction | | I've found a much shorter example (without imports) that does not | compile. The error displayed is: | | Ambiguous type variable `a' in the top-level constraint: | `ATermConvertibleSML a' | arising from use of `las' at | /home/maeder/haskell/examples/NoMonoRestr.hs:29 | | (comenting out the initial "OPTIONS" line, will make it go through) | | Cheers Christian

2 1

-fallow-incoherent-instances
by Christian Maeder 30 Nov '04

30 Nov '04

The attached module does not compile and yields the following error: InCoherentInst.hs:17: Could not deduce (Confuse a) from the context (Typeable a) arising from use of `breakFn' at InCoherentInst.hs:17 Probable fix: Add (Confuse a) to the type signature(s) for `addGeneralFallOut' In the first argument of `GeneralBreakFn', namely `breakFn' In the definition of `addGeneralFallOut': addGeneralFallOut = let breakFn a = throwDyn (GeneralFallOutExcep a) in GeneralBreakFn breakFn The same source compiles ok without -fallow-incoherent-instances (or with -fno-allow-incoherent-instances). If, furthermore, the "confusing instance" is commented out, the source even compiles without extensions. I don't know if this is a bug, possibly related to the import of Typeable stuff. I don't need a fix. I only want to point out that globally switching on the option -fallow-incoherent-instances is likely to break existing code, currently (ghc 6.2.2). Cheers Christian

3 4

CWString API
by Krasimir Angelov 30 Nov '04

30 Nov '04

Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal (wchar_t *) type to String. I found some inconsistencies in the API. - castCWcharToChar and castCharToCWchar functions are defined only for Posix systems and they aren't exported. In the same time castCCharToChar and castCharToCChar have the same meaning and they are defined and exported on all platforms. - CWchar type looks a little bit strange compared to CChar, CString and CWString types. In my opinion CWChar looks more consistent. Since the CWString API isn't released in previous GHC releases I think now is the time to fix that. Any opinions? Cheers, Krasimir __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 4

RE: CWString API
by Simon Marlow 30 Nov '04

30 Nov '04

On 30 November 2004 09:35, John Meacham wrote: > On Tue, Nov 30, 2004 at 12:41:04AM -0800, Krasimir Angelov wrote: >> Hello guys, >> >> I am working on updated version of HDirect and now I >> am going to use CWString API to marshal (wchar_t *) >> type to String. I found some inconsistencies in the API. >> - castCWcharToChar and castCharToCWchar functions >> are defined only for Posix systems and they aren't >> exported. In the same time castCCharToChar and >> castCharToCChar have the same meaning and they are >> defined and exported on all platforms. > > The problem is that these operations are very unsafe, there is no > guarenteed isomorphism or even injection between wchar_ts and Chars. > If people really know what they are doing, they can do the conversion > themselves via fromIntegral/ord/chr, but I don't think we should > encourage such unsafe usage with functions when it is simple for the > user to work around it themselves. That's right - castCWcharToChar and its dual are unlikely to be correct on Windows, where wchar_t is UTF-16. However, AFAICS the whole Windows API works in terms of UTF-16, only dealing with surrogate pairs in the text output routines. So it might sometimes be more convenient and efficient, but not strictly speaking correct, to do no conversion between a UTF-16 value and Haskell's Char in the FFI on Windows. I think we want to provide an interface that lets you do this if you know what you're doing. Cheers, Simon

2 1

RE: -fno-monomorphism-restriction
by Simon Peyton-Jones 29 Nov '04

29 Nov '04

I'm not sure whether you are saying (a) or (b): a) This is a compiler bug; even with -fno-monomorphism-restriction the module should compile. Are you sure? b) this is a feature request: you want a flag -fmonomorphism-restriction to restore the monomorphism restriction even if it's been turned off by an earlier flag? rsvp Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Christian Maeder | Sent: 24 November 2004 13:44 | To: GHC Users Mailing List | Subject: -fno-monomorphism-restriction | | Hi, | | I've a file ATC/Sml_cats.hs that does not compile (see below) with the | flag -fno-monomorphism-restriction (ghc 6.2.2), whereas it compiles fine | without that option. Since I want to use -fno-monomorphism-restriction | for other files (from programatica) I've a problem, because there is no | option -fmonomorphism-restriction that I could place inside of | ATC/Sml_cats.hs. | | If someone wants to reproduce the error, do the following: | 1) check out HetCATS repository with: | cvs -d pserver:cvsread@cvs-agbkb.informatik.uni-bremen.de:/repository co | HetCATS | 2) comment out variable HC_PACKAGE in the Makefile (to avoid dependency | from uni) | 3) add the flag -fno-monomorphism-restriction to the variable HC_FLAGS | 4) call (GNU) make | | Cheers Christian | | Compiling ATC.Sml_cats ( ./ATC/Sml_cats.hs, ./ATC/Sml_cats.o ) | | ./ATC/Sml_cats.hs:23: | Ambiguous type variable `a' in the top-level constraint: | `ATermConvertibleSML a' | arising from use of `ad'' at ./ATC/Sml_cats.hs:2068 | | ./ATC/Sml_cats.hs:23: | Ambiguous type variable `a1' in the top-level constraint: | `ATermConvertibleSML a1' | arising from use of `aa'' at ./ATC/Sml_cats.hs:1501 | | ./ATC/Sml_cats.hs:23: | Ambiguous type variable `a2' in the top-level constraint: | `ATermConvertibleSML a2' | arising from use of `aa'' at ./ATC/Sml_cats.hs:1479 | | ./ATC/Sml_cats.hs:23: | Ambiguous type variable `a3' in the top-level constraint: | `ATermConvertibleSML a3' | arising from use of `las' at ./ATC/Sml_cats.hs:421 | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 4

Re: Bug in compiling large projects ?
by Christian Maeder 26 Nov '04

26 Nov '04

> Use -fallow-incoherent-instances to use the first choice above) This flag should be added to the flag reference list: http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html… Christian

1 0

RE: Bug in touchForeignPtr?
by Simon Marlow 24 Nov '04

24 Nov '04

On 23 November 2004 13:46, Keean Schupke wrote: > Simon Marlow wrote: > >> Note that the GC only starts the finaliser thread. The program can >> still terminate before this thread has run to completion (this is one >> reason why we say that finalisers don't always run before program >> termination). >> >> > This sounds like a bug to me... surely you should wait for all > forked threads to finish before the RTS exits. No, the fact that GHC doesn't wait for all forked threads before terminating is the intended behaviour. If you want anything else, you can implement it. Cheers, Simon

4 4