- Glasgow-haskell-users

RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
by Simon Marlow 15 Sep '04

15 Sep '04

On 15 September 2004 00:33, Roberto Zunino wrote: > However, compiling with > > ghc -prof Main.hs test.c -#include test.h > > or s/-prof/-fvia-C/, works fine, provided test.h contains the correct > function prototypes. > > ------ test.h > long long myInt64(void); > double myDouble(void); > ------ > > AFAICS, it seems as the asm code generator knows about the Haskell > types and therefore knows how to fetch the bits correctly, while the > via-C code generator simply uses the C function calls (without > prototypes), so functions return types are defaulted to int. > > Also, you can try adding -Wall and see if the C compiler warns about > this (mine does). > > The GHC user's guide (section 8.2.2) is also insightful. It seems that > using C headers is pretty much required, or, as the guide itself says, > "You're crazy not to do it". ;-) This is correct. You should get a warning from the C compiler even without -Wall, because we turn on -Wimplicit to catch exactly these problems. Cheers, Simon

1 0

RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
by Bayley, Alistair 15 Sep '04

15 Sep '04

Thanks, including the header does fix it. I was lazy, as you can link quite easily against a DLL without having to provide a header; just the import decls suffice, plus -l and -L directives. I have had this problem (not using the -I directive) in a different guise, when trying to optimise. I've added the header to the foreign import decls e.g. foreign import "sqlite.h sqlite3_open" ... I left it out earlier because this version of the Sqlite library ships just as a DLL, with no accompanying header. I downloaded the source and found one I could use (I *hope* it's the right one), but it does make you wonder what C (and other) programmers who want to use the library are expected to do... Alistair. -----Original Message----- From: Roberto Zunino [mailto:zunino@di.unipi.it] <snipped> AFAICS, it seems as the asm code generator knows about the Haskell types and therefore knows how to fetch the bits correctly, while the via-C code generator simply uses the C function calls (without prototypes), so functions return types are defaulted to int. Also, you can try adding -Wall and see if the C compiler warns about this (mine does). The GHC user's guide (section 8.2.2) is also insightful. It seems that using C headers is pretty much required, or, as the guide itself says, "You're crazy not to do it". ;-) Regards, Roberto Zunino. ----------------------------------------- ***************************************************************** 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. *****************************************************************

1 0

URI Typeable & Data
by Simon David Foster 15 Sep '04

15 Sep '04

Could we possibly have derived instances of Typeable and Data for Network.URI.URI in the 6.3 CVS please? -Si.

1 0

RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
by Bayley, Alistair 15 Sep '04

15 Sep '04

I've built a small test case. When I compile with: ghc Main.hs test.c -o Main.exe ... the (correct) output from Main.exe is: 123.0 5678901234567890 And when I compile with: ghc -prof Main.hs test.c -o Main.exe ... the (incorrect) output from Main.exe is: 1.0 986516178 ------ Main.hs: {-# OPTIONS -ffi #-} module Main where import Foreign.C foreign import ccall "myDouble" myDouble :: IO CDouble foreign import ccall "myInt64" myInt64 :: IO CLLong main = do d <- myDouble putStrLn $ show d l <- myInt64 putStrLn $ show l ------ test.c: double myDouble() { double d = 123.0; return d; } long long myInt64() { long long x = 5678901234567890; return x; } ----------------------------------------- ***************************************************************** 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. *****************************************************************

2 1

RE: linker errors
by Simon Marlow 14 Sep '04

14 Sep '04

On 13 September 2004 17:44, Frank-Andre Riess wrote: > this is my first post on this list. I'm quite new to using Haskell > (started in July), so my question might be somewhat trivial, but I > still hope you can help me out. > > At the moment our project - a parser for a type language - consists > of the following modules: > Lexer > IntermediateSyntax > Parser (from a Happy source file) - uses Lexer and IntermediateSyntax > Main - uses Parser > > When compiling using ghc, I get the following error: > > Parser.o(.text+0x10fc5): In function `r1fgN_entry': >> undefined reference to `DataziTuple_Z77T_con_info' > collect2: ld returned 1 exit status > > I neither know the function `r1fgN_entry' nor > `DataziTuple_Z77T_con_info'. So what is it? The compiler has generated intermediate code which uses a 77-tuple, but unfortunately the libraries don't contain code for 77-tuples (we only go up to 62-tuples). This is kind of a known bug, occasionally tickled by Happy-generated parsers. If you're not generating your parser with 'happy -agc', then that should help. Cheers, Simon

1 0

linker errors
by Frank-Andre Riess 13 Sep '04

13 Sep '04

