Re: dynamic loading with ghc api?
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 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 tries to call the function that it > loaded from the .o file. Maybe I need to compile the .o with > something more than `ghc -c MyPlugin.hs'? > > Rob > > On Thu, Apr 7, 2011 at 3:35 PM, Don Stewart wrote: >> 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_closure" >>> >>> Is that the correct symbol to load for the name "value" in module >>> "Thing"? And if so, how to I get the haskell value out of the Ptr >>> that I get from lookupSymbol? I found some code to do it and it works >>> value :: Int, but it seg faults if value :: Integer, or something more >>> complex like a function. >>> >>> {-# LANGUAGE MagicHash #-} >>> {-# LANGUAGE UnboxedTuples #-} >>> ... >>> let !(Ptr addr) = ptr >>> in case addrToHValue# addr of >>> (# hval #) -> hval >>> >>> Is there some documentation for this that I'm missing? I'm looking at >>> haddock with just type signatures, like this: >>> >>> http://www.haskell.org/ghc/docs/7.0.3/html/libraries/ghc-7.0.3/ObjLink.html >>> >>> (I'm a haskell beginner.) >>> >>> thank you, >>> Rob >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: dynamic loading with ghc api?
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 tries to call the function that it loaded from the .o file. Maybe I need to compile the .o with something more than `ghc -c MyPlugin.hs'? Rob On Thu, Apr 7, 2011 at 3:35 PM, Don Stewart wrote: > 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_closure" >> >> Is that the correct symbol to load for the name "value" in module >> "Thing"? And if so, how to I get the haskell value out of the Ptr >> that I get from lookupSymbol? I found some code to do it and it works >> value :: Int, but it seg faults if value :: Integer, or something more >> complex like a function. >> >> {-# LANGUAGE MagicHash #-} >> {-# LANGUAGE UnboxedTuples #-} >> ... >> let !(Ptr addr) = ptr >> in case addrToHValue# addr of >> (# hval #) -> hval >> >> Is there some documentation for this that I'm missing? I'm looking at >> haddock with just type signatures, like this: >> >> http://www.haskell.org/ghc/docs/7.0.3/html/libraries/ghc-7.0.3/ObjLink.html >> >> (I'm a haskell beginner.) >> >> thank you, >> Rob >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: dynamic loading with ghc api?
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_closure" > > Is that the correct symbol to load for the name "value" in module > "Thing"? And if so, how to I get the haskell value out of the Ptr > that I get from lookupSymbol? I found some code to do it and it works > value :: Int, but it seg faults if value :: Integer, or something more > complex like a function. > > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > ... > let !(Ptr addr) = ptr > in case addrToHValue# addr of > (# hval #) -> hval > > Is there some documentation for this that I'm missing? I'm looking at > haddock with just type signatures, like this: > > http://www.haskell.org/ghc/docs/7.0.3/html/libraries/ghc-7.0.3/ObjLink.html > > (I'm a haskell beginner.) > > thank you, > Rob > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
dynamic loading with ghc api?
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 haskell value out of the Ptr that I get from lookupSymbol? I found some code to do it and it works value :: Int, but it seg faults if value :: Integer, or something more complex like a function. {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} ... let !(Ptr addr) = ptr in case addrToHValue# addr of (# hval #) -> hval Is there some documentation for this that I'm missing? I'm looking at haddock with just type signatures, like this: http://www.haskell.org/ghc/docs/7.0.3/html/libraries/ghc-7.0.3/ObjLink.html (I'm a haskell beginner.) thank you, Rob ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Validate failures on the new codegen
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 order to be compatible with the current > infrastructure, i.e. NCG? Not quite. We have two C-- representations, in cmm/CmmNode.hs and cmm/OldCmm.hs respectively. Our backends consume OldCmm, and Hoopl consumes CmmNode, and then converts it to OldCmm using CmmCvt.hs. > If I also read correctly somewhere on GHC Trac Wiki, then this -fnew-codegen > should sometime in the future even replace NCG. May I ask you when such > replace is planed? That's the idea, but depends on how long it takes for us to get the new code generator generating as good (or better--that's the idea behind Hoopl) as the old code generator at a reasonable pace. The new codegen is already several years into the making. > I'm asking since I'm still poking with the idea of writing NCG for some GHC > not yet supported platform and since this will be my free time hobby project > it'll certainly take some time hence I do have doubts if to use current NCG > as a basis for it or wait and/or use your new planned infrastructure. It's certainly a question. Since we can convert from one to another, whichever one you pick, we should be able to support (some fiddling may be required if you use the new C-- representation, since none of our other backends use it right now--but this is certainly the way forward.) Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange performance effects with unsafePerformIO
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. > > The example above runs in 1.45s for me with current HEAD, and I gave up > waiting with 7.0. Thank you all for your explanations, the blackholing indeed seems to be the cause for the slowdown. Is there any documentation available about the blackholing process? Maybe we can find a hint on how to change our code to avoid the problem. Regards, Bjoern ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: T3738 allocation figures for 32-bit
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 due to allocation figures also for space_leak001, T4801 and T3064. space_leak001 failing with bytes allocated 9328745840 is more than maximum allowed 91 (allocation figures slightly vary among the different ways) which is close enough to not worry about, considering the minimum allowed is 905000. T4801 with peak_megabytes_allocated 41 is less than minimum allowed 70 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 358364424 is more than maximum allowed 8000 max_bytes_used 17406288 is more than maximum allowed 400 and T3064 with peak_megabytes_allocated 9 is less than minimum allowed 14 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 69984336 is less than minimum allowed 15000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again max_bytes_used 3368652 is less than minimum allowed 600 If this is because you have improved GHC, please update the test so that GHC doesn't regress again The figures in HEAD's testsuite are again close to what I get, while the 7.0.3 figures are way off. The testsuite wasn't fully updated in the 7.0 branch, so there are a few failures there. They don't indicate any actual problems as far as I'm aware. Next time we'll make sure to clean up any failures in the branch before releasing. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users