- Glasgow-haskell-users

Re: Cygwin & GHC
by George Russell 04 Apr '02

04 Apr '02

Simon Peyton Jones wrote: > 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=20 > completely self-contained -- no dependence on cygwin1.dll etc. > This was *huge* step forward: GHC installs and runs with no problem > on Windows now. I agree about it being a huge step forward. I do not think I would be in favour of undoing this and going back to having to install cygwin (in the right version) to get GHC to run. > 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. I am a little but not hugely bothered by (1) and (2), as they can all be worked around in various ways. The real problem is (3), since it means that not just IO events but almost all events from the non-Haskell world cannot be waited on without bringing the Haskell world to a halt. Is it possible to do something about (3) without switching back to Cygwin?

1 0

RE: [nhc-bugs] Cygwin and GHC
by Simon Peyton-Jones 04 Apr '02

04 Apr '02

| Can you comment on how much longer the GHC core team will exist? Indefinitely. Meaning that (a) There is no time limit: Simon and I have permanent posts Reuben and Julian left when the grant ran out; we knew that was coming, but there is no correponding future event known. (b) But (as has been the case for the last 15 yrs) "indefinite" does not mean "forever". One day I'll get old and die. The more people that help look after GHC, the healthier it will be. It's fun, it's rewarding, and it's not as demanding as you might think. There's even a lovely commentary to explain how it works http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ Simon

1 0

Fw: Cygwin and GHC
by Claus Reinke 04 Apr '02

04 Apr '02

[interesting; postfix at haskell.org claims rightly that there is no ghc-users list there. so how did Simon's mail reach me in the first place? well, here we go again] ----- Original Message ----- From: "Claus Reinke" <claus.reinke(a)talk21.com> To: "Simon Peyton-Jones" <simonpj(a)microsoft.com>; <ghc-users(a)haskell.org>; <nhc-bugs(a)haskell.org> Cc: "C.Reinke" <C.Reinke(a)ukc.ac.uk> Sent: Thursday, April 04, 2002 1:45 PM Subject: Re: Cygwin and GHC > >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. > > Some comments from a binary-only GHC user who tends to depend > a lot on cygwin while using windows: > > >This was *huge* step forward: GHC installs and runs with no problem > >on Windows now. > > This *is* a huge step forward, and together with GHCi and HOpenGL, > has even tempted me to use GHC a bit more:-) > > Having to wrestle with two different GHC installations on one platform > would seem a step backward. So, I'd not only agree with one build > only (GHC should be compilable under cygwin, though, for those who > absolutely need to go the other way, or who want to track the CVS > version), I'd like one build to work both in native and in cygwin mode. > As a Haskell user, I'm interested in: > > - a standalone GHC, producing standalone executables and dlls, with > good FFI interfaces to the non-Haskell world > - portability across platforms, with as few code changes or restrictions > as possible > > My approach to keeping windows/unix differences small is mostly based > on cygwin, so I need to be able to use GHC and it's executables under > cygwin, as I would use it under unix, in combination with other (windows/ > cygwin) software. That doesn't mean that GHC-generated executables or > libraries need to be cygwin-dependent, and cygwin is, by design, able to > use windows executables (mixing of libraries is probably another story). > > >1. GHC does not understand cygwin paths in the file names passed > >to it on the command line. > > Making GHC understand cygwin paths makes software more system > dependent, not more portable. And what about the executables produced > by GHC? Most of the cygwin path problems could, in theory, be solved > without changing GHC, but with a lot of accumulated UNIX makefiles, > that can be unpractical. > > As far as I understand, GHC can cope with both relative unix-style and > relative and absolute windows-styles paths, so the remaining problem I > tend to encounter are "absolute" unix-style paths which are really relative > to the cygwin root directory. (I also seem to recall someone mentioning > problems related to GHC passing "normalised" paths to other tools, but > if GHC uses it's own toolchain, that seems unlikely?) > > My suggestion would be a --prefix <path> option, or GHC_PATH_PREFIX > variable for GHC-produced executables (including GHC itself), telling them > that any absolute, unix-style paths are to be interpreted relative to <path> > (e.g., in cygwin makefiles, default installation, HC=ghc --prefix c:/cygwin). > That wouldn't be platform-specific and might also come in handy for other > purposes. > > >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. > > That looks like a real bugger to me as it impacts on portability of Haskell > programs. Going from incomplete posix support to even less posix support > was a step backwards. > > >3. I/O on Win32 is *blocking*. A blocking input operation freezes all > >the other Haskell threads. > > No experience with that one, but in general, establishing consistent I/O > behaviour across platforms would be a very useful asset. > > >Are there any other problems? > > perhaps: > > 4. File I/O on windows differs from I/O in unix (locking of files instead > of implicit maintainance of hidden handles, I think??). cygwin tries to > smooth things over, but fails for more complex cases (open a file for > reading, remove it, open it for writing, copy from read handle to write > handle).We just traced a problem in building nhc on cygwin down to > that one.. How does mingw fare in that respect? Better? Or even worse? > > 5. I assume that GHC and it's executables interface rather well with the > windows world. What about interfacing to software ported from unix > that depends on cygwin, though? > > >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. > > No heuristic, please, just some more flexibility for makefile authors > (/cygwin/c/foo tends to be /cygdrive/c/foo these days, and sometimes > is //c/foo, but c:/foo tends to work as well - do you want to track > cygwin's mount table in GHC?-). > > >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? > > I step back to make space for the volunteers, but mingw being minimalistic, > what are the chances that it's posix support is a suitable alternative to > cygwin's, which isn't complete, either? > > >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. > > As far as I know, cygwin (the *larger* cousin of mingw) is still waiting > for someone to contribute solutions to I/O problems on top of windows.. > > Thanks for raising this issue, > Claus > > PS. > >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 have to admit that I'm a bit concerned about the overall number of > people involved in Haskell implementations. Fortunately, the licenses > are very open, and fortunately, we do have those heroic volunteers, > but the Haskell implementation core team isn't going to be much (if > any) bigger than the GHC core team soon. Given the interests of some > (well, at least one;) companies, and the volunteers working for those, > perhaps they could acknowledge the work done by those volunteers > as being essential for their business? And given the wide-spread use > in academia as a research and teaching platform, does anyone know > of a way of securing some kind of international platform funding, to > keep the current implementations alive and to develop them further > (as an academic complement to Galois' (?) and MS' contributions > in terms of man-power)?] > >

1 0

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