December 2005 - Glasgow-haskell-users

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 30 May '06

30 May '06

On 25 October 2005 10:01, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> On 24 October 2005 19:04, Wilhelm B. Kloke wrote: >> >> Is it that it does not find the libraries, or does it find the >> libraries but still gets a bunch of undefined references? If the >> latter, then there could be an issue with the mangler. Try an 'nm' >> on libHSbase.a to see if the missing symbols are actually defined. > > Nm shows that the problem may come from splitting. The missing symbols > are marked as locals (small d); being in different .o modules they > are not resolved. Try with splitting off: set SplitObjs=NO in your mk/build.mk. Cheers, Simon

3 2

RE: instance inference
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

Interesting example. Yes, GHC builds recursive dictionaries these days. There's a bit of discussion in our SYB paper in ICFP'05. http://research.microsoft.com/%7Esimonpj/papers/hmap/ And Martin Sulzmann has a whole paper about this point. http://www.comp.nus.edu.sg/~sulzmann/ ("Co-induction...") Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 12 December 2005 10:46 | To: glasgow-haskell-users(a)haskell.org | Subject: instance inference | | I'm puzzled that the following is accepted. Is some sort of greatest | fixed point computation used for instances? | | {-# OPTIONS_GHC -fglasgow-exts #-} | module M where | | class C a b where c :: a -> b -> Bool | | instance C b b => C (Maybe a) b where c x y = c y y | | f :: Maybe a -> Bool | f x = c x x | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 7

New bug tracker: Trac
by Simon Marlow 22 Jan '06

22 Jan '06

Hi Folks, We've been meaning to switch bug trackers for some time, and yesterday I finally got annoyed enough with SourceForge to do something about it. I've imported all our SourceForge tracker data into a new Trac installation: http://cvs.haskell.org/trac/ghc Not only do we get a faster and more flexible bug tracker, but we also get online browsing of the darcs repository (well, for some reason it isn't working right now, but I hope to get it fixed). Also the Trac wiki will be a good place to put the User Guide annotations that we've been talking about. The bug tracker is set up to mail glasgow-haskell-bugs(a)haskell.org with any and all ticket modifications at the moment; if you're on that list, there will probably be an increased volume of mail as we'll be making more use of the bug tracker than before. My feeling is that we don't need to create a new mailing list for this, but by all means speak up if you disagree. The wiki is currently closed because I don't want to have to deal with spam. Use HaWiki for now. Developers with an account on cvs.haskell.org: please add yourselves as users on the Trac, so I can give out permissions to edit tickets. You create a user like this: - log in to cvs.haskell.org - htpasswd /srv/trac/ghc/trac.htpasswd <username> - type your password when prompted - let me know when you've done this Cheers, Simon

8 7

RE: darcs switchover
by Simon Marlow 20 Jan '06

20 Jan '06

On 20 December 2005 16:19, Ross Paterson wrote: > On Tue, Dec 20, 2005 at 03:50:02PM +0000, John Goerzen wrote: >> On 2005-12-19, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: >>> Ross Paterson <ross(a)soi.city.ac.uk> writes: >>>> But how about having a separate repository for each library >>>> package? >>> >>> Seconded. >> >> Simon, any thoughts? > > Also, if the library packages are separate, the rest of the stuff in > the libraries directory would be part of GHC's build system (nhc98 > too at the moment, but it sounds like Malcolm will be changing that) > so might as well be part of the ghc repository. The time to mention this would have been a few weeks ago when I proposed the current scheme :-) I think it /would/ actually be nicer to split up the repository into separate packages. However, of the two ways to do this that John mentioned, only the second is practical IMO - that is, generate the repositories from CVS. So it's entirely up to John whether he wants to put the effort in or not. I don't think the current situation is bad - we had planned to split the packages into separate repositories eventually anyway, but we would lose the history at that point. Splitting them now means we keep the history, which is good. Cheers, Simon

7 16

RE: storing highly shared data structures
by Simon Marlow 12 Jan '06

12 Jan '06

