- Glasgow-haskell-users

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

Simple implicit parameters question
by brk＠jenkon.com 28 Aug '01

28 Aug '01

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

1 0

tail -f behaviour in ghc.
by Alex Ferguson 27 Aug '01

27 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. I suspect the intended and actual behaviour in all cases is "as per Unix handles", but shouldn't it in principle be specified independently thereof? Cheers, Alex.

1 0

RE: SocketPrim.socketToHandle
by Simon Marlow 27 Aug '01

27 Aug '01

> Currently this functions has the type > > > SocketPrim.Socket -> PrelHandle.IOMode -> IO PrelIOBase.Handle > > Could you change the order of the arguments, please? I can`t see > any particular requirement of the socket being the first argument, > but swapping it with IOMode would eliminate an additional 'flip' > when mapping socketToHandle over a list of sockets, e.g.: > > > handles <- mapM (socketToHandle ReadMode) sockets Yes, but currently it matches the argument order of openFile. On the grounds that the change is unforced and would break existing programs, I'm not enclined to change it. However, if there's a concensus then this kind of change can happen when we switch over to the new libraries - libraries(a)haskell.org is the right place to discuss this. Cheers, Simon

1 0

SocketPrim.socketToHandle
by Volker Stolz 25 Aug '01

25 Aug '01

Currently this functions has the type > SocketPrim.Socket -> PrelHandle.IOMode -> IO PrelIOBase.Handle Could you change the order of the arguments, please? I can`t see any particular requirement of the socket being the first argument, but swapping it with IOMode would eliminate an additional 'flip' when mapping socketToHandle over a list of sockets, e.g.: > handles <- mapM (socketToHandle ReadMode) sockets -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

1 0