- Glasgow-haskell-users

Internships at MSR Cambridge, summer 2011 and later
by Simon Marlow 28 Jan '11

28 Jan '11

Hi folks, If you're a postgraduate and would like to spend 12 weeks in Cambridge working on a GHC or Haskell-related project, then apply for an internship: we have open slots starting in July this year and later. We've had many successful intern projects over the years. Lots more information here: http://hackage.haskell.org/trac/ghc/wiki/Internships The earliest available slot is the popular July-September summer slot, and for that you would need to have an application in by *Wednesday Feb 16*. However, we can also be flexible about start dates, and if you wanted to start later than July then you have more time to get an application in. By all means apply if you're interested in coming later in the year. Don't forget to email either Simon or myself if you intend to apply. This is very important: otherwise your application gets lost in the system. Cheers, Simon

1 0

Stack overflow weirdness
by Daniel Fischer 28 Jan '11

28 Jan '11

While tuning some code, the test programme suddenly started producing stack overflows. Reverting the code to a previous version did not revert that behaviour, code that previously produced a well-behaved binary now produced stack overflowing ones. But only with ghc-7.0.1, not with ghc-6.12.3 and ghc-6.12.1, and when compiled with optimisations (both, -O and -O2) and without profiling. A HEAD from October and a freshly darcs pulled HEAD displayed the same behaviour as 7.0.1. At some point I tried compiling with -fno-strictness (+ -O or -O2) which again produced well-behaved albeit somewhat slower binaries. An hour or so later, I again compile with -O2 without -fno-strictness to see whether the Core revealed something and, as suddenly as the stack overflows started, they disappeared, for the time being, I consistently get well-behaved binaries. A run of an overflowing binary with -hT -K32M produced a triangular graph with > 10MB Blackhole allocation and > 30MB TSO allocation in the peak. Obviously the behaviour is not reproducible, nevertheless, perhaps somebody has an idea what went on. Or should I attribute it to cosmic rays? Cheers, Daniel

2 2

handleToFd without closing of the file descriptor
by Volker Wysk 28 Jan '11

28 Jan '11

Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker

2 1

Behavior of the inliner on imported class methods
by José Pedro Magalhães 26 Jan '11

26 Jan '11

Hello all, I fail to understand the behavior of the inliner in the following example: module M1 where > > class MyEnum a where myEnum :: [a] > > instance MyEnum () where myEnum = [()] > > module M2 where > > import M1 > > f1 = map (\() -> 'p') [()] > f2 = map (\() -> 'q') myEnum > The generated core code for M2 with ghc-7.0.1 -O is: M2.f22 :: GHC.Types.Char > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 2}] > M2.f22 = GHC.Types.C# 'q' > > M2.f11 :: GHC.Types.Char > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 2}] > M2.f11 = GHC.Types.C# 'p' > > M2.f21 :: () -> GHC.Types.Char > [GblId, > Arity=1, > Caf=NoCafRefs, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] > M2.f21 = > \ (ds_dch :: ()) -> case ds_dch of _ { () -> M2.f22 } > > M2.f2 :: [GHC.Types.Char] > [GblId, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 3 0}] > M2.f2 = > GHC.Base.map > @ () @ GHC.Types.Char M2.f21 M1.$fMyEnum()_$cmyEnum > > M2.f1 :: [GHC.Types.Char] > [GblId, > Caf=NoCafRefs, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 3}] > M2.f1 = > GHC.Types.: > @ GHC.Types.Char M2.f11 (GHC.Types.[] @ GHC.Types.Char) > So, why does the inliner fail to get rid of the map in f2, while correctly ditching it in f1? Note that using two modules is essential here: if the instance is in M2 (and thus becoming orphan), the inliner works "correctly". Adding INLINE/INLINABLE pragmas to myEnum doesn't improve things either. Is this a bug, or is there a reason for this behavior? Thanks, Pedro

3 3

GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

