June 2002 - Glasgow-haskell-users

Re: HGL with GHC in Win32
by C.Reinke 24 Jun '02

24 Jun '02

> >> The size problem is traceable to [Greencard's ffi code generation] > I took a look at this and found that Sigbjorn had fixed it some months > ago Would that be in the released Greencard or only in the cvs version? > Building GDITypes with this command: > > green-card --target=ffi -i. --include-dir ../../green-card/lib/ghc -i . GDITypes.gc > generates correct code for prim_RGB (the problem Hal Daume ran into). > and for Win32Window.adjustWindowRect So the Win32 sources could now be regenerated and future builds and releases wouldn't run into these problems with Win32 or HGL anymore? ------------------------------------------------------------------- >>> Just as long as someone remembers to do the re-greencarding <<< ------------------------------------------------------------------- in cvs: hslibs/win32 before the next release, please, because that won't happen automatically anymore (but then I may be wrong about this - I don't understand the fptools Makefiles, yet;-). Great - thanks, Claus PS. I still have to figure out how to make hslibs/win32 in isolation, so I won't be able to test & confirm whether this solves all the HGL/GHC/Win32 problems for a while (e.g., there was the problem of polygon creation running out of resources, see Friday's email; that could easily be related to the same ffi problem, but it would be good to check) - anyone else in a better position for testing?

2 2

Andy Gill's Html library
by Thomas L. Bevan 24 Jun '02

24 Jun '02

Hi, I've been working through the source code of Andy Gill's Html library for my own edification. Andrew makes the following definitions. \begin{code} instance (Show a) => Show (BlockTable a) where showsPrec p = showsTable type TableI a = [[(a,(Int,Int))]] -> [[(a,(Int,Int))]] data BlockTable a = Table (Int -> Int -> TableI a) Int Int \end{code} You can create a (1x1) table entry \begin{code} single :: a -> BlockTable a single a = Table (\ x y z -> [(a,(x+1,y+1))] : z) 1 1 \end{code} Can someone explain the reasoning behind using a function to describe a Table rather than just a list of lists? Tom

1 0

Re: HGL with GHC in Win32
by C.Reinke 24 Jun '02

24 Jun '02

> Thanks for looking at this Claus. no problem - I'm kind of nearby, and I'm not promising anything (unless just looking at it is going to help;-). > > - the full-screen titlebar effect with the SOE variant suggests > > some window-handling incompatibility, if it wasn't for Hugs and GHC > > using the same graphics source code.. (is there a difference in the > > win32 bindings for Hugs vs GHC?) > > [This mail got rather long. My best guess is that yield on GHC > doesn't yield as thoroughly as on Hugs and that the Win32 library > isn't being greencarded with the --safe-code flag. (Either by itself > would probably be fine, it's having both at once that is probably > killing you.)] According to the docs, yield does as yield should, and the unix version (ghc/hgl/X) seems to work.. Btw, while looking at code with scheduling-related issues in mind, other questions appeared to me: Shouldn't all those IORefs (e.g., for the list of windows) be MVars in the GHC version? For a start, what about NoInline pragmas for global IORefs? But, at least on unix, these don't seem to be the problem.. Unless there are any other suggestions, I could give the green card --safe-code a try. But why doesn't the green card input use %safecode to eliminate that potential error source?-) And how would cross-ffi garbage-collection issues affect window parameters at startup? Anyway, is there a useable win32 green card input package hanging around somewhere (the link to glasgow is dead it seems; CVS has moved the gc-sources aside and has never been very modular - is there a way for me to take the win32/gc-src/ directory from CVS and make it, without having to prepare the various other parts of fptools that fptools-Makefiles tend to depend on so merrily?-(. Alternatively, is anyone out there using ghc's win32 binding? Presumably, that kind of problem would show up in other uses. Claus PS. Is there a way to get system call traces on windows/cygwin?

3 6

RE: compiling libraries with ghc
by Simon Marlow 24 Jun '02

24 Jun '02

> hi, i wrote some utilities to make my coding a little easier > and i put them in some libraries. then to use them i made a > package conf file and added it with ghc-pkg -a. i then tried > compiling them with > > ghc -package-name extensions -c Foo.hs > > but i am not sure i am compiling it right as i get linker > errors of the form > > /usr/libexec/elf/ld: cannot find -lDirectoryAndExtensions > > whenever i try to compile a program that uses my libraries. I can't tell exactly what's wrong from this error message - what does your package conf file look like? > i can fix this by copying all the .o files to libFoo.a files. > what is the right way to compile libraries? You should make a lifFoo.a for static linking, and a single Foo.o for use with GHCi. The documentation on packages in the user guide explains how to do this. Cheers, Simon

1 0

compiling libraries with ghc
by Chris Moline 24 Jun '02

