- Glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.1 beta
by humasect 25 Sep '08

25 Sep '08

installPackage: internal error: stg_ap_ppp_ret (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [build.stage.1] Abort trap make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 Intel Mac. I will also report bug. peace and happiness, -humasect

4 3

Re: GADTs and functional dependencies
by Wolfgang Jeltsch 24 Sep '08

24 Sep '08

Am Dienstag, 23. September 2008 19:07 schrieben Sie: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > >> > >> data GADT a where > >> > >> GADT :: GADT () > >> > >> class Class a b | a -> b > >> > >> instance Class () () > >> > >> fun :: (Class a b) => GADT a -> b > >> fun GADT = () > > > > I’d expect this to work but unfortunately, using GHC 6.8.2, it fails with > > the > > > > following message: > >> FDGADT.hs:12:11: > >> Couldn't match expected type `b' against inferred type `()' > >> `b' is a rigid type variable bound by > >> the type signature for `fun' at FDGADT.hs:11:16 > >> In the expression: () > >> In the definition of `fun': fun GADT = () > > > > What’s the reason for this? Is there a workaround? Does this work in > > 6.8.3 or 6.10.1? > > This similar code using type families compiles in 6.8.3 and 6.9: > > data GADT a where > GADT :: GADT () > > type family F a > type instance F () = () > > fun :: GADT a -> F a > fun GADT = () Exactly. But this makes my code incompatible with GHC 6.6. :-( I thought, someone said that with the new typing machinery in GHC 6.10, more functional dependency programs are accepted because functional dependencies are handled similarly to type families (or something like that). Is this true? Since the type family version is okay, why shouldn’t the functional dependency version be okay? Best wishes, Wolfgang

2 2

Debian stable not supported?
by Yitzchak Gale 24 Sep '08

24 Sep '08

The Debian ghc6 package for the stable distribution is currently back at GHC 6.6 - not surprising given the way stable works at Debian. There is currently no backport of a more recent GHC to Debian stable. I need GHC 6.8 for a project to run on a production server. That means it will be running Debian stable. Unfortunately, the so-called "generic" Linux binary distribution package for GHC 6.8.3 does not work on the current, up-to-date Debian stable distribution because it is "too old". In my case, and I suspect for many people, the production server running stable is on a low-cost hosted VPS. That kind of platform doesn't have nearly enough memory and disk space to compile GHC. So even that is not an option. I know that in the past Haskell was used exclusively for research, but nowadays shouldn't it be possible to use Haskell also for production-quality projects? With help from Igloo and thetallguy on #ghc, for which I am grateful, I was finally able to get a working GHC 6.8.3 on my production server, but only after jumping through a lot of hoops. It involved setting up a Debian-stable-like environment in a chroot on another computer, building GHC there from source, and manually moving all of the appropriate files up to the server. Before I delete that chroot build environment - could it be useful for making GHC 6.8.3 available to others? If someone points me in the right direction, perhaps I could create a binary tarball and/or backport deb. Or at least record somewhere the basic steps of how to get a recent GHC in this situation. Thanks Yitz

5 5

GHC 6.8.3's source is unusable?
by Magicloud 24 Sep '08

24 Sep '08

Hi, I want to compile ghc on my office box, which does not have any binary ghc exist. So I followed http://hackage.haskell.org/trac/ghc/wiki/Building/Porting, "Porting GHC to a new platform" section. Well, this was what I got: (On target) $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target sytem type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for ghc... no checking for ghc-pkg matching... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2660: -v0: command not found ./configure: line 2664: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory What does this mean!

4 4

Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
by Chris Kuklewicz 23 Sep '08

23 Sep '08

I am cross-posting this message to several lists. I had learned the trick before the documentation was updated. It seems I have used a very unreliable trick. And the "use castToSTUArray" suggested alternative is a really poor one since I am not using arrays at all. Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the "binary" package). The alloca/poke/peek work around I have looks like castWord32ToFloat :: Word32 -> Float castWord32ToFloat x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) castFloatToWord32 :: Float -> Word32 castFloatToWord32 x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) The unsafeCoerce trick that is no longer working looks like: castWord64ToDouble :: Word64 -> Double castWord64ToDouble (W64# w) = D# (unsafeCoerce# w) castDoubleToWord64 :: Double -> Word64 castDoubleToWord64 (D# d) = W64# (unsafeCoerce# d) Any ideas? Or is the alloca trick the only way to do this? Chris Ian Lynagh wrote: > Hi Chris, > > On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote: >> Also, I tried two tricks: >> (D# x) <-> (W64# x) which works fine >> (F# x) <-> (W32# x) which produced garbage, so I had to replace it with >> alloca/poke/peek. > > This isn't supported, and I suspect is the cause of the -fasm problems. > > Please see > http://hackage.haskell.org/trac/ghc/ticket/2209 > for more details and suggested alternative. > > > Thanks > Ian >

3 2

Re: Instances and DoCon
by Serge D. Mechveliani 23 Sep '08

23 Sep '08

On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: > On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: > > | > > | And still ghc-6.8.3 builds itself from source. > > > > I have no idea how -- Happy has been needed for some time. Maybe someone else does. > > It's not meant to be needed for building from a source tarball. > This should be fixed now. Dear GHC team, can you, please, provide such GHC source distributives which require possibly smaller set of programs for the user to separately pre-install? For example, do not require of the user to install Alex, Happy and Cabal. Because we write applications in Haskell. For example, the user needs to program algebra by using some CA library written in Haskell. One needs to install GHC -- and the simpler the better. In this situation, it is bad to force him to think of what is Alex or Happy, and where to find them and how to install. The least hindrance in installation makes some users to reject the tool: "Oh! looks messy, suspicious thing. I tried the binary, but it reports of wrong libarary versions. I have already spent one hough! Also these pure functional languages look restrictive ... Let me better try the Foo system". Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Some initial results with DPH
by Austin Seipp 23 Sep '08

23 Sep '08

(I'm posting this here in the hope people like Manual and Roman will see it and take some interest.) I've built the GHC 6.10 beta (that is, The Glorious Glasgow Haskell Compilation System, version 6.10.0.20080921) mainly so I could play around with DPH because it's too exciting to ignore any longer. The program I'm using here is pretty trivial but it's a simple enough test case, I think. It's really cribbed from dph's examples almost entirely, I just made some superficial data sets to test on and here are the results. The code is attached in a .tar file; you'll need to tweak the Makefile to point to your GHC instead of mine if you use it. Things to note: * The vectorise pass boosts compilation times *a lot*. I don't think this is exactly unwarrented since it seems like a pretty complicated transformation, but while making the primitive version using just the unlifted interface the compilation takes about 1.5 seconds, for the vectorised version it's on the order of 15 seconds. For something as trivial as this dot-product thing, that's a bit of a compilation time, though. * It's pretty much impossible to use ghc-core to examine the output core of the vectorised version - I let it run and before anything started showing up in `less` it was already using on the order of 100mb of memory. If I just add -ddump-simpl to the command line, the reason is obvious: the core generated is absolutely huge. * For the benchmark included, the vectorised ver. spends about 98% of its time from what I can see in the GC before it dies from stack overflow. I haven't tried something like +RTS -A1G -RTS yet, though. * The vectoriser is really, really touchy. For example, the below code sample works (from DotPVect.hs): > import Data.Array.Parallel.Prelude.Int as I > > dotp :: [:Int:] -> [:Int:] -> Int > dotp v w = I.sumP [: (I.*) x y | x <- v, y <- w :] This however, does not work: > dotp :: [:Int:] -> [:Int:] -> Int > dotp v w = I.sumP [: (Prelude.*) x y | x <- v, y <- w :] That is, just using the version from Prelude causes the vectoriser to err like so: > ghc -o vect --make test.hs -fcpr-off -threaded -Odph -funbox-strict-fields -fdph-par > [1 of 2] Compiling DotPVect ( DotPVect.hs, DotPVect.o ) > *** Vectorisation error *** > Tycon not vectorised: GHC.Num.:TNum > make: *** [vect] Error 1 > This is a particularly strange occurance; reason being if we dig into the source code of the dph-par package we see that Data.Array.Parallel.Prelude.Int simply re-exports Data.Array.Parallel.Prelude.Base.Int (which is a hidden module, mind you) which is where (*) is defined, and it is defined like so: > (+), (-), (*) :: Int -> Int -> Int > (+) = (P.+) > (-) = (P.-) > (*) = (P.*) Where 'P' is the qualified Prelude import. Am I misunderstanding something here about how the dph packages are layed out? I think this is pretty correct and if so it's a really really strange happening to be honest. I also ran into a few other errs relating to the vectoriser dying - if I can find some I'll reply to this with some results. So far this all seems pretty negative, but on the flip-side... * The unlifted interface exported by the dph-prim-{par,seq} packages is wonderful and already works really well. See http://hpaste.org/10621 for an example - super low-GC time, both of my cores get used. * As I have increased the data sets for the dot-product example, my cores continue to get used and the GC time stays really, really low which is a great thing. * I've yet to hit any strange compilation err or problem when using the primitive packages. * Strictly speaking the dph-{par,seq} packages seem to expose more to code and combinators to those pieces of code using the vectorisation pass, but the combinators here are simple, they work and you get good results. * GHC hits a lot of optimizations, with ghc-core you can see thousands upon thousands of rules firing all over the place to aggressively inline/transform things! The DPH work done so far seems fantastic and I realize this is all in the works so everything I say now might not be worth anything tomorrow, and GHC 6.10 is only shipping with a very limited version of the system, but I figured some people would like to see initial results on some small test cases. I plan on exploiting this package a lot more in the future and testing it with larger computations and data sets, and when I do I'll be sure to give the feedback to you guys (once HEAD is steaming along again and the 6.10 branch has calmed.) Austin

2 2

skip -O2 via-C
by Serge D. Mechveliani 20 Sep '08

20 Sep '08

I take back my two recent reports about the effect of -O2, -fvia-C. Because 1) -O is sufficient, 2) there are too many issues that are more important than the behavior under -O2 and via-C. So, it is a good idea to save effort. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

testing ghc-6.10-candidate
by Serge D. Mechveliani 20 Sep '08

20 Sep '08

Simon Peyton-Jones <simonpj(a)microsoft.com> wrote on 15 Sep 2008 about Instances and DoCon To: "Serge D. Mechveliani" <mechvel(a)botik.ru> CC: "cvs-ghc(a)haskell.org" <cvs-ghc(a)haskell.org> > Serge > > I take it all back. I've been persuaded that it's best to accept > DoCon-sty le instances as they appear, and I've put quite a bit of > work into making it so. > > So you should not need to change any code. Do try the HEAD > (any recent snapshot should do) if you can. All right, I have tested ghc-6.9.20080910 on docon-2.12-pre. Find the source on http://botik.ru/pub/local/Mechveliani/ghcBugs/docon-2.12-pre.zip It is put there only for testing GHC, and it has the compilation flag denotation in docon.cabal improved for newer Cabal and ghc-6.10. The tet shows the followng. 1. It accepts the DoCon-style overlapping instances (as in docon-2.11) -- in the example of ... => LinSolvRing (Fraction a) that you pointed out below. 2. But in several places DoCon has parasitic additions (similar to the below MulSemigroup (Fraction a)) to the context for overlapping instances. These places are marked in the docon-2.12-pre source with 'overlaps in ghc'. I would like to cancel them, similar as we now cancel the above MulSemigroup (Fraction a) in the context. But ghc-6.9.20080910 does not allow this. So, I wonder: what is the difference? 3. `Making' under -O2 reports for the module Det_.hs several warnings of the kind ... [25 of 83] Compiling Det_ ( Det_.hs, dist/build/Det_.o ) SpecConstr: too many specialisations for one function (see -fspec-constr-count): Function: dt{v X1E1R} [lid] Specialisations: [([sc_s1E2A{v} [lid], sc_s1E2B{v} [lid], ... What might this mean? 4. It has improved: it `makes' docon-2.12 under -O fast enough, without code explosion, the code is as fast as expected. It also `makes' the test Main under -O fast enough (unlike ghc-6.8.3). 5. The same is for -O2. But this does not gain more performance. -O2 -fvia-C also does not gain more performance, but leads to 7 times longer compilation. Anyway, I am satisfied with -O. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru ------------------------------------------------------------------- | Good news: I have cured the massive code-explosion problem you | encountere with GHC 6.8. I'm | about to commit a patch for that, so it'll be in GHC 6.10. | | However, I'm now getting a complaint about overlapping instances | (DoCon 2.11). GHC 6.10 is | being a bit more consistent about coherence. Here is one example: | | Fraction.hs:124:48: | Overlapping instances for MulSemigroup (Fraction a) | arising from a use of `inv' at Fraction.hs:124:48-57 | Matching instances: | instance [overlap ok] (GCDRing a) =3D> MulSemigroup (Fraction a) | -- Defined at Fract_.hs:438:9-46 | instance [overlap ok] MulSemigroup (Fraction Integer) | -- Defined at Fraction.hs:260:9-39 | (The choice depends on the instantiation of `a' | To pick the first instance above, use -XIncoherentInstances | when compiling the other instance declarations) | | It's absolutely right! If you wanted the instance for | (MulSemigroup (Fraction Integer)), then | the call to inv could in principle use | MulSemigroup (Fraction Integer) instance, and give | different behaviour. (See the user manual stuff about incoherent- | instances.) | | Possible solutions: | a) add -XAllowIncoherentInstances | b) make the instance declaration look like | instance (MulSemigroup (Fraction a), GCDRing a) => | LinSolvRing (Fraction a) | thereby deferring the choice [..]

