- Glasgow-haskell-users

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

10 May '05

On 09 May 2005 17:56, Thomas Schwinge wrote: >>>> On 10 April 2005 14:20, I wrote: >>>>> Is someone aware of any efforts to port the GHC to GNU/Hurd? >>>>> If not, I'd like to give that a try. > > I succeeded. :-) Thanks! I've committed all your patches, and merged them onto the 6.4 branch. Cheers, Simon

1 0

RE: GHC as library
by Simon Marlow 10 May '05

10 May '05

On 10 May 2005 03:42, Robert Dockins wrote: > 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). The CVS HEAD contains our current work on GHC as a library. The interface is already useful, we're using it in the Visual Studio extension, and we've restructured GHC itself to put our existing front ends on top of this interface. Take a look in ghc/compiler/main/GHC.hs. Cheers, Simon

1 0

Bootstrapping using a C compiler (was: RE: Can't compile GHC)
by Simon Marlow 10 May '05

10 May '05

Thanks for all the comments in this thread. I'm going to describe some of the technical issues with making a GHC distribution that you can bootstrap on any platform from a single set of sources below. But first, let me explain our thinking on why we don't consider this a priority: we aim to provide working binary distributions for 99.9% of the potential users of GHC. Once you have a working binary of GHC, building GHC again should be easy (if you run into problems, it's a *high* priority from our point of view to fix it). For the other 0.1%, we provide detailed instructions for porting GHC to your platform. It works, but it's a tricky process. Once you have *one* working GHC, you can build future versions probably for at least 4 years (we pull the ladder up after ourselves to avoid #ifdef-hell in the compiler). It may be that we don't have that 99.9% figure for 6.4, but when you consider versions back to 5.02 (the oldest version we can build 6.4 with, I believe), it's probably true. If your platform has a binary distribution, but you want to build GHC using just a C compiler for idealogical reasons, you're slightly misguided :-) ---------- Let me describe some of the technical issues with getting GHC to build out of the box, with no GHC binary installed, on any platform. Hopefully this will provide some useful pointers to anyone out there with a burning desire to improve the GHC OOB experience. How could we achieve a platform-independent bootstrap? The only way I can see to do this is to have a set of completely platform-independent .hc files to bootstrap from. Then the general plan would be - bootstrap unregisterised to get a stage1 compiler. stage1 might be reduced functionality: no GHCi, perhaps no native code gen, no template haskell. - use this to build fully registerised libraries & stage2 To get our platform-independent .hc files, the contents of ghc/compiler ghc/lib ghc/utils libraries/base libraries/Cabal must all be compilable to platform-independent .hc code. That means - No platform #ifdefs in the Haskell code in these directories - No hsc2hs code in these directories We have to eradicate all platform #ifdefs, because they give rise to platform-varying .hc code. In practice, this will probably mean translating some code from Haskell to C. hsc2hs is a similar problem - that gives rise to platform-varying .hs code. Fortunately there is very little hsc2hs code left in here - it gives rise to other porting problems so we removed it. Our job is slightly easier: - As long as we still compile via-C, we can omit the native code generator in stage1, and build it in stage2 only. That's a big source of #ifdefs we don't have to worry about (arguably we should just compile in all the variants of the NCG anyway). However, our job is harder because - ghc/compiler/main/Constants.hs contains a bunch of baked-in constants such as the platform word-size. These would have to be made dynamic - or at least turned into unsafe reads of an external C variable. Given that a majority of the #ifdefs are Unix-vs-Windows, we could consider a partial solution, and settle for having two sets of .hc files, one for Unix and one for Windows. We could further split the Unix camp into 32-bit and 64-bit Unix, which makes the job even easier (the Constants.hs problem partly goes away). A few very rough figures: - total platform #ifdefs in the relevant sources: 395 - after omitting the native code gen: 148 - after omitting Windows: 28 - after omitting GHCi: 21 and there are 3 .hsc files in libraries/base, but they aren't necessary for bootstrapping. Hmm, it's starting to look plausible. Constants.hs is the biggest sticking point, and then hacking up the build system to do bootstrapping. Hope this has been of use to someone... Cheers, Simon

1 0

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