Re: dynamic loading with ghc api?

2011-04-07 Thread Don Stewart
Using plugins with dynamic Haskell objects hasn't been tested in quite a while. -- Don On Thu, Apr 7, 2011 at 5:14 PM, Rob Nikander wrote: > Is the 'plugins' package compatible with dynamic linking of the main > program?   I ask because I wrote a test program using > System.Plugins.load and it w

Re: dynamic loading with ghc api?

2011-04-07 Thread Rob Nikander
Is the 'plugins' package compatible with dynamic linking of the main program? I ask because I wrote a test program using System.Plugins.load and it works fine, but when I link it to the GHC api using `ghc -dynamic ...' (which is nice cause it avoids the 50 MB executable), it seg faults when it t

Re: dynamic loading with ghc api?

2011-04-07 Thread Don Stewart
Perhaps look at the plugins package source? -- Don On Thu, Apr 7, 2011 at 12:20 PM, Rob Nikander wrote: > Hi all, > > I'd like to load a value from a .o file.  I've got... > > import ObjLink > main = do >  initObjLinker >  loadObj "Thing.o" >  resolveObjs >  Just ptr <- lookupSymbol "Thing_value

dynamic loading with ghc api?

2011-04-07 Thread Rob Nikander
Hi all, I'd like to load a value from a .o file. I've got... import ObjLink main = do initObjLinker loadObj "Thing.o" resolveObjs Just ptr <- lookupSymbol "Thing_value_closure" Is that the correct symbol to load for the name "value" in module "Thing"? And if so, how to I get the haskel

Re: Validate failures on the new codegen

2011-04-07 Thread Edward Z. Yang
Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011: > OK! Thanks for the information. So this -fnew-codegen is this famous > codegen which is using hoopl for data-dependency tracking or something > like that if I understand correctly Yep. > And which is producing just C-- in

Re: Strange performance effects with unsafePerformIO

2011-04-07 Thread Björn Peemöller
Simon Marlow schrieb: > Incidentally this will be faster with GHC 7.2, because we implemented > chunked stacks, so unsafePerformIO never has to traverse more than 32k > of stack (you can tweak the chunk size with an RTS option). This is > still quite a lot of overhead, but at least it is bounded.

Re: T3738 allocation figures for 32-bit

2011-04-07 Thread Simon Marlow
On 02/04/2011 22:35, Daniel Fischer wrote: Hit send too soon: Apparently the allocation figures drastically vary by arch and OS, it would probably be necessary to test on several such and be more generous with the limits. The same holds for other tests, of course. I had unexpected failures du