December 2010 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

MonoLocalBinds and hoopl
by Edward Z. Yang 19 Jun '11

19 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

ANNOUNCE: GHC 7.0.2 Release Candidate 1
by Ian Lynagh 26 Feb '11

26 Feb '11

We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

10 17

New codegen failing test-cases
by Edward Z. Yang 14 Jan '11

14 Jan '11

I fired up the new codegen and ran make fast on the regression suite and the following new tests started failing: 3207(normal) 4030(normal) cgrun016(normal) cgrun045(normal) cgrun051(normal) dsrun005(normal) dsrun007(normal) dsrun008(normal) exceptionsrun001(normal) exceptionsrun002(normal) ffi021(normal) simplrun010(optc) strun002(optc) I plan on investigating them in further detail. Cheers, Edward

9 30

Some patches for GHC
by Bas van Dijk 05 Jan '11

05 Jan '11

Hello, I was just wondering if somebody could review (and hopefully apply) some of or all the patches in: http://hackage.haskell.org/trac/ghc/attachment/ticket/4834/ghc_new_monad_hi… Note that these patches are independent of the newly proposed monad hierarchy. Thanks, Bas

2 2

How to compile unregisterised build?
by Karel Gardas 04 Jan '11

04 Jan '11

Hello, before going to fill some bugreports about broken unregisterised builds I'd like to be sure I understand the topic and know well how to configure it. So, I do have three platforms with Linux OS: - mips64: gcc 4.3.2 + ghc 6.8.2 (debian) - ARMv7: gcc 4.4.1 + ghc 6.10.4 (Ubuntu) - IA64: gcc 4.3.2 + ghc 6.8.2 (debian) on all three, I attempted to build 6.12.3 unregisterised by: ./boot ./configure cat > mk/build.mk GhcUnregisterised=YES GhcWithNativeCodeGen=NO SplitObjs=NO ^D make On all three platforms this failed with: mips64: "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.o In file included from /home/kgardas/src/ghc-6.12.3/includes/Stg.h:230, from /tmp/ghc14979_0/ghc14979_0.hc:3:0: /tmp/ghc14979_0/ghc14979_0.hc: In function ‘ghczmprim_GHCziGenerics_zdgtoUnit_entry’: /tmp/ghc14979_0/ghc14979_0.hc:17:0: warning: implicit declaration of function ‘JMP_’ ghc-stage1: could not execute: /home/kgardas/src/ghc-6.12.3/inplace/lib/ghc-asm make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.o] Error 1 make: *** [all] Error 2 ARMv7: "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.o /tmp/ghc29691_0/ghc29691_0.hc: In function ‘ghczmprim_GHCziGenerics_zdgtoUnit_entry’: /tmp/ghc29691_0/ghc29691_0.hc:18:0: warning: implicit declaration of function ‘JMP_’ ghc-stage1: could not execute: /home/kgardas/src/ghc-6.12.3/inplace/lib/ghc-asm make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.o] Error 1 make: *** [all] Error 2 IA64: "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.o /tmp/ghc15668_0/ghc15668_0.hc: In function ‘__stginit_ghczmprim_GHCziGenerics’: /tmp/ghc15668_0/ghc15668_0.hc:331:0: warning: function called through a non-compatible type /tmp/ghc15668_0/ghc15668_0.hc:331:0: note: if this code is reached, the program will abort ghc-stage1: could not execute: /home/kgardas/src/unreg/ghc-6.12.3/inplace/lib/ghc-asm make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.o] Error 1 make: *** [all] Error 2 Is that my own mistake or is it really ghc 6.12.3 unregisterised build that broken? Thanks, Karel -- Karel Gardas kgardas(a)objectsecurity.com ObjectSecurity Ltd. http://www.objectsecurity.com

2 3

Edentv build
by Aswad, Mustafa 31 Dec '10

31 Dec '10

Hi Mesha; I try to build the latest version from edentv, but I have problem to build the depends packages. I am stick to build "cairo", it gives my the following error Preprocessing library cairo-0.12.0... Building cairo-0.12.0... Graphics/Rendering/Cairo.hs:8:0: error: cairo-version.h: No such file or directory It is required by GTK packages. Can you till where I can find the right version that can build with ghc-6.12.3 or to install this package? I have tried the one which in http://hackage.haskell.org/packages/archive/cairo/0.12.0/ but it does not work. cheers -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

2 1

Re: [darcs-users] How to develop on a (GHC) branch with darcs
by Iavor Diatchki 22 Dec '10

22 Dec '10

