- Glasgow-haskell-users

Re: Validate failures on the new codegen
by Edward Z. Yang 07 Apr '11

07 Apr '11

Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011: > OK! Thanks for the information. So this -fnew-codegen is this famous > codegen which is using hoopl for data-dependency tracking or something > like that if I understand correctly Yep. > And which is producing just C-- in order to be compatible with the current > infrastructure, i.e. NCG? Not quite. We have two C-- representations, in cmm/CmmNode.hs and cmm/OldCmm.hs respectively. Our backends consume OldCmm, and Hoopl consumes CmmNode, and then converts it to OldCmm using CmmCvt.hs. > If I also read correctly somewhere on GHC Trac Wiki, then this -fnew-codegen > should sometime in the future even replace NCG. May I ask you when such > replace is planed? That's the idea, but depends on how long it takes for us to get the new code generator generating as good (or better--that's the idea behind Hoopl) as the old code generator at a reasonable pace. The new codegen is already several years into the making. > I'm asking since I'm still poking with the idea of writing NCG for some GHC > not yet supported platform and since this will be my free time hobby project > it'll certainly take some time hence I do have doubts if to use current NCG > as a basis for it or wait and/or use your new planned infrastructure. It's certainly a question. Since we can convert from one to another, whichever one you pick, we should be able to support (some fiddling may be required if you use the new C-- representation, since none of our other backends use it right now--but this is certainly the way forward.) Edward

1 0

T3738 allocation figures for 32-bit
by Daniel Fischer 07 Apr '11

07 Apr '11

Hit send too soon: > Apparently the allocation figures drastically vary by arch and OS, it > would probably be necessary to test on several such and be more > generous with the limits. The same holds for other tests, of course. I had unexpected failures due to allocation figures also for space_leak001, T4801 and T3064. space_leak001 failing with bytes allocated 9328745840 is more than maximum allowed 9100000000 (allocation figures slightly vary among the different ways) which is close enough to not worry about, considering the minimum allowed is 9050000000. T4801 with peak_megabytes_allocated 41 is less than minimum allowed 70 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 358364424 is more than maximum allowed 80000000 max_bytes_used 17406288 is more than maximum allowed 4000000 and T3064 with peak_megabytes_allocated 9 is less than minimum allowed 14 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 69984336 is less than minimum allowed 150000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again max_bytes_used 3368652 is less than minimum allowed 6000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again The figures in HEAD's testsuite are again close to what I get, while the 7.0.3 figures are way off. Cheers, Daniel

2 1

Some tips for using git rebase and keeping your history clean
by Johan Tibell 06 Apr '11

06 Apr '11

Hi all, Since we've now switched to git I though I share Linus' notes on rebasing for those of you who haven't seen them: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html The mail talks about when to use rebase and when not to. Johan

1 0

-DDEBUG and testsuite
by Edward Z. Yang 06 Apr '11

06 Apr '11

Hello all, If I run 'make fast' in the testsuite, with a stage2 compiler that has been built with -DDEBUG, should I be getting extra failures? Edward

3 4

Re: [Gtk2hs-users] cairo error: ghc.exe: unable to load package `cairo-0.12.0'
by Axel Simon 05 Apr '11

05 Apr '11

Hi Daniel, On 04.04.2011, at 16:01, Daniel wrote: > Hi list, > > I've built gtk2hs successfully for ghc-7.0.2, but if I try to load > the example > Drawing.hs from the cairo packages demo folder I get: > > > *Main> :load Drawing.hs > [1 of 1] Compiling Main ( Drawing.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > Loading package transformers-0.2.2.0 ... linking ... done. > Loading package mtl-2.0.1.0 ... linking ... done. > Loading package array-0.3.0.2 ... linking ... done. > Loading package containers-0.4.0.0 ... linking ... done. > Loading package process-1.0.1.5 ... linking ... done. > Loading package time-1.2.0.3 ... linking ... done. > Loading package random-1.0.0.3 ... linking ... done. > Loading package haskell98-1.1.0.1 ... linking ... done. > Loading package cairo-0.12.0 ... linking ... <interactive>: > C:/users/daniel/appd > ata/roaming/cabal\cairo-0.12.0\ghc-7.0.2\HScairo-0.12.0.o: unknown > symbol `_cair > o_image_surface_get_data' > ghc.exe: unable to load package `cairo-0.12.0' > > Have tried many things so far: > > * Starting with re-inited package database > * Doing a $ nm /h/Gtk+/bin/libcairo-2.dll | grep -i > cairo_image_surface_get_data > yielding 68de04d8 T _cairo_image_surface_get_data > * Temporarily renaming libcairo-2.dll (the only one found on my > setup, even > not-in-PATH ones are non-existent) yielding as expected "dll not > found" error > * as you can see there is no "literal" space in the gtk+ > installation path > (h:\Gtk+), only in the users haskell package installation path, but > that's > fairly standard with Windows I guess > * Compilable with ghc --make ... though, but that's sadly not > sufficient as > Chart package isn't installable due to this issue If ghc --make works but interactively the object cannot be found, then it might be a ghc problem rather than ours, especially since the symbol exists in the DLL. Can somebody from the ghc group shed some light on the issue? Cheers, Axel

