- Glasgow-haskell-users

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

Using Haskell with Java
by Dmitri Pissarenko 08 Jan '05

08 Jan '05

Hello! I have a Java application, which has a lot of GUI and one complex algorithm. I spent many months writing and debugging that algorithm, but it still has a lot of bugs. At the moment, I am thinking about implementing that algorithm in Haskell, while leaving the GUI in Java. I would like to know whether it is possible to write algorithmic (let's call them back-end) parts of a system in Haskell and user interface in Java? Can Haskell and Java parts of a system co-operate? Will such a hybrid system run on Windows and Linux? Are there any tutorials about this? Has someone already tried it? Thanks in advance Dmitri Pissarenko ----- Ende der weitergeleiteten Nachricht -----

5 5

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 08 Jan '05

08 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by ggd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Open Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 11:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-06 22:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0