- Glasgow-haskell-users

RE: .hi-boot abuse
by Simon Marlow 08 Jan '04

08 Jan '04

> I have a question which came up as a result of some attempts > to enforce > seperate compilation. Suppose we have two modules as follows: > > ------ A.hs -------- > module A (AbstractType) where > > data AbstractType = it's hidden implementation > > f :: AbstractType -> String > f _ = "foo" > > g :: AbstractType > g = something > > ------ B.hs --------- > module B where > import A > > s = f g > > > Now, I want to be able to Compile A, Compile B, change the > implementation of AbstractType in A, recompile A, and then not have to > recompile B. Unfortunately, this doesn't seem to happen in > GHC 6.0.1, as > the representation of AbstractType is placed in A.hi, so when the > representation changes, it forces a recompilation of B. Good point. Following some changes made by Simon P.J. recently, GHC will in the future not put the representation of an abstract type in the interface file when not optimising. This change will appear in 6.4. Your .hi-boot trick looks like it *might* be ok, but no guarantees! Cheers, Simon

1 0

Announce: GHC 6.2 for Mac OS X Jaguar and Panther
by Gregory Wright 07 Jan '04

07 Jan '04

Hello, A port of ghc-6.2 for Mac OS X (both Jaguar and Panther) is available from the darwinports system. Information on obtaining darwinports is available from http://darwinports.opendarwin.org. Once darwinports is installed, building ghc is done by changing to the lang/ghc directory and issuing the command: sudo port install ghc will be built from source and by default is installed in /opt/local/bin, although the user may specify another installation directory. This release supports building with HOpenGL support. It is not included by default, but may be specified by the command: sudo port install +opengl Note that as the system is built from source it may take several hours for the 'port install' command to finish. (On an 800 MHz G4 powerbook it takes about four and a half hours.) ghc from darwinports may be helpful for those still using Jaguar and are having difficulty with Wolfgang Thaller's binary distribution for Panther. Or you may just like building from source, like me. Best Wishes, Greg Wright Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 gwright(a)antiope.com

1 0

GHC 6.2, -main-is option under Windows, not working?
by Graham Klyne 07 Jan '04

07 Jan '04

I'm trying to use the new GHC -main-is flag to compile programs under Windows from source files with module names other than Main, but it doesn't seem to be working. Details of my problem are at: http://haskell.org/pipermail/haskell/2004-January/013332.html Is it a bug, or something I'm overlooking? Does anyone have any clues? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Running a "final" finaliser
by Simon Marlow 07 Jan '04

07 Jan '04

> Hmm, further experiments with creating zillions of garbage > ForeignPtrs (not just 1) reveals that the problem only occurs > if *no* garbage collection has occured before the program shuts > down. In other words, as long as at least one garbage collection > has occured, it doesn't matter if library shutdown occurs immediately > in response to killLibRef or if it's deferred until the reference > count hits zero as a result of finalisers being called. (This test > is without the explicit performGC of course.) > > So (hoping I will not have to eat my words:-) I'm begining to suspect > this is a buglet in the ghc rts somewhere. It may be a bug; I can't see anything obviously wrong in your code. The best way to proceed is for you to send us a complete test case which is producing the (claimed) incorrect output, and we'll look into it. Cheers, Simon

2 1

Compiling HOpenGL Examples with GHC 6.2 Mac OS
by HNBeck＠t-online.de 06 Jan '04

06 Jan '04

Hi, as far as I understand now, for my compiliing problem (see last past with same subject) I must do ghc -package OpenGL -package GLUT --make Cube.hs and in the code doing import OpenGL import GLUT Right so far ? But it seems that the package description in the GHC 6.2 distribution is not right for this packages (OpenGL and GLUT), for both the directory $(InstallDir)/Graphics/Rendering and $(InstallDir)/Graphics/UI is used .....??? Greetings Hans

1 0

RE: "Fail: unknown exception"
by Simon Marlow 06 Jan '04

06 Jan '04

> This has to be one of the most irritating ways a program can > fall over. > Can't the Haskell RTS try just a /little/ harder to help the poor > programmer? For example by saying what sort of exception it is, and > (if it's a dynamic exception) what type it has? An "unknown exception" is a dynamic exception. GHC just uses the ordinary instance of Show on Exception to print out the value of an exception, and it so happens that all it prints out for a dynamic exception is "unknown exception". Arguably the show instance should print out the type too. It could; I just looked into it and unfortunately there's an annoying module loop in the libraries which means doing this would entail some restructuring. Why can't GHCi just print out the type itself? Because it has to be done in the context of the interpreted program, which means GHCi would have to compile a little snippet of code to show the exception. Annoying, but doable. Cheers, Simon