Hello, Thanks for all your responses (and the --skip-conflicts tip)! I use git for a lot of my development, so I was hoping that I was just experiencing "culture shock" and simply doing things with the wrong mind-set. Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution. For me, switching GHC to git would certainly be a win. In terms of the future of darcs, while better tools for managing rebasing would certainly be useful, I am not confident that any solution based on mutation (i.e., "rewriting history" by rebasing/ amend-recoding) would work well in a distributed environment due to the difficulty of sharing these changes---it seems to require some sort of "higher order" version control where you have to keep track of the changes to the changes :-) In the context of git, I only brought up "rebasing" because it seemed like the closest concept to what I was doing with darcs. If GHC was to switch to git, I think that we should certainly use git's ordinary merge model to keep track of history. -Iavor PS for VCS folks: I think that an interesting idea of combining darcs and git would be to use git's graph-based history model, but to annotate the edges on the graph with semantic patches ala darcs. This would make it possible to write smarter auto-merge strategies for git. On Tue, Dec 7, 2010 at 7:16 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > Ganesh Sittampalam writes: > > > I think there are three things that can help with this problem: > > > > 1) a darcs rebase command. This will give you a nice way to manage the > > workflow already discussed, and you won't have to squish everything > > through into a mega-patch. You'll still have to periodically abandon one > > branch for another though (but I think that's also the case with git > > rebase). > > I'm not sure what you mean by "abandon". > > In a git rebase, you pretty much have to forget the original branch > immediately (everywhere in the world!), or there will be great fun for > all concerned. You really really do not want to merge an original > branch with its rebased descendant in git.[1] Unfortunately, unless > the rebased branch gets dibs on the branch's name, it's all too easy > to perform such a merge inadvertantly (eg, git pull will do it). So > in that sense a git rebase means immediately abandoning the old branch, > and all the commit history of the old branch. (The details of the > history are copied into the rebased commits, but they do not have the > same identity as the originals, so merge conflicts are guaranteed.) > > > I also have some hope, though this is more speculative, of offering > > a clean way of tracking the relationship between the old branch and > > the new branch so that any stray patches against the old branch can > > be cleanly rebased to the new branch later on. > > As explained above, DAG-based VCSes like git can't do this cleanly > (that is one way of expressing the reason why rebase is severely > deprecated in some circles), and I don't think git will be able to do > so in the near future. OTOH, if Darcs gets rebase but can't handle > this, I'd have to count that as a net minus. Recombinant patching is > really what Darcs is all about IMO. > > In practice, git rebase needs to be kept private to a single user, and > is impractical even if private, if the user has propagated the branch > to other local repositories. Because git branching is so lightweight, > nobody really sees this as a big problem; throwaway branches are used > all the time as interim steps in many operations (eg, git stash). > Darcs branches, on the other hand, are much more heavyweight (modulo > the work you propose on colocated branches, but that's farther away > than rebase is). > > IMHO YMMV. But I strongly recommend you think carefully about this. > Analogies to git rebase are a trap here. It's implemented differently > and used to solve different problems from the way rebase is proposed > for use in Darcs. > > > Footnotes: > [1] There may be better ways to deal with this than garbaging the > original commits, but so far nobody really needs it. > >

12 12

Beware: Bad I/O performance on Windows without -threaded
by Simon Marlow 21 Dec '10

21 Dec '10

I just noticed that I/O performane on Windows without -threaded is pretty terrible. The following program: main = getConetnts >>= putStr tested with a 1MB file: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.28s ( 0.49s elapsed) <snip> But if we add -threaded: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs -threaded $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.05s ( 0.07s elapsed) <snip> Several times better. I just made a tweak in my working tree to increase the I/O buffer sizes, and this helps quite a lot: $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.06s ( 0.05s elapsed) <snip> $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs -threaded $ ./cat <1M >/dev/null +RTS -s <snip> Total time 0.05s ( 0.05s elapsed) <snip> Why is this? I'm not entirely sure, but I suspect it is the implementation of asynchronous I/O in the RTS that is only used on Windows without -threaded (rts/win32/AsyncIO.c etc.). Every I/O operation in the non-threaded RTS on Windows involves a couple of OS-thread switches. I'll get the buffer size fixes into 7.0.2. Cheers, Simon

1 0

GIO.012.0 installation
by Aswad, Mustafa 21 Dec '10

21 Dec '10

Hi dear; I am try to build Gio package using cabal version cabal-install version 0.8.2 and Ghc version version 6.12.3. Bu I got such error which I can not solve it setup: The pkg-config package gio-2.0 version >=2.16.4 is required but it could not be found. Could any of you till me how come this problem. thanks -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

2 1