24 Jun '02

hi, i wrote some utilities to make my coding a little easier and i put them in some libraries. then to use them i made a package conf file and added it with ghc-pkg -a. i then tried compiling them with ghc -package-name extensions -c Foo.hs but i am not sure i am compiling it right as i get linker errors of the form /usr/libexec/elf/ld: cannot find -lDirectoryAndExtensions whenever i try to compile a program that uses my libraries. i can fix this by copying all the .o files to libFoo.a files. what is the right way to compile libraries? sincerly, chris moline

1 0

HGL with GHC in Win32
by C.Reinke 21 Jun '02

21 Jun '02

S J Thompson <S.J.Thompson(a)ukc.ac.uk> writes: > Can anyone help? I would like to run a program using the Haskell > Graphics Library under GHC on Windows. HGL is listed as a package > (when ghc is asked about its packages) but not actually > distributed > as a package with ghc-5.02.3. On trying to remedy this, > - I am able to compile HGL by hand on windows, but on executing > the HelloWorld.hs the program hangs: nothing happens. > - HGL doesn't appear to compile on unix (solaris). > I'd be grateful for any feedback. As far as I can see, none of the replies so far answered Simon's Win32 question, so I had quick look: - Alastair suggested using a different green card target, but no user green-carding seems needed in the win32 case -- the win32 binding comes with ghc, and the win32 graphics sources don't seem to include green card input (no .gc, .gc.in, only .hs) - using ghc --make, compilation is no (big) problem but graphics-2.0.4.src.tar.gz and SOE.msi's graphics are out of synch - running examples compiled against minimally modified graphics-2.0.4 win32 sources just blocks - running examples compiled against SOE.msi's graphics win32 sources kind of works sometimes (although that may not be obvious), but more often it produces odd effects, not at all in line with the Hugs behaviour for the same sources - the full-screen titlebar effect with the SOE variant suggests some window-handling incompatibility, if it wasn't for Hugs and GHC using the same graphics source code.. (is there a difference in the win32 bindings for Hugs vs GHC?) It seems that others started to look into this some 6 months ago, which is why the SOE version is slightly more successful, but no further progress is recorded in CVS. Has anyone succeeded in removing the remaining quirks? Claus PS. Some more details (win2k/cygwin, if that matters): The file graphics-2.0.4.src.tar.gz from the X11 section at http://haskell.org/graphics/downloading.html includes both x11 and win32 directories, but the win32-branch is out of synch (modifications to get it to compile with ghc on win32 are relatively straightforward, but then the resulting executable just hangs, so there must be some less obvious changes missing). The main Hugs98 download page at http://cvs.haskell.org/Hugs/pages/downloading.htm links to the graphics-bundle, but also provides an SOE bundle (SOE.msi), which includes a graphics bundle (also available separately). Again, the graphics bundle includes both x11 and win32 branches, but in this version, the win32 branch compiles without further changes. The resulting executables produce titlebars (full screen width) instead of windows as default, but double-clicking on the title bars unfolds a (full-screen) window, and some simple examples seem to run more or less okay (often less:-(. Here are two trivial examples: import GraphicsUtils main = runGraphics $ do w <- openWindow "testing" (200,200) drawInWindow w $ text (100,100) "1,2,3" getKey w closeWindow w The window size is ignored (full-screen titlebar effect), and after a keypress, the window closes, but the executable has to be stopped by ctrl-c. With a slight modification, main = runGraphics $ do w <- openWindow "testing" (200,200) drawInWindow w $ text (100,100) "1,2,3" drawInWindow w $ polygon [(50,50),(100,100),(50,100)] getKey w closeWindow w we get: $ a.out Uncaught Error: Polygon: Not enough storage is available to process this command. (error code: 8) Both examples run just fine with Hugs on win32, using the same win32 branch of the same graphics bundle. This may indicate differences in the win32 bindings themselves? The CVS pages (how do I find the latest location of stuff in there, btw? is there a libraries version of HGL?) at http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/graphics/lib/win32… list some changes by Sigbjorn, suggesting that Simon was not the first to run into these problems: "Misc changes to have it *compile* with ghc-5.02.1 (but not exec correctly). Based on patches contrib'ed by Frank Dellaert." PPS. Things are starting to get hard to find. Compiling a list of all locations of various graphics variants on {www,cvs}.haskell.org is left as an exercise.. :-(

2 1

Bus error through optimization on sparc
by Christian Maeder 21 Jun '02

21 Jun '02

> > ghc-5.02.3 -O hello.hs > > a.out > Bus error (core dumped) > 5.02.3 works with gcc 3.0 on x86. I haven't tried Sparc. "-O" (and "-O2") does not work on Sparc. We have ghc-5.02.3 und gcc_3.1 Regards Christian