2 1

Compiling HOpenGL Examples with GHC 6.2 Mac OS
by HNBeck＠t-online.de 06 Jan '04

06 Jan '04

Hi, I'm a Haskell newbee and try to compile the HOpenGL Examples with GHC 6.2 Mac OS X with it's build in openGL stuff, by giving ghc --make Cube.hs the answer is :"not find module GLUT and GL", which is understandable because in the Cube.hs there is the code import GL import GLU But how to say ghc what he needs ? Is it -addpackage or -l option (in other words "import" is the same as include in C?) ? BTW: In the HOpenGL distribution, in the directory lib there is a file GL.hs and GLUT.hs which I think are the files needed for teh example above. But I don't found these files in the new GHC 6.2 distribution, is that correct ? Thanks for your help. Greetings Hans

1 0

RE: Running a "final" finaliser
by Simon Marlow 06 Jan '04

06 Jan '04

> The other thing that strikes me about this is don't we also have > the same potential problem with weak pointer finalisers? Can they > be supported in Haskell without pre-emptive concurrency? Weak pointers are a GHC-only extension too, at the moment. They require some careful GC algorithms as well as support for Haskell finalisers. GHC uses weak pointers to implement ForeignPtr internally. Cheers, Simon

1 0

threadDelay problem
by Adrian Hey 06 Jan '04

06 Jan '04

Hello, Whilst experimenting with concurrency and a library which expects me to use the usual event loop I wrote some test code like this.. main :: IO () main = do forkIO forked loop -- Main Loop loop :: IO () loop = do maybeEvent <- pollEvent -- non-blocking case maybeEvent of Just event -> do dispatch event loop Nothing -> do threadDelay 10000 -- 10000 uS = 10 mS loop -- Concurrent thread for test purposes forked :: IO () forked = do threadDelay 1000000 -- 1000000 uS (= 1 S) putStrLn "Hello" forked The idea is to stop a Haskell prog with no runable threads or events to process hogging CPU time. I was a bit dissapointed to find that despite this on my (otherwise idle) machine the above code was still using 96% of cpu time. But fiddling about a bit I found that by changing the thread delay in the main loop to 20 mS the CPU usage dropped to 1% or so, which is much more acceptable (well it did say 1/50 th second accuracy in the docs :-). So this all seems OK, but I wonder if this is a reliable solution on all platforms ghc is ported to (given the the consequence of getting this wrong can be a very greedy program). Is the 20 mS resolution figure a function of ghc only? Or might it depend on other factors too (like OS). Or might it change with ghc version? I think it would nice to have some reliable way to ensure that in reality the thread delay will be as small as possible, but always greater than zero. Maybe a threadDelayResolution constant could be provided? Also, assuming that currently the (hypothetical) threadDelayResolution is 20000 and that in reality the actual threadDelay is N*20000 where N is an integer, I think the docs for threadDelay should specify how N is calculated from the argument of threadDelay. At the moment chosing a thread delay of 19999 sends my CPU usage right back up to 96%, though whether that's as specified or merely a property of ghc 6.2 under Redhat 9 seems a little ambiguous :-) BTW, the docs for Control.Concurrent mention something about an -i<n> RTS option, but I can't find any info on this in the user guide. When I try it I get an error, listing all RTS options. There's no -i listed but there is something that looks related, a -C option, but this doesn't appear in the ghc user guide either :-( Regards -- Adrian Hey

1 0

RE: Running a "final" finaliser
by Simon Marlow 06 Jan '04

06 Jan '04

> The other complication I can see is that ForeignPtr finalisers can't > be Haskell. So I have to call the Haskell finalisation from C. > Is that safe? I'm afraid I still don't fully understand why Haskell > finalisers are unsafe or why (if) calling Haskell from a C finaliser > (which then called C land again) would be any safer. If you don't mind your code being non-portable, then Foreign.Concurrent provides Haskell finalisers. This support will be available only on Haskell implementations which implement pre-emptive concurrency (i.e. just GHC for now). Cheers, Simon

3 3