2 1

Re: [Haskell] Polymorphic types in RHS of type instances
by José Pedro Magalhães 04 Apr '11

04 Apr '11

Hi, [Moving to glasgow-haskell-users(a)haskell.org] I would also like to know the answer to this question. While I can imagine it has something to do with type checking/inference, it is not immediately clear to me where the problem lies. Thanks, Pedro On Sat, Feb 5, 2011 at 12:25, Steven Keuchel <steven.keuchel(a)gmail.com>wrote: > Hi list, > > I was wondering why GHC doesn't allow usage of polymorphic types in > the right-hand side of type instance declarations for type families. > The GHC user guide states: "The right-hand side of a type instance > must be a monotype (i.e., it may not include foralls) [...]", but it > doesn't state the reason. > > I stumbled upon this limitation when I was trying to generically > calculate Johann's and Ghani's interpreter (transformers) for nested > data types from their "Initial Algebra Semantics is Enough!" paper. > > Cheers, > Steven > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 2

T3738 allocation figures for 32-bit
by Daniel Fischer 02 Apr '11

02 Apr '11

In 7.0.3's testsuite, allT in perf/should_run says: test('T3738', [stats_num_field('peak_megabytes_allocated', 1, 1), # expected value: 1 (amd64/Linux) # expected value: 12800 (x86/OS X): if_wordsize(32, stats_num_field('bytes allocated', 12700, 14000)), if_wordsize(64, stats_num_field('bytes allocated', 60000, 80000)), # expected value: 72608 (amd64/Linux) only_ways(['normal']) ], compile_and_run, ['-O']) which looks quite amazing. On my linux box I consequently get bytes allocated 60608 is more than maximum allowed 14000 *** unexpected failure for T3738(normal) which looks quite horrible. But considering that 6.12.3 allocated nearly 500,000 bytes for that, it's pretty fine. In HEAD's testsuite, the figures have been adjusted to if_wordsize(32, stats_num_field('bytes allocated', 40000, 50000)), and HEAD does that, allocating 46008 bytes. A trivial 'main = return ()' produces ./nuff +RTS -s 47,496 bytes allocated in the heap 1,376 bytes copied during GC 34,036 bytes maximum residency (1 sample(s)) 19,212 bytes maximum slop here Apparently the allocation figures drastically vary by arch and OS, it would probably be necessary to test on several such and be more generous with the limits. Cheers, Daniel

1 0

Re: [Haskell-cafe] is ppc64 arch registerised
by Antoine Latter 01 Apr '11

01 Apr '11

On Fri, Apr 1, 2011 at 6:30 AM, Jiri Skala <jaskalnik(a)gmail.com> wrote: > Hi all, > I've read on this page > > http://hackage.haskell.org/trac/ghc/wiki/Platforms > > the ppc64 arch is registerised. > > I succeeded to build ghc-7.0.2 on ppc64 (Fedora) with > GhcUnregisterised=YES. Switching off this option currently leads to > failure. > > I'd like to know: > > - is the info about registerised ppc64 arch still valid? > > - could you provide me tips how to build it registerised? > Someone on the ghc-users list might know specifics. > Thanks > > Skalnik > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Class constraints for associated type synonyms
by Jan-Willem Maessen 01 Apr '11

01 Apr '11

Hi all - I've been trying to construct a class declaration with an associated type synonym, but I'd like to constrain that type to belong to a particular class. Consider the following class: class Monoid m => Constructs c m | c -> m where construct :: m -> c This captures the idea that the collection c ought to be constructed using the monoid m (say if we're doing the construction using the Writer monad)--the functional dependency indicates the desire for the type c to injectively determine the choice of monoid m. For example: newtype ListBuilder a = Builder ([a] -> [a]) deriving (Monoid) instance Constructs [a] (ListBuilder a) where construct (Builder f) = f [] instance (Ord a) => Constructs (Set a) (Set a) where construct = id Now I'd like to be able to do the same thing using an associated type synonym, something like this: class Monoid (GeneratorOf a) => Generable a where type GeneratorOf a :: * -> * construct :: GeneratorOf a -> a Now, it seems I need FlexibleInstances to do this when I'm using an associated type synonym, but I don't need the flexibility when using a multiparameter type class. In both cases the instance constraint involves types that can be injectively inferred (if I have my terminology straight; work with me here) from a single type mentioned in the class head. In particular, I can imagine storing the dictionary for Monoid (GeneratorOf a) in the dictionary for Generable a, and thus allowing context reduction of (Monoid (GeneratorOf tyvar)) to (Generable tyvar). Meanwhile, I think there are things that are permitted by FlexibleInstances that I'd rather *not* have creeping into my programs. Is there a fundamental constraint I'm missing here that requires the full generality of FlexibleInstances? Do I need to use FlexibleInstances whenever I use associated types in my programs? -Jan-Willem Maessen

3 3

ANNOUNCE: GHC version 7.0.3
by Ian Lynagh 31 Mar '11

31 Mar '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.2, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/release-7-0-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. 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/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ 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/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

5 8