January 2005 - Glasgow-haskell-users

HaXml and ghc-current
by Peter Simons 12 Jan '05

12 Jan '05

Hi, I've just tried to install HaXml with the latest GHC from CVS, and the package compiles fine but the installation procedure aborts with: ghc-pkg: cannot find package HaXml `cat ghcpkgcmd` --add-package <pkg.conf Reading package info from stdin... ghc-pkg: Line 1: Invalid syntax (no colon after field name) Apparently something has changed in the package database format? I haven't been following all this, so I am a bit at a loss what to do. Has anyone else managed to install HaXml successfully? Any advice? Peter

3 6

RE: 6.4 News
by Simon Marlow 12 Jan '05

12 Jan '05

On 12 January 2005 12:49, Christian Maeder wrote: > in a new version of ghc I've noticed that a colon in a path (as > argument to "-i") is no longer recognized. Will this also be the case > in the new version ghc-6.4? Thanks! In fact I broke that by accident recently. Now fixed. Cheers, Simon

1 0

6.4 News
by Christian Maeder 12 Jan '05

12 Jan '05

Hi, in a new version of ghc I've noticed that a colon in a path (as argument to "-i") is no longer recognized. Will this also be the case in the new version ghc-6.4? Cheers Christian This used to compile with ghc6.2.2: ghc --make -v -i../DrIFT-src:../.. GenerateRules.hs [...] Glasgow Haskell Compiler, Version 6.3.20050101 [...] GenerateRules.hs: Could not find interface file for `Common.Utils' locations searched: ../DrIFT-src:../../Common/Utils.hs ../DrIFT-src:../../Common/Utils.lhs Common/Utils.hs Common/Utils.lhs if I give several -i flags it works: ghc --make -i../DrIFT-src -i../.. GenerateRules.hs

1 0

Unicode in GHC: need some advice on building
by Dimitry Golubovsky 11 Jan '05

11 Jan '05

