December 2003 - Glasgow-haskell-users

GHC Warning Request
by Ashley Yakeley 28 Dec '03

28 Dec '03

When -fwarn-unused-imports is switched on, "import M()" should not issue a warning. In 6.2, it does. The idea is that I only wish to import instance declarations here, and that's the obvious way of making that explicit. I'm using -Werror (new in 6.2, thanks), and most of the time I'm interested in knowing about superfluous imports. -- Ashley Yakeley, Seattle WA

1 0

GHC 6.2 breaks multiline string literals
by Stefan Reich 28 Dec '03

28 Dec '03

This worked in GHC 6.0.1: multilineLiteral = " line1 line2" But doesn't work in GHC 6.2. Is this a bug or rather a bugfix? Anyway, I found it very convenient to embed verbatim string blocks this way. Is there maybe another way to achieve the same thing? Thanks in advance, -Stefan

4 4

ANNOUNCE: GHC version 6.2
by Simon Marlow 27 Dec '03

27 Dec '03

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 6.2 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.2. Highlights include: * Arrows syntax * New pragma: UNPACK for selectively unpacking strict constructor fields. * New option -e for giving an expression to evaluate on the command-line. * Portability improvements. GHC has been ported to a few new platforms. * Removal of obsolete features: _ccall_, _casm_, ``...''. * Many bugs fixed See the release notes for a full list of the changes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6.2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

9 12

RE: ghc-6.2 compilation problems
by Simon Marlow 23 Dec '03

23 Dec '03

> > > The build output is like so: > > [snip] > > > Fail: does not exist > > > Action: openFileEx > > > Reason: No such file or directory > > > File: base/base.haddock > > > > Hmmm. It's possible the gentoo ebuild is trying to 'make > install-docs' > > without building the docs in the first place. > > This has indeed been the problem and is hopefully fixed by now. > However, the question remains what exactly the use of the variable > NO_HADDOCK_DOCS is if it can be set to yes and haddock is still > called at least once it in the libraries dir (I think to create > the file index.html). Could you perhaps explain the intention behind > the NO_HADDOCK_DOCS variable? Oops, the libraries Makefile should really check NO_HADDOCK_DOCS. Thanks for pointing it out. Cheers, Simon

1 0

RE: ghc-6.2 compilation problems
by Simon Marlow 22 Dec '03

22 Dec '03

> I'm getting problems building ghc 6.2. It fails building the > documentation (which I didn't really want anyway). I'm using > the gentoo ebuild script. > > I've got haddock 0.6 installed. (That was my first error!) > I'm hoping someone might know what is going wrong here. I'll > report back > to the gentoo ghc package maintainer. > > The build output is like so: [snip] > Fail: does not exist > Action: openFileEx > Reason: No such file or directory > File: base/base.haddock Hmmm. It's possible the gentoo ebuild is trying to 'make install-docs' without building the docs in the first place. Cheers, Simon

2 1

RE: Concurrency problems with Handle
by Simon Marlow 22 Dec '03

22 Dec '03

> Now, if I let one side of the connection send some characters: > sequence_ $ take 10 $ repeat $ (writeChan outputChan 's') > and I let the other side consume them: > sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) > then the characters are sent and received correctly, but the > receiving side > shows the characters only after the connection is closed. This looks correct: stdout is probably buffered. To see the characters as they are written, hSetBuffering stdout NoBuffering. If this doesn't work, then there is probably some other buffereing going on somewhere (don't run it in emacs, for example). > If I let both sides send and consume characters in turn, like this: > sequence_ $ take 10 $ repeat $ threadDelay 250 >> > (writeChan outputChan > 's') >> (putChar =<< readChan inputChan) > and > sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) >> > threadDelay 250 >> (writeChan outputChan 'c') > , one character is sent, and the other end waits indefinitely before > sending his character. Could be a bug. Can you construct a complete program which illustrates the problem, and send it to us? > Could it have anything to with this? > "One final note: the aaaa bbbb example may not work too well > on GHC.... I suspect that this is not the problem, since the case being referred to in the docs here is where two running threads are competing for the same resource, which doesn't seem to be the case in your code. Cheers, Simon

1 0

GHC and UNICODE...
by MR K P SCHUPKE 22 Dec '03

22 Dec '03

Whilst I appreciate the topic of show is not directly related to GHC, what I would like to know is how to handle UNICODE properly... If I assume I have a good unicode terminal, so stdin and stdout are in unicode format, and all my text files are in unicode, how do I deal with this properly in GHC... what is the current state of affairs? Regards, Keean.

3 2

RE: GHC and UNICODE...
by Simon Marlow 22 Dec '03

22 Dec '03

> something I have wanted to do is modify Alex so that ∀ turns into the > regular expression 0xe2 0x88 0x80 (and so forth) so that ghc (whose > lexer is generated from alex) can simply accept utf8 input. I also really want to get GHC accepting UTF-8 source files, but I don't think this is the best way to go about it. Sure, you can run Alex over the UTF-8 source, but the grammar will be huge. A simpler way is to take advantage of the fact that Haskell only uses 5 classes of Unicode characters: uniSmall, uniLarge, uniWhite, uniSymbol, and uniDigit. Alex has a good input abstraction behind which you can hide the translation from UTF-8 to Char, so you can map these 5 classes of unicode characters onto 5 special Char values, and use Alex unmodified. Well, perhaps Alex will need a small modification so that its upper bound on Char values is variable (currently it is fixed at 255). Then you have to think about whether GHC keeps strings internally in UTF-8 or expanded unicode. Perhaps UTF-8 is initially easier (not much change to the FastString type), but this might have further ramifications. Hmmm... looks like a good project to put on the GHC Task List! Cheers, Simon

1 0

RE: How to force finalization of ForeignPtr
by Simon Marlow 22 Dec '03

22 Dec '03

[ forwarded to ffi(a)haskell.org ] > In the current implementation there is no way to > force finalization of the foreign ptr if there are > still references to it. In this scenario > the finalization will be executed during the next > garbage collection. In some cases it is known that the > foreign pointer value is not used anymore but the > references still exist in the stack and they cannot be > freed from the collector. In such cases I want to be > able to explicitly finalize the foreign pointers. For > that reason I wrote the following simple function: > > module FinalizeForeignPtr(finalizeForeignPtr) where > > import GHC.ForeignPtr > import Data.IORef > > finalizeForeignPtr :: ForeignPtr a -> IO () > finalizeForeignPtr foreignPtr = do > finalizers <- readIORef refFinalizers > sequence_ finalizers > writeIORef refFinalizers [] > where > refFinalizers = case foreignPtr of > (ForeignPtr _ ref) -> ref > (MallocPtr _ ref) -> ref There's a race condition between multiple finalizeForeignPtrs, but apart from that it looks fine. I don't see any reason why we shouldn't have this. GHC's weak pointer interface has a similar function for running the finalizer early. Cheers, Simon

1 0

RE: ghc-6.2 compilation problems
by Simon Marlow 22 Dec '03

22 Dec '03

> This is ghc-6.2, trying to built it with ghc-6.2: > > > $ ./configure --with-x --enable-threaded-rts --enable-objectio > --enable-hopengl This looks like a problem with ObjectIO - Krasimir? Cheers, Simon

1 0