May 2005 - Glasgow-haskell-users

GHC as library
by Robert Dockins 09 May '05

09 May '05

I seem to recall some time ago the Simons asked on one of these lists about uses people might have for GHC-as-library. It sounded really neat to me, and I just kind of wonder if there is any motion on that front. I'm thinking about hacking up a system to extract proof obligations into Coq (http://coq.inria.fr/) from Haskell, and being able to get my hands on various things would be really nice (like being able to get at the AST after typechecking, but before conversion to core). Robert Dockins

1 0

RE: Can't compile GHC
by Simon Marlow 09 May '05

09 May '05

On 09 May 2005 16:03, Daniel Carrera wrote: > robert dockins wrote: > >> Perhaps. Nonetheless it is common practice for compilers to be >> written in the target language and to be compiled via bootstrapping. >> Ever take a look at the GCC sources? You guessed it: C. > > Please don't confuse the compiler being written in the target language > with the compiler requiring itself. It should be possible to compile > it with a compiler for a /different/ language. > > You can compile gcc with Sun's CC. You should be able to compile ghc > with nh98. It is possible to compile GHC without having GHC installed, there are detailed instructions in the Building Guide. Indeed you found the instructions, but gave up because the instructions talked about "porting". So is that all you're complaining about? While it's a bit fiddly to get GHC up for the first time, you only have to do it once. Hence, making this easier is not a top priority. Cheers, Simon

6 5

Can't compile GHC
by Daniel Carrera 09 May '05

09 May '05

Hello, I've been trying to learn Haskell. Some software isn't user friendly. But I think that a compiler requiring itself to compile is actively user hostile. I've spent over a week trying to get GHC to work on my Solaris workstation and I've concluded that it just isn't going to happen. I tried to compile GHC but it said taht it needed GHC to compile. I read the README trying to find out what people without ghc are supposed to do to install ghc. But no instructions are found. I check the website, hoping to find a binary. I find an old binary, but it just won't work. Something about libgcc_s.so.1. After a lot of work, I got another Haskell compiler, NHC98. Hoping that would do, I tried to compile GHC again. No luck. I read something about .hc files. I look everywhere in the source distribution, but no .hc files are to be found. I go back to the website. Read the building guide section on "porting" Why would I read that? I don't want to port it, I just want to compile it on a platform it's already been ported to. The porting page says that the source distribution has ANNOUNCE files that tell me where to get the .hc files. I wonder why it didn't just tell me directly, but oh well, I go back to the source distribution. It turns out the building guide was lying. The ANNOUCE file doesn't say anything about .hc files or where to get them. I find the file distrib/hc-build. I figure I might as well try it. Nothing to lose. But nope, that didn't do it either. At this point I really wonder why the compiler was designed this way instead of doing the configure; make; make install that everyone else does. It's not often that it takes me more than a week to compile a program. At this point I decide that I'll teach people Python instead of Haskell. I don't particularly like Python, but hey, it works. Best, Daniel.

8 12

RE: Porting the GHC to GNU/Hurd
by Simon Marlow 09 May '05

09 May '05

On 20 April 2005 17:34, Thomas Schwinge wrote: > On Sun, Apr 10, 2005 at 10:39:08PM +0100, Simon Marlow wrote: >> On 10 April 2005 14:20, Thomas Schwinge wrote: >>> Is someone aware of any efforts to port the GHC to GNU/Hurd? >>> If not, I'd like to give that a try. >> >> No, and good luck! > > I should be able to get it going using .hc files from i386-linux. > Correct? > But where can I find these files or how can I create them myself? I > was not (yet) able to find instructions about creating them in the > "porting guide" and a web search also didn't reveal anything useful, > yet. Just follow the instructions in section 10.2 of the Building Guide: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l#unregisterised-porting that tells you how to build the .hc files and bootstrap from them on the target machine. Cheers, Simon

2 1

The signature contexts in a mutually recursive group should all be identical
by Robert van Herk 09 May '05

09 May '05

Hi all, I am having a question about the "The signature contexts in a mutually recursive group should all be identical"-message. From what I understand from previous posts on this subject is that this is not strictly necessary, but is in the Haskell '98 specs, and that this error message only occurs in toy programs. How ever, I think I am having a real example of a restriction caused by this message. The example is very big though (more than 1000 lines). What it boils down to is the following: I am writing a framework for website development. In this framework, a webpage, or a piece of a webpage, is called a component. I have 2 important components, namely "def" and "myComp". myComp is being parametrized by some "accessors", i.e. functions that read and write IORefs. wfAction creates a link in the generated HTML code to another component. That is: when the client clicks that link, he will see the html generated by the component wfAction was parametrized by. In the example below, in def, when the client clicks "Click here for another component" in his webbrowser, he will see the contents of (myComp accessors). In myComp, I made a wfAction back to def. I *think* this should all work. However, I get a compile error, saying that the contexts of def and myComp are different: Contexts differ in length When matching the contexts of the signatures for myComp :: forall e r4 r2 r3 v. (AdmitChildHTML e, WFReader r4 Int, WFErrorWriter r2, WFWriter r2 [Char], WFErrorReader r2, WFReader r2 String, WFReader r3 v, WFErrorReader r3, WFWriter r3 String, Show v, WFErrorWriter r3) => WFHTMLComponent (MyCompAccessors (R Bool) r2 r3 r4) e IO () def :: forall e. (AdmitChildHTML e) => WFHTMLComponent' e IO () def :: AdmitChildHTML e => WFHTMLComponent' e IO () def = do { accessors <- liftIO $ myCompController; html (do doc_head body ( do text "Welcome" br empty wfAction "Click here for another component" (myComp accessors) ) ) ; } data MyCompAccessors r1 r2 r3 r4 = (WFReader r4 Int) => MyCompAccessors {loginAccessors::(MyLoginAccessors r1 r2 r3), rReloadCount::r4} myCompController :: IO (MyCompAccessors (R Bool) (RWE String) (RWE String) (R Int)) myCompController = ... --returns something that can read booleans, read and write strings, read and write strings, read integers myComp :: (AdmitChildHTML e, WFReader r4 Int, WFErrorWriter r2, WFWriter r2 [Char], WFErrorReader r2, WFReader r2 String, WFReader r3 v, WFErrorReader r3, WFWriter r3 String, Show v, WFErrorWriter r3) => WFHTMLComponent (MyCompAccessors (R Bool) r2 r3 r4) e IO () myComp compAccessors = do { i <- wfRead (rReloadCount compAccessors); html ( do doc_head body ( do text ( "This is the " ++ (show i) ++ "th time you are seeing this page within this session." ) br empty ... --include some other components wfAction "Click here to see the default component again" def; --THIS IS WHAT MAKES IT ALL GO WRONG ) ) ; } data MyLoginAccessors r1 r2 r3 = (WFReader r1 Bool, WFReader r2 String, WFWriter r2 String, WFReader r3 String, WFWriter r3 String ) => MyLoginAccessors {rLoggedIn::r1, rwLogin::r2, rwPasswd::r3} myLoginController :: IO (MyLoginAccessors (R Bool) (RWE String) (RWE String)) myLoginController = ...

