- Glasgow-haskell-users

RE: Endangered I/O operations
by Simon Marlow 22 May '01

22 May '01

> If you handle std{in,out,err} connectedness in other ways, I > think you've > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from > Korn & Vo's SFIO, but it hasn't proved to be all that useful. I wasn't planning to handle connectedness at all. Is it important, do you think? (I'm not against the feature, just trying to avoid feeping creaturism...) Cheers, Simon

2 1

hTell
by Simon Marlow 21 May '01

21 May '01

Quick question: can anyone tell me why IOExts.hTell returns a HandlePosition, whereas IO.hSeek takes an Integer?

2 1

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