Re: Windows ghc6.04
Sigbjorn Finne wrote: Not sure what 2) refers to, but 1) and 3) is already in 6.2.x; no need to use the heavier-weight -threaded stuff to enable it. What I mean is a Windows version of Simon M's: http://www.haskell.org//pipermail/libraries/attachments/20040317/609414e2/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? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Integrating ghc's rts into other single-threaded frameworks
| 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Windows ghc6.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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Dynamic loading problem
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-pkg can't build GHCi libs in Windows Command Prompt
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.2.1 compilation fails when compiling FFI code with -prof or -O2
On 21 April 2004 13:49, Bayley, Alistair wrote: Sorry for the stupidity... just found the -Idir 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 -Idir flag when compiling via C, as -Idir 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 -Idir 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Integrating ghc's rts into other single-threaded frameworks
On Wed, 2004-05-05 at 14:55, Simon Peyton-Jones wrote: | 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. So here's what I don't understand: we make a non-blocking call to gtk+'s main loop (which makes a blocking call in a new OS thread). So we get callbacks from gtk in this other thread, which is fine. However if we launch any other Haskell threads that want to update the GUI in any way they need to make calls in the GUI OS thread. But the GUI OS thread is not in Haskell land at this point, it's blocked in a call to the gtk+ main loop. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating ghc's rts into other single-threaded frameworks
So here's what I don't understand: we make a non-blocking call to gtk+'s main loop So far, so good. (which makes a blocking call in a new OS thread). With (the current version of) GHC's threaded RTS, there's only one OS thread involved until you spawn a second thread (with forkIO or forkOS). So we get callbacks from gtk in this other thread, which is fine. I'd expect you to get the callbacks in the same thread as the call-out, that is in your main thread (the same thread that was used to run the main action). However if we launch any other Haskell threads that want to update the GUI in any way they need to make calls in the GUI OS thread. But the GUI OS thread is not in Haskell land at this point, it's blocked in a call to the gtk+ main loop. Correct. GTK will need to help you a bit here for this to work. Many GUI toolkits offer a post event to main event loop function that may be called from any thread, at any time. You could use that to send a StablePtr (IO ()) to the GUI thread. You could also use a pipe to send that StablePtr to the GUI thread (I'm sure you can make GTK's event loop wait until a file descriptor is readable). I don't think that this machinery should take more than ten or twenty lines of code to implement. The absolute worst-case scenario involves registering a timer callback with GTK and regularily polling a Chan (IO ())... Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: wanted: tester for libraries/Win32
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:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED] Behalf Of Ross | | Paterson | | Sent: Thursday, 29 April 2004 7:59 AM | | To: [EMAIL PROTECTED] | | 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 | | [EMAIL PROTECTED] | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [HOpenGL] GHC 6.2.1 Binding Completeness
[ 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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
