May 2004 - Glasgow-haskell-users

RE: wanted: tester for libraries/Win32
by Mike Thomas 05 May '04

05 May '04

Hi Ross. I CVS updated libraries/Win32 and libraries/HGL in a HEAD fptools build tree from a few weeks ago then "make boot" and "make" in each followed by "make" in the HGL examples directory. I hadn't realised that the hsc binding existed. All built but running was a bit sad: gtest - crashes hello-world - flashes initial white then changes to black background window, window title shows only 'H', crashes when close icon hit. tests - crashes Will do a complete update/rebuild tonight and let you know what happens in case that is the cause. Sorry for the delay and thanks for the good work. Cheers Mike Thomas. | -----Original Message----- | From: Mike Thomas [mailto:mike.thomas@brisbane.paradigmgeo.com] | Sent: Friday, 30 April 2004 8:19 AM | To: Ross Paterson | Subject: RE: wanted: tester for libraries/Win32 | | | Hi Ross. | | I'm catching up on email and still busy with things other than | GHC, but did you get help with this? | | If not, let me know and I'll try and do something over the next week. | | Cheers | | Mike Thomas. | | | -----Original Message----- | | From: glasgow-haskell-users-bounces(a)haskell.org | | [mailto:glasgow-haskell-users-bounces@haskell.org]On Behalf Of Ross | | Paterson | | Sent: Thursday, 29 April 2004 7:59 AM | | To: glasgow-haskell-users(a)haskell.org | | Subject: wanted: tester for libraries/Win32 | | | | | | Would someone who's building from CVS under Windows like to try make | | in libraries/Win32, libraries/HGL and libraries/HGL/examples, and | | even run the programs in the latter directory (should they happen | | to compile)? | | _______________________________________________ | | Glasgow-haskell-users mailing list | | Glasgow-haskell-users(a)haskell.org | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | |

1 0

RE: Integrating ghc's rts into other single-threaded frameworks
by Simon Peyton-Jones 05 May '04

05 May '04

| I'm thinking about how to make threaded Haskell program work nicely with | Gtk+ (the widget toolkit) and whether the new threaded rts will help or | not. | ... | | Would bound threads help? I'm not sure I understand the idea very well. That's *exactly* what the bound-threads idea is for. It's implemented in GHC 6.2.1 (see the bound-thread operations in Control.Concurrent). There is a more detailed writeup about bound threads that I think we neglected to complete and publish. Wolfgang Thaller is the main author, and I hope he may pick this up. Meanwhile we'll put the current draft on the GHC site. Simon

3 2

Re: [HOpenGL] GHC 6.2.1 Binding Completeness
by Sven Panne 05 May '04

05 May '04

[ I'm cross-posting this, perhaps some kind soul has binary snapshots available. ] Yann Morvan wrote: > [...] I recently installed the last version of GHC (6.2.1) that comes > with the new OpenGL binding. I was just starting to port my code to it, > but I have trouble finding some basic functionnalities (like glTexImage2D for > instance). Is that binding incomplete ? Alas, no, the OpenGL binding on the release branch is not complete. > If yes when will it be finished ? If no when will the redbook examples be ported to it ? The story is quite a bit different on the main branch, the binding is almost finished there, you get OpenGL 1.5 plus a few dozen extensions. The only missing bit is currently NURBS, but it's already halfway there. We generally don't merge new features onto the release branch, only bug fixes, hence the difference. Currently there are "official" releases including this, but if you can tell a bit about your intended platform, perhaps somebody else on the GHC/Hugs mailing lists can help (Linux, WinDoze, MacOS X and Solaris reportedly work). I can offer bleeding edge snapshots of Hugs and GHC including the latest and greatest OpenGL/GLUT binding compiled for x86 Linux (SuSE 9.1, don't know if the RPMs work on other platforms). Another option is building GHC and/or Hugs from CVS for yourself, which is not that hard nowadays (at least if you have enough GB and GHz :-), see: http://haskell.org/ghc/docs/latest/html/building/building-guide.html > I am reduced to greping the code of the binding for calls to the C openGL > functions and suspect that I am missing things. Thanks to Haddock, there is no need for grep-ing. I keep the docs on http://haskell.org/HOpenGL/newAPI/ fairly actual, and the GHC packages include similar documentation. Cheers, S.

