- Glasgow-haskell-users

hsc: Passing -1 as CString/Ptr a?
by Volker Stolz 22 Nov '01

22 Nov '01

Hi, I want to invoke the C-function 'dlsym', which has three possible options for a parameter of type (void*): - NULL - void* to a string, i.e. CString in Haskell - RTLD_NEXT = (void *)(-1) The first two ones are no problem, I can use a CString and 'nullPtr'. For the last one, I have the problem that in the "Next"-case I cannot write pack :: Flag -> CString pack Null = nullPtr pack Name str = str pack Next = #const RTLD_NEXT because there's no way to cast Int to a Ptr -- at least I didn't find any. Unluckily, the C-codes (void *)(-1) even gets expanded by hsc to the literal "4294967295" which can't be right either. So currently I'm facing two possible solutions: pack Next = nullPtr `plusPtr` 4294967295 (expanded from "... #const RTLD_NEXT") or pack Next = nullPtr `plusPtr` (-1) (which is not a good idea since it doesn't use the C-constant) "Ptr" is abstract so I cannot create this Ptr myself. Maybe the Ptr-module just lacks a 'minusOnePtr' similar to 'nullPtr'? -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

1 0

RE: Binary library
by Jan de Wit 22 Nov '01

22 Nov '01

> > Does Malcolm's Binary library exist for ghc? If not, is there > > a standard > > way (ie using Haskell that works on any compiler) to dump a data > > structure into a file that another program or part of the same program > > can then pick up and read (cf "serialize" in Java)? I'm > > reluctant to go > > with a solution that's compiler-specific. > > Using Show & Read is the only really portable way to do this, > unfortunately. [snip] Well, it's not really portable... Try the program at the end of this file, by first executing hugsMain in hugs, exiting and then running main in ghc or ghci, and you'll see: | Cons{hd='a',tl=(Cons{hd='b',tl=Nil})} | *** Exception: Prelude.read: no parse So, at least ghc and hugs disagree... My ghc version is 5.02 and my hugs is February 2000/2001 (both give the same output). Cheers, Jan de Wit ----8<---- module Test where data List a = Nil | Cons { hd :: a, tl :: List a } deriving (Show,Read,Eq) theList = Cons 'a' (Cons 'b' Nil) hugsMain = do writeFile "test.txt" (show theList) main main = do s <- readFile "test.txt" let theListFromFile = read s print theList print theListFromFile print $ theList == theListFromFile writeFile "test.txt" (show theList)

3 5

RE: Binary library
by Jan de Wit 21 Nov '01

21 Nov '01

> Can anyone spot the fault in the derived instance of Read produced > by DrIFT? > > Regards, > Malcolm The precedence of things printed or read after a label should IMO be lower than 10, probably even 0. In other words: calls to showsPrec/readsPrec 10 should be replaced by showsPrec/readsPrec 0 in the code below. I haven't checked this though, however I've written a generic version of read and show using Generic Haskell which omits the superfluous parentheses by using precedence 0. Cheers, Jan > > > data List a = Nil | Cons { hd :: a, tl :: List a } > > > > {-* Generated by DrIFT-v1.0 : Look, but Don't Touch. *-} > > instance (Show a) => Show (List a) where > > showsPrec d (Nil) = showString "Nil" > > showsPrec d (Cons aa ab) = showParen (d >= 10) > > (showString "Cons" . showChar '{' . > > showString "hd". showChar '='. showsPrec 10 aa. showChar',' . > > showString "tl" . showChar '=' . showsPrec 10 ab > > . showChar '}') > > > > instance (Read a) => Read (List a) where > > readsPrec d input = > > (\ inp -> [((Nil) , rest) | ("Nil" , rest) <- lex inp]) input > > ++ > > readParen (d > 9) > > (\ inp -> > > [((Cons aa ab) , rest) | ("Cons" , inp) <- lex inp , > > ("{" , inp) <- lex inp , ("hd" , inp) <- lex inp , > > ("=" , inp) <- lex inp , (aa , inp) <- readsPrec 10 inp , > > ("," , inp) <- lex inp , ("tl" , inp) <- lex inp , > > ("=" , inp) <- lex inp , (ab , inp) <- readsPrec 10 inp , > > ("}" , rest) <- lex inp]) > > input

1 0

[Linux-basic-compiling]GHC-3.02 build on GHC-2.10
by Rafael Martínez Torres 21 Nov '01

21 Nov '01

I apologize if this is not the correct moment-place to deal with this old version. I'm trying to compile the GHC-3.02 version using ghc-2.10 binaries, happy-1.6 binaries on a i386-unknown-linux. In the future I would like to hack with it. I had to modify the file ghc/run_time/main/Signals.lc because it used a non-existing structure, named "struct sigcontext_struct" instead of "struct sigcontext". Main problem arise when linking. If I'm not wrong, the output from Haskell code are "C" files. They are compiled and linked by the C compiler. At the final linking step, the linker shows me unresolved references to symbols: "_fxstat","_lxstat" or "__setmjmp". After inspecting the code, on directory ghc/lib/cbits/openFile.c [...], I realized this belong to C functions fstat(),lstat() and setjmp() . These libraries are implicitly included by libc, I think. Any C-program links without problem,when compiled by invoking explictly "gcc", but I seems the ghc-2.10 compiler not to find the libc (and so his sub-components ). Does any body suggest me what I can do to perform a good compiling ? What parameters should I modify and where ? In directory mk ? Where lasgow-haskell-users(a)haskell.org else ?

1 0

RE: [Linux-basic-compiling]GHC-3.02 build on GHC-2.10
by Simon Marlow 21 Nov '01

21 Nov '01

> I apologize if this is not the correct moment-place to deal with this > old version. > > I'm trying to compile the GHC-3.02 version using ghc-2.10 binaries, > happy-1.6 binaries on a i386-unknown-linux. > In the future I would like to hack with it. [ I presume you have a good reason for needing GHC 3.02 - I'd be interested to know what it is! ] It looks like that the ghc-2.10 binaries you are using don't work well with the version of Linux (in particular the version of the C library) that you're using. Probably the only way to get going is to bootstrap from the .hc files for 3.02. Cheers, Simon