1 0

Summary so far (was: HOpenGL and --enable-threaded-rts)
by Simon Marlow 20 Jun '02

20 Jun '02

This discussion is getting rather long, so I thought I'd summarise (as much for my benefit as everyone else's). Please let me know if I get anything wrong. It turns out that some C libraries designed to be used from multi-threaded programs make use of thread-local state. This is at odds with GHC's new extension to support using OS threads to multiplex calls to blocking foreign functions - this is the extension we call the "threaded RTS", which is off by default but turned on if you configure GHC with --enable-threaded-rts. The threaded-rts extension is important if you want to call foreign functions that might block - without thread-rts this would block all the other Haskell threads until the blocking foreign call returns. The problems arise because GHC's threaded RTS doesn't make any distinction between OS threads; as far as it is concerned any OS thread is as good as any other. We hadn't considered the use of thread-local state by external C libraries when we designed this (obviously :-{). Ok, so what can we do? 1. Swap the thread-local state in ================================== Wolfgang's proposed fix is to allow the right thread-local state to be swapped in at the right moment, just before running a Haskell thread. I don't think this will work in general, because part of the thread-local state is the thread ID of the OS thread itself, which can't be swapped in. Also, Sven pointed out that swapping in the context in the GLUT case can have other drastic performance implications. 2. Every Haskell thread has its own OS thread ============================================= Some other folk proposed moving to a 1-1 correspondence between Haskell threads and OS threads. I think this is a poor solution simply because of the overhead - Haskell threads are very lightweight (1000s of threads is entirely reasonable), but OS threads tend to be much heavier. For example, I'm sure this would kill the performance of the Haskell web server. 3. Some Haskell threads have their own OS thread ================================================ Another solution is to fix a 1-1 correspondence between Haskell threads and OS threads for some Haskell threads only, perhaps selected by a different version of forkIO. We think this is implementable, has zero overhead if you don't use it, but it does require that the user of the external binding remembers to use the right flavour of forkIO. Callbacks have to create a new Haskell thread which is bound to the current OS thread. Alastair points out that it might be significant which Haskell thread runs a particular finalizer. 4. Thread groups ================ Claus's suggestion is similar, but gives the Haskell programmer more control over the mapping between OS threads and Haskell threads. I must admit I'd been wondering about something similar myself. He suggests that every Haskell thread is bound to a specific OS thread, but that more than one Haskell thread can map to the same OS thread (a thread group). This is slightly less convenient for the Haskell programmer - one has to be careful to fork a new thread group to avoid being blocked by a foreign call. ------------------ We can afford to discuss this a while longer, because Simon & I are currently focussed on the next release (I don't want to hold up 5.04 for a fix, and it wouldn't be a disaster if we had go straight to 5.06 in a couple of months or so). Personally I can't decide whether (3) or (4) is the better solution. I'm pretty sure (1) and (2) aren't viable, though. Cheers, Simon

2 1

RE: when is compilation necessary
by Simon Peyton-Jones 20 Jun '02

20 Jun '02

I assume you mean 'bar' in module Main? | Now, suppose I change Foo.hs so that "foo x = x + 2". If I | ghc --make on | Main, it will build Foo, then Bar, then Main, then link. Is | all of this necessary or can I (manually) just rebuild Foo | and then relink? Necessary with -O (because the defn of foo may be inlined in Bar). Not necessary without -O. GHC takes a look at Bar, in case foo's type has changed, but the "skipping" message says that it decided that nothing had changed. cam-02-unx:~/tmp$ ghc --make Main ghc-5.02.3: chasing modules from: Main Compiling A ( A.hs, A.o ) Skipping B ( B.hs, B.o ) Skipping Main ( Main.hs, ./Main.o ) ghc: linking ... Simon | suppose i have three modules: | | > module Foo(foo) where | > foo x = x + 1 | | > module Bar(bar) where | > import Foo | > bar x = foo (x+1) | | > module Main(main) where | > import Bar | > main = print (foo 5) | | Now, suppose I change Foo.hs so that "foo x = x + 2". If I | ghc --make on | Main, it will build Foo, then Bar, then Main, then link. Is | all of this necessary or can I (manually) just rebuild Foo | and then relink? | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

RE: Status of GHC with gcc 3.x ?
by Simon Marlow 20 Jun '02

20 Jun '02

> What is the status of GHC with gcc 3.x (on Sun)? 5.02.3 works with gcc 3.0 on x86. I haven't tried Sparc. The current CVS works with gcc 3.1 on x86, but I have some slight worries about some strange code I've seen that version of gcc generate. Also, I haven't tried on Sparc. My advice: stick with 2.95 for the time being. I'll try to test with other versions of gcc on Sparc before the next release. Cheers, Simon

1 0