1 0

RE: GHC 6.2.1 compilation fails when compiling FFI code with -prof or -O2
by Simon Marlow 05 May '04

05 May '04

On 21 April 2004 13:49, Bayley, Alistair wrote: > Sorry for the stupidity... just found the -I<dir> option... > > Although it is a bit frustrating when an FFI program that used to > compile stops when you add supposedly "harmless" options such as -O > or -prof. Might be worth adding a section to the FFI section of the > manual about using the -I<dir> flag when compiling via C, as -I<dir> > is not needed when you compile with native code generation. And a > mention in the FFI section that -prof and -O will change the > compilation strategy from native to via-C (thus possibly requiring > the addition of the -I<dir> flag) would be nice, although I realise > that's duplicating information available elsewhere. I've updated the docs and added a FAQ entry along these lines. Cheers, Simon

1 0

RE: ghc-pkg can't build GHCi libs in Windows Command Prompt
by Simon Marlow 05 May '04

05 May '04

On 04 May 2004 19:54, Krasimir Angelov wrote: > In the current implementation of the ghc-pkg util > it is impossible to build GHCi libs if you don't have > ld in the current search path. Under Windows the > compiler usually comes with its own linker > (ghc-lib/ld.exe). Why doesn't ghc-pkg use the own > linker? If there isn't any reason not to do that I > would like to apply the patch: > > 374a375,379 >> #ifdef mingw32_HOST_OS >> execDir <- getExecDir "/bin/ghc-pkg.exe" >> system (maybe "" (++"/gcc-lib/") execDir++"ld -r -x -o " ++ >> ghci_lib_file ++ > >> " --whole-archive " ++ batch_lib_file) >> #else > 376a382 >> #endif Please go ahead and apply this patch. Cheers, Simon

1 0

RE: Dynamic loading problem
by Simon Marlow 05 May '04

05 May '04

On 30 April 2004 18:01, Duncan Coutts wrote: > On Fri, 2004-04-30 at 17:36, Simon Marlow wrote: >> 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? > >> 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). > > Details would be interesting. I can't guarantee that everything in here is correct, but here are the notes I made last time I looked into the problem: http://www.haskell.org/~simonmar/shared-libs if anyone has any further thoughts I'd be glad to collect them into a document. >> 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. > > Does that involve changing what reference get linked to which symbols > or would it be a matter of finding a bunch of symbols & calling them > after doing a dlopen() ? Another way of asking the same thing is can > the calling newDynCAF be done in a separate phase (ie after dlopen()) > or is it intimately part of the linking process? It is done when a CAF is entered for the first time, so it would be difficult to do at link time. The real problem is that the garbage collector has no idea which CAFs are still reachable in dynamically linked code. For GHCi, we retain *all* CAFs in dynamically linked code for this reason. This is done by arranging that all dynamically loaded CAFs get placed on a list when they are first entered - this is what newDynCAF() does. If you load code using GHC's linker then this is the behaviour you get. A workaround for the problem, if you're not using GHC's linker, is to make StablePtrs for each of the functions you're going to call in the dynamically loaded code. This will ensure that the GC retains all CAFs reachable from those functions. Perhaps the dynamic linking library should do this? Cheers, Simon

1 0

RE: Windows & ghc6.04
by Simon Marlow 05 May '04

05 May '04

On 05 May 2004 07:20, George Russell wrote: > What I mean is a Windows version of Simon M's: > > > http://www.haskell.org//pipermail/libraries/attachments/20040317/609414e 2/Process-0001.obj > > or alternatively > > http://tinyurl.com/2yx2g > > I'm glad that (1) (world not stopping on IO) and (3) (networking) are > already > present in 6.2.x though, since it increases the chance of a uniform > interface > to processes working on Windows. Is there any chance of this in 6.4? I'm planning to implement the prototype System.Process for Windows too, using Ross's new port of the Win32 library. If I get around to it, it'll be in 6.4 (but not in any future 6.2.x releases). Cheers, Simon

1 0

Windows & ghc6.04
by George Russell 05 May '04

05 May '04

