August 2001 - Glasgow-haskell-users

Help in calling Haskell from C
by Mark Conway Wirt 12 Oct '01

12 Oct '01

I've been using hdirect for C <-> Haskell calls, and I've hit a bit of a snag. I'm using ghc 5.00.2 and hdirect 0.17. I've been able to call Haskell from C easily enough, but I've been unable to go the other way. I've tried following the directions in the hdirect manual, and tried building the examples in the hdirect distribution. Everything works up until final linking, where I receive undefined references. The C code should initialize the Haskell run-time, as it include the startup code: extern void startupHaskell (int argc, char* argv[]); startupHaskell(argc,argv); I'm compiling via ghc with the following options: ghc -package hdirect -fglasgow-exts -static -no-hs-main and the idl is compiled as such: ihc -s -fhs-to-c --gen-headers -fuse-ints-everywhere --output-h=.... Does hdirect work with ghc 5.00.2? I'm not receiving any errors in the build process, so I think my problems are more related to a lack of documentation, as opposed to a bug. Does anyone have any information (beyond what is in the hdirect documentation) on calling ghc-compiled code from C? The undefined references I'm getting are: undefined reference to `__init_Main' undefined reference to `Main_main_closure' Thanks in advance. I've looked though the mailing list archive and haven't found anything. If this has been answered before I apologize. --Mark

5 9

Posix.runProcess
by George Russell 19 Sep '01

19 Sep '01

I think Posix.runProcess should give access to the eventual exit state of the process, if any. Two possible ways: (1) Change its result to IO (IO ExitCode), the inner action being something that waits for the process to complete (without blocking all other threads!) and returns the ExitCode. (Even better would be to make the result just IO ExitCode but this might be too incompatible for people who rely on runProcess returning at once.) (2) If (1) can't be done, change its type to return something similar to Posix.getProcessStatus.

3 4

RE: GHC FFI Return Type Bug
by Julian Seward (Intl Vendor) 08 Sep '01

08 Sep '01

Sigbjorn Am confused by your answer. | > char fooble ( ... ) | > { | > return 'z'; | > } | > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I | > don't know is, is the C compiler obliged to clear the upper 24 bits of | > %eax, or does that onus fall on the callee? | | Yes, the callee is required to narrow <expr> in 'return | <expr>;' to fit that of the specified return type -- see 9.8 | of Harbison and Steele. So, a C compiler that cause f() to | return 0x7fffffff for the following, | | unsigned char g() | { | return 0x7fffffff; | } | | unsigned int f() | { | return g(); | } | | is in the wrong. [Notice that narrowing for signed integral | types is undefined in ISO C, but most current-day compilers | implement such narrowing ops the same way, i.e., by masking | off excess bits.] So we don't need to worry about doing the masking on the Haskell side, right? | > Also, I don't even know where to look for the specification | of details | > of the C calling conventions. Anyone got a clue? | > | | Harbison & Steele Chapters 6 and 9 cover the conversion rules | that apply to functions (and other expressions). As you no | doubt already know, lower-level details are the domain of a | platform's ABI. | | Sounds to me like unboxed sized Words and Ints is the | (unavoidable) way to go. Why would we need these unless we *did* need to worry about masking on the Haskell side? Pls clarify. J

2 2

powerpc-unknown-linux port
by Lars Brinkhoff 31 Aug '01

31 Aug '01

I'd like to try to port GHC to powerpc-unknown-linux. There seems to be only x86 HC files available for GHC 5.00.2. Would those be of any help to me?

2 1

problems compiling ghc-5.00.2 on Solaris 2.6
by Akop Pogosian 28 Aug '01

28 Aug '01

I am trying to build ghc-5.00.2 on one of our systems by a user request. I have successfully compiled ghc-4.08.2. Now I am trying to build ghc-5.00.2 but compilation fails in the following way after I issue the following commands: MAKE=gmake ./configure --prefix=/local/sol/2.6/depot/ghc-5.00.2 <works fine> gmake ... ../../../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -Wall -DCOMPILING_STDLIB -I../../../includes -I../../../rts -- closeFile.c echoAux.c errno.c fileEOF.c fileGetc.c fileLookAhead.c fileObject.c filePosn.c filePutc.c fileSize.c flushFile.c freeFile.c getBufferMode.c getCPUTime.c getLock.c inputReady.c openFile.c progargs.c readFile.c seekFile.c setBinaryMode.c setBuffering.c system.c tcSetAttr.c writeError.c writeFile.c ------------------------------------------------------------------------ ===fptools== Finished making `boot' in cbits ... PWD = /home/src/akopps/ghc-5.00.2/ghc/lib/std ------------------------------------------------------------------------ ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc ld.so.1: /home/src/akopps/ghc-5.00.2/ghc/utils/hsc2hs/hsc2hs-bin: fatal: libncurses.so.5: open failed: No such file or directory Killed gmake[3]: *** [Directory.hs] Error 137 gmake[2]: *** [boot] Error 1 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/home/src/akopps/ghc-5.00.2/ghc' gmake: *** [all] Error 1 hsc2hs-bin does not work because the system can't find ncurses although ncurses is installed. Our convention is to install all third-party software is /opt/local. Ncurses is present in /opt/local/lib but the runtime linker can't find it. I could solve this problem by adding /opt/local/lib to LD_LIBRARY_PATH but I'd rather not do that. I prefer to compile programs in such was that they find the needed libraries on their own. I use ld's -R flag to accomplish that. However, I don't know how to do it in the case of hsc2hs-bin. Does anyone know how to build ghc in such way that the binaries can find the libaries on their own without needing to use LD_LIBRARY_PATH? Thanks. -akop