1 0

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

09 May '05

Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Closed 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: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 16:33 Message: Logged In: YES user_id=139853 (Well fwiw all gtk2hs-0.9.7/demos segfault for me too.) ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 09:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 19: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-07 06: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

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

08 May '05

Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Closed 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: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 09:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 19: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-07 06: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

[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
by SourceForge.net 08 May '05

08 May '05

Feature Requests item #1084122, was opened at 2004-12-13 10:54 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: John Skaller (skaller) Assigned to: Nobody/Anonymous (nobody) Summary: RPM doesn't support --prefix Initial Comment: After installing ghc for linux using rpm with --prefix=/usr/local, the ghc scriipt incorrectly thinks the libraries etc are in /usr: #!/bin/sh GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2"; TOPDIROPT="-B/usr/lib/ghc-6.2.2"; # Mini-driver for GHC exec $GHCBIN $TOPDIROPT ${1+"$@"} After editing, at least the compiler actually starts up :) ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 08:57 Message: Logged In: YES user_id=139853 Not really sure what the right solution is - one hack that comes to mind is adding a %post install script in the spec file that would replace the default prefix with the specified one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-12 22:06 Message: Logged In: NO Still a problem with 6.2.4 - Additionally, you now need to edit the package.conf file. Karl M. Syring syring(a)email.com ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-14 01:26 Message: Logged In: YES user_id=48280 Re-opened. Any RPM gurus out there who could knock this one on the head? Note it's not just the ghc script, there's a couple of other scripts that need munging (ghci, ghc-pkg, hsc2hs maybe). ---------------------------------------------------------------------- Comment By: John Skaller (skaller) Date: 2004-12-13 23:54 Message: Logged In: YES user_id=5394 I can see it isn't supported :) However after the change to those two lines, the compiler works, links libraries, and the resultant binary executes correctly (as far as I can tell never having written any Haskell before .. :) So why not support it? I had no choice .. my root partition, containing /usr is 97% full.. :) ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 21:54 Message: Logged In: YES user_id=48280 You're trying to install the binary RPM using a different prefix? That's not supported, I'm afraid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_…

1 0

problem with xlib binding
by Frederik Eaton 08 May '05

08 May '05

Hi, Hmm, have the new xlib bindings been tested? For instance, when I run the following program: ---------------------------------------------------------------- module Main where import Graphics.X11.Xlib import Graphics.X11.Xlib.Display main :: IO () main = do display <- openDisplay "" root <- rootWindow display $ defaultScreen display getGeometry display root closeDisplay display return () ---------------------------------------------------------------- It prints out: xtest: user error (Error bad status 1 raised in function getGeometry) >From the code it looks like the haskell getGeometry is calling XGetGeometry - which has type Status XGetGeometry(...) - and interpreting the 1 return value as an error (via the internal wrapper 'throwUnlessSuccess' which takes 0 for success). But the Xlib Programming Manual says "Some errors, such as failure to open a font, are indicated by return values of type Status on the appropriate routine ... The returned values are *zero* on failure and *nonzero* on success." (emphasis added) So unless I'm really misinterpreting things, the binding to each and every one of the 13 functions that uses 'throwUnlessSuccess' is wrong. Well, before I realized this I'd gone ahead and written a reasonably significant program against the binding assuming that at least the basics would work, but it seems there is some distance to go before the library is usable. One would think that with a "Stability: provisional" library every function has been run successfully at least once, but I can't imagine that this is the case here. Is there even a working Haskell equivalent of 'basicwin' from the Xlib Programming Manual to test things out? This would also be a helpful example for users. Regards, Frederik -- http://ofb.net/~frederik/

1 1

foldr f (head xs) xs is not the same as foldr1 f xs
by David Sabel 08 May '05

08 May '05

Hi! A small example for the claim mentioned in the subject: Prelude> let x = 1:undefined in foldr (curry fst) (head x) x 1 Prelude> let x = 1:undefined in foldr1 (curry fst) x *** Exception: Prelude.undefined Perhaps it would be better to change the implementation of foldr1? Cheers, David

3 3