Is there any chance that GHC 6.04, or any GHC version in the next few months, will support the following on Windows: 1) use of native threads so that the world won't be stopped every time you wait for a character; 2) the new system-independent runProcess interface; 3) Network.Socket. (Maybe it does already?) I have a feeling the answer will be "Yes, if you implement it", but sadly my time is limited ...

3 3

ghc-pkg can't build GHCi libs in Windows Command Prompt
by Krasimir Angelov 04 May '04

04 May '04

In the current implementation of the ghc-pkg util it is impossible to build GHCi libs if you don't have ld in the current search path. Under Windows the compiler usually comes with its own linker (ghc-lib/ld.exe). Why doesn't ghc-pkg use the own linker? If there isn't any reason not to do that I would like to apply the patch: 374a375,379 > #ifdef mingw32_HOST_OS > execDir <- getExecDir "/bin/ghc-pkg.exe" > system (maybe "" (++"/gcc-lib/") execDir++"ld -r -x -o " ++ ghci_lib_file ++ > " --whole-archive " ++ batch_lib_file) > #else 376a382 > #endif Cheers, Krasimir __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

Integrating ghc's rts into other single-threaded frameworks
by Duncan Coutts 03 May '04

03 May '04

All, I'm thinking about how to make threaded Haskell program work nicely with Gtk+ (the widget toolkit) and whether the new threaded rts will help or not. Graphics toolkits (X windows or win32 GDI) typically have pretty strict requirements on threads. While it is possible to make use of multiple OS/kernel threads, the locking issues are non-trivial and it is generally not encouraged. It is probably best to consider them as single threaded libraries. So while my initial thought was to make a blocking call to Gtk's main loop in another OS thread using the threadsafe atribute so that it runs in a separate thread, I now think this is not the best approach. The problem is that calls to Gtk functions in other Haskell threads will be made in a different OS thread from the one running the Gtk main loop. Would bound threads help? I'm not sure I understand the idea very well. (It is possible to set up a polling system where gtk periodically calls back to Haskell land and we call ghc's yield function. As you might expect, this works but performs poorly and consumes cpu time when idle.) So a better approach might be to try and integrate the main loops of gtk+ and the ghc rts. Gtk provides a fairly flexible API for controlling it's main loop. You can either run it as a single blocking function or run a single iteration at a time or even split up each iteration into phases. So the question is which main loop gets to block? Unfortunately, neither can do so unless it knows the full set of file descriptors and timeouts of both main loops. So the question is which would be easier? The glib main loop could act as the master main loop since there are functions for registering callbacks for fds and timeouts. At the moment, I don't believe there is any way to ask the ghc rts what fds & timeouts it is interested in. The glib main loop is designed so that it can integrate into an external main loop (though no doubt with some difficulty). See: http://www.gtk.org/~otaylor/gtk/2.0/main-loop.html also an older message http://mail.gnome.org/archives/gtk-devel-list/1999-March/msg00145.html The glib main loop can be split up into phases (prepare, query, check, dispatch), see: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#m… It's not clear to me how one would use that to integrate two main loops, but perhaps it's clearer to the ghc rts gurus. There is also a function for changing the 'poll' function that the glib main loop uses. This might be another way to allow the ghc rts main loop to be the master one. I'd guess that it would be easier to expose some rts function that tells us what fds & timeouts ghc's rts is interested in at any particular time and write some glue code (in C) to install ghc's rts events sources in an external main loop. What would such an API look like? Presumably we'd need to know if there are runnable Haskell threads and we'd need to be able to run them for one timeslice. If there were no runnable threads, we'd want to know the set of fds & timeouts that the rts would want to block upon. [sorry, this next bit is a bit implementation specific] http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#G… To create a GSource from this we would need to implement a prepare, check & dispatch to fill out a GSourceFuncs struct. In prepare we'd check to see if there are currently any runnable Haskell threads (returning true if there were). It would also set up the set of fds to be polled. It would also return the timeout of the soonest timeout that the ghc rts has (or -1). In check we'd return true if any fds were ready or a timeout had expired. In dispatch we'd ask the ghc rts to run for one timeslice. Any simpler / better ideas anyone? Duncan

1 0