- Glasgow-haskell-users

Oops [Fwd: Re: Allowing duplicate instances in GHC 6.4]
by Robert van Herk 31 Mar '05

31 Mar '05

Sorry, this is the compiler error I get: No instances for (KeyHasValue MyKeyVal k' v', Datasource.Tools.FakePrelude.TypeEq Float k' z, Datasource' z [MyKeyVal] [MyKeyVal] Float Int) When I am trying to do do { createJoinedDS' x x; (joined,(v::Maybe Int)) <- _dsread joined (2.0::Float); } Robert

2 3

Re: Oops [Fwd: Re: Allowing duplicate instances in GHC 6.4]
by Robert van Herk 31 Mar '05

31 Mar '05

> See change above! > > Also note type of fundep for Datasource should now be: > > class Datasource s k v | s -> k v where ... > > I see.... But the cool thing was, that my datasources were generic, in the sence that they could store multiple k's and v's. Now, they would be unique for the actual storage mechanism used, meaning, for example, that I could only read values from 1 table, if I'd instantiate the datasource for a database coupling. Currently, I use the Boilerplate approach to make it possible to store multiple types in one datasource, for example: data MyKeyVal = IntXString Int String | FloatXInt Float Int deriving (Eq, Ord, Show) Furthermore, I generate an instance of KeyHasValue, to tell my framework which keys are valid for a datasource, for example: instance KeyHasValue MyKeyVal Int String where constructor = IntXString instance KeyHasValue MyKeyVal Float Int where constructor = FloatXInt I have an instance instance (..., KeyHasValue a k v) => Datasource [a] k v where ... This way, I can read Ints from a [MyKeyVal], and get a String, and read Floats, and get an Int. If I would have a fundep class Datasource s k v | s -> k v where ... this wouldn't be possible anymore, I guess? Regards, Robert

2 1

[Fwd: Oops [Fwd: Re: Allowing duplicate instances in GHC 6.4]]
by Robert van Herk 31 Mar '05

31 Mar '05

Sorry, oops again: The problem is that it complains that it cannot find an instance for Datasource' z [MyKeyVal] [MyKeyVal] Float Int Whilst I have an instance Datasource [MyKeyVal] Float Int Thus, it seems that it needs an explicit type for the z here. Both datasources stored in the joined datasource are of type [MyKeyVal], so I would expect this to compile correctly, and then take the left datasource. Sorry that my explanation is all so confusing.... Robert

1 0

Allowing duplicate instances in GHC 6.4
by Robert van Herk 31 Mar '05

31 Mar '05

Hi all, I need to use duplicate instances. I read in the documentation on GHC 6.4, that overlapping class instances checks are lazy instead of gready in 6.4. However, my code still gives duplicate instance errors when compiling in GHC 6.4. Is the duplicate instance check still gready? Is there a way to overwrite that behaviour? Right now, I have two instance of a class Datasource. Datasource allows the user to read (key,value) pairs. class Datasource ds k v where ... Now, I wanted to make a special datasource that combines two datasources, namely data JoinedDS left right = JoinedDS left right instance (Datasource left k v) => Datasource (JoinedDS left right) k v where ... instance (Datasource right k v) => Datasource (JoinedDS left right) k v where ... The idea is that when you combine 2 datasources in one JoinedDS, the user can read both types from the JoinedDS. I do not need to allow to combine 2 different datasources that have the same types of (key,value) pairs, so the duplicate instances will not occur and when they do, this will be by mistake. Hence, the two premisses in the instance declaration will never be fulfilled both at the same time and I do not want a duplicate instance error here. Is there a solution to this problem? Thanks, Robert

2 8

Size of UArrays
by Andreas Marth 30 Mar '05

30 Mar '05

Hallo! I would like to know how big an "UArray (100,100) Double" is (approximately) in Bytes. And how much heap will the program consume for it. (I mean does the garbage collector need this size, or double the size, or what?) Thanks, Andreas

2 1

RE: moving from ghc-6.2 to 6.4
by Simon Marlow 30 Mar '05

30 Mar '05

On 29 March 2005 08:59, Johannes Waldmann wrote: > I am trying to bring a larger heap of code > (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder > stories about faster compilation, faster execution, Data.Map, and so > on ...) > Here are a few observations and questions > that may be useful to others as well. > > * what is the situation with ghc-6.4 for sparc/solaris? > I don't see a binary package in the download area. > I started to build from source - can this be successful? > > (The rest of this report refers to i386/linux) There are some outstanding issues on Sparc/Solaris that I didn't get around to investigating before the release. One of them is a random crash, so you should probably consider 6.4 to be broken on Sparc/Solaris for the time being (it might be related to gcc version though: 6.2.x might be just as broken with recent gcc versions). I'm keen to get more data points, if you have the time & inclination to test it. We could really do with a Sparc/GHC guru to take up the mantle of maintaining the Sparc port - it's kind of hard for us to do it without the hardware locally, and I'm no Sparc expert. > * Cabal is very nice! - The only thing that was confusing me > is that I have to list all modules in the *.cabal file: > if I don't, it still happily builds and installs the package > but it cannot be used, giving linker errors. Couldn't this be > checked earlier? Or better, couldn't it infer the needed > hidden modules? Anyway I can generate the module list by a shell > script but that does not feel right. - How do I build and install > a profiling version of a package, how does Cabal support this? The module list: yes, I think this is something the Cabal team would like to automate in the future. There's no way to build profiled packages at the moment, as far as I'm aware. I agree it's an important feature, though. > * I don't see "dramatic" improvements in execution times - > are there some magic ghc options I missed? I used -O -fvia-C. > Still, executables are maybe 2 .. 5 % smaller and faster than they > were with 6.2 - and compilation without -O is really fast. I don't know where this rumour of dramatic improvements in execution time comes from :-) Our testing shows modest improvements in most programs, with some programs going slower. The focus of 6.4 wasn't really on performance, but we hope to merge performance improvements back into future 6.4 releases. Cheers, Simon

4 3

RE: moving from ghc-6.2 to 6.4
by Simon Marlow 30 Mar '05

30 Mar '05

On 29 March 2005 17:56, Keean Schupke wrote: > Thought I would run some benchmarks with different compiler options, > so I pulled out some code (that compiled fine with 6.2). The code uses > MArrays to calculate a tree difference between two different XML > files. Anyway tying to compile with 6.4 I get: > > >ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): > > app_match: unbound tpl s{tv a2M9} > > > >Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, > > Any idea how to track down the cause of this? The error message claims to be from GHC 6.3, perhaps you're using a pre-6.4 snapshot? Could you try with the released 6.4 and let us know if it still happens? Cheers, Simon > Keean. > > Simon Marlow wrote: > >> On 29 March 2005 08:59, Johannes Waldmann wrote: >> >> >> >>> I am trying to bring a larger heap of code >>> (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder >>> stories about faster compilation, faster execution, Data.Map, and >>> so on ...) Here are a few observations and questions >>> that may be useful to others as well. >>> >>> * what is the situation with ghc-6.4 for sparc/solaris? >>> I don't see a binary package in the download area. >>> I started to build from source - can this be successful? >>> >>> (The rest of this report refers to i386/linux) >>> >>> >> >> There are some outstanding issues on Sparc/Solaris that I didn't get >> around to investigating before the release. One of them is a random >> crash, so you should probably consider 6.4 to be broken on >> Sparc/Solaris for the time being (it might be related to gcc version >> though: 6.2.x might be just as broken with recent gcc versions). >> I'm keen to get more data points, if you have the time & inclination >> to test it. >> >> We could really do with a Sparc/GHC guru to take up the mantle of >> maintaining the Sparc port - it's kind of hard for us to do it >> without the hardware locally, and I'm no Sparc expert. >> >> >> >>> * Cabal is very nice! - The only thing that was confusing me >>> is that I have to list all modules in the *.cabal file: >>> if I don't, it still happily builds and installs the package >>> but it cannot be used, giving linker errors. Couldn't this be >>> checked earlier? Or better, couldn't it infer the needed >>> hidden modules? Anyway I can generate the module list by a shell >>> script but that does not feel right. - How do I build and install >>> a profiling version of a package, how does Cabal support this? >>> >>> >> >> The module list: yes, I think this is something the Cabal team would >> like to automate in the future. There's no way to build profiled >> packages at the moment, as far as I'm aware. I agree it's an >> important feature, though. >> >> >> >>> * I don't see "dramatic" improvements in execution times - >>> are there some magic ghc options I missed? I used -O -fvia-C. >>> Still, executables are maybe 2 .. 5 % smaller and faster than they >>> were with 6.2 - and compilation without -O is really fast. >>> >>> >> >> I don't know where this rumour of dramatic improvements in execution >> time comes from :-) Our testing shows modest improvements in most >> programs, with some programs going slower. The focus of 6.4 wasn't >> really on performance, but we hope to merge performance improvements >> back into future 6.4 releases. >> >> Cheers, >> Simon >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Kind of StableName
by Simon Marlow 29 Mar '05

