- Glasgow-haskell-users

Packages in GHC 6.6
by Simon Marlow 25 Aug '06

25 Aug '06

Here is what I propose to do regarding the libraries we ship with GHC 6.6. Comments are appreciated, since we need to finalise this story before the release candidate at the end of this week. For a while we have had the goal of devolving as many of the libraries that ship with GHC as possible. With Cabal, this is now possible: you can download GHC and then install 3rd-party packages with little hassle, or upgrade libraries that came with your GHC installation. So the days of the monolithic GHC+libraries installations should perhaps come to an end. On the other hand, it's often quite useful to be able to install a single distribution and get a comprehensive set of libraries. The folks who package GHC for the deeply package-based OSs like Debian, Gentoo and *BSD would like GHC to come with a minimal set of libraries and install the others as separate packages. Another consideration is that it's useful for our nightly builds to build as many libraries as possible, so we can help catch bitrot. However, the default GHC build now takes a very long time mostly due to the huge set of libraries, and most people building GHC don't need to build eg. OpenGL by default. What's more, the maintainers of many of these libraries would like to be able to make releases independently of GHC. So here's what I propose: - A "GHC source tree" will contain a core set of packages. This is what you will get if you download ghc-6.6-src.tar.bz2, or do "sh darcs-all get" in a darcs repo. The core packages are: base, haskell98, template-haskell, readline, stm, Cabal, unix, Win32 plus hopefully regex-base and regex-posix if I integrate them this week. These are the packages required to bootstrap GHC, or those with deep GHC dependencies (template-haskell & stm). - The core packages will have a stable API across patchlevel releases of GHC (perhaps with the exception of Cabal). We will fork the darcs repos of the core packages where necessary. - A source tree can optionally be populated with more packages, which will be included in the build as normal. At the moment, the only packages you can add in this way are: ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, fgl, haskell-src, html, mtl, network, parsec, time, xhtml because we're still using GHC's build system to build packages rather than Cabal. When we switch to using Cabal to build packages inside a GHC build, then it will be possible to populate the tree with any Cabal package. Possibly we could also distribution an "extra libs" source bundle containing these packages. - We will continue to build all these packages in the nightly builds. (but perhaps build failures in optional packages should not break the whole build). - darcs-all will have an option to grab the optional packages (all the packages in the list above). - Gentoo, Debian etc. will include only the core packages with GHC, the others will become separate entities. - We will continue to bundle the .tar.bz2 binary distributions, and the Windows installer, with all the optional packages. Perhaps there could also be minimal installers containing just the core packages. - We may have to change the set of core packages in the future, if GHC accumulates more dependencies for example. Any comments, or suggestions? Cheers, Simon

6 16

Re: Packages in GHC 6.6
by Krasimir Angelov 25 Aug '06

25 Aug '06

I wrote simple tool that I am using to build MSI installer for Visual Haskell. It will not be so hard to extend it to support Cabal. After that it will be easy to prepare an installer for GHC with optional libraries. Don't expect it to be ready for 6.6 release! Cheers, Krasimir On 8/22/06, Jason Dagit <dagit(a)eecs.oregonstate.edu> wrote: > [snipped] > For the windows installer, I imagine this working something like the > cygwin or ms office installer. There could be a screen listing all > the libraries and the installer itself comes in two flavors, either > contains only the minimum (and uses the network to grab any > additional) or the installer contains everything and lets the user > select which packages to install (defaulting to everything).

3 5

Data.Generics vs. Template Haskell
by Vyacheslav Akhmechet 25 Aug '06

25 Aug '06

I am trying to figure out where these two libraries stand in relation to each other and which one is preferred to do generic programming in Haskell. I understand that their goals often intersect but couldn't find any good comparisons. Could someone point me in the right direction? Thanks, - Slava Akhmechet

4 3

Re: Data.Generics vs. Template Haskell
by Vyacheslav Akhmechet 24 Aug '06

24 Aug '06

---------- Forwarded message ---------- From: Vyacheslav Akhmechet <coffeemug(a)gmail.com> Date: Aug 24, 2006 5:35 PM Subject: Re: Data.Generics vs. Template Haskell To: Bulat Ziganshin <Bulat.Ziganshin(a)gmail.com> Ok, so there are two aspects that I can see here. One such aspect is ability to "reflect" on types (at runtime or compile time). An example of that is creating an automatic mapping from relational databases to haskell newtypes. Another aspect is being able to get an a representation of Haskell code AST in terms of Haskell datatypes in order to be able to process Haskell ASTs in Haskell. As far as I can see the first aspect is a subset of the second because all Haskell types are known at compile time. If this is the case, why the need for two libraries (I am not counting DriFT because it looks like it hasn't been maintained for a long time)? Or am I missing something? Additionally, which one is more maintained and has the most potential to become standard (whether de facto or real) in the future? On 8/24/06, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > Hello Vyacheslav, > > Thursday, August 24, 2006, 11:51:46 PM, you wrote: > > > I am trying to figure out where these two libraries stand in relation > > to each other and which one is preferred to do generic programming in > > Haskell. I understand that their goals often intersect but couldn't > > find any good comparisons. Could someone point me in the right > > direction? > > search for "generics" on hswiki, you should find a lot of papers. in > particular, there is a new paper that compares many different > approaches to generic programming. in particular, TH is not g.p. > tools, it's just a universal Haskell code generator whcih can be used > to solve particular tasks in this area. but to solve general problem > of defining traversal function what has some general case and a nu,ber > of type-specific cases TH is not very appropriate > > TH (and DriFT) are widely used to generate instances like the haskell > compiler itself generates instances for Eq/Show/... and TH, > unlike many g.p. tools does it at compile-time. using TH, you also get > access to field/constructor names > > summary: if your task fits into the features provided by g.p. tools, > you will gain a much time using them. if your task need compile-time > code generation (so that generic program will be no slower than > hand-written one) or you need some advanced features which your g.p. > tool doesn't provide - welcome to TH with all its programming > oddities. development of TH routines for g.p. is an order of magnitude > slower (at least!) than doing the same with specialized tool > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > >

1 0

RE: Packages in GHC 6.6
by Simon Marlow 24 Aug '06

24 Aug '06

On 24 August 2006 11:20, Henning Thielemann wrote: > On Tue, 22 Aug 2006, Simon Marlow wrote: > >> - A source tree can optionally be populated with more packages, >> which will be included in the build as normal. At the moment, >> the only packages you can add in this way are: >> >> ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, >> fgl, haskell-src, html, mtl, network, parsec, time, xhtml >> >> because we're still using GHC's build system to build packages >> rather than Cabal. When we switch to using Cabal to build >> packages inside a GHC build, then it will be possible to populate >> the tree with any Cabal package. >> >> Possibly we could also distribution an "extra libs" source >> bundle containing these packages. > > Just a question: Will it still be possible to have an Haddock index of > _all_ installed libraries without hassle? I know haddock supports > this, but how easy will it be to achieve that? Since the distributions we build with the nightly builds will have all the libraries, the Haddock docs in the distributions we ship will have complete integrated indices. This means that making a minimal distribution in a build tree that has everything is not just a matter of removing stuff, also the Haddock index must be rebuilt, and the package database needs to have the extra packages removed too. Thanks for reminding me about this! I'm not sure we'll ship minimal binary installers for 6.6 yet, it depends whether we get to it before the release date. Cheers, Simon

4 3

Default bufferring behavior
by Vyacheslav Akhmechet 23 Aug '06

23 Aug '06

I encountered the following issue last night. Writing a program like this: main = do putStr "> " x <- getLine putStr x behaves as expected in hugs and ghci (first prints "> ", then waits for input, then prints the input). However, when compiling and running an executable via ghc, the behavior was very different. I saw a blank console screen and when I typed something it was echoed back to me (as in "> 25") only after I hit enter. This is trivially fixed by flushing: main = do putStr "> " hFlush stdout x <- getLine putStr x or by turning off buffering. Is this the intended behavior? This problem does not appear when using putStrLn (as it flushes automatically) and is quite distracting to newbies. To me it looks like this behavior is at odds with something one can reasonably expect and bufferring should be turned off by default. What do you guys think? Thanks, - Slava.

2 1

Re[2]: [GHC] #814: RTS always grabs 256Mb on startup
by Bulat Ziganshin 23 Aug '06

23 Aug '06

Hello GHC, Wednesday, August 23, 2006, 2:21:30 AM, you wrote: > #814: RTS always grabs 256Mb on startup > * resolution: => fixed > * status: new => closed > Fixed for 6.6 Esa, i thanks you for fixing this problem, it was really uncomfortable for me. can you please also apply your patch to 6.4 sources? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Circular dependency between the compiler and TH?
by Joel Reymont 22 Aug '06

22 Aug '06

Apparently, pkString is part of TH.Syntax which is part of ./ libraries/template-haskell/Language/Haskell/TH/Syntax.hs. This does not get built after the compiler is built but the compiler depends on it in compiler/hsSyn/Convert.lhs. How do I resolve this? -- http://wagerlabs.com/

6 18

Template Haskell crashes unexpectedly...
by Brian Hulley 22 Aug '06

22 Aug '06

Hi, I'm starting to explore Template Haskell and I've got the following program: -- almost directly from "Template meta-programming in Haskell" paper module Duma.Template.Test ( Format(..) , printf ) where import Language.Haskell.TH data Format = D | S | L String printf :: [Format] -> ExpQ printf fs = gen fs [| "" |] gen :: [Format] -> ExpQ -> ExpQ gen [] x = x gen (D : xs) x = [| \n -> $(gen xs [| $x ++ show n |]) |] gen (S : xs) x = [| \s -> $(gen xs [| $x ++ s |] ) |] gen (L s : xs) x = gen xs [| $x ++ $(stringE s) |] module Main where import Duma.Template.Test import Language.Haskell.TH data Car = Car {_f :: Int} getInfo :: Q Info getInfo = reify (mkName "Car") main = do e <- runQ (printf [D,S,L "foo"]) putStrLn (pprint e) let x = $(printf [D,S,L "foo"]) 10 "hello" putStrLn x -- Crashes if I try to print out the info -- info <- runQ getInfo -- putStrLn (pprint info) _ <- getChar return () The example from the paper works fine with the few minor adjustements ie Expr --> ExpQ, lift --> stringE. However if I try and obtain the Info it compiles but then crashes at runtime (using ghc 6.4.2 on Windows). Any ideas? (Perhaps because the type doesn't exist - yet the first call to runQ (printf...) *does* work at runtime) Also, I'm puzzled by the type of reify, because the name "Car" above should surely be both a TyConI and a DataConI so how does this function decide which to return the info about? I expected an extra parameter to determine what namespace to look the name up in. BTW what I'm trying to do is write a TH function which adds a field to a data type and a corresponding instance method eg given: class Object a where getName :: a -> Unique foo :: a -> Int data Square = Square {_f :: Int} instance Object Square where foo = _f will modify the above code (or create new instance and new data type) to: data Square = Square {_name :: Unique, _f :: Int} instance Object Square where getName = _name foo = _f ie adding a bit of boilerplate to the data type and instance decl. Anyway any ideas about why reify doesn't distinguish between lookups of name-as-tycon vs name-as-datacon or why it crashes will be greatly appreciated ;-) Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

3 7

[GHC Users] GLUT & OpenGL on Intel Mac
by Ryan Cleven 22 Aug '06

22 Aug '06

I was wondering if anyone has managed to get the GLUT or OpenGL trivial examples going on the Intel mac binary distribution from aug 8th running? I can't get them running under either ghc or ghci. Thanks, Ryan

1 0