- Glasgow-haskell-users

newbie: GHC 6.3 build problem
by Alson Kemp 23 Jan '05

23 Jan '05

All, Okay, I've done due diligence on this problem and haven't found any solution, so I figured that I'd spam the list for help. System: Gentoo Linux (freshly emerged...) Pentium 3 GCC 3.3.4 I'm trying to build cvs-HEAD and am having problems. The build completes just fine, but the built GHC 6.3 does not include the "-I" include directories option for GCC. "ghc -O2 -v program.hs" shows that gcc is called thusly: gcc -x c /tmp/ghc10338.hc -o /tmp/ghc10338.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=603 -ffloat-store -I . If I use the Gentoo-built 6.2.2, then the call to gcc is: gcc -x c /tmp/ghc32417.hc -o /tmp/ghc32417.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -mno-omit-leaf-frame-pointer -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=602 -nopie -fno-stack-protector -fno-stack-protector-all -ffloat-store -I . -I . -I /usr/lib/ghc-6.2.2/include Help! How do I build GHC to include the proper "-I" flags when calling gcc? -Alson Kemp

2 3

RE: Dynamic linking under Windows
by Simon Marlow 21 Jan '05

21 Jan '05

On 21 January 2005 09:13, Santoemma Enrico wrote: > I don't understand from the manual whether it is possible to have a > short .exe file and the rest as a dynamic linking part, or not yet. Not at the moment. It was possible in the past, and it might be possible again shortly in the future: Wolfgang Thaller has been doing lots of work on dynamic linking support, which will be in GHC 6.4. It probably won't be completely supported on Windows by 6.4, though. Cheers, Simon

1 0

Dynamic linking under Windows
by Santoemma Enrico 21 Jan '05

21 Jan '05

Hello, I don't understand from the manual whether it is possible to have a short .exe file and the rest as a dynamic linking part, or not yet. Thanks, Enrico

1 0

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

20 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by wthaller 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: Wolfgang Thaller (wthaller) Date: 2005-01-20 23: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-20 21: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 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

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

20 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by aanno 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: Thomas Pasch (aanno) Date: 2005-01-20 21: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 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

Implicit parameters:
by Keean Schupke 19 Jan '05

19 Jan '05

Question regarding implicit parameters... The GHC manual says: "Dynamic binding constraints behave just like other type class constraints in that they are automatically propagated." But the following code produces an error: --------------------------------------------------------------------------------------------------------- main = do var <- newIORef (0::Int) let ?global_counter = var in f f = do a <- get_unique putStr (showInt a "\n") b <- get_unique putStr (showInt b "\n") c <- get_unique putStr (showInt c "\n") get_unique :: (?global_counter :: IORef Int) => IO Int get_unique = readIORef ?global_counter ---------------------------------------------------------------------------------------------------------- If "(?global_counter :: IORef Int)" were a class constraint the type signature for 'f' could be derived automatically... but we get: Unbound implicit parameter (?global_counter::IORef a) arising from use of `get_unique' at Test.hs:17:13-22 Is this a bug? Is there some reason why this is not possible? (and if it is not possible shouldn't the documentation be changed to reflect this)... Keean.

2 2

RE: [Haskell-cafe] GHC for .NET?
by Simon Peyton-Jones 19 Jan '05

19 Jan '05

| "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

2 1

RE: package installation
by Simon Marlow 19 Jan '05

19 Jan '05

On 17 January 2005 22:53, Sean Bowman wrote: > I'm trying to install HUnit to use with ghci and hugs and having some > trouble. It works if I use the -i option with ghci, but I'd rather > not have to specify that on the command line every time. Putting it > in a ~/.ghci file doesn't seem to work. How can I set the search path > for 3rd party Haskell modules? You have two choices: use the -i option, or make a package. The "right way" to use 3rd party libraries is to make a package. We're making it easier to build packages with Cabal (http:///www.haskell.org/cabal/). Incedentally, GHC 6.4 will come with HUnit. And I believe there's a Cabal version floating around somewhere that should install with GHC 6.2.2. Cheers, Simon

1 0

RE: debian ghci on sparc64
by Simon Marlow 19 Jan '05

19 Jan '05

On 18 January 2005 21:01, William Lee Irwin III wrote: > On 15 December 2004 14:46, William Lee Irwin III wrote: >>> There seems to be some trouble with the debian ghci on sparc64. I >>> can dredge up more information if given an idea of what to look for. > > On Tue, Jan 18, 2005 at 04:41:02PM -0000, Simon Marlow wrote: >> This turned out to be relatively straightforward. Two fixes: >> ghc-asm.lprl needs slight modifications for new versions of gcc on >> sparc-*-linux, and the dynamic linker also needs to have USE_MMAP >> enabled due to needing to execute dynamically allocated memory. >> I've made these fixes in the HEAD, and also merged them into the 6.2 >> branch. William: there's a fixed tree in >> /mnt/dm0/simonmar/ghc-6.2.2 on your sparc64 box. > > Great, thanks for fixing it up! I can make similar arrangements for > the alpha issue, if desired. Are you referring to this bug? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232727 If so, that's quite a bit of work - not 6.4 material I'm afraid. Cheers, Simon

2 1

RE: self-import
by Simon Peyton-Jones 19 Jan '05

19 Jan '05

Good point, thank you! I'd forgotten that the OGI modules paper, which I read carefully at the time, covered recursion (Section 5.4). But my real point wasn't that it's impossible to define a meaning, only that the meaning might be a bit unexpected to a programmer, and involves a fixpoint calculation (which the paper indeed performs). It does also require the scope-resolver to process the whole of a strongly-connnected component of modules at a time, which GHC isn't set up to do. That's an engineering issue, not a semantic one, though. Simon | -----Original Message----- | From: Thomas Hallgren [mailto:hallgren@cse.ogi.edu] | Sent: 18 January 2005 22:12 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Cc: john(a)repetae.net | Subject: Re: self-import | | Simon Peyton-Jones wrote: | | >I quite liked this idea until I thought of this: | > | > module Doc.Pretty.Long( M.f, f ) where | > import qualified M( f ) | > import Doc.Pretty.Long as M | > | > f x = x | > | >The second import decl imports all the things exported by | >Doc.Pretty.Long. But what does it export? Well, M.f. But what is M.f. | >Well, it could be the f coming from 'import M.f'. But wait! | >Doc.Pretty.Long exports the locally-defined f too... and the second | >import decl will make that be called M.f too. | > | > | Our module system paper has answers to this type of questions, since it | deals with the meaning of recursive modules: | | http://www.cse.ogi.edu/~diatchki/hsmod/ | | It is implemented in the Programatica Haskell front-end, which thus | supports modules importing themselves in particular, and mutually | recursive modules in general, without the need for boot .hi files. I | wonder when other Haskell implementations are going to catch up? :-) | | -- | Thomas H

1 0