May 2001 - Haskell - Haskell.org

RE: IO Errors
by Simon Marlow 25 May '01

25 May '01

> In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon

1 0

CFP: LDTA'2002
by Marjan Mernik 25 May '01

25 May '01

[apologies if you receive multiple copies of this message] ----------------------------------------------------------- 2nd Workshop on Language Descriptions, Tools and Applications LDTA'2002 Affiliated with ETAPS'2002 April 13, 2002 Grenoble, France The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications of these language definitions and tools developed for or with these language definitions. For call for papers and additional information please check the following URL: http://www.cwi.nl/conferences/LDTA2002 Schedule Submission of full paper December 15, 2001 Notification January 31, 2002 Final version due February 28, 2002

1 0

IO Errors
by Steinitz, Dominic J 25 May '01

25 May '01

Can anyone tell me why this behaves as it does? In Hugs, I get C:\My Documents\functional\ldapsck1\buffer.hs Main> main Illegal operation (561 reductions, 1029 cells) Main> If the input file is the one line: 1234567812345678 the output file is: Starting logging 1234567812345678 Error In ghc, the program hangs without even creating a file. Dominic import IO main :: IO () main = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" ifh <- openFile "tst.txt" ReadMode let loop = do b <- try (getBuffer ifh 16) case b of Right msg -> do logMessage ofh msg loop Left e -> if isEOFError e then do logMessage ofh "Finishing logging" hClose ofh else do logMessage ofh "Error" ioError e in loop logMessage :: Handle -> String -> IO () logMessage hd msg = do hPutStrLn hd msg hFlush hd getBuffer :: Handle -> Int -> IO String getBuffer h n = if (n <= 0) then return "" else do c <- hGetChar h cs <- getBuffer h (n-1) return (c:cs) ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: a cygwin binary package of ghc-5.00.x
by Mike Thomas 25 May '01

25 May '01

Hi. > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > Thank you in advance > > > > Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas.

2 2

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

a cygwin binary package of ghc-5.00.x
by Alexander V. Voinov 24 May '01

24 May '01

Hi All, Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander

1 0

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: Building Programs
by Simon Peyton-Jones 24 May '01

24 May '01

It depends on which implementation you have. hmake is good, and is independent of implementation. ghc 5.0 has a make system built in, so you can say ghc --make Main to build your program. Or ghc --interactive Main to run it interactively. Hugs also follows module dependencies automatically. hbc had a similar mechanism I think. Simon | -----Original Message----- | From: Steinitz, Dominic J | [mailto:Dominic.J.Steinitz@BritishAirways.com] | Sent: 24 May 2001 10:46 | To: haskell | Subject: Building Programs | | | What's the recommended way of building a system consisting of | many Haskell modules? Should I use hmake, make or is there | some other preferred mechanism in the Haskell world? | | Dominic. | | -------------------------------------------------------------- | ----------------------------------- | 21st century air travel http://www.britishairways.com | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

Building Programs
by Steinitz, Dominic J 24 May '01

24 May '01

What's the recommended way of building a system consisting of many Haskell modules? Should I use hmake, make or is there some other preferred mechanism in the Haskell world? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

I/O buffering (was: Endangered I/O operations)
by Simon Marlow 24 May '01

24 May '01

[ moved from glasgow-haskell-users to haskell(a)haskell.org ] Carl Witty writes: > If the report does not allow the implementation to flush buffers at > any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be "returned to the file" (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that "Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer". What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon > I would much rather > use an implementation where stdout and stderr came out in the right > order, and reading from stdin flushed stdout. (As another example, an > implementation might want to flush all buffers before doing a fork(), > to avoid duplicated output.) > > The only caveat is that if such flushing is allowed but not required, > it might encourage writing sloppy, nonportable code. > > >

1 0