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/glasgow-haskell-users@haskell.org/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

On Fri, 2004-04-30 at 17:36, Simon Marlow wrote:
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?
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).
Details would be interesting.
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.
Does that involve changing what reference get linked to which symbols or would it be a matter of finding a bunch of symbols & calling them after doing a dlopen() ? Another way of asking the same thing is can the calling newDynCAF be done in a separate phase (ie after dlopen()) or is it intimately part of the linking process? There seem to be several people interested in doing plug-in systems with dynamically loaded modules. I just came across this report: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/distinguished/dynamiclinker... Duncan

I wrote a little data structure with quantified constructors: module MyModule where import Data.Generics import Data.HashTable data Item = forall a. (Data a) => Leaf Bool a | forall a. (Data a) => Branch Bool a Int Int deriving (Typeable) I want it to make an instance of Data: instance Data Item where gfoldl k z (Leaf b v) = z (Leaf b) `k` v gfoldl k z (Branch b v a1 a2) = z (\x -> Branch b x a1 a2) `k` v --gunfoldl k z c = case constrIndex c of -- 1 -> k z (Leaf undefined undefined) toConstr (Leaf _ _) = leafConstr toConstr (Branch _ _ _ _) = branchConstr dataTypeOf _ = itemDataType itemDataType = mkDataType "Subliminal.Item" [leafConstr, branchConstr] leafConstr = mkConstr itemDataType "Leaf" [] Prefix branchConstr = mkConstr itemDataType "Branch" [] Prefix But, when I try to compile it with ghc-6.4-20050217: ghc -fglasgow-exts -i. -c kicsi.hs kicsi.hs:13:4: Warning: No explicit method nor default method for `gunfold' In the instance declaration for `Data Item' ghc-6.4.20050217: panic! (the `impossible' happened, GHC version 6.4.20050217): cgPanic k{v a1vu} static binds for: local binds for: gunfold{v r22q} SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC version 6.4.20050217): initC: srt Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. If I uncomment the gunfoldl lines: ghc -fglasgow-exts -i. -c kicsi.hs kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data' Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32 Could you please help me? Thanks Akos -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Akos Korosmezey Tel: +36-1-439-5936 Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax: +36-1-437-7576 P.O.B. 107, H-1300 Budapest, Hungary Home: +36-26-342-687 mailto:Akos.Korosmezey@ericsson.com Mobile: +36-30-740-7732 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It is called "gunfold" rather than "gunfoldl" as you will see when you browse the Data.Generics.Basics. Also, your gunfold code looks like it will not work. Here is a simple example for Maybe: gunfold k z con = case constrIndex con of 1 -> z Nothing -- no children 2 -> k (z Just) -- one child, hence one k Bottom line: - apply z to the Constructor - apply k as many times as the number of children. No warranty that this is easy for your type Item. Good luck, Ralf Akos Korosmezey wrote:
I wrote a little data structure with quantified constructors:
module MyModule where import Data.Generics import Data.HashTable
data Item = forall a. (Data a) => Leaf Bool a | forall a. (Data a) => Branch Bool a Int Int
deriving (Typeable)
I want it to make an instance of Data:
instance Data Item where gfoldl k z (Leaf b v) = z (Leaf b) `k` v gfoldl k z (Branch b v a1 a2) = z (\x -> Branch b x a1 a2) `k` v --gunfoldl k z c = case constrIndex c of -- 1 -> k z (Leaf undefined undefined) toConstr (Leaf _ _) = leafConstr toConstr (Branch _ _ _ _) = branchConstr dataTypeOf _ = itemDataType
itemDataType = mkDataType "Subliminal.Item" [leafConstr, branchConstr] leafConstr = mkConstr itemDataType "Leaf" [] Prefix branchConstr = mkConstr itemDataType "Branch" [] Prefix
But, when I try to compile it with ghc-6.4-20050217:
ghc -fglasgow-exts -i. -c kicsi.hs
kicsi.hs:13:4: Warning: No explicit method nor default method for `gunfold' In the instance declaration for `Data Item' ghc-6.4.20050217: panic! (the `impossible' happened, GHC version 6.4.20050217): cgPanic k{v a1vu} static binds for: local binds for: gunfold{v r22q} SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC version 6.4.20050217): initC: srt
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/.
If I uncomment the gunfoldl lines:
ghc -fglasgow-exts -i. -c kicsi.hs
kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data'
Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32
Could you please help me?
Thanks Akos
-- Ralf Lammel ralfla@microsoft.com Microsoft Corp., Redmond, Webdata/XML http://www.cs.vu.nl/~ralf/
participants (4)
-
Akos Korosmezey
-
Duncan Coutts
-
Ralf Laemmel
-
Simon Marlow