RE: turn off let floating
On 29 April 2004 10:17, David Sabel wrote: You could try out that theory by copying the definition of unsafePerformIO into your code, and putting an INLINE pragma on it. I think it's safe to do this in your case (it's not safe in general). That's interesting for me, in which situations isn't it safe to inline the definition of unsafePerformIO? We try to maintain the invariant that the IO action that is the argument to unsafePerformIO is atomic, in the sense that it is either completely performed or not performed when the application of unsafePerformIO is evaluated (ignoring exceptions). If we let the compiler inline unsafePerformIO, then the compiler would sometimes be able to share part of the IO computation amongst multiple instances, because it can see that the first action is applied to the realWorld# constant. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Dynamic loading problem
On 29 April 2004 16:55, Hampus Ram wrote: by using the RTS I've made it possible to dynamically load modules for quite some time now. However, recently I've stumbled inte quite a problem. I've created a bunch of modules to handle all dynamic loading for me and things are good for simple programs. But now I want to load my dynamic loading modules dynamically (yes, it sounds weird) and that can't be done - not on linux anyways. The functions from the rts are ffi:ed into my program but when dynamically loading the module, these functions can't be found (unknown symbol `lookupSymbol`) and neither can I load the HSrts.o package to make them visible due to duplicate functions (I found a duplicate definition for symbol makeStableNamezh_fast). How can I proceed? Can I pass some flag to the linker or such to force them to behave as I want? The linker (ghc/rts/Linker.c) has an explicit symbol table for symbols in the RTS that need to be visible in dynamically loaded code. Not pretty, but it works and is cross-platform. You need to add some more symbols to this table, and recompile the RTS. Alternatively, you might be able to re-link HSrts.o with --export-dynamic (something like 'ld -r --export-dynamic HSrts.o -o my-HSrts.o') and then link this object into your program. This works by making all the symbols in HSrts.o visible to the system's dynamic linker, which is used to resolve symbols that the RTS dynamic linker can't find. I only have this problem with linux (tested on Debian and Redhat) using ghc 6.2.1. On Solaris everything works just great (one doesn't even have to load any extra packages there) with ghc 6.0.1. Not sure why it works on Solaris. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.2.1 retaining profiling broken?; program segfaults with -hr flag
I've tried to get a heap retaining profile (-hr) of my (largish) program with GHC 6.2.1 (on Windows NT4), but it segfaults when run. I can produce a -hc profile without grief. Is this a known problem? P.S. I've trimmed my program back a bit to provide a test case (and to remove FFI code), but there are still five modules involved. - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Dynamic loading problem
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? As I recall it seems to nearly work. Andre Pang got them to load and function but it was a bit fragile and the rts would complain after a short while: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03923.h tml 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). 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. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.2.1 retaining profiling broken?; program segfaults with -hrflag
On 30 April 2004 14:25, Bayley, Alistair wrote: I've tried to get a heap retaining profile (-hr) of my (largish) program with GHC 6.2.1 (on Windows NT4), but it segfaults when run. I can produce a -hc profile without grief. Is this a known problem? P.S. I've trimmed my program back a bit to provide a test case (and to remove FFI code), but there are still five modules involved. It's not a known problem, but I think it has been reported once before. I'll get around to looking into it at some point. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