1 0

RE: Binary library
by Simon Marlow 21 Nov '01

21 Nov '01

> Does Malcolm's Binary library exist for ghc? If not, is there > a standard > way (ie using Haskell that works on any compiler) to dump a data > structure into a file that another program or part of the same program > can then pick up and read (cf "serialize" in Java)? I'm > reluctant to go > with a solution that's compiler-specific. Using Show & Read is the only really portable way to do this, unfortunately. Sven Panne did a port of nhc's Binary library a while back, which you can find on haskell.org, but it will certainly need some work to get it going on recent GHC's. We'd really like a good serialisation library, BTW, if anyone out there feels like donating one! Cheers, Simon

1 0

GMP
by Marcin 'Qrczak' Kowalczyk 21 Nov '01

21 Nov '01

I think there exists a problem. I haven't encountered it because I haven't tried to provoke it, but if I'm not mistaken it can cause big trouble. Programs compiled by ghc set gmp's allocation functions to ones which allocate byte arrays on the Haskell heap, instead of the default malloc/free. Now imagine a program or library which uses gmp for its own purposes and is linked with a program or library compiled with ghc. GMP's hooks are global, gmp is shared. Neither of allocation methods is suitable for the other side. So it won't work. Is there a solution? -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

2 1

profiling problem
by Andre W B Furtado 20 Nov '01

20 Nov '01

I've installed GHC-5.02 (and the profiling libraries) for Windows platforms (I have Windows98 running on my machine), but everytime I try to check the heap profiling for a program, I always get an empty graph (as the one attached). I'm sure I am doing the right steps (compiling the program with "-prof -auto-all" option, executing it with "+RTS -h" and then calling hp2ps). Any suggestions? -- Andre

2 3

RE: not naming modules Main
by Simon Peyton-Jones 20 Nov '01

20 Nov '01

(Moving this to GHC users.) What exactly do you propose? * Haskell allows you to define a 'main' in any module you please. * GHCi allows you to execute any of these 'main' functions independently. (You get all the speed of compiled code if you compile the module first and load the compiled module into GHCi.) * But if you want to link together a bunch of modules into an executable, there must be some way to decide which 'main' you want to execute. Haskell's way is to say "It's the 'main' from module Main". We like feedback about what would be useful -- GHC has lots of things that aren't exactly Haskell that were generated by such suggestions. But I'm unclear what you would like (let alone how easy it would be to implement). Simon | -----Original Message----- | From: Hal Daume [mailto:hdaume@ISI.EDU] | Sent: 16 November 2001 18:34 | To: haskell(a)haskell.org | Subject: not naming modules Main | | | I'm really frustrated that modules that you want to compile | to executables have to be named Main. I often have a module | with a main method that I use for testing or whatever | (perhaps I want the gained speed of an executable) but is, | for the most part, a module I import into others. I end up | having to constantly change the module name whenever I want | to compile it and I find this terribly frustrating. | | Is there any reason you can't just compile things that simply | export a main method with the proper type? Is this a ghc | specific thing or does nhc also have this restriction? Any | chance ghc will change its policy on this? | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell | |

3 2

(no subject)
by Chen Yu 20 Nov '01

20 Nov '01

hi, there i am compiling ghc with a c library doing cryptology. however i notic there are conflicts on the definitions of these functions: MD5Init MD5Update MD5Final is there any way to remove them from ghc? many thanks! ------ regards, chenyu _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1