Hello There, this is my first post on this list. I'm quite new to using Haskell (started in July), so my question might be somewhat trivial, but I still hope you can help me out. At the moment our project - a parser for a type language - consists of the following modules: Lexer IntermediateSyntax Parser (from a Happy source file) - uses Lexer and IntermediateSyntax Main - uses Parser When compiling using ghc, I get the following error: Parser.o(.text+0x10fc5): In function `r1fgN_entry': : undefined reference to `DataziTuple_Z77T_con_info' collect2: ld returned 1 exit status I neither know the function `r1fgN_entry' nor `DataziTuple_Z77T_con_info'. So what is it? Thanks in advance, Frank-Andre Riess

2 1

RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
by Bayley, Alistair 13 Sep '04

13 Sep '04

I'm using the newer v3 API, which has functions to get column values as String, Int, Double, Int64, etc. It also has a prepare/step/finalise trio of functions for doing queries, which suits me better. Alistair. > -----Original Message----- > From: Krasimir Angelov [mailto:ka2_mail@yahoo.com] > Sent: 13 September 2004 12:28 > To: Bayley, Alistair; glasgow-haskell-users(a)haskell.org > Subject: RE: Profiling makes FFI Marshalling of Doubles and > Int64s fail > > > --- "Bayley, Alistair" > <Alistair_Bayley(a)ldn.invesco.com> wrote: > > > Thanks Krasimir. I did have a look at your code, but > > I don't see any foreign > > types other than CString and Int, which work OK for > > me regardless of > > profiling option. (BTW, you tend to use Int rather > > than CInt - is this > > safe?) > > Good suggestion. Have done in the CVS. SQLite returns > all fetched values as strings. Are you sure that you > read them as strings? > > Cheers, > Krasimir ----------------------------------------- ***************************************************************** 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. *****************************************************************

1 0

RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
by Bayley, Alistair 13 Sep '04

13 Sep '04

Thanks Krasimir. I did have a look at your code, but I don't see any foreign types other than CString and Int, which work OK for me regardless of profiling option. (BTW, you tend to use Int rather than CInt - is this safe?) I guess I should build a small C library which uses CDouble and CLLong, just to make sure the problem isn't with the Sqlite dll. > -----Original Message----- > From: Krasimir Angelov [mailto:ka2_mail@yahoo.com] > Sent: 13 September 2004 10:53 > To: Bayley, Alistair; glasgow-haskell-users(a)haskell.org > Subject: Re: Profiling makes FFI Marshalling of Doubles and > Int64s fail > > > --- "Bayley, Alistair" > <Alistair_Bayley(a)ldn.invesco.com> wrote: > > > (using GHC 6.2.1 under Windows XP) > > > > I'm trying to use the Sqlite (version 3) dll - see > > http://www.sqlite.org/ . > > Hi Alistair, > > HSQL already provides binding to sqlite. I don't know > whether you will have the same problem with profiling > version of HSQL but you can try. > > Cheers, > Krasimir ----------------------------------------- ***************************************************************** 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. *****************************************************************

2 1

Profiling makes FFI Marshalling of Doubles and Int64s fail
by Bayley, Alistair 13 Sep '04

13 Sep '04

(using GHC 6.2.1 under Windows XP) I'm trying to use the Sqlite (version 3) dll - see http://www.sqlite.org/ . Marshalling of 32-bit ints and Strings works well, but 64-bit Ints and Doubles fail (I get garbage back from the FF calls) when I compile with "-prof -auto-all". If I compile without profiling, everything works as I expect. When I try to load the compiled (with -prof) object files in GHCi, it fails with this error message: ------------------------ Compiling TestCase ( TestCase.lhs, interpreted ) ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): ByteCodeFFI.mkMarshalCode_wrk(x86) LI_ Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. ------------------------ GHCi works correctly with non-profiled object files. Thanks, Alistair. ----------------------------------------- ***************************************************************** 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. *****************************************************************

2 1

Re: Using GHC and wxHaskell; ik weet niet of je dit ook leest
by Daan Leijen 11 Sep '04

11 Sep '04

Ivan Boldyrev wrote: > On 8861 day of my life Mike Thomas wrote: > >> | Is that a good option? How can I use the wxHaskell libraries with GHC? >> | I´m working under Windows XP. >> >> Check out wxHaskell: >> >> http://wxhaskell.sourceforge.net/ > > Does it work under Windows? > > One of my friends tried it under Windows, but failed. But I have only > Linux, and don't know details (but he wished to use it without Cygwin > but with MSVC; may be, it is source of problem?) wxHaskell works best on Windows (especially since ghci works with it too :-) It can be compiled with both mingw32 and MS Visual C -- detailed build instructions can be found on the wxhaskell website. However, I would recommend a pre-compiled windows binary distributions as compiling everything requires good knowledge of all the build tools. I hope this helps, -- Daan.

1 0