in ghci: Prelude> import Numeric.Units.Dimensional.Prelude as D Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ let s = 9 *~ (meter D.* meter) in s 3.0 m Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ 9 *~ (meter D.* meter) ghci hangs. complied and optimized code detects <<loop>> and let-trick from the above does not help. Here's the complete ghci -v session which contains all package versions ghci -v GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.0.1, for Haskell 98, stage 2 booted by GHC version 6.12.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.0.1-i386/usr/lib/ghc-7.0.1/package.conf.d/package.cache Using binary package database: /Users/pavel/.ghc/i386-darwin-7.0.1/package.conf.d/package.cache hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> import Numeric.Units.Dimensional.Prelude as D hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ let s = 9 *~ (meter D.* meter) in s hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package numtype-1.0 ... linking ... done. Loading package dimensional-0.8.0.1 ... linking ... done. 3.0 m hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ 9 *~ (meter D.* meter) hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: HANG!

4 6

RE: GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

Thanks, Simon! Is the patch in the STABLE snapshot now? pavel On 26.01.2011, at 13:57, Simon Peyton-Jones wrote: > Right; it’s a bug all right. Happily, I committed a major patch two weeks ago, which cures the bug (I checked). The fix will be in 7.0.2. Meanwhile, if you can build the HEAD or get a development snapshot, you should be good to do. > > Thanks for reporting this > > Simon

2 1

Re: GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

Hi, Jeremy. Probably I didn't read your message carefully enough. Sorry for that. In my case there's no recursive code sqrt calls nroot that calls Prelude.nroot and Prelude./. Does that qualify? pavel >> On 25.01.2011, at 22:35, Jeremy Shaw wrote: >> >>> There is a weird type-checking bug in 7.0.1 that causes loopy behavior: >>> >>> http://hackage.haskell.org/trac/ghc/ticket/4809 >>> >>> Not sure if that is what is happening to you or not. Though in my experience it did not actually print <<loop>>, it just hung. > My understanding of the bug is that the type-checker failed to properly detect and handle super classes in recursive dictionaries. As a result the dictionaries call each other in a loop and nothing ever happens.. > You mentioned that the 'let' trick sometimes fixed things. In the code I had trouble with, subtle changes would make the code magically start working. For example, changing *unused* functions in 'where' clauses would cause code to suddenly start working :) > > Anyway, since you are certain your issue is not related, you can just ignore my message. > > - jeremy > > On Jan 25, 2011, at 1:43 PM, Pavel Perikov wrote: > >> It is NOT type checking bug. It causes Rec {} in core and _|_ in runtime :) >> >

1 0

backward compatibility
by Kazu Yamamoto 25 Jan '11

25 Jan '11

Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr -> do _ <- throwSocketErrorIfMinus1Retry "socketpair" $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Of course, indentation is necessary before "_". But this can be compiled with GHC 7.0.1 but cannot with GHC HEAD. I sent feedback to some maintainers of packages. Some quickly fixed it and registered it again. But others did not respond. That is reality. So, my question is why GHC HEAD does not maintain backward compatibility? What are befits for giving it up? --Kazu

11 21

RFC: Compiler plugins for GHC (was: Release/git plans)
by austin seipp 23 Jan '11

23 Jan '11

