- Glasgow-haskell-users

RE: [Haskell] RE: ANNOUNCE: GHC version 6.4
by Simon Marlow 15 Mar '05

15 Mar '05

On 15 March 2005 00:46, Sebastian Sylvan wrote: > I'm having trouble building this. > I download the source, go to my source dir and run ./configure (which > seems to run to completion without problems), then I run make and get > the following: > > .... > "./mk/config.mk", line 554: Need an operator > "./mk/config.mk", line 554: Need an operator > ..... > Error expanding embedded variable > > This is on freeBSD 5.3 You need to use 'gmake' (GNU make). Cheers, Simon

1 0

RE: [Haskell] RE: ANNOUNCE: GHC version 6.4
by Simon Marlow 15 Mar '05

15 Mar '05

On 14 March 2005 18:08, Cale Gibbard wrote: >>> 4. It looks like Data.FiniteMap has been renamed Data.Map, or >>> something. There's no Data.Map at >>> <http://haskell.org/haddock/libraries/>, do these need to be >>> updated? >> >> The right place for library documentation is >> >> http://haskell.org/ghc/docs/latest/html/libraries >> >> I should probably make the version you're looking at into a link to >> avoid confusion. >> > > Data.Map appears to be broken from there too. I get some sort of page > with a menu as if the html file is a directory containing only the > items "HTML" and "using" both of which are broken links, and then "[an > internal server error occured]". Fixed; it turns out that Apache was trying to interpret a file with a .map extension differently. Cheers, Simon

1 0

ANNOUNCE: GHC version 6.4
by Simon Marlow 14 Mar '05

14 Mar '05

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.4 ============================================================= The GHC Team is delighted to announce a new major release of GHC. It has been a long time since the last major release (Dec 2003!), and a lot has happened: - GADTs (Generalised Abstract Datatypes) are supported - STM (Software Transactional Memory) is implemented - Full support for Cabal and a much improved package framework - Better support for mutually-recursive modules - A complete rewrite of the back end - Accurate source locations in error messages - Lots of new libraries The full release notes are here: http://haskell.org/ghc/docs/6.4/html/users_guide/release-6-4.html How to get it ~~~~~~~~~~~~~ If you haven't already done so, please fill in the GHC Survey: http://www.haskell.org/ghc/survey/start.cgi We'll use the information you give us to improve future releases of GHC. The easy way to get GHC is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ Binary packages will become available as they are built - if the package for your system isn't available yet, please try again later. We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * x86_64-unknown-linux * powerpc-apple-darwin (MacOS X) * powerpc-apple-linux * sparc-sun-solaris2 (may have bitrotted due to lack of attention) Ports to other platforms are possible with varying degrees of difficulty. The builder's guide on the web site gives a complete run-down of what ports work and how to go about porting to a new platform; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

7 8

TH libraries and linking.
by Lemmih 14 Mar '05

14 Mar '05

Greetings, I've recently been playing around with using TH to generate FFI bindings. The resulting code is in general very concise, more maintainable and far less error-prone than the hand-written counterpart. But increased code bloat ascends out of all this happiness. The binding is required to link with both template-haskell and the library which generates the FFI code, so any binary using the generated binding would get a few hundred kilobytes added which strictly aren't necessary (am I wrong here?). This can be unacceptable for small bindings. One could perhaps get around this cheap by changing the TH pretty printer to output valid Haskell instead of just pretty Haskell (I'm specifically talking about a misplaced 'where' in instance declarations). Then one could use the TH library just like a normal preprocessor. I'm no expert so there's probably difficulties which I can't see. -- Friendly, Lemmih

1 0

RE: Fedora packages of new GHC and Hugs releases
by Simon Marlow 14 Mar '05

14 Mar '05

On 14 March 2005 11:38, Jens Petersen wrote: > Hugs98-Mar2005 and ghc-6.4 are available in the Fedora Haskell > package repositories for a couple of days now for i386 and x86_64. > (nhc98 coming shortly.) > > For more information about Fedora Haskell see > <http://haskell.org/fedora/>. Are your GHC x86_64 RPMs registerised, or unregisterised? Cheers, Simon

2 1

RE: ANNOUNCE: GHC version 6.4
by Simon Marlow 14 Mar '05

14 Mar '05

On 14 March 2005 10:45, Ashley Yakeley wrote: > 1. "ghc -M" complains about multiply-defined "Main" modules. > entered as > <http://sourceforge.net/tracker/index.php?func=detail&aid=1162736&group_ i > d=8032&atid=108032> We'll look into this. A first approximation answer is "you can't do that" with the 6.4 implementation of -M. Sorry. > 4. It looks like Data.FiniteMap has been renamed Data.Map, or > something. > There's no Data.Map at <http://haskell.org/haddock/libraries/>, do > these need to be updated? The right place for library documentation is http://haskell.org/ghc/docs/latest/html/libraries I should probably make the version you're looking at into a link to avoid confusion. > 5. Apparently a bunch of stuff is in different pacakges, such as mtl. > Is > there documentation about what's in what package? Perhaps Haddock > should > show packages or something? I'm not yet familiar enough with Cabal to > know what the best way of doing this is. The contents page for the libraries lists the package name for each module. It's not ideal - it would be nice to be able to filter the contents page by package, but I haven't got around to implementing that. Cheers, Simon

1 0

RE: ANNOUNCE: GHC version 6.4
by Simon Peyton-Jones 14 Mar '05

14 Mar '05

| ============================================================= | > The (Interactive) Glasgow Haskell Compiler -- version 6.4 | > | ============================================================= | 2. What's up with "Warning: orphan instances"? I believe I forgot do document the -fwarn-orphans flag. But info is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#orphan-modules Simon

1 0

RE: web site layout
by Simon Marlow 11 Mar '05

11 Mar '05

On 10 March 2005 14:32, Ross Paterson wrote: > There's currently no way to give a permanent URL for the best > available version of the 6.4 documentation, i.e. the latest minor > release. > How about either a symlink 6.4-latest, or renaming the directory 6.4 > as 6.4.0 and making 6.4 a symlink to the latest? Same goes for dist, > I suppose. Ok, 6.4-latest is now a symlink to 6.4 under ghc/docs. I'll make a note to update the link when doing a release. Cheers, Simon

1 0

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

11 Mar '05

Feature Requests item #1097471, was opened at 2005-01-06 20:55 Message generated for change (Comment added) made by simonmar 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: Simon Marlow (simonmar) Date: 2005-03-11 09: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 08: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-20 22: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 20: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 10: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 21: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 11 Mar '05

11 Mar '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-03-11 09: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-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