Hi, Following up the discussion in Haskell-Cafe about ways to bring better Unicode support in GHC. I may take care on putting this into the GHC runtime, but I need some advice as I am completely new to this. What needs to be done primarily, is to replace the FFI calls made from GHC.Unicode (iswupper, islower etc.) with functions implemented directly in the runtime, or in an external library (independent from libc). I tried to do this in two ways. First, I made a shared object containing substitutes for these functions (draft code, based on what I submitted for Hugs some time ago), and LD_PRELOADed it. Everything went fine, and my small test program worked both compiled to binary and in GHCi (it just coredumped when towlower/towupper was called on non-ASCII character without the substitution library). Bad thing is, LD_PRELOAD does not work on all systems. So I tried to put the code directly into the runtime (where I believe it should be; the Unicode properties table is packed, and won't eat much space). I renamed foreign function names in GHC.Unicode (to avoid conflict with libc functions) adding u_ to them (so now they are u_iswupper, etc). I placed the new file into ghc/rts, and the include file into ghc/includes. I could not avoid messages about missing prototypes for u_... functions , but finally I was able to build ghc. Now when I compiled my test program with the rebuilt ghc, it worked without the LD_PRELOADed library. However, GHCi could not start complaining that it could not see these u_... symbols. I noticed some other entry points into the runtime like revertCAFs, or getAllocations, declared in the Haskell part of GHCi just as other foreign calls, so I just followed the same style - partly unsuccessfully. Where am I wrong? Another thing, this might be done without intervention into the sources, just as an external library. Which would be the best placement for the library, so it would load/compile in automatically? I tried to find information in the GHC Commentary, but it did not give me much. Dimitry Golubovsky Middletown, CT

2 1

RE: Bug in libcompat
by Simon Marlow 10 Jan '05

10 Jan '05

On 08 January 2005 18:15, Krasimir Angelov wrote: > I found a bug in libcompat. GHC-6.3 automatically > defines mingw32_TARGET_OS macro, but previous versions > does't. When GHC is compiled with GHC < 6.3 then > System.FilePath and probably some other modules aren't > compiled properly. What should be done? Maybe it is > enough to add #include <ghcconfig.h> in the begining > of each module from libcompat but I don't know whether > this will not affect something other. > Main.hs from ghc-pkg imports > Distribution.Compat.ReadP which is hiden module when > GHC is compiled with GHC-6.3 but it is available from > libcompat when GHC < 6.3 is used. I think I've fixed these. Cheers, Simon

1 0

RE: Loading package GHC in GHCi
by Simon Marlow 10 Jan '05

10 Jan '05

On 09 January 2005 06:50, Sean Seefried wrote: > I have managed to build package GHC *and* load it into GHCi. > Initially this did not work. When I loaded up ghci with the -package > ghc flag I was assaulted with the following error message. > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol > _OutOfHeapHook > whilst processing object file > /Users/sseefried/cvs-ghc/PLUGGABLE/working/ghc/compiler/HSghc.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. > > I tracked down this symbol in the GHC source and found it in > ghc/compiler/parser/hschooks.c. The purpose of redefining the > functions within this file is apparently to improve the quality of the > error messages. That is, the symbols generated are meant to override > those in the RTS. Unfortunately GHCi doesn't like this at all. At the > moment it prohibits loading a symbol that is already in the RTS, which > seems very reasonable from a certain perspective - I can see that a > duplicate symbol would usually be an error. Except that in the case we > really *do* want to load it so that it overrides the old one. > > The only solution I can come up with is a modification to the > package.conf syntax so that one can specify symbols which are part of > the RTS package and the package in question. We could then modify the > dynamic linker of GHC so that these symbols were removed from the > RTS's symbol table. The symbols would then be loaded back in again > in with the package thus overriding the old symbols. > > What do you think of this proposal? I haven't implemented it yet > because the alternative - that of simply removing the conflicting > symbols from package ghc might be what you want. My temporary fix for > getting package ghc to load into GHCi is just this - I strip the > symbols that overlap between the RTS and package ghc. However, this > means that the code that was supposed to be overridden in the RTS is > no longer being overridden. Although this works this doesn't seem to > be what we want. I'm not keen on adding new syntax to package.conf for this. We shouldn't rely on the overriding behaviour - it's non-portable anyway. I think the best solution is for these hooks to be replaced by variables containing function pointers, in the same way as the "hooks" in RtsMessages.c. The user program has to override main() in order to set them, but this is done portably by using the -no-hs-main option to GHC, and a standard main() is pretty small. Cheers, Simon

1 0

self-import
by John Meacham 10 Jan '05

10 Jan '05

It would be useful to be able to do a module Doc.Pretty.Long.Name where import Doc.Pretty.Long.Name as This so within the module we can refer to itself as 'This' without having to write out the full name, however ghc complains that the hi file for the module it is trying to compile is not available. It would be nice if ghc could recognize the self-import case and handle it directly. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

Loading package GHC in GHCi
by Sean Seefried 09 Jan '05

09 Jan '05

Hi Simon (and others), I have managed to build package GHC *and* load it into GHCi. Initially this did not work. When I loaded up ghci with the -package ghc flag I was assaulted with the following error message. GHCi runtime linker: fatal error: I found a duplicate definition for symbol _OutOfHeapHook whilst processing object file /Users/sseefried/cvs-ghc/PLUGGABLE/working/ghc/compiler/HSghc.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. I tracked down this symbol in the GHC source and found it in ghc/compiler/parser/hschooks.c. The purpose of redefining the functions within this file is apparently to improve the quality of the error messages. That is, the symbols generated are meant to override those in the RTS. Unfortunately GHCi doesn't like this at all. At the moment it prohibits loading a symbol that is already in the RTS, which seems very reasonable from a certain perspective - I can see that a duplicate symbol would usually be an error. Except that in the case we really *do* want to load it so that it overrides the old one. The only solution I can come up with is a modification to the package.conf syntax so that one can specify symbols which are part of the RTS package and the package in question. We could then modify the dynamic linker of GHC so that these symbols were removed from the RTS's symbol table. The symbols would then be loaded back in again in with the package thus overriding the old symbols. What do you think of this proposal? I haven't implemented it yet because the alternative - that of simply removing the conflicting symbols from package ghc might be what you want. My temporary fix for getting package ghc to load into GHCi is just this - I strip the symbols that overlap between the RTS and package ghc. However, this means that the code that was supposed to be overridden in the RTS is no longer being overridden. Although this works this doesn't seem to be what we want. Cheers, Sean

2 1

Newbie question
by Dmitri Pissarenko 09 Jan '05

09 Jan '05

Hello! I am learning Haskell according to the "Yet Another Haskell Tutorial" by Hal Daume Ill. One of the exercises involves a) asking the user to enter several numbers (while the end of the sequence is indicated by entering 0) b) calculate the sum of those numbers. The program given below tries to do that. I can read a list of strings. Then, I try to convert the list of strings into a list of numbers by means of map. That is, given a list ["1","2","3"], I want to convert it into [1,2,3]. In GHCi, this is done via map read ["1","2","3"] However, when I apply this same call in my program below, I'm getting following error when loading the program in GHCi: <error-message> Loading package base ... linking ... done. Compiling Main ( AskForNumbers.hs, interpreted ) AskForNumbers.hs:10: Couldn't match `IO' against `[]' Expected type: IO t Inferred type: [b] In the application `map read words' In a 'do' expression: map read words Failed, modules loaded: none. </error-message> Line 10 corresponds to the statement map read words, which seems to work in GHCi. What am I doing wrongly? Thanks in advance Dmitri Pissarenko PS: What follows is my Haskell program. module Main where import IO main = do hSetBuffering stdin LineBuffering words <- askForNumbers printWords words map read words putStrLn "The sum is" foldl (+) 0 words askForNumbers = do putStrLn "Please enter a number:" text <- getLine if text == "" then return [] else if text == "0" then return [] else do rest <- askForNumbers return (text : rest) printWords [] = putStrLn "EOL" printWords (h : t) = do putStrLn h printWords t

3 3

Bug in libcompat
by Krasimir Angelov 08 Jan '05

08 Jan '05

I found a bug in libcompat. GHC-6.3 automatically defines mingw32_TARGET_OS macro, but previous versions does't. When GHC is compiled with GHC < 6.3 then System.FilePath and probably some other modules aren't compiled properly. What should be done? Maybe it is enough to add #include <ghcconfig.h> in the begining of each module from libcompat but I don't know whether this will not affect something other. Main.hs from ghc-pkg imports Distribution.Compat.ReadP which is hiden module when GHC is compiled with GHC-6.3 but it is available from libcompat when GHC < 6.3 is used. Cheers, Krasimir __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0