29 Mar '05

On 28 March 2005 11:25, Nicolas Oury wrote: > I try to use StableNames for hash consing on complex types - I have to > mix in a same table StableNames of different types - and I wonder why > StableName is of kind * -> * and not *. I think we gave StableName the extra type parameter to help with type safety. But I can't think of a convincing example right now... anyway, it would be quite easy to build an alternative StableName implementation without the type parameter. Take a look at the source code for System.Mem.StableName, it's quite short. Cheers, Simon

1 0

RE: Biographical Profiling
by Simon Marlow 29 Mar '05

29 Mar '05

On 25 March 2005 15:59, Andreas Marth wrote: > The ghc user guide says that there are 4 states a heap object may be > in. Unfortunately in my program there are 5 states (inherent_use, > use, drag, lag, void) with inherent_use being the biggest part (many > MBs) and the one not mentioned in the users guide. > My question is what does it mean? What can I do to get rid of it? IIRC, inherently used closures are primitive objects that we don't record use-stamps on. This includes things like the stack (part of a primitive thread object), arrays, MVars, and IORefs. Cheers, Simon

1 0

RE: [Haskell] Haskell 6.4 perfomance
by Simon Marlow 29 Mar '05

29 Mar '05

GHC 6.4 uses C-- as an intermediate language, it doesn't compile via C-- (yet). A full C-- backend has the potential to generate faster code that going via GCC, because C-- would have control over the stack and the calling convention. In my experience, extra optimisation flags for gcc make very little difference for GHC-compiled code, and may even make things worse. By all means do some benchmarks, though! Cheers, Simon On 25 March 2005 08:19, Alexandre wrote: > Keean, thank you. > > Does any tests/benchmarks available? > > Regards, > /Alexandre. > > > On Mar 25, 2005, at 00:47, Keean Schupke wrote: > >> Think this should really go to glasgow-haskell-users... >> >> If this is true - how do I get ghc to use C--, and is it really >> faster than using gcc as a backend with all the bells & whistles >> turned on (for a pentium-III) something like >> >> "-O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer >> -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 >> -ffast-math -fsched-spec-load -fprefetch-loop-arrays >> -maccumulate-outgoing-args -fmove-all-movables >> -freduce-all-givs" >> >> Keean. >> >> Alexandre wrote: >> >>> As I heard, 6.4 version of the Haskell using C-- backend and make >>> lots of the resulting code perfomance (programs executed faster). >>> If so, does any test/comparison with other languages available? >>> >>> Thank you in advance, >>> Regards, >>> /Alexandre. >>> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0