On 22 December 2005 13:43, Christian Maeder wrote: > for storing highly shared data structures we use so called Annotated > Terms (shortly ATerms, details below). > > http://www.cwi.nl/htbin/sen1/twiki/bin/view/SEN1/ATerm > > In contrast to the Binary (or GhcBinary) class we compute the sharing, > which saves a lot of space for data types that keep redundant > information. > > With this we can store some of our data structures (of course only > non-cyclic and finite ones) in a few KBs that need MBs if stored > without sharing (as when using the Binary or the Show/Read > classes). > > So far so good. The problem remaining is that an object is _traversed_ > as if being unshared and thus the _time_ for the ATermTable > construction becomes too long for us. > > GHC's internal data structures (on the heap) are in many cases shared, > by pointer references. I.e. if I add a (single) symbol table to every > symbol that I use, then the symbol table will not be copied, but only > a reference added to my symbol. > > How can I detect this sharing in order to avoid traversing the very > same symbol table for every symbol? > > I've tried to use a "Map (Ptr ()) ShATerm". So before traversing an > object I look up its address and check if is was traversed before (if > not I traverse it and store it in my map for future lookups). > > 1.) I'm not sure if it is safe to use "Ptr ()" (meanwhile garbage > collection, heap compaction and what not could happen). Right - Ptr isn't the right thing here, because GC will move objects around. That's why we have StablePtr and StableName. In fact, what you really want here is the pointer-equality memo table implementation in the Memo module (package util). This is scheduled to be removed in 6.6, but it will be available as a Cabal package. Cheers, Simon

5 15

storing highly shared data structures
by Christian Maeder 11 Jan '06

11 Jan '06

Dear Haskell Experts, for storing highly shared data structures we use so called Annotated Terms (shortly ATerms, details below). http://www.cwi.nl/htbin/sen1/twiki/bin/view/SEN1/ATerm In contrast to the Binary (or GhcBinary) class we compute the sharing, which saves a lot of space for data types that keep redundant information. With this we can store some of our data structures (of course only non-cyclic and finite ones) in a few KBs that need MBs if stored without sharing (as when using the Binary or the Show/Read classes). So far so good. The problem remaining is that an object is _traversed_ as if being unshared and thus the _time_ for the ATermTable construction becomes too long for us. GHC's internal data structures (on the heap) are in many cases shared, by pointer references. I.e. if I add a (single) symbol table to every symbol that I use, then the symbol table will not be copied, but only a reference added to my symbol. How can I detect this sharing in order to avoid traversing the very same symbol table for every symbol? I've tried to use a "Map (Ptr ()) ShATerm". So before traversing an object I look up its address and check if is was traversed before (if not I traverse it and store it in my map for future lookups). 1.) I'm not sure if it is safe to use "Ptr ()" (meanwhile garbage collection, heap compaction and what not could happen). 2.) A single "Map (Ptr ()) ShATerm" does not work! It seems that sometimes objects are shared that have different types (as tests revealed). This seems obvious for newtypes but also happens (I think) without newtype declarations. However, shared ATerms are always different for different types, because the corresponding data constructors are different. So, I'm now thinking if I should try using the type of my data as key as well, i.e. using "Map (TypeRep, Ptr ()) ShATerm" to avoid duplicate traversals. Would this be worth the effort? What other possibilities could I try? An obvious solution is to avoid the redundancy in the first place (i.e. simply don't store the symbol table with every symbol), but that would require a major change of our sources, and would the code become clearer? (Many functions would need more arguments.) Finally, _reading in_ shared ATerms is fast, since ghc seems to exploit the sharing given by the injective ATermTable. Thanks for any help Christian More details: Brand, M.G.J. van den, H.A. de Jong, P. Klint, and P.A. Olivier (2000). "Efficient Annotated Terms." Software -- Practice & Experience 30:259--291. (The link "ATerm Library" http://www.cwi.nl/projects/MetaEnv/haterm/ under http://www.haskell.org/libraries/#compilation looks outdated to me. We have extra source code that - at the moment - cannot be distributed separately) Via an extension to DrIFT, http://repetae.net/john/computer/haskell/DrIFT, we generate class instances (similar to the Binary class) for our types that we want to store. Our ATerms are (basically) constructor terms of the form: data ShATerm = ShAAppl String [Int] deriving (Eq, Ord) (The annotation part of ATerms is omitted here since we don't use it) The Int-list contains the arguments as indices into an ATermTable being an injective "IntMap ShATerm" with update and lookup functions: addATerm :: ShATerm -> ATermTable -> (ATermTable, Int) getATerm :: Int -> ATermTable -> ShATerm The class (that DriFT derives instances for) looks as follows: class ShATermConvertible t where toShATerm :: ATermTable -> t -> (ATermTable, Int) fromShATerm :: (ATermTable, Int) -> t The automatically derived instance of i.e. a user-defined List data type "data List a = Nil | Cons a (List a)" is: instance ShATermConvertible a => ShATermConvertible (List a) where toShATerm att0 Nil = addATerm (ShAAppl "Nil" []) att0 toShATerm att0 (Cons a b) = case toShATerm att0 a of { (att1, a') -> case toShATerm att1 b of { (att2, b') -> addATerm (ShAAppl "Cons" [a', b']) att2 }} fromShATerm (att, i) = case getATerm i att of ShAAppl "Nil" [] -> Nil ShAAppl "Cons" [a, b] -> case fromShATerm (att, a) of { a' -> case fromShATerm (att, b) of { b' -> Cons a' b' }} _ -> error "ShATermConvertible List" (Internally the ATermTable also keeps an inverse "Map ShATerm Int" to support the efficient implementation of addATerm.) We can use the "baffle" tool to convert our files from shared (TAF) to unshared ATerm format and vice versa.

