- Glasgow-haskell-users

Re: newSession gone from GHC API
by humasect 29 Sep '08

29 Sep '08

Also to make Located String in the simple way: import SrcLoc L noSrcSpan "-hidir ../build" also make sure to "import MonadUtils" for that version of liftIO. I have converted the graphical/opengl/openal shell for the project I am working on successfully, let me know if you have questions! -lyndon 2008/9/29 Claus Reinke <claus.reinke(a)talk21.com> I just noticed that newSession has been removed from the GHC API. >> Unfortunately, this breaks nearly all examples on the web: >> http://www.haskell.org/haskellwiki/GHC/As_a_library >> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API >> Could someone fix those up, to show the new style of interaction? Also >> are the breaking changes to newSession in GHC 6.10, or only in GHC Head? >> > > Thomas said he was working on a conversion guide, but > delayed by travelling: > > http://www.haskell.org/pipermail/cvs-ghc/2008-September/045361.html > > Meanwhile, since you're somewhat familar with haddock, his > patches to port haddock to the new api may help (I used them > to figure out where to look for more info;). Or, if you prefer > smaller examples, have a look at > > http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/syb-utils/examples/GhcApiSybT… > > which I patched recently (diff below). Mostly, you'll be looking for > runGhc, dropping session parameters, changing dynamic flags from > String to Located String, and splitting checkModule into separate > phases (there's a class that simplifies access via the old record selector > functions). Possibly other small things, like using liftIO to > do IO in the Ghc monads. > > Hth, > Claus > > $ darcs changes -v -p 'new Ghc Api' | sed 's/\[_.._\]\[_._\]$//' > diffing dir... > Mon Sep 22 20:01:02 GMT Daylight Time 2008 claus.reinke(a)talk21.com > * adapt example to new Ghc Api > { > hunk ./examples/GhcApiSybTesting.hs 15 > +import SrcLoc > +import MonadUtils > hunk ./examples/GhcApiSybTesting.hs 35 > -main = defaultErrorHandler defaultDynFlags $ do > - s <- newSession (Just libdir) > - flags <- getSessionDynFlags s > - (flags,_,_) <- parseDynamicFlags flags ["-package ghc"] > +main = defaultErrorHandler defaultDynFlags $ > + runGhc (Just libdir) $ do > + flags <- getSessionDynFlags > + (flags,_,_) <- parseDynamicFlags flags [noLoc "-package ghc"] > hunk ./examples/GhcApiSybTesting.hs 40 > - setSessionDynFlags s flags{ hscTarget=HscInterpreted } > - addTarget s =<< guessTarget source Nothing > - load s LoadAllTargets > - unqual <- getPrintUnqual s > + setSessionDynFlags flags{ hscTarget=HscInterpreted } > + addTarget =<< guessTarget source Nothing > + load LoadAllTargets > + unqual <- getPrintUnqual > + {- > hunk ./examples/GhcApiSybTesting.hs 50 > + -} > + tcm <- typecheckModule =<< parseModule (mkModuleName modName) > + doSomething unqual tcm > hunk ./examples/GhcApiSybTesting.hs 63 > - doSomething unqual cm = do > - let parsed = parsedSource cm > - renamed = renamedSource cm > - typechecked = typecheckedSource cm > + doSomething unqual tcm = liftIO $ do > + let parsed = parsedSource tcm > + renamed = renamedSource tcm > + typechecked = typecheckedSource tcm > hunk ./examples/GhcApiSybTesting.hs 84 > - maybe (putStrLn "no typechecked source") > - (printForUser stdout unqual . shown TypeChecker) > typechecked > + printForUser stdout unqual $ shown TypeChecker typechecked > > } > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

GADTs and functional dependencies
by Wolfgang Jeltsch 29 Sep '08

29 Sep '08

Hello, please consider the following code: > {-# 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? Thank you in advance. Best wishes, Wolfgang

7 15

6.10-candidate tested
by Serge D. Mechveliani 29 Sep '08

29 Sep '08

Dear GHC developers, I have tested ghc-6.10.0.20080921 on * making it by ghc-6.8.2, * making it by itself, * the DoCon and Dumatel applications. It looks all right. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

6 10

newSession gone from GHC API
by Mitchell, Neil 29 Sep '08

29 Sep '08

Hi I just noticed that newSession has been removed from the GHC API. Unfortunately, this breaks nearly all examples on the web: http://www.haskell.org/haskellwiki/GHC/As_a_library http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API Could someone fix those up, to show the new style of interaction? Also are the breaking changes to newSession in GHC 6.10, or only in GHC Head? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

2 1

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

28 Sep '08

uh oh.. ~/Haskell/bin/ghc +RTS -N2 -RTS -hidir ../build/ -odir ../build/ -threaded -package ghc -main-is Shell --make Shell -DCALLCONV=ccall [4 of 4] Compiling Shell ( Shell.hs, ../build/Shell.o ) Linking Shell ... ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) When linking with new GHC api after converting this shell to use it ( http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus) -lyndon

3 3

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