February 2008 - Glasgow-haskell-users

H98 Text IO
by Duncan Coutts 27 Feb '08

27 Feb '08

>From the H98 report: All I/O functions defined here are character oriented. [...] These functions cannot be used portably for binary I/O. In the following, recall that String is a synonym for [Char] (Section 6.1.2). So ordinary text Handles are for text, not binary. Char is of course a Unicode code point. The crucial question of course is what encoding of text to use. For the H98 IO functions we cannot set it as a parameter, we have to pick a sensible default. Currently different implementations disagree on that default. Hugs has for some time used the current locale on posix systems (and I'm guessing the current code page on windows). GHC has always used the Latin-1 encoding. These days, most operating systems use a locale/codepage encoding that covers full the Unicode range. So on hugs we get the benefit of that but on GHC we do not. This is endlessly surprising for beginners. They do putStrLn "αβγδεζηθικλ" and it comes out on their terminal as junk. It also causes problems for serious programs, see for example the recent hand-wringing on cabal-devel. So here is a concrete proposal: * Haskell98 file IO should always use UTF-8. * Haskell98 IO to terminals should use the current locale encoding. The main controversial point I think is whether to always use UTF-8 or always use the current locale or some split as I've suggested. C chose to always go with the current locale. Some people think that was a mistake because the interpretation changes from user to user. For terminals it is more clear cut that the locale is the right choice because that is what the terminal is capable of displaying. Using anything else will produce junk. We can detect if a handle is a terminal when we open it using hIsTerminalDevice. This should be done automatically (and ghc would ghc get it for free because it already does that check to determine default buffering modes). Sockets and pipes would be treated the same as files when opened in the default text mode. The only special case is terminals. The major problem is with code that assumes GHC's Handles are essentially Word8 and layer their own UTF8 or other decoding over the top. The utf8-string package has this problem for example. Such code should be using openBinaryFile because they are reading/writing binary data, not String text. Note that many programs that really need to work with binary file already use openBinaryFile, those that do not are already broken on Windows which does cr/lf conversion on text files which breaks many binary formats (though not utf8). So we have decide which is more painful, keeping a limited text IO system in GHC or breaking some existing programs which assume GHC's current behaviour. Opinions? Please can we keep this discussion to the interpretation of the H98 IO functions and not get into the separate discussion of how we could extend or redesign the whole IO system. This is a questions of what are the right defaults. Duncan

7 15

Re: H98 Text IO
by Reinier Lamers 26 Feb '08

26 Feb '08

Op 26-feb-2008, om 18:42 heeft Chris Kuklewicz het volgende geschreven: > The goal is that more complicated situations are reflected in > more complicated "ghc" or "main" invocations. The least complicated > usage defaults to being identical cross-platform and regardless of > terminal I/O. > > I think the best default would be UTF8 for all text handles. This can > be easily documented, it can be easily understood, and will produce > the fewest suprises. > (...) > ** Unless influenced by command-line switches, these default to UTF8. I think that making the behavior of programs change, depending on compiler options, will produce a lot of surprises. I think that being only able to set the default encoding from within the program is a better idea, because it keeps the specification of the behavior of the program inside the source. Reinier

2 1

how to use ghci-debugger with packages
by Frederik Eaton 26 Feb '08

26 Feb '08

Hello, I have a program which uses some code in a package, and I would like to be able to find out the source of an error which is occuring inside that package. Can I use the ghci-debugger to do this? If I try to set a breakpoint inside the package, it says: "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module Vector.Sparse.Wrappers is not interpreted" But this page: http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html has no use of the word "package", so I assume that reading that (long) document won't ansnwer my question... Thank you, Frederik -- http://ofb.net/~frederik/

3 5

Visual Haskell sources
by Andrei Formiga 26 Feb '08

26 Feb '08

Hello, The Visual Haskell 0.2 release notes [1] say that sources are available, but the download page only has binaries available. Where are the sources? Also, does it use the Visual Studio SDK, and is it compatible with VS 2008? Thanks. [1] http://haskell.org/visualhaskell/doc/index.html#release-notes -- []s, Andrei Formiga

2 1

Re: Problem with Windows ghc 6.8.2
by Matthew Bentham 24 Feb '08

24 Feb '08

----- Original Message ---- > From: Daniel Fischer <daniel.is.fischer(a)web.de> > To: Matthew Bentham <matthew_bentham(a)yahoo.com>; glasgow-haskell-users(a)haskell.org > Sent: Sunday, February 24, 2008 1:13:48 AM > Subject: Re: Problem with Windows ghc 6.8.2 > > Am Sonntag, 24. Februar 2008 01:54 schrieb Matthew Bentham: > > Hi all, > > > > I'm not too experienced with ghc or Haskell, so I wanted to check here > > rather than submitting a bug: > > It's probably the base-split. In 6.6.1, Text.PrettyPrint was in the base > package, in 6.8.2 it's in the pretty package. > Try compiling with -package pretty, or better still, with --make: > > /path/to/ghc --make test > > or > > /path/to/ghc -o test.exe test.hs -package pretty > > If that's not it, you might have a real problem. Thanks, they both work great. Matthew

1 0

Problem with Windows ghc 6.8.2
by Matthew Bentham 24 Feb '08

24 Feb '08

Hi all, I'm not too experienced with ghc or Haskell, so I wanted to check here rather than submitting a bug: $ cat test.hs import Text.PrettyPrint main = print "foo" $ /c/ghc/ghc-6.6.1/bin/ghc test.hs $ ./main.exe "foo" $ /c/ghc/ghc-6.8.2/bin/ghc test.hs test.o(.text+0x217):fake: undefined reference to `__stginit_prettyzm1zi0zi0zi0_TextziPrettyPrint_' $ I'm using Vista64. The session above was copied from a cygwin shell, but it does the same in an msys shell or cmd.exe. Both versions of ghc were installed using the official binary distribution. I'm having trouble compiling ghc from source at the moment (I think there's another issue I'm hitting with the 6.6.1 build, haven't tracked it down yet) so I can't debug what is going wrong myself. I'd appreciate people's advice about what to do. Should my test program work or am I doing something wrong? Maybe there are some optional libraries to install that I have missed, that used to be core? Output from ghc -v test.hs follows: $ rm test.hi $ $ $ /c/ghc/ghc-6.8.2/bin/ghc -v test.hs *** Tidy Core: Result size = 16 writeBinIface: 1 Names writeBinIface: 7 dict entries *** CorePrep: Result size = 18 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: c:\ghc\ghc-6.8.2\gcc -Bc:\ghc\ghc-6.8.2\gcc-lib/ -I. -c c:\Users\mjb67\AppData\Local\Temp\ghc4332_0\ghc4332_0.s -o test.o *** Windres: c:\ghc\ghc-6.8.2\bin/windres --preprocessor="c:\ghc\ghc-6.8.2\gcc" "-Bc:\ghc\ghc-6.8.2\gcc-lib/" "-E" "-xc" "-DRC_INVOKED" --use-temp-file --input=c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.rc --output=c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o --output-format=coff *** Linker: c:\ghc\ghc-6.8.2\gcc -Bc:\ghc\ghc-6.8.2\gcc-lib/ -v -o main.exe -DDONT_WANT_WIN32_DLL_SUPPORT test.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o -Lc:/ghc/ghc-6.8.2/lib\haskell98-1.0.1.0 -Lc:/ghc/ghc-6.8.2/lib\array-0.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\process-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\random-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\directory-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\filepath-1.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-time-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-locale-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _base_GHCziBase_Izh_static_info -u _base_GHCziBase_Czh_static_info -u _base_GHCziFloat_Fzh_static_info -u _base_GHCziFloat_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _base_GHCziBase_Izh_con_info -u _base_GHCziBase_Czh_con_info -u _base_GHCziFloat_Fzh_con_info -u _base_GHCziFloat_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _base_GHCziBase_False_closure -u _base_GHCziBase_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_GHCziIOBase_NonTermination_closure -u _base_GHCziIOBase_BlockedOnDeadMVar_closure -u _base_GHCziIOBase_BlockedIndefinitely_closure -u _base_GHCziIOBase_Deadlock_closure -u _base_GHCziIOBase_NestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure Reading specs from c:/ghc/ghc-6.8.2/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) ld -Bdynamic -o main.exe -u _base_GHCziBase_Izh_static_info -u _base_GHCziBase_Czh_static_info -u _base_GHCziFloat_Fzh_static_info -u _base_GHCziFloat_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _base_GHCziBase_Izh_con_info -u _base_GHCziBase_Czh_con_info -u _base_GHCziFloat_Fzh_con_info -u _base_GHCziFloat_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _base_GHCziBase_False_closure -u _base_GHCziBase_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_GHCziIOBase_NonTermination_closure -u _base_GHCziIOBase_BlockedOnDeadMVar_closure -u _base_GHCziIOBase_BlockedIndefinitely_closure -u _base_GHCziIOBase_Deadlock_closure -u _base_GHCziIOBase_NestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure c:/ghc/ghc-6.8.2/gcc-lib/crt2.o c:/ghc/ghc-6.8.2/gcc-lib/crtbegin.o -Lc:/ghc/ghc-6.8.2/lib\haskell98-1.0.1.0 -Lc:/ghc/ghc-6.8.2/lib\array-0.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\process-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\random-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\directory-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\filepath-1.1.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-time-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\old-locale-1.0.0.0 -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -Lc:/ghc/ghc-6.8.2/gcc-lib test.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o -lHShaskell98-1.0.1.0 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSrandom-1.0.0.0 -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/ghc/ghc-6.8.2/gcc-lib/crtend.o test.o(.text+0x217):fake: undefined reference to `__stginit_prettyzm1zi0zi0zi0_TextziPrettyPrint_' *** Deleting temp files: Deleting: c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.o c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.rc c:/Users/mjb67/AppData/Local/Temp/ghc4332_0/ghc4332_0.s *** Deleting temp dirs: Deleting: c:/Users/mjb67/AppData/Local/Temp/ghc4332_0

2 1

hs-plugins -- simple example fails
by Peter Collingbourne 22 Feb '08

22 Feb '08

Hello, I'm having problems trying to use hs-plugins (the darcs version, as I am on a 64-bit machine). The test suite mostly works without problems, but I can't get my own code to work. I put together a simple example which illustrates my problem: Main.hs ==================== module Main (Tree(..), Interface(..), main) where import Ptr import System.Plugins data Tree = Tree (Ptr Tree) data Interface = Interface { processTree :: Ptr Tree -> IO (Ptr Tree) } main = load "XYZuse.o" ["."] [] "resource" >>= (\(LoadSuccess _ v) -> (processTree v nullPtr)) ==================== XYZuse.hs ==================== module XYZuse (resource) where import Main resource = Interface { processTree = return } ==================== This is the output I get: ==================== $ ghc -c -o Main.o Main.hs $ ghc -c -o XYZuse.o XYZuse.hs $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package Cabal-1.1.6 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src-1.0 ... linking ... done. Loading package plugins-1.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol Main_processTree_closure whilst processing object file ./Main.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. ==================== Thanks, -- Peter

2 1

Recursion over lists
by TOPE KAREM 22 Feb '08

22 Feb '08

Hello everyone, I am just learning to program in Haskell, and I found recursion very interesting. However, I need to write a recursive function over two lists. The function must check the elements in the two lists and return an element that is common to both lists if there is any. Any assistance would be appreciated. Thank you.

3 2

ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
by Manuel M T Chakravarty 20 Feb '08

20 Feb '08

Ladies and Gentlemen, Finally, you can have the glorious GHC in a format satisfying the discerning Mac user: http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg Installation instructions: nil This is *not* the same compiler as in the official 6.8.2 release. It is the state of the 6.8 branch at the 11th of February - hence, the funny version number. Once, 6.8.3 is being released, there'll be a clean release package. The package includes all extra libraries and full documentation. It installs GHC systemwide and requires an admin password. Happy Installing! Manuel -=- Extra details for the curious -=- GHC is being packaged as a framework bundle - GHC.framework - that is installed in /Library/Frameworks/. As far as I can tell this is the most appropriate way of bundling a compiler environment on the Mac. Frameworks are versioned and we use GHC's integer version number to assign framework versions - ie, the present package installs version 608. This is in line with Apple's recommendation to use version numbers that signify API changes for frameworks. The package installs appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to make the binaries, ghc manpage, and html documentation easily accessible. Furthermore, it comes with a shell script that removes the GHC.framework and all symbolic links into the framework. The framework is currently not relocatable and an admin password is needed to install it. Contributions improving this situation would be most welcome. The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all. The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC). I am less sure about building packages on Tiger as I don't know whether the underlying Xcode project requires Xcode 3.0 - Tiger only has 2.5. However, it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.) Further information on GHC installer packages as well as instructions on how to build your own are at http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer

8 28

ghc-6.8.1 on WinXP: windres: can't open font file `for'
by Bayley, Alistair 20 Feb '08

20 Feb '08

I've just installed ghc-6.8.1 on my WinXP workstation (I already have it successfully working on my laptop). When I compile anything, the linking stage fails with: c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory Any clues as to what's wrong? Google isn't very helpful... (I've stripped my path back to just windows, windows\system32, and ghc, but no joy). Alistair P.S. output from ghc -v3 (trimmed): Linking Main.exe ... *** Windres: c:\ghc\ghc-6.8.1\bin/windres --preprocessor=c:\ghc\ghc-6.8.1\gcc -Bc:\ghc\ghc-6.8.1\gcc-lib/ -E -xc -DRC_INVOKED --input=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.rc --output=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.o --output-format=coff c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory The .rc file it is given contains: 1 24 MOVEABLE PURE "Main.exe.manifest" so this "... font file 'for':..." message is a puzzle. ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 6