2 2

Overlapping instance declarations
by Simon Peyton-Jones 19 Sep '08

19 Sep '08

| 2. But in several places DoCon has parasitic additions | (similar to the below MulSemigroup (Fraction a)) | to the context for overlapping instances. | These places are marked in the docon-2.12-pre source with | 'overlaps in ghc'. | I would like to cancel them, similar as we now cancel the above | MulSemigroup (Fraction a) in the context. | But ghc-6.9.20080910 does not allow this. | So, I wonder: what is the difference? No you can't cancel them! Consider class Foo a where fop :: a->a instance Foo [a] where ... instance Foo [Int] where .. class Bar a where bop :: a -> a instance Bar [a] where bop = fop In the Bar [a] instance, we get a constraint (Foo [a]). It's wrong to commit to the Foo [a] instance, because if you are ultimately building a Bar [Int] instance you want the Foo [Int] instance of fop! The Right Thing is to add (Foo [a]) to the context of the Bar instance thus instance Foo [a] => Bar [a] where bop = fop I'll expand the user manual (in the section about overlapping instances) to cover this point. The other situation that DoCon contains is more like this: class C a where { op1,op2 :: a -> a } instance C [Int] where... instance C a => C [a] where op1 x = op2 x ++ op2 x op2 x = ... In the C [a] instance you'll see that op1 calls op2, thereby giving rise to a C [a] constraint. I *originally thought* that the same reasoning applied as above, so we should reject the program. But applying the solution I describe above would give instance C [a], C a => C [a] where .. which is silly. Here the Right Thing is to satisfy the C [a] constraint "locally", without worrying about the overlap. This is justified because we'll only be *in* the code for op1 in the C [a] instance if we know that 'a' does not match Int. Thanks for bringing this up. Simon

2 1