RE: GHC Dynamic Loading
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Cygwin and GHC
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fw: Cygwin and GHC
[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 [EMAIL PROTECTED] To: Simon Peyton-Jones [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: C.Reinke [EMAIL PROTECTED] 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
RE: [nhc-bugs] Cygwin and GHC
| 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin GHC
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? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
explicitly quantified classes in functions
Why can I not define the following (in ghc): class Foo p where instance Foo Double where foo :: Double - (forall q . Foo q = q) foo p = p From my humble (lack of) knowledge, there seems to be nothing wrong here, but ghc (5.03) complains about unifying q with Double. I *can* write: class Foo p where instance Foo Double where data T = forall q . Foo q = T q foo :: Double - T foo p = T p which is very similar, except that the explicit universal quantification is happening in in the datatype and not the function type. why is the former disallowed? -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicitly quantified classes in functions
On Thu, Apr 04, 2002, Hal Daume III wrote: Why can I not define the following (in ghc): class Foo p where instance Foo Double where foo :: Double - (forall q . Foo q = q) foo p = p From my humble (lack of) knowledge, there seems to be nothing wrong here, but ghc (5.03) complains about unifying q with Double. I *can* write: I believe that ghc translates the signature above to foo :: forall q . Foo q = Double - q (I don't understand why GHC does this... it seems to have more potential for confusion) This should more clearly show that foo is required to take a Double and give, in return, anything in class Foo that is requested, which it certainly does not (it always returns a Double). class Foo p where instance Foo Double where data T = forall q . Foo q = T q foo :: Double - T foo p = T p which is very similar, except that the explicit universal quantification is happening in in the datatype and not the function type. Actually, this is not really universal quantification, it is existential quantification. If you actually wrote a datatype that did universal quantification, it wouldn't work either: data T = T (forall q . Foo q = q) (I think this can also be written data T = T (Foo q = q) but I don't remember for sure). David ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicitly quantified classes in functions
I believe that ghc translates the signature above to foo :: forall q . Foo q = Double - q (I don't understand why GHC does this... it seems to have more potential for confusion) I thought post 5.03 didn't do this? Isn't this the point of Putting type annotations to use? Or am I missing something? This should more clearly show that foo is required to take a Double and give, in return, anything in class Foo that is requested, which it certainly does not (it always returns a Double). Right. class Foo p where instance Foo Double where data T = forall q . Foo q = T q foo :: Double - T foo p = T p which is very similar, except that the explicit universal quantification is happening in in the datatype and not the function type. Actually, this is not really universal quantification, it is existential quantification. If you actually wrote a datatype that did universal I meant existential. Sorry ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicitly quantified classes in functions
Why can I not define the following (in ghc): class Foo p where instance Foo Double where foo :: Double - (forall q . Foo q = q) foo p = p From my humble (lack of) knowledge, there seems to be nothing wrong here, but ghc (5.03) complains about unifying q with Double. Well, of course! The result has to have type (forall q . Foo q = q), but p actually has type Double. Of course GHC complains. The question is, why YOU think it is OK. And the answer is that you reason: there is only one instance of Foo, so when I say Foo q, that means q must be Double. But you're making the closed world assumption, that you know all of the instances of Foo. The compiler doesn't, and for good reason. Suppose you were to export these definitions from the module where they appear, into another module which defines instance Foo Integer Now, of course, it should be OK to use Foo with the type Double - Integer (since Foo Integer holds in this context). Yet clearly, the *definition* you gave cannot be used with this type. Hence the type is wrong. Of course, you could argue that if the definition of foo is *not* exported, then the compiler should use the closed world assumption and the program should be accepted. But it would be really weird if whether a definition is well-typed or not depended on whether or not it was exported... John ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicitly quantified classes in functions
class Foo p where
instance Foo Double where
foo :: Double - (forall q . Foo q = q)
foo p = p
From my humble (lack of) knowledge, there seems to be nothing wrong
here, but ghc (5.03) complains about unifying q with Double.
Well, of course! The result has to have type (forall q . Foo q = q), but p
actually has type Double. Of course GHC complains.
Ah yes, silly me. What I had in mind, I suppose, was something more along
the lines of:
foo :: Double - (exists q . Foo q = q)
Basically, I want to be able to write a function that takes a value and
produces any value so long as the type of that returned value is an
instance of Foo. So, for instance, a trimmed down real example of how I
want to use this:
class Foo p e where
foo :: exists q . Foo q e = p - e - q
bar :: p - e - Double
instance Foo Double e where
foo p _ = p
bar p _ = p
instance Foo [(e,Double)] e where
foo l e = case lookup e l of { Nothing - 0 ; _ - 1 }
bar l e = case lookup e l of { Nothing - 0 ; Just x - x }
Of course this latter Foo definition isn't really the instance I would
define, but that instance is much more complex and the complexity isn't
needed to illustrate the point.
The idea is that you take an instance of Foo together with an e (an
event) and apply those to foo and you get a new instance of Foo. OTOH
you can also take an instance of Foo together with an event and get a
double out.
Sadly I'm not aware of any such exists predicate. I'm hoping I'm simply
not aware :).
- Hal
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: explicitly quantified classes in functions
| Ah yes, silly me. What I had in mind, I suppose, was | something more along the lines of: | | foo :: Double - (exists q . Foo q = q) Correct. Currently you can only express this by wrapping the existential in a constructor: data R = forall q. Foo q = MkR q foo :: Double - R Mark Shields and I wrote a paper about doing more fully fledged existentials, but it's quite a significant chunk of work to implement. http://research.microsoft.com/~simonpj/Papers/first-class-modules Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
