April 2002 - Glasgow-haskell-users

Cygwin and GHC
by Simon Peyton-Jones 04 Apr '02

04 Apr '02

Folks, There's been some mail recently about GHC and Cygwin, some of it on the nhc-bugs list (hence ccing this there). I'm a bit confused so this message is to try to clarify the situation. The GHC core team is now down to Simon M and me. Sigbjorn heroically helps out on Win32 stuff, but it isn't his job. So we have strictly limited effort available. I am therefore deeply reluctant to provide both GHC-for-mingw32 and GHC-for-cygwin. One build on Win32 is enough! We ended up with a mingw32 basis because it meant we could make GHC completely self-contained -- no dependence on cygwin1.dll etc. This was *huge* step forward: GHC installs and runs with no problem on Windows now. Therefore I ask: can someone summarise succinctly what the problems with GHC-for-mingw32 are? The ones I know about are these: 1. GHC does not understand cygwin paths in the file names passed to it on the command line. 2. GHC on Win32 does not come with a Posix library. If we used a Cygwin basis, Posix would be easy because cygwin does all the hard work. 3. I/O on Win32 is *blocking*. A blocking input operation freezes all the other Haskell threads. Are there any other problems? My own ill-informed thoughts on these are: 1. GHC already fudges filenames to take account of the Win32/Unix conventions. We could add more fudges, to change /cygwin/c/foo to c:\foo, for example. Perhaps controlled by a -cygwin flag to tell GHC-for-win32 whether to use cygwin fudges or not. Heuristic, yes; but might solve the problem for 99% of customers. 2. Mingw32 provides quite a lot of Posix, so if someone was prepared to put in a bit of work we could get a good part of the Posix library available on Win32, still via mingw. Any volunteers? 3. Non-blocking I/O is a soluble problem: Win32 provides suitable primitives. But they are different to the Unix primitives, so there is work to do in the runtime system to make it work. This is harder for a volunteer to do because it's in the runtime system, but not impossible. Any thoughts? Ideas are much more likely to be implemented if they are either easy, or you can help do the job! Simon

1 0

RE: GHC Dynamic Loading
by Simon Marlow 04 Apr '02

04 Apr '02

> I am trying to dynamically load a shared haskell module - and > it almost > works... however as > soon as the grabage collector thread runs it frees/moves > something and the > program falls over. > Presumably this means I need to use a StablePtr - however I > have as yet been > unable to work out > what exactly is the cause. I was hoping somebody with some > knowledge of th > einternals of GHC could > help me out... What you're doing really isn't supported, I'm afraid. The particular problem I believe you're running into is that the garbage collector doesn't know about the module you loaded so it can't distinguish pointers to static data in that module from heap pointers. You *can* achieve something like this using GHCi's dynamic linker (which is available in the RTS from any program). The interface is quite straightforward, see ghc/rts/Linker.h. You can load .o files of Haskell code, or shared libraries of C code (*not* Haskell code) using this mechanism. Cheers, Simon

1 0

GHC Dynamic Loading
by Keean 04 Apr '02

04 Apr '02

I am trying to dynamically load a shared haskell module - and it almost works... however as soon as the grabage collector thread runs it frees/moves something and the program falls over. Presumably this means I need to use a StablePtr - however I have as yet been unable to work out what exactly is the cause. I was hoping somebody with some knowledge of th einternals of GHC could help me out... The summary of what happens is: using FFI to call libdl on linux: - load module using dlopen (the library is compiled with -optl -shared and the loader is compiled with -rdynamic, so after loading all static symbols should be resolved.) - using dlsym to get a FunPtr to a module initialiser. - passing a StablePtr to a (FiniteMap String (SomeFunction)) as well as a dynamically exported continuation function (ie a "main-loop") which takes the FiniteMap as an argument to the initialiser. (now in the loaded module) - de-reference FiniteMap StablePtr, and add a handler function and string-identifier using addToFM, then create a newStablePtr to the modified FiniteMap and call the dynamic imported main-loop fn with FiniteMap as argument. - main loop calls back to module at a later time - dependant on string identifier. when I run this with +RTS -B it successfully loads, links and calls back 3 or 4 times, then goes 'beep' and dies - I think in the garbage collector thread itself, or as soon as the GC finishes. Any info that would shed light on what is happening would be useful. Regards, Keean Schupke.

1 0

RE: fast IO in ghc
by Jan-Willem Maessen 04 Apr '02

04 Apr '02

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > And, with a lot of help from Koen, I'm about to fold in a > much more efficient implementation of Read, which may help. Any of the guilty parties want to give a quick overview of how it's going to work? -Jan-Willem Maessen

2 1

RE: installing ghc on Solaris without gcc
by Simon Marlow 03 Apr '02

03 Apr '02

