May 2001 - Glasgow-haskell-users

Endangered I/O operations
by Simon Marlow 18 May '01

18 May '01

I'm currently re-implementing GHC's I/O library, and I'd like to get people's opinions on the following I/O extensions currently provided by GHC - should we continue to provide them or not. 1. IOExts.hConnectTo This was designed to be a way to have one handle automatically flushed before we flush another handle (eg. outputting to stderr causes stdout to be flushed first). The current implementation has a number of problems: errors and blocking arenn't handled properly when doing the connected flush. If no-one is using it, I'd like to get rid of it. 2. IOExts.withHandleFor This is a cunning hack to allow you to temporarily redirect one handle to another, like 2>&1 in shell speak. I'm dubious as to whether it works consistently - there's certainly not enough error checking in the implementation, so if no-one is using it I'd like to drop it. 3. IOExts.hGetBuf, IOExts.hPutBuf, IOExts.hGetBufBA, IOExts.hPutBufBA These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc. I can't remember why we have both blocking and non-blocking versions, although I distinctly remember implementing and documenting them :-) If anyone is using, or knows of a good use for, the non-blocking versions, then I'll keep them. Otherwise, I'd like to rename hGetBufFull to hGetBuf, and similarly for the others. Cheers, Simon

2 1

Re: Problems building GHC 5.00 on Solaris 2.5.1
by Alister Whitford 17 May '01

17 May '01

I forgot to mention in my first mail that I also got nearly 4000 warnings of the form, "call-clobbered register used for global register variable". They all occur in ghc/include/Reg.h, on the lines that declare the registers F1, F2, F3, F4, D1 and D2. However, in ghc/include/MachReg.h, we see: #if sparc_TARGET_ARCH ... #define CALLER_SAVES_F1 #define CALLER_SAVES_F2 #define CALLER_SAVES_F3 #define CALLER_SAVES_F4 #define CALLER_SAVES_D1 #define CALLER_SAVES_D2 So I am assuming that this warning may safely be ignored - is this correct? Btw, apologies that my original message was in MIME format. Sadly Outlook sends it like that even if you select plain text as your message format, so I have resorted to composing my messages in vi and using the unix mail command...

1 0

Problems building GHC 5.00 on Solaris 2.5.1
by Whitford, Alister 16 May '01

16 May '01

I'm trying to build GHC 5.00 on Solaris 2.5.1. I've got most of the way there. So far, I've had to: - Hack glafp-utils/sgmlverb/Makefile because by lex doesn't support the -8 option. - Hack mk/target.mk in several places because my ld doesn't support the -x option. - Hack configure.in to prevent it from trying to build ReadLine (which was failing.) (Any comments on the above?) The compiler and standard libraries have all built. I'm now attempting to build DrIFT, but I get the following error: ../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp -fglasgow-exts -package text -O ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o Literate.o ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o UserRuleBinary.o UserRuleXml.o UserRules.o Undefined first referenced symbol in file siginterrupt /tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals.o) ld: fatal: Symbol referencing errors. No output written to DrIFT In fact, this occurs whenever I run ghc-inplace to try to create an executable :-( It turns out that siginterrupt is defined in /usr/ucblib/libucb.a, so if I muck about a bit, I can get a working executable like so: /tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace -o test -L/usr/ucblib -lucb test.lhs So the question is: how do I get libHSrts.a to link automatically with /usr/ucblib/libucb.a so that the compiler will work properly? Many thanks in advance for any help! Cheers, Alister.

1 0

RE: Windows binary installation for GHC 5.00
by Simon Peyton-Jones 16 May '01

16 May '01

Yes, it'll be 'soon' (days, or a week or three, but not months) Simon | -----Original Message----- | From: Bernd Holzmüller [mailto:holzmueller@ics-ag.de] | Sent: 16 May 2001 08:38 | To: glasgow-haskell-users(a)haskell.org | Subject: Windows binary installation for GHC 5.00 | | | Is there any prediction for when the Windows (NT) binary | distribution for GHC 5.00 will be available? I would not want | to install GHC5.00 from the source distribution in case the | binary distribution is going to be released "soon". Anyway, I | would expect getting an appropriate note via the | glasgow-haskell-users mailing list. | | Bernd Holzmüller | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-| users |

1 0

Windows binary installation for GHC 5.00
by Bernd Holzmüller 16 May '01

16 May '01

Is there any prediction for when the Windows (NT) binary distribution for GHC 5.00 will be available? I would not want to install GHC5.00 from the source distribution in case the binary distribution is going to be released "soon". Anyway, I would expect getting an appropriate note via the glasgow-haskell-users mailing list. Bernd Holzmüller

1 0

Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by cwitty＠newtonlabs.com 14 May '01

14 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > I didn't say that this works for any kind of parser > combinator, I merely said that it works Doitse's and mine. > Both implement SLL(1) parsers for which - as I am sure, you > know - there exists a decision procedure for testing > ambiguity. More precisely, whenever the library can build > the parse table, the grammar must be non-ambigious. As the > parse table construction is lazy, this covers only the > productions exercised in that particular run, which is why I > said that you need a "file involving all grammar constructs > of the language." Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty

1 0

Compile problems with ghc-5.0
by Gérard Milmeister 13 May '01

13 May '01

I use Redhat 6.2. The binary install is ok, but when I compile ghc-5.0 from source using ghc-5.0, I get the following error after 'make all': ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc ../../../ghc/utils/hsc2hs/hsc2hs-inplace: /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin: No such file or directory Furthermore, most available libraries seem to be uncompilable with ghc-5.0, e.g. c2hs and gtk2hs. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich

3 2

Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by cwitty＠newtonlabs.com 13 May '01

13 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > I don't think, the point is the test for non-ambiguity. At > least, Doitse's and my self-optimising parser combinator > library will detect that a grammar is ambigious when you > parse a sentence involving the ambiguous productions. So, > you can check that by parsing a file involving all grammar > constructs of the language. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty

3 2

RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by Simon Marlow 12 May '01

12 May '01

S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on > macros, I > have to ask: why use happy rather than monadic parsing? > Monadic parsing > allows you to avoid a whole additional language/compilation > step and work > in Hugs (where you don't have a makefile). What does Happy > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon

5 4

RE: GHCi turned upside down?
by Simon Marlow 11 May '01

11 May '01

> GHCi allows us to mix fixed compiled and dynamic interpreted code to > be run from what I presume is dynamic interpreted code - the command > prompt. Would it be possible to run dynamic interpreted code from > a compiled program? I'm hoping the answer is "Yes, because > this is what > GHCi does", the only problem being to clean up the syntax and document > it. It's certainly possible, but bear in mind that you'd have to link in essentially the whole of GHCi into your program in order to do it! But one of the things on our wish list is to have a clearly defined interface to the underlying compilation/session manager, (i.e. what we've been calling the HEP, or Haskell Execution Platform). This would allow you to plug in new user interfaces, make interpreted COM objects, and in general have Haskell compilation/execution services available from a Haskell API. There's still work to do in deciding exactly what this API should look like, though. Cheers, Simon

1 0