(moved into g-h-u mainline to avoid cluttering discussion around new GHC plans. Anybody who has comments on the plugins work is encouraged to reply here, not there.) Neil, Preemptive TL;DR: I don't quite know, but I'd be willing to work on it. I seem to remember at the time Max originally did his work (2008,) dynamic linking outside of the home-grown linker inside GHCi (a rather ad-hoc, special-use linker) was not available for any platforms GHC supported. I wouldn't know what windows support lacked at the time it was initially written, and I'm not sure about the state of it now is the main thing I'm getting at I suppose. I didn't know enough about GHC at the time. If my memory serves correctly, Clemens Fruhwirth initally wrote the patches for dynamic linking as we know it for GHC in 2007, although they were only for linux. Later on, Simon M and Duncan Coutts did the remaining work to get it release-quality ready on linux sometime around when the new build system for GHC hit. I seem to remember Well-Typed LLC *also* doing work on also supporting that form of dynamic linking on windows. As a feature it seems to touch several parts of GHC for every supported platform, if it is to support the use-cases we would expect (like writing DLL/shared objects, or also having the compiler being able to dynamically link objects - like plugins.) I can't for the life of me remember if any of this work went into mainline GHC, or what the current state of dynamic linking on windows is. At this exact moment, I do not have a windows machine to test or develop GHC HEAD on - although we're in luck, as I should have a local windows instance to use as a personal machine within the week. I have only tested the patch on Linux and OS X Snow Leopard against GHC HEAD - I am honestly not even aware of what is necessary to build a development version of GHC on windows. But, I would be more than willing and happy to work on it and work with GHC HQ to support it if you're a potential user. I wouldn't want to shaft Windows users anyway. So, if anybody can point out how to get GHC development on windows up and running, I think I can point myself in the right direction. I'll be sure to get back to you on how things go, Neil. On Sat, Jan 22, 2011 at 11:20 AM, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > Hi Austin, > > The compiler plugins work is a great, and I'd be a likely user. The > original version wasn't supported on Windows, because GHC on Windows > lacked various forms of dynamic linking. Does the current patch you've > prepared work on Windows? > > Thanks, Neil > > On Sat, Jan 22, 2011 at 10:29 AM, Max Bolingbroke > <batterseapower(a)hotmail.com> wrote: >> On 21 January 2011 23:59, austin seipp <as(a)hacks.yi.org> wrote: >>> Perhaps Max can >>> elaborate on why this design was rejected in favor of the current one, >>> so we can see how and where it falls down, and what we really want. >> >> The only reason really is that it added a lot of mechanism. From the >> top of my head: >> * Parsing etc for PHASE pragmas that declared phase objects >> * A new namespace for phases >> * Stuff to gather declared phases from all imported modules during compilation >> * A built-in phase for each core pass >> * A solver that ordered core passes and plugin passes according to the phases >> >> So it was a lot of trouble for relatively little gain. In an effort to >> keep the delta against GHC small I threw it out in favour of the much, >> much simpler design we have today. >> >>> Thomas pointed out the Scala compiler plugin design document, so I'll >>> be sure to read over it this weekend when I get the chance to cook up >>> ideas. >> >> The Scala plugins project was just starting when I was working on GHC >> plugins so there was no design doc I could refer to at that time. >> Shame :-( >> >> Thanks for taking the lead on resurrecting plugins, Austin! >> >> Cheers, >> Max >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > -- Regards, Austin -- Regards, Austin

2 1

Release/git plans
by Simon Marlow 22 Jan '11

22 Jan '11

As promised, here are our plans for forthcoming GHC releases and the git switchover: - do a 7.0.2 RC as soon as possible, followed shortly by a release. Currently blocking this is a problem with Cabal that shows up on OS X 10.6, we hope to have this resolved soon. - switch the GHC repo to git (this is ready to go, we just need to flip the switch and do some work on the wiki build documentation) - switch the libraries and other repositories to git, once we have decided on the strategy (mirror or convert) for each one. - make a new stable branch for 7.2, and release 7.2.1 shortly after. So we'll be doing a 7.2.1 release much earlier than planned. Our motivation for doing this is: - the 7.0 branch is darcs, but the HEAD will be git, so the longer this situation persists the more difficult it is to merge changes. Hence we want to fork a new STABLE branch as soon as possible. - one of the fixes we need to make soon, to fix equality superclasses, is too large a change to put in the 7.0 branch. We also have some pending changes to the internal representation of coercions that will be disruptive in HEAD, and will make future merging to 7.0 difficult. - 7.0.2 should be a nice stable release, and HEAD is actually in pretty good shape right now too. FYI, the git repo is now attached to our Trac instance, so you can browse the source tree and history here: http://hackage.haskell.org/trac/ghc/browser it's not terribly fast, but it works. With git we'll be able to link directly to commits from tickets and vice-versa. The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git (note different from the URL for the testing repo, although it's the same repo). I'm mirroring this manually from the darcs repo, so it might lag a bit at times. Cheers, Simon

8 10