> after having used ghc on linux and win32 for quite a while now > I am stuck with installing the binary distribution on Solaris. > > The Solaris machine does not have a gcc installed. This is correctly > detected by ./configure. You really need gcc, sorry. I don't know what might have caused the link errors you saw, but it may be an artifact of doing linking through Solaris's cc rather gcc (actually I'm surprised it got that far). Cheers, Simon

1 0

installing ghc on Solaris without gcc
by Sven Eric Panitz 03 Apr '02

03 Apr '02

after having used ghc on linux and win32 for quite a while now I am stuck with installing the binary distribution on Solaris. The Solaris machine does not have a gcc installed. This is correctly detected by ./configure. However the eventually installed ghc still calls gcc instead of just cc. Eventually I made a symbolic link ln -s cc gcc just to see if this might work. Unfortunately this gives linker errors: bash-2.04$ ghc Main.hs compilation IS NOT required Undefined first referenced symbol in file PrelIOBase_heapOverflow_closure (command line) PrelInt_I16zh_static_info (command line) PrelPack_unpackCString_closure /usr/local/lib/ghc-5.02.2/libHSrts.a(RtsAPI.o) PrelFloat_Dzh_con_info /usr/local/lib/ghc-5.02.2/libHSrts.a(RtsAPI.o) PrelWord_W64zh_con_info /usr/local/lib/ghc-5.02.2/libHSrts.a(RtsAPI.o) PrelStable_StablePtr_static_info /usr/local/lib/ghc-5.02.2/libHSrts.a(RtsAPI.o) ... Is ghc supposed to work with cc instead of gcc? If this is so, what am I doing wrongly? thanks Sven Eric

1 0

fast IO in ghc
by Hal Daume III 03 Apr '02

03 Apr '02

I tend to deal a lot with very very large data files in Haskell and my current approach to dealing with getting data out of one program an into another is writing it to a file using 'show' and then reading it in using 'read'. Unfortunately, this is very slow and produces very large files which are very slow to read and write. Is there another option? I don't care about H98 compatibility, so if there's a way to somehow just dump ghc's internal representation (I also don't care about x-platformness) to a file and read it back, that would be excellent. Other suggestions are welcome too :). -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

RE: fast IO in ghc
by Simon Peyton-Jones 03 Apr '02

03 Apr '02

And, with a lot of help from Koen, I'm about to fold in a much more efficient implementation of Read, which may help. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 03 April 2002 05:36 | To: GHC Users Mailing List | Subject: fast IO in ghc | | | I tend to deal a lot with very very large data files in | Haskell and my current approach to dealing with getting data | out of one program an into another is writing it to a file | using 'show' and then reading it in using 'read'. | Unfortunately, this is very slow and produces very large | files which are very slow to read and write. Is there | another option? I don't care about H98 compatibility, so if | there's a way to somehow just dump ghc's internal | representation (I also don't care about x-platformness) to a | file and read it back, that would be excellent. Other | suggestions are welcome too :). | | -- | 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 |

1 0

RE: fast IO in ghc
by Simon Marlow 03 Apr '02

03 Apr '02

> I tend to deal a lot with very very large data files in Haskell and my > current approach to dealing with getting data out of one > program an into > another is writing it to a file using 'show' and then reading > it in using > 'read'. Unfortunately, this is very slow and produces very > large files > which are very slow to read and write. Is there another > option? I don't > care about H98 compatibility, so if there's a way to somehow just dump > ghc's internal representation (I also don't care about > x-platformness) to > a file and read it back, that would be excellent. Other > suggestions are > welcome too :). I wrote a binary I/O library recently for GHC, which we're using to speed up interface file reading and writing. The library is similar to nhc98's Binary library, execept that it works in terms of bytes rather than bits, and we don't do lazy binary I/O in the same way. It currently has some GHC-specific stuff in it, but I plan to make a generic version for the libraries at some point. For the time being, you can pull it out of CVS and take a look - it's in ghc/utils/Binary.hs. It should work if you remove the GHC-specific bits. Cheers, Simon

1 0

Haskell/Erlang Research Position
by Phil Trinder 03 Apr '02

03 Apr '02

Research Associate in Haskell/Erlang for Distributed Telecommunications �17,278-�26,229 p.a. Applications are invited for a three year Research Associate position at Heriot-Watt University to work with Dr Phil Trinder on an EPSRC funded project entitled "High-Level Techniques for Distributed Telecommunications Software". The project is a collaboration with Motorola UK Research Labs and aims to evaluate high-level distributed programming techniques for constructing realistic telecommunications software. Applications are welcomed from candidates with a doctorate or a very good first degree in Computing or cognate discipline; a successful candidate without a PhD will have the opportunity of registering for one. Applicants should have good written and verbal communication skills and be able to demonstrate a strong programming ability: experience with distribution and the Haskell or Erlang programming languages is desirable. Likewise a research background, and familiarity with the telecommunications sector are desirable. For application details please contact the Personnel Office, Heriot-Watt University, Edinburgh, EH14 4AS, tel/fax: 0131 451 3475 (24 hours) quoting Ref 66/02/J. The closing date is Friday 19th April 2002. Informal enquires can be directed to Phil Trinder tel: +44 131 451 3435, or e-mail: trinder(a)cee.hw.ac.uk. More details of the project and further particulars for the position can be found at: http://www.cee.hw.ac.uk/~dsg/telecoms/

1 0