4 6

darcs switchover
by Simon Marlow 09 Jan '06

09 Jan '06

Hi Folks, As you probably know, there is a mirror of the GHC source tree in a darcs repository. (information about accessing the darcs repository is here: http://cvs.haskell.org/trac/ghc/wiki/GhcDarcs) The aim is to eventually switch over to using darcs for our revision control. The point of this message is to find out what constraints people have that will affect when we can throw the switch. It doesn't look like we'll be able to keep a CVS mirror going once we switch to darcs, so darcs will be the only way to get an up-to-date GHC source tree. How will it affect you? - If you just get the GHC sources from anonymous cvs, then you have to switch to getting sources using darcs. It's pretty simple. - If you are a developer, then you need to: (a) get sources from darcs, and (b) use 'darcs push' instead of 'cvs commit'. - You won't be able to browse the CVS repository via cvsweb any more. You can browse the contents of the darcs repository directly, and we hope to set up some kind of darcs-aware browsing too. We've switched some of our nightly builds over to using darcs, and it seems to be working nicely. darcs get --partial can actually get the sources quicker than anonymous CVS used to. Please let me know if the switchover is going to adversely affect your life, so that we can formulate a plan and timescale for switching over. Malcolm, Ross - since you both also use the CVS libraries tree, is it going to be possible for you to switch to using darcs to get the libraries? Any idea how long you'll need? Cheers, Simon

9 17

Unboxed types and FFI (GHC Users Guide, Section 8.1.1)
by Dimitry Golubovsky 04 Jan '06

04 Jan '06

The section 8.1.1 of the GHC User's Guide says this: The following unboxed types may be used as basic foreign types (see FFI Addendum, Section 3.2): Int#, Word#, Char#, etc Does this mean that when declaring a foreign function import for a C function int fun(int) I may write foreign import ccall "bla.h fun" fun :: Int# -> Int# instead of using CInt? Are there any examples of using unboxed types with FFI? -- Dimitry Golubovsky Anywhere on the Web

2 1

Two issues bulding ghc 6.4.1
by Dimitry Golubovsky 04 Jan '06

04 Jan '06

I have encountered two issues trying to build ghc-6.4.1 from the source tarball. 1. (fixed) GNU make v 3.79 does not work (was discussed on irc yesterday: at least two people including myself got this issue), v 3.80 works. If not already in FAQ/wiki perhaps worth including. 2. Error while assembling (or mangling?) ForeignObj.lhs; fragments of make output below (long lines wrapped/truncated, the whole file is too long to post it here but I'll provide it if needed): ======================================================================= ------------------------------------------------------------------------ ../../ghc/compiler/ghc-inplace -M -optdep-f -optdep.depend -optdep-s -optdepp -osuf o -H16m -O -ign <<ghc: 13519236 bytes, 3 GCs, 92336/92336 avg/max bytes residency (1 samples), 16M in use, 0.02 INIT ( ------------------------------------------------------------------------ ==fptools== make boot -wr; in /home/dima_ext/ghc-6.4.1/hslibs/doc ------------------------------------------------------------------------ ------------------------------------------------------------------------ ===fptools== Finished making `boot' in lang concurrent posix util data text net hssource doc ... PWD = /home/dima_ext/ghc-6.4.1/hslibs ------------------------------------------------------------------------ make[1]: Leaving directory `/home/dima_ext/ghc-6.4.1/hslibs' make[1]: Entering directory `/home/dima_ext/ghc-6.4.1/hslibs' ------------------------------------------------------------------------ ===fptools== Recursively making `all' in lang concurrent posix util data text net hssource doc ... PWD = /home/dima_ext/ghc-6.4.1/hslibs ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make all -wr; in /home/dima_ext/ghc-6.4.1/hslibs/lang ------------------------------------------------------------------------ ------------------------------------------------------------------------ ===fptools== Recursively making `all' for ways: p ... PWD = /home/dima_ext/ghc-6.4.1/hslibs/lang ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make way=p all; PWD = /home/dima_ext/ghc-6.4.1/hslibs/lang ------------------------------------------------------------------------ rm -f ForeignObj.p_o; if [ ! -d ForeignObj_split ]; then mkdir ForeignObj_split; else /usr/bin/find Fo ../../ghc/compiler/ghc-inplace -H16m -O -cpp -fglasgow-exts -Icbits -imonads -ignore-package lang -O - ForeignObj.lhs:98:0: Warning: Module `Addr' is deprecated: This library will go away soon; use Foreign.Ptr instead ForeignObj.lhs:98:0: Warning: Deprecated use of data constructor `A#' (imported from Addr): This library will go away soon; use Foreign.Ptr instead ForeignObj.lhs:98:0: Warning: Deprecated use of `addrToPtr' (imported from Addr): This library will go away soon; use Foreign.Ptr instead [more deprecated API warnings follow] ForeignObj.lhs:98:0: Warning: Deprecated use of type constructor or class `Addr' (imported from Addr): This library will go away soon; use Foreign.Ptr instead ForeignObj.lhs:136:0: Warning: foreign declaration uses deprecated non-standard syntax ghc-asm: (mangler) still have jump involving %edi! pushl 4(%esi) call EnterFunCCS addl $4,%esp cmpl $0,era je .L580 movl 8(%esi),%eax andl $1073709056,%eax orl $1073741824,%eax [more assembly language follows] movl %eax,CCCS jmp *(%ebp) .align 4 .L582: jmp *-4(%ebx) .Lfe5: <<ghc: 92002572 bytes, 15 GCs, 2799244/5043524 avg/max bytes residency (3 samples), 17M in use, 0.01 I make[3]: *** [ForeignObj.p_o] Error 255 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/dima_ext/ghc-6.4.1/hslibs' make: *** [build] Error 1 ======================================================================================================= What was used: GHC to bootstrap: bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.2 bash$ gcc --version egcs-2.91.66 bash$ as --version GNU assembler 2.9.1 Copyright 1997 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i386-slackware-linux'. Has anyone else had this? Earlier, GHC 6.2.2 built with these tools OK. Thanks for any ideas. Dimitry

3 4

"Duplicate instance declarations"
by Bulat Ziganshin 28 Dec '05

28 Dec '05

Hello all why the folowing is not allowed even with all extensions enabled both in Hugs and GHC? class BufStream h where class CharStream h where instance (CharStream h) => BufStream h where class MemoryStream h where instance (MemoryStream h) => BufStream h where i plan to implement many streams, some of which are supporting getBuf/putBuf interface of MemoryStream, and some getChar/putChar interface of CharStream and then automatically derive BufStream using the appropriate operations. but that just fail how can i pass around these restriction? can this be supported in future Hugs/GHC versions? ... just now i encountered this problem again: -- Copy entire contents of Stream to another Stream class (Stream h1, Stream h2) => StreamCopying h1 h2 where copyStream :: h1 -> h2 -> IO () instance (MemoryStream h1, BufStream h2) => StreamCopying h1 h2 where copyStream h1 h2 = return () instance (BufStream h1, MemoryStream h2) => StreamCopying h1 h2 where copyStream h1 h2 = return () -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 3