1 0

RE: tail -f behaviour in ghc.
by Alex Ferguson 28 Aug '01

28 Aug '01

> Indeed, it appears not to work in GHC 5.00.2, but I've checked that it > does work with the forthcoming 5.02. Code is attached. Ta much -- almost exactly what I was trying ('cept for posix sleep rather than threadDelay, and other (apparent) niceties). I'll double check this against 5.02 locally, in case there's some other oddity occurring.

1 0

RE: tail -f behaviour in ghc.
by Simon Marlow 28 Aug '01

28 Aug '01

> Odd! Not only does it not have that behaviour in ghc-4.0[48], it also > didn't seem to work when I tried coding it that way in C. Maybe tells > you more about my C skills... ;-) > > I'll wait until the stable ghc-5.02, and then try this again, just in > case this has indeed changed significantly recently, rather than it > just being me missing something obvious. Indeed, it appears not to work in GHC 5.00.2, but I've checked that it does work with the forthcoming 5.02. Code is attached. Cheers, Simon

1 0

RE: tail -f behaviour in ghc.
by Alex Ferguson 28 Aug '01

28 Aug '01

> Sure, EOF is checked every time you read rather than being cached after > the first time it occurs (actually this is the case in the new I/O > library in 5.02, I'm not sure about 5.00.2). So it's reasonable to do a > sleep/read loop similar to 'tail -f'. Odd! Not only does it not have that behaviour in ghc-4.0[48], it also didn't seem to work when I tried coding it that way in C. Maybe tells you more about my C skills... ;-) I'll wait until the stable ghc-5.02, and then try this again, just in case this has indeed changed significantly recently, rather than it just being me missing something obvious. Cheers&thanks, Alex.

1 0

RE: tail -f behaviour in ghc.
by Simon Marlow 28 Aug '01

28 Aug '01

> I suspect this is more of a "my patchy knowledge about file handles" > question than a ghc or a Haskell question, but at the risk of > revealing > same in public... > > Is it possible to implement "follow mode" behaviour, a la tail -f, > without using "seek" (or hSetPosn, which I assume is essentially > seek slightly abstractified). Essentially this comes down to whether > once a handle reaches "eof", whether than can be subsequently > falsified. Sure, EOF is checked every time you read rather than being cached after the first time it occurs (actually this is the case in the new I/O library in 5.02, I'm not sure about 5.00.2). So it's reasonable to do a sleep/read loop similar to 'tail -f'. Cheers, SImon

1 0

RE: Simple implicit parameters question
by Simon Peyton-Jones 28 Aug '01

28 Aug '01

It's the monomorphism restriction again. Check out the section in the Haskell Report, which gives some motivation (4.5.4). Solution: make mytrim into a function or give a type signature to mytrim Simon | -----Original Message----- | From: brk(a)jenkon.com [mailto:brk@jenkon.com] | Sent: 28 August 2001 02:37 | To: glasgow-haskell-users(a)haskell.org | Subject: Simple implicit parameters question | | | Hi all, | | Using one implicit parameter works fine for me, but when I | use two, things seem to go astray. Here's a highly contrived example: | | main = | do | putStrLn $ mytrim with ?width = 20 with ?line = "The | quick brown fox jumped over the lazy dog" | | | mytrim | ?width > length ?line = ?line | | otherwise = take ?width ?line | | | But ghc complains: | | $ ghc -o scratch.exe scratch.hs -fglasgow-exts | | scratch.hs:8: | Unbound implicit parameter `?width :: Int' | arising from use of implicit parameter `?width' at scratch.hs:8 | In the first argument of `(>)', namely `?width' | In the definition of `mytrim': ?width > (length ?line) | | scratch.hs:8: | Unbound implicit parameter `?line :: [Char]' | arising from use of implicit parameter `?line' at scratch.hs:8 | In the first argument of `length', namely `?line' | In the second argument of `(>)', namely `length ?line' | | | Can someone please tell me what I'm doing wrong? | | Thanks, | | Bryn Keller | Senior Software Engineer | Jenkon | brk(a)jenkon.com | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0