IRC_Meetings: ghc-meeting-2008-09-03.log

17:00 < JaffaCake> welcome all to the #ghc meeting...
17:00 < dejones> JaffaCake: Good day.  :)
17:00 < nominolo> tjena
17:01 < JaffaCake> waern: hi, good to see you
17:01 < dejones> JaffaCake: Side note, I'm still working to integrate my code... I am having to do it manually.  :(
17:01 < dejones> Anyway, meeting...
17:01 < JaffaCake> manually == without darcs?
17:01 < dejones> Yes.
17:01 < dejones> With diffs.
17:01  * nominolo has to fix 100+ test suite failures first
17:02 < JaffaCake> waern: how difficult is it to get Happy to propagate documentation across package boundaries?
17:02 < T1> So far there is no final decision on if the new back-end will be used in 6.10, right?
17:02 < JaffaCake> no new back end in 6.10, sorry
17:02 -!- T1 is now known as TMD
17:02 < JaffaCake> In fact, we're pushing qutie a few things back beyond 6.10 now, due to lack of time
17:03 < Igloo> nominolo: Oh, if I put those credentials you sent in place etc then you wouldn't have to do it manually, right?
17:03 < nominolo> Igloo: I guess so
17:03 < JaffaCake> So the current plan is to leave the VCS switch until after 6.10 when we have more time to plan it properly
17:03 < Igloo> OK, I'll make a note to do that then
17:04 < BSP_> JaffaCake: isn't that going to make it hard to backport fixes?
17:04 < ghcbot> Build x86 Windows head fast #2670 finished: Failure (failed stage2 boottestsuite runtestsuite)
17:04 < ghcbot> Build details are at http://darcs.haskell.org/buildbot/all/builders/x86%20Windows%20head%20fast/builds/2670
17:04 < JaffaCake> BSP_: that's one downside, but if we do it in 3 months' time or so the rate of merges will have slowed
17:04 < nominolo> JaffaCake: so what *will* go in then?
17:05 < JaffaCake> http://hackage.haskell.org/trac/ghc/wiki/Status/Releases
17:05 < lambdabot> Title: Status/Releases - GHC - Trac
17:05 < JaffaCake> Haddock 2 is now in
17:05 < waern> JaffaCake: hi
17:05 < Igloo> "in 3 months time" probably means "just after 6.10.2" or something, but we can play it by ear depending on how many bugs are found etc
17:05 < JaffaCake> I'm working on Unicode Handles, I hope that will go in (but I'm not sure at this stage)
17:06 < JaffaCake> shared libraries will probably not be on by default in 6.10
17:06 < JaffaCake> there's a big update to type familiies still scheduled to go in
17:07 < JaffaCake> nominolo: will your patch be ready, do you think?
17:07 < waern> JaffaCake: hmm, you mean to solve the problem with docs from ghc-prim that should show up in the Prelude?
17:07 < Igloo> backend-revamp is now post-6.10, right?
17:07 < JaffaCake> waern: yes, also the array package, and some others
17:07 < nominolo> JaffaCake: i hope so
17:08 < waern> JaffaCake: currently we don't store documentation in the .haddock files, but we could, and that would solve the problem quite easily I think
17:08 < nominolo> JaffaCake: chances are > 50%
17:08 < BSP_> might it be an idea to push back the release?
17:08 < BSP_> since there seem to be lots of features we would like to have not quite baked yet
17:08 < JaffaCake> waern: yes, that's what I thought - any chance of it happening before 6.10? :)
17:08 < Igloo> BSP_: You can push releases back forever, one week at a time, though
17:09 < waern> JaffaCake: we could let the rule be to always show the documentation in the package that "inherits" it, even though the module it comes from might not be hidden in the original package
17:09 < Igloo> Also, ICFP is a nice time for people to try out RCs and report problems
17:09 < thoughtpolice> JaffaCake: so type families are still scheduled to be totally working for 6.10? what about the NDP work that will go in?
17:09 < JaffaCake> yes, I'm with Igloo here
17:09 < waern> JaffaCake: hmm, well, there are other things I've been meaning to fix before 6.10 as well
17:10 < JaffaCake> I'm not sure about NDP
17:10 < JaffaCake> but TF, yes
17:10 < JaffaCake> waern: ok, what else is high up the list?
17:11 < JaffaCake> waern: yes, I think the behaviour should be the same regardless of whether you're re-exporting from a module in the same package or in a different package
17:12 < thoughtpolice> JaffaCake: the status page needs to be updated with some of this new info then, it seems
17:12 < waern> JaffaCake: but that's not what my rule says :)
17:12 < thoughtpolice> i.e. extensible exceptions are done now too, aren't they?
17:12 < Igloo> I've just moved them
17:12 < quicksilver> quasiquoting?
17:12 < BSP_> quicksilver: thats marked as done
17:12 < JaffaCake> waern: ok, I misunderstood then - what's the difference?
17:13 < JaffaCake> quicksilver: QQ is in, yes
17:13 < waern> JaffaCake: oh, hmm, well now that I think about it the only difference is for "module" export items (IIRC)
17:13 < JaffaCake> right
17:13 < quicksilver> \o/ I look forward to playing with that.
17:14 < waern> JaffaCake: anyway, those details can be worked out, and it doesn't matter that much
17:14 < waern> JaffaCake: as for the priorities, I've been meaning to send some patches to GHC before 6.10 comes out that fixes a few problems
17:15 < JaffaCake> ok, great
17:15 < waern> JaffaCake: for example the lack of docs on type synonym definitions
17:15 < malcolmw> there was a message recently about undoing or reverting the package split of base/getopt/concurrent/timeout/unique - is that settled?
17:16 < JaffaCake> oh, I didn't realise we had a bug there
17:16 < Igloo> malcolmw: It's decided, but I haven't atually done it yet
17:16 -!- judahj [n=judah@cpe-76-170-234-70.socal.res.rr.com] has joined #ghc
17:16 < waern> JaffaCake: it's making some packages on hackage fail, due to parse errors
17:16 < thoughtpolice> quicksilver: it's really cool, mmorrow has been doing a bunch of stuff with it and got a quoter built on Language.C working the other day
17:16 < waern> JaffaCake: fail when making the docs, that is
17:17 < thoughtpolice> i'll have to learn some TH and play with it a bunch :]
17:17 < quicksilver> thoughtpolice: really nice.
17:17 < JaffaCake> I have some improvements to parallel performance that might make it into 6.10 too
17:18 < waern> JaffaCake: but other than that, I can prioritize the inter-package documentation stuff higher than the rest of the Haddock bugs. So perhaps we'll get it in
17:18 < JaffaCake> Jost Berthold has implemented work stealing for par/seq
17:18 < dejones> :)
17:18 < JaffaCake> waern: sounds like the type synonym issue is higher priority, if it's causing outright failures
17:19 < waern> JaffaCake: yep
17:19 < thoughtpolice> quicksilver: it's really great because you basically just need a parser and an instance for TH's Lift (which can be automatically done) and you're basically 95% of the way there. it's a simple process; I speculate almost all of the parsers for various things on hackage could be fitted to use QQ
17:20 < thoughtpolice> with minimal effort, to boot.
17:20 < nominolo> QQ is a really evil feature for HaRe
17:20 < quicksilver> thoughtpolice: the syntax is still slightly gnarly though.
17:20 < quicksilver> thoughtpolice: ascii is so limiting sometimes.
17:23 < dcoutts_> so, what's next on the agenda ?
17:23 < JaffaCake> should we ship extralibs with GHC 6.10?
17:23 < dcoutts_> ah, ok, good one :-)
17:23 < Igloo> No. Next?  :-)
17:24 < JaffaCake> heh :)
17:24 < dcoutts_> JaffaCake: so, we've got a haskell-platform package that depends on the others
17:24 < dcoutts_> so we've got something to start testing the build infrastructure
17:24 < nominolo> which others?
17:24 < dcoutts_> nominolo: mostly just extra libs + cabal-install
17:24 < dcoutts_> for the first release
17:24 < Igloo> dcoutts_: Does that mean the build infrastructure exists? What does it do, if so?
17:25 < nominolo> but that doesn't require ghc shipping with them, does it?
17:25 < JaffaCake> ok, so someone will be able to get an HP by: 1. get cabal-install, 2. cabal-install hp
17:25 < dcoutts_> JaffaCake: yes, or possibly just get the HP and make install
17:25 < Igloo> JaffaCake: 0. get tar, zlib, http, etc
17:25  * malcolmw notes that extra-libs no longer includes essential libraries like HOpenGL
17:25 < dcoutts_> malcolmw: haskell-platform currently does depend on those
17:25 < malcolmw> dcoutts_: oh cool
17:26 < JaffaCake> right, so we talked about having a tarball of the HP that will bootstrap itself
17:26 < dcoutts_> malcolmw: if we find they cannot be built on all platforms in time for a release then we could consider dropping some
17:26 < dcoutts_> JaffaCake: right
17:26 < dcoutts_> and I'm going to try and get an instance of the new hackage-server running on a public host asap
17:27 < dcoutts_> so people can use cabal-install to provide build reports + logs
17:27 < JaffaCake> so we should drop extralibs then?
17:27 < dcoutts_> well, maybe, if we're sufficiently confident :-)
17:28 < JaffaCake> it would force the issue :)
17:28 < dcoutts_> true true
17:28 -!- Jedai [n=jedai@dhcp2978.kent.ac.uk] has joined #ghc
17:28 < dcoutts_> JaffaCake: we'd need help with osx and windows installers
17:29 < claus> ghc builds extralibs in a cygwin/mingw environment (with configure&co); cabal-install tries to build packages in plain windows;is HP really ready to take over without stumbling?
17:29  * dcoutts_ knows nothing about osx installers
17:29  * JaffaCake either
17:29 < dcoutts_> claus: if you use cabal-install with sh on your path then I believe it works with configure
17:29 < JaffaCake> we're going to ship a Windows installer of the HP though
17:30 < dcoutts_> right, so it's only builders that need mingw for opengl etc
17:30 < judahj> dcoutts_: I think it's OK for an initial release of HP to use unix-y installation on OS X
17:30 < claus> dcoutts: that would have to be a mingw sh; and then there's the issue of ghc's mingw vs any other mingw installs, right?
17:30 < dcoutts_> JaffaCake: but no unix bindist of the HP I think, at least not initially
17:31 < dcoutts_> judahj: you mean a tarball + building from source ?
17:31 < JaffaCake> right
17:31 < judahj> dcoutts_: right
17:31 < dcoutts_> claus: yes, a mingw sh
17:31 < JaffaCake> dcoutts_: if you want a home-dir install of the HP, you install the GHC bindist, then use the HP tarball
17:31 < dcoutts_> claus: afaik, ghc's subset of mingw does not come with sh
17:31 < dcoutts_> just gcc and the bits needed for gcc
17:32 < dcoutts_> JaffaCake: right
17:32 -!- conal [n=user@d5153048F.access.telenet.be] has quit [Connection timed out]
17:33 < dcoutts_> JaffaCake: how does the windows installer for ghc + extralibs work atm?
17:33 < dcoutts_> for registering packages
17:33 < dcoutts_> I guess it installs them all together in one tree, so does not have any problem with registering
17:33 < Igloo> It does make install, then tars up the installed directory
17:33 < JaffaCake> dcoutts_: it comes pre-registered
17:33 < Igloo> Where the path used to register starts with $topdir
17:33 < dcoutts_> indeed never registers on the target machine
17:33 < dcoutts_> right
17:33 < claus> dcoutts: right, which would mean that HP users would need to install a full mingw, and then ghc would still not use that; so people have to copy things from the full mingw to ghc's mingw for ghc to find them (ffi,includes,)
17:33 < dcoutts_> so gtk2hs has to do relocatable installs and call ghc-pk
17:34 < JaffaCake> claus: no, not at all
17:34 < Igloo> claus: What do you mean by "HP users"?
17:34 < dcoutts_> claus: if they wanted to build from source, yes they'd need full mingw. But no copying things about would be necessary I think.
17:35 < JaffaCake> not just mingw; you'd need Cygwin or MSYS
17:35 < dcoutts_> right, msys
17:35 < JaffaCake> but we don't expect Windows users to build from source
17:36  * dcoutts_ fires up MSYS and runs cabal update && cabal install cabal-install && cabal install --reinstall opengl
17:37 < Igloo> I guess the pre-registered libs means that it makes more sense to make one large installer than to bundle the GHC installer in the HP installer
17:37 < Igloo> i.e. the HP bindist would start from the Windows tarball
17:37 < JaffaCake> currently cabal-install will register with absolute pathnames on Windows, won't it?
17:38 < dcoutts_> JaffaCake: yes, but it's possible to make relocatable ones I think
17:38 < JaffaCake> so we'd have to do something special when building the HP on Windows for the installer
17:38 < dcoutts_> if doing copy --destdir
17:39 < dcoutts_> JaffaCake: there's definately some support for relocatable things, with some restrictions
17:39 < dcoutts_> JaffaCake: but not for docs
17:40 < Igloo> We just need to use GHC's installPackage to do the install step, I think
17:40 < JaffaCake> isn't that just for binaries?
17:40 < claus> JaffaCake: not-from source is good to hear; I've been trying to find the ticket I think part of it is http://hackage.haskell.org/trac/ghc/ticket/1502 ;
17:40 < lambdabot> Title: #1502 (GHC should integrate better with mingw) - GHC - Trac
17:40 < JaffaCake> Igloo: ah, good point
17:40 < JaffaCake> that ticket has a suitable vague title
17:41 < claus> JaffaCake: on the other hand, the build darcs on windows instructions looked a lot more frightening a few weeks ago, perhaps that copying is no longer needed, just point to the installation dir of the libs?
17:41 < JaffaCake> I never copy anything to my GHC install on Windows
17:42 < JaffaCake> but I do jump through some hoops to get darcs built (see my post on darcs-users)
17:42 < dcoutts_> claus: I just tested cabal install opengl on windows using msys. Works fine.
17:42 < JaffaCake> I don't think I understand why it is necessary to copy things to the GHC directory
17:43 < claus> jaffacake: I probably just read too many adhoc build instructions
17:43 < JaffaCake> regarding that ticket - if we had GHC bundle the mingw installer, we want to be sure that multiple GHC installs don't overwrite each other's mingw installs
17:45 < JaffaCake> dcoutts_: yay
17:45 < dcoutts_> JaffaCake: huh? ghc already bundles bits of mingw. What else do people need?
17:45 < JaffaCake> some of the binutils, apparently
17:45 < dcoutts_> oh, like strip?
17:45 < claus> dcoutts: great! (assuming it works?-) perhaps for confused people like me, there should be some docs saying how easy it is to cabal install even complex packages like opengl with ffi and configure on windows these days, and ask people to revise/simplify their package build instructions
17:46 < JaffaCake> (from the ticket) strip, nm, reimp, dlltool, pexport, windres
17:46 < dcoutts_> JaffaCake: fair enough. I don't think that should cause any trouble. You already have gcc, ld, etc
17:46 -!- bringert [n=bringert@dhcp-250-26.nomad.chalmers.se] has quit [Read error: 104 (Connection reset by peer)]
17:46 < dcoutts_> of course they're not on the normal path, which is why it works
17:47 < dcoutts_> but cabal looks for gcc in ghc's gcc-lib
17:47 < dcoutts_> and ld
17:47 < JaffaCake> yeah, I consider it to be part of GHC's back end, not something we expose to users
17:47 < dcoutts_> right
17:47 < JaffaCake> cabal is naughty :)
17:47 < dcoutts_> JaffaCake: it has to, otherwise we cannot build .c code reliably
17:47 < dcoutts_> or we might get incompatible results
17:48 < JaffaCake> can't you build it with ghc?
17:48 < dcoutts_> JaffaCake: at the moment we do use ghc to build .c code actually
17:48 < dcoutts_> but we have to call ld directly
17:48 < dcoutts_> and we find gcc to pass to hsc2hs
17:48 < JaffaCake> yes, I remember that
17:48 < JaffaCake> it's a bit unsatisfactory
17:49 < dcoutts_> if ghc wants to ship without gcc then that's fine, we'll just look on the path for gcc etc
17:49 < JaffaCake> perhaps we should supply ld/gcc that you can just invoke without the -B stuff
17:49 < dcoutts_> it's not that tricky
17:49 < JaffaCake> no, but we might want to change it in the future
17:50 < dcoutts_> sure
17:50 < JaffaCake> it's better not to have this dependency
17:50 < dcoutts_> which dependency exactly?
17:50 < JaffaCake> the dependency from Cabal on how to find & invoke gcc in a GHC installation
17:51 < dcoutts_> JaffaCake: mm, well it's that or we have to find it in the path
17:51 < dcoutts_> and that either means ghc has to install it to the path
17:51 < dcoutts_> or the user needs to install mingw
17:51 < JaffaCake> I mean if we commit to putting gcc & ld in the same place as GHC, that would be easier
17:51 < dcoutts_> people like to be able to install ghc without changing the path apparently
17:51 < dcoutts_> don't ask me why
17:52 < JaffaCake> although maybe that would cause more problems
17:52 < dcoutts_> JaffaCake: that's not much different, we still need to go look in a special place
17:52 < Igloo> Or "ghc --where-is gcc" etc
17:52 < dcoutts_> JaffaCake: it's just $ghcdir/gcc rather than $ghcdir/gcc-lib/gcc
17:52 < JaffaCake> dcoutts_:  it's the magic -B stuff that I'm more worried about
17:53 < dcoutts_> JaffaCake: oh that, it's not a problem from cabal's pov, it'd save us ~3 lines of code
17:53 < dcoutts_> since we need to set up gcc specially anyway
17:53 < Igloo> We may as well make gcc not need it if we can, though
17:53 < dcoutts_> sure, if it's easy to do
17:55 < claus> what about compatibility of mingw versions? is that no longer an issue?
17:55 < dcoutts_> so, for the HP tarball, I think all it'd need is a suitably crafted tarball content and a portable sh script.
17:55 < dcoutts_> we'd have it compile cabal-install, and then invoke cabal-install with a local repo to install the platform
17:55 < dcoutts_> the local repo being in the tarball of course
17:56 < JaffaCake> right
17:56 < JaffaCake> sounds good
17:56 -!- clanehin_ [n=lane@cpe-069-134-113-217.nc.res.rr.com] has quit [Remote closed the connection]
17:56 < Igloo> dcoutts_: Why cabal-install rather than something like GHC's cabal-bin?
17:56 < Igloo> If you build cabal-install then you need to build http etc
17:56 -!- clanehin_ [n=lane@cpe-069-134-113-217.nc.res.rr.com] has joined #ghc
17:57 < dcoutts_> Igloo: because we're installing those anyway, and it means it'll do the whole lot in one go in the right order without a makefile
17:57 < dcoutts_> cabal --local-repo=blah install haskell-platform
17:58 < JaffaCake> I think the point is that we need to build & install cabal-install's deps before we can build cabal-install
17:58 < JaffaCake> using plain Cabal, presumably
17:59 < JaffaCake> I better go... bye folks!
17:59 < Igloo> See ya
17:59 < dcoutts_> JaffaCake: no, it's easy
18:00 < dcoutts_> ghc --make cabal-install/Main.hs -o cabal -iCabal:zlib:HTTP
18:00 < JaffaCake> oh, that's cheating
18:00 < dcoutts_> heh
18:00 < dcoutts_> we'd end up building them again
18:00 < Igloo> You'll still build them twice
18:00 < dcoutts_> for the proper install
18:00 < dcoutts_> Igloo: feh
18:01 < Igloo> It's a bit bikesheddy, but I'd use cabal-bin to build up to cabal-install, and then cabal-install (for topological sort) to do the rest
18:02 < dcoutts_> why? what does it save?
18:02 < dcoutts_> Igloo: if one's clever one could arrange to make the first build get re-used for the Cabal bootstrap
18:02 < dcoutts_> since Cabal builds itself twice too
18:02 < dcoutts_> once to make setup then setup build the real thing
18:03 < dcoutts_> so one could pre-populate the .hi and .o files needed for that while building cabal-install
18:03 < dcoutts_> so it'd only be http and zlib that'd get built twice
18:03 < dcoutts_> and they're relatively small
18:03 < dcoutts_> and we'd not be building with -O the first time
18:03 < Igloo> You don't need to build Cabal
18:03 < dcoutts_> oh, good point
18:04 < dcoutts_> so even less need to worry
18:04 < dcoutts_> building the others twice is no big deal
18:05 < Igloo> It means that any cpp flags etc that are set in the Cabal files are used. Like I said, it's bikesheddy, so I'm not going to spend much time arguing about it  :-)
18:05 -!- tibbe [n=tibbe@72.14.229.17] has joined #ghc
18:05 < dcoutts_> hmm, that could be important for zlib on windows actually
18:11 -!- TMD [n=tmdubui@144.51.26.41] has left #ghc []
18:12 -!- tengvall [i=53915df2@gateway/web/ajax/mibbit.com/x-b228be07131bdf23] has quit ["http://www.mibbit.com ajax IRC Client"]