From duncan.coutts at worc.ox.ac.uk Tue May 1 10:45:00 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 10:55:05 2007 Subject: darcs patch: added cppOptions and c2hsOptions In-Reply-To: <20070421213555.GA3000@soi.city.ac.uk> References: <007b01c78304$e1869570$6601a8c0@box> <1177049408.25192.214.camel@localhost> <008101c78316$8ede7010$6601a8c0@box> <1177064241.25192.227.camel@localhost> <1177158728.7696.13.camel@localhost> <20070421213555.GA3000@soi.city.ac.uk> Message-ID: <1178030700.6211.130.camel@localhost> On Sat, 2007-04-21 at 22:35 +0100, Ross Paterson wrote: > On Sat, Apr 21, 2007 at 10:32:08PM +1000, Duncan Coutts wrote: > > I have a patch, I'll send it soonish (probably Monday) for other people > > to review and test. > > > > It's a general change to the way Cabal does pre-processing. Instead of > > generating the .hs files in place in the source tree we put them all in > > a special build tree in the dist dir (like where we put the .o and .hi > > files, but not actually the same directory). > > I've been meaning to do something like that, to get the generated files > under dist, and to separate out the compiler-independent part of the code. > There should be no need for the compiler-specific parts to worry about > main-is or hs-source-dirs, when the first phase can handle those. > > Another benefit is that we could include compiler-independent preprocessor > output (where possible) in source distributions. If the package is > built in an environment lacking that preprocessor, it can use the > shipped output. If the preprocessor is available, it can run it with > compiler-specific flags (e.g. happy -agc). Not all preprocessors can > produce compiler-independent output, though. I've got it to a half-way house, I've made PreProcessor into a record data type which records if the pre-processor generates platform independent output. We should add something about whether the result is independent of the haskell implementation or not. ( Incidentally, This PreProcessor abstraction is probably the right place to add things like composing pre-processors, eg .y.pp, .chs.pp etc. I'm not sure if PreProcessor should incorporate the suffix stuff or if it should represent a particular use of a pre-processor independent of some general suffix rule. ) Also, I've still got the platform-independent pre-processed files going back into the src dirs. This isn't nice. The only reason I'm doing that is not to break sdist, however we should probably do that differently anyway. For example at the moment you need to have done a build for the pre-processed sources to exist in the src dir. Perhaps sdist should just generate the platform independent (and impl-independent) sources directly into the temp dir where we make the tarball. Then during builds we can put them all into the dist/build dir. The only downside to this is if generating the sources is expensive. Sometimes it is indeed expensive, happy can take quite a while on large grammars and in Gtk2Hs, generating 100+ .hs files with c2hs takes a minute or two on a fast box. So how about this, we put generated sources into their own dir, not dist/build but somewhere else. We separate platform dependent and independent generated sources. We could even separate impl-dependent sources from independent ones. Then if you do sdist after a build then there is no additional pre-processing needed, but if you do sdist from a clean tree then it will do the pre-processing. Some thing like: gen/platform-dependent/ gen/platform-independent/ghc/ gen/platform-independent/generic/ it would be the gen/platform-independent/ tree that'd be included into the src tarball. That way when it comes to building from a tarball we find we don't have to re-run the pre-processor, assuming the file modification times all work out as expected. I don't think the gen/platform-independent can live under dist since that doesn't need to be anywhere related to the build tree and yet this must be present if we build from a tarball. Suggestions? Duncan From igloo at earth.li Tue May 1 11:41:39 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue May 1 11:39:00 2007 Subject: Cleaning up hooks In-Reply-To: <462DC3C2.30505@gmail.com> References: <462DC3C2.30505@gmail.com> Message-ID: <20070501154139.GA29334@matrix.chaos.earth.li> On Tue, Apr 24, 2007 at 09:45:54AM +0100, Simon Marlow wrote: > I think the API for hooks is in need of an overhaul. I agree. > 4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks. > If your Setup.hs uses hooks to modify the PackageDescrption, then > cabal-rpm won't see the modifications. That's something I think you just shouldn't be doing, and hopefully we won't need to after this summer. > Anyway, here's the basic idea. A common thing to want to do in Setup.lhs > is to modify the PackageDescription, so we provide a way to do that: Again, I don't think that'll be true after the configurations stuff is implemented. > thenHook :: Hook a -> Hook a -> Hook a > thenHook hook1 hook2 args flags pd lbi = do > hook1 args flags pd lbi > hook2 args flags pd lbi > > Then to add a post-hook to the build command you could do this: > > addPostBuild :: Hook BuildFlags -> Hooks -> Hooks > addPostBuild hook hooks > = hooks { buildHook = buildHook hooks `thenHook` hook } I think most of the time we would want `thenHooks` (defined in terms of thenHook), e.g. (with the current names) we'd have something like: defaultBuildHooks = simpleBuildHooks `thenHooks` configureBuildBooks where configureBuildBooks might define a confHook (to run ./configure) and a cleanHook (to remove config.log etc). Thanks Ian From ross at soi.city.ac.uk Tue May 1 19:31:38 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue May 1 19:29:00 2007 Subject: darcs patch: added cppOptions and c2hsOptions In-Reply-To: <1178030700.6211.130.camel@localhost> References: <007b01c78304$e1869570$6601a8c0@box> <1177049408.25192.214.camel@localhost> <008101c78316$8ede7010$6601a8c0@box> <1177064241.25192.227.camel@localhost> <1177158728.7696.13.camel@localhost> <20070421213555.GA3000@soi.city.ac.uk> <1178030700.6211.130.camel@localhost> Message-ID: <20070501233138.GA23659@soi.city.ac.uk> On Tue, May 01, 2007 at 03:45:00PM +0100, Duncan Coutts wrote: > Also, I've still got the platform-independent pre-processed files going > back into the src dirs. This isn't nice. The only reason I'm doing that > is not to break sdist, however we should probably do that differently > anyway. > > For example at the moment you need to have done a build for the > pre-processed sources to exist in the src dir. Perhaps sdist should > just generate the platform independent (and impl-independent) sources > directly into the temp dir where we make the tarball. Then during > builds we can put them all into the dist/build dir. Certainly. Building (using specialized preprocessing) ought to be separated from constructing source packages (which requires portable preprocessor output). > The only downside to this > is if generating the sources is expensive. Sometimes it is indeed > expensive, happy can take quite a while on large grammars and in Gtk2Hs, > generating 100+ .hs files with c2hs takes a minute or two on a fast box. I wonder if optimizing this is worth the increase in complexity (and where does it end -- you need platform-specific versions to avoid the c2hs runs). I was after something less ambitious: including portable preprocessor output in a source package so that people can build it even if they don't have the preprocessor. (Their build may be sub-optimal, though.) That could be done by mapping each suffix to a pair of functions portable :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor specific :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor for type Preprocessor = (FilePath, FilePath) -> (FilePath, FilePath) -> Int -> IO () The first one would be used in sdist; if the portable preprocessor is available, add its output to the source package. The second function would be used in build; if the specific preprocessor is unavailable, copy the .hs version of the module (which, if present, should be portable preprocessor output). (Presumably if the portable preprocessor is available the specific one is too, but we don't need to use that.) BTW, since you're now collecting Haskell files in a single build hierarchy, you could copy the main-is to Main.[l]hs in that hierarchy, and also generate the Paths module directly there instead of in autogen. BTW2, building under Hugs will now require two directories under dist: one for the (build-specific) preprocessor output and another for the build outputs, which may be obtained from those using cpphs and ffihugs. From duncan.coutts at worc.ox.ac.uk Tue May 1 19:33:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 19:43:20 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <20070501212920.GA3838@die.therning.org> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> Message-ID: <1178062398.9770.31.camel@localhost> On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: > >So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you > >just need: > > > >hs-source-dirs: test-src, src > > No, that's not enough, I also have to add the following lines to make > the executable compile and link: > > extensions: ForeignFunctionInterface > c-sources: csrc/ptrace.c > > That is, I end up compiling the library a second time! Can't I get the > executable to link against the library that was just created? > I was just expecting to not have to repeat myself in the cabal file. > Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. > Also, I don't really see what you mean by "that dir can be placed > anywhere by the user". That dir is created as part of the build > process and it's location is, AFAICS, always going to be ./dist/build. Actually it's location can be set at configure time with --scratchdir= so that for example you could put it in a temp dir or something. Duncan From duncan.coutts at worc.ox.ac.uk Wed May 2 04:09:47 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 2 04:22:59 2007 Subject: darcs patch: added cppOptions and c2hsOptions In-Reply-To: <20070501233138.GA23659@soi.city.ac.uk> References: <007b01c78304$e1869570$6601a8c0@box> <1177049408.25192.214.camel@localhost> <008101c78316$8ede7010$6601a8c0@box> <1177064241.25192.227.camel@localhost> <1177158728.7696.13.camel@localhost> <20070421213555.GA3000@soi.city.ac.uk> <1178030700.6211.130.camel@localhost> <20070501233138.GA23659@soi.city.ac.uk> Message-ID: <1178093387.9770.41.camel@localhost> On Wed, 2007-05-02 at 00:31 +0100, Ross Paterson wrote: > On Tue, May 01, 2007 at 03:45:00PM +0100, Duncan Coutts wrote: > > Also, I've still got the platform-independent pre-processed files going > > back into the src dirs. This isn't nice. The only reason I'm doing that > > is not to break sdist, however we should probably do that differently > > anyway. > > > > For example at the moment you need to have done a build for the > > pre-processed sources to exist in the src dir. Perhaps sdist should > > just generate the platform independent (and impl-independent) sources > > directly into the temp dir where we make the tarball. Then during > > builds we can put them all into the dist/build dir. > > Certainly. Building (using specialized preprocessing) ought to be > separated from constructing source packages (which requires portable > preprocessor output). > > > The only downside to this > > is if generating the sources is expensive. Sometimes it is indeed > > expensive, happy can take quite a while on large grammars and in Gtk2Hs, > > generating 100+ .hs files with c2hs takes a minute or two on a fast box. > > I wonder if optimizing this is worth the increase in complexity (and > where does it end -- you need platform-specific versions to avoid the > c2hs runs). I was talking nonsense I realise. Of course for building the sdist we don't run c2hs anyway, we only generate the platform-independent .hs files. So the only one of those that takes time is happy and that never takes that long and people typically do not have dozens of .y files in a project (unlike .chs/.hsc files). > I was after something less ambitious: including portable preprocessor > output in a source package so that people can build it even if they > don't have the preprocessor. (Their build may be sub-optimal, though.) Hmm, so then for example most people will end up not getting the fastest possible haddock since the tarball will contain only the generic happy parser. Actually won't everyone using the haddock tarball get the slow parser even if they do have happy installed because the normal thing is to not rebuild the pre-preocessed file if it was modified later? > That could be done by mapping each suffix to a pair of functions > > portable :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor > specific :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor > for > type Preprocessor = > (FilePath, FilePath) -> (FilePath, FilePath) -> Int -> IO () > > The first one would be used in sdist; if the portable preprocessor is > available, add its output to the source package. > > The second function would be used in build; if the specific preprocessor > is unavailable, copy the .hs version of the module (which, if present, > should be portable preprocessor output). (Presumably if the portable > preprocessor is available the specific one is too, but we don't need to > use that.) Oh ok, so that does deal with the haddock tarball containing the generic parser but me having happy installed on the system and ending up with the fast parser. > BTW, since you're now collecting Haskell files in a single build > hierarchy, you could copy the main-is to Main.[l]hs in that hierarchy, Why would we want to do that? > and also generate the Paths module directly there instead of in autogen. Yes. > BTW2, building under Hugs will now require two directories under dist: > one for the (build-specific) preprocessor output and another for the > build outputs, which may be obtained from those using cpphs and ffihugs. Ah yes, indeed. Duncan From ross at soi.city.ac.uk Wed May 2 04:47:09 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed May 2 04:44:30 2007 Subject: darcs patch: added cppOptions and c2hsOptions In-Reply-To: <1178093387.9770.41.camel@localhost> References: <007b01c78304$e1869570$6601a8c0@box> <1177049408.25192.214.camel@localhost> <008101c78316$8ede7010$6601a8c0@box> <1177064241.25192.227.camel@localhost> <1177158728.7696.13.camel@localhost> <20070421213555.GA3000@soi.city.ac.uk> <1178030700.6211.130.camel@localhost> <20070501233138.GA23659@soi.city.ac.uk> <1178093387.9770.41.camel@localhost> Message-ID: <20070502084709.GA3736@soi.city.ac.uk> On Wed, May 02, 2007 at 09:09:47AM +0100, Duncan Coutts wrote: > On Wed, 2007-05-02 at 00:31 +0100, Ross Paterson wrote: > > BTW, since you're now collecting Haskell files in a single build > > hierarchy, you could copy the main-is to Main.[l]hs in that hierarchy, > > Why would we want to do that? To move a little bit of logic from the various compiler-specific parts to the compiler-independent first phase. It's not a big deal, but you'll probably want to do it anyway when fixing #14: allow preprocessing for Main modules. From simonmarhaskell at gmail.com Wed May 2 05:08:41 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 2 05:06:02 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <1178062398.9770.31.camel@localhost> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> <1178062398.9770.31.camel@localhost> Message-ID: <46385519.1030804@microsoft.com> Duncan Coutts wrote: > On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: > >>> So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you >>> just need: >>> >>> hs-source-dirs: test-src, src >> No, that's not enough, I also have to add the following lines to make >> the executable compile and link: >> >> extensions: ForeignFunctionInterface >> c-sources: csrc/ptrace.c >> >> That is, I end up compiling the library a second time! Can't I get the >> executable to link against the library that was just created? > >> I was just expecting to not have to repeat myself in the cabal file. >> Not such a strange thing to expect from a build system, I think :-) > > Yes this is an interesting question about what it means to have programs > in the same cabal package as an executable. > > Currently having a executable and a library inside a cabal package is > not the same thing as having a library package and separate package that > contains only that executable. The difference is that when the > executable is in the same cabal package it merely has access to the same > modules, it doesn't 'depend' on that library package exactly. So for > example it can access modules which are not exposed by the library and > indeed it can compile those same modules with completely different build > flags. So currently those modules will be built twice. > > It's not clear to me that this is the right meaning, or indeed that we > should allow multiple entries in a single .cabal file. I think it might > be better to just have multiple .cabal files (possibly in the same > directory). Then we could be explicit and state that an executable > depends on the library or if we want to use different build flags, or > use modules that are not exposed by the lib then we can do that and only > in that case do we build those modules twice. Right at the front of the Cabal docs it says: "However having both a library and executables in a package does not work very well; if the executables depend on the library, they must explicitly list all the modules they directly or indirectly import from that library." IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib+exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). Cheers, Simon From simonmarhaskell at gmail.com Thu May 3 03:47:08 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 3 03:44:42 2007 Subject: Cleaning up hooks In-Reply-To: <20070501154139.GA29334@matrix.chaos.earth.li> References: <462DC3C2.30505@gmail.com> <20070501154139.GA29334@matrix.chaos.earth.li> Message-ID: <4639937C.8030802@gmail.com> Ian Lynagh wrote: > On Tue, Apr 24, 2007 at 09:45:54AM +0100, Simon Marlow wrote: >> I think the API for hooks is in need of an overhaul. > > I agree. > >> 4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks. >> If your Setup.hs uses hooks to modify the PackageDescrption, then >> cabal-rpm won't see the modifications. > > That's something I think you just shouldn't be doing, and hopefully we > won't need to after this summer. Yes, I quite agree. I saw the code in e.g. base/Setup.hs, and noticed how it broke with 'setup makefile', and decided there must be a better way. Certainly configurations are an even better way. >> thenHook :: Hook a -> Hook a -> Hook a >> thenHook hook1 hook2 args flags pd lbi = do >> hook1 args flags pd lbi >> hook2 args flags pd lbi >> >> Then to add a post-hook to the build command you could do this: >> >> addPostBuild :: Hook BuildFlags -> Hooks -> Hooks >> addPostBuild hook hooks >> = hooks { buildHook = buildHook hooks `thenHook` hook } > > I think most of the time we would want `thenHooks` (defined in terms of > thenHook), e.g. (with the current names) we'd have something like: > > defaultBuildHooks = simpleBuildHooks `thenHooks` configureBuildBooks > > where configureBuildBooks might define a confHook (to run ./configure) > and a cleanHook (to remove config.log etc). Right, I can imagine that might be more convenient. So we agree in principle that removing all the pre/post hooks from UserHooks and providing thenHook/thenHooks would be an improvement? It's a bit of a no-brainer refactoring, I might do it when I'm feeling bored sometime. Or maybe Thomas could do it as part of the SOC project? Cheers, Simon From igloo at earth.li Thu May 3 05:22:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu May 3 05:19:40 2007 Subject: Cleaning up hooks In-Reply-To: <4639937C.8030802@gmail.com> References: <462DC3C2.30505@gmail.com> <20070501154139.GA29334@matrix.chaos.earth.li> <4639937C.8030802@gmail.com> Message-ID: <20070503092225.GA29081@matrix.chaos.earth.li> On Thu, May 03, 2007 at 08:47:08AM +0100, Simon Marlow wrote: > > So we agree in principle that removing all the pre/post hooks from > UserHooks and providing thenHook/thenHooks would be an improvement? I agree, certainly. Thanks Ian From bringert at cs.chalmers.se Thu May 3 16:22:54 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu May 3 16:18:11 2007 Subject: hackageDB directory layout In-Reply-To: <20070503082442.GA2863@soi.city.ac.uk> References: <20070503082442.GA2863@soi.city.ac.uk> Message-ID: On May 3, 2007, at 10:24 , Ross Paterson wrote: > [for some reason I don't seem to be able to get this to the > libraries list, so I'm sending it to cabal-devel] > > I propose to change the directory layout of the HackageDB data, by > putting > each version in a separate directory (to simplify future expansion). > This will not affect users of the web interface, but will be a > breaking > change for those who reference the files directly, notably cabal- > install. > > Here's how the positions of the files of the binary package would > change > (-> denotes a symbolic link): > > Current layout Proposed layout > -------------------------------------------------------------------- > binary/binary-0.2.cabal binary/0.2/binary.cabal > binary/binary-0.2.tar.gz binary/0.2/binary-0.2.tar.gz > binary/binary-0.2.misc/doc/html/ binary/0.2/doc/html/ > binary/binary-0.3.cabal binary/0.3/binary.cabal > binary/binary-0.3.tar.gz binary/0.3/binary-0.3.tar.gz > binary/binary-0.3.misc/doc/html/ binary/0.3/doc/html/ > binary/latest.misc -> binary-0.3.misc binary/latest -> 0.3 Fine by me. In cabal-install you probably only need to change Network.Hackage.CabalInstall.Update.pkgURL. /Bj?rn From duncan.coutts at worc.ox.ac.uk Thu May 3 16:45:28 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 3 16:55:23 2007 Subject: cabal-upload & cabal-install Message-ID: <1178225128.9770.141.camel@localhost> Hia Ross, Bjorn, Pepe Iborra and I were hacking on cabal-install today. I hope you like our patches :-). Pepe updated it to use filepath so it'd work on windows and I fiddled with locations of config and things to try and make installation simpler so it'll work "out of the box". I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it. However I failed to upload Cabal-1.1.6.2 which I also released today. Via both the website and cabal-upload interfaces it failed the upload after a few 100k, so I think it's a server side issue. Does it have a limit on the upload size? cabal-1.1.6.2.tar.gz is just over 500k. You can grab it here and try: http://haskell.org/cabal/release/latest/cabal-1.1.6.2.tar.gz My general impression is that cabal-install, hackage and cabal-upload are really nice, especially the hackage web ui. You've done a lot of work! What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it. One longer term thing I was thinking about was using hackage and cabal-install to gather testing feedback. We could have cabal-install report (with user consent) build successes and failures, including useful info about the environment, including the platform, Haskell implementation and version, the version of cabal, cabal-install and versions of the all the dependent packages (not sure if it should be directly or transitively). This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine. Duncan From ross at soi.city.ac.uk Thu May 3 19:27:03 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 3 19:24:17 2007 Subject: cabal-upload & cabal-install In-Reply-To: <1178225128.9770.141.camel@localhost> References: <1178225128.9770.141.camel@localhost> Message-ID: <20070503232703.GA8984@soi.city.ac.uk> On Thu, May 03, 2007 at 09:45:28PM +0100, Duncan Coutts wrote: > What do we need to do next? Should we invite a little bit of wider > testing on cabal-install + hackage and get some user feedback. If that's > good we should actively advertise and push it. I think slowly building the user base among early adopters (as now) will be the most useful. There's a GSoC project to extend the web interface, which will involve changes and the risk of temporary breakage. We won't be ready for everyone till after that. As far as I know, the main thing missing from cabal-install is documentation. There's a tricky issue of how it should relate to a system package manager, but that will have to wait. > One longer term thing I was thinking about was using hackage and > cabal-install to gather testing feedback. We could have cabal-install > report (with user consent) build successes and failures, including > useful info about the environment, including the platform, Haskell > implementation and version, the version of cabal, cabal-install and > versions of the all the dependent packages (not sure if it should be > directly or transitively). > > This would be a great way to do distributed testing and a way of finding > out which packages are well used and tested. If summary info is on the > website it also allows users to find out if a package is likely to work > on their machine. Sounds like a great idea. Another possibility is to have buildbots feeding this info back for all packages. From stefanor at cox.net Thu May 3 22:19:55 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu May 3 22:17:09 2007 Subject: cabal "fails" with no explanation Message-ID: <20070504021955.GA3839@localhost.localdomain> stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 cleaning... stefan@stefans:/usr/local/src/xmonad$ echo $? 1 stefan@stefans:/usr/local/src/xmonad$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 stefan@stefans:/usr/local/src/xmonad$ configure, build, and install all also work but return 1. The same issue is observed with X11-extras. Stefan From mstone at sccs.swarthmore.edu Fri May 4 00:47:35 2007 From: mstone at sccs.swarthmore.edu (Michael Stone) Date: Fri May 4 00:44:47 2007 Subject: Detrimental c2hs / "other-modules" interaction Message-ID: <20070504044735.GA23090@sccs.swarthmore.edu> Dear Cabal Developers, First, thanks for the excellent work so far. Second, I thought I'd report a frustrating experience I had on my first attempt to package a library. I'm currently extracting a Cairo binding from Gtk2hs because I want to use Cairo on a server that doesn't have X or GTK readily available. As I went about adapting Gtk2hs' binding, I ran into the following issue: 1) Cabal does not clean up after c2hs - in particular, it does not delete the temporary .chi and .chs.h files that c2hs produces for each file it processes. 2) Cabal does not do dependence analysis. Consequently, the "other-modules" field of my cairo.cabal is order-sensitive. Together, these mean that after I manually delete those temporary files, my build fails mysteriously because the dependencies are not being resolved in an order that c2hs can work with. This in turn makes it non-trivial to make reliable builds. Please let me know if you'd like any further information. Thanks, Michael Stone From bringert at cs.chalmers.se Fri May 4 04:10:55 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Fri May 4 04:06:11 2007 Subject: cabal-upload & cabal-install In-Reply-To: <1178225128.9770.141.camel@localhost> References: <1178225128.9770.141.camel@localhost> Message-ID: <1F408B12-4F0B-44CF-993A-8AEEE8E136F7@cs.chalmers.se> On May 3, 2007, at 22:45 , Duncan Coutts wrote: > ... > I was also trying cabal-upload. I found that cabal-upload needs some > functions from the HTTP lib that are not actually exported. In > particular the stuff to do with authorisation in the Browser > module. It > looks like it ought to be exported since it isn't actually used > internally. When I do patch the HTTP lib to export that, cabal-upload > works for me. I uploaded filepath-1.0 today using it. I think that's just a problem with the versioned dependency in cabal- upload.cabal. HTTP-3000.0.0 should already have those exports. Feel free to fix it (I don't have a lot of time right now with the baby). /Bj?rn From duncan.coutts at worc.ox.ac.uk Fri May 4 04:00:59 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 4 04:10:53 2007 Subject: Detrimental c2hs / "other-modules" interaction In-Reply-To: <20070504044735.GA23090@sccs.swarthmore.edu> References: <20070504044735.GA23090@sccs.swarthmore.edu> Message-ID: <1178265659.9770.177.camel@localhost> On Fri, 2007-05-04 at 00:47 -0400, Michael Stone wrote: > Dear Cabal Developers, > > First, thanks for the excellent work so far. > > Second, I thought I'd report a frustrating experience I had on my first > attempt to package a library. Thanks. > I'm currently extracting a Cairo binding from Gtk2hs because I want to > use Cairo on a server that doesn't have X or GTK readily available. I'm a maintainer of Gtk2Hs, c2hs and Cabal and I've slowly been working towards the same goal -- of improving c2hs and Cabal sufficiently to package all the Gtk2Hs components separately with Cabal. > As I went about adapting Gtk2hs' binding, I ran into the following > issue: > > 1) Cabal does not clean up after c2hs - in particular, it does > not delete the temporary .chi and .chs.h files that c2hs produces for > each file it processes. I fixed this one a couple days ago in fact :-) If you use the latest darcs version of both c2hs and Cabal, cabal now tells c2hs to put all its generated files under ./dist/build which means we don't clutter the source dirs with generated files and deleting the dist/build dir cleans them all up. > 2) Cabal does not do dependence analysis. Consequently, the > "other-modules" field of my cairo.cabal is order-sensitive. Yeah. This is very annoying. Lennart Kolmodin made a patch to do dep analysis just for the .chs files. We've not applied it yet, partly because we were looking for a more general solution and when I tested it briefly it didn't quite work. But this can probably be made to work with a little hacking. If you want to hack on it, the patch is here: http://haskell.org/~duncan/cabal/c2hs.dpatch > Together, these mean that after I manually delete those temporary files, > my build fails mysteriously because the dependencies are not being > resolved in an order that c2hs can work with. This in turn makes it > non-trivial to make reliable builds. > > Please let me know if you'd like any further information. To be practical, I think the easiest way to get just cairo building on a server without the Gtk+ headers is to hack the current Gtk2Hs build system. You'd want to modify the configure tests so that it doesn't bother to look for gtk+, and #ifdef out the gtk modules section in Makefile.am, like we do conditionally for the other optional modules. The other reason to take this approach is that currently the cairo source code uses a feature of c2hs that is only present in the gtk2hs fork of c2hs, so it'd need more work to use the mainline c2hs. OTOH, It's only a minor change as I recall. We're aiming to switch to the mainline c2hs some time too. BTW, if you're interested in seriously using the cairo bindings, we are looking for some help in updating them to provide the current cairo-1.4 API (rather than the current cairo-1.0 API) and to get the PDF, PS and SVG backends working. At the moment the only non-X11 backend we've got is the image/PNG backend. Duncan From duncan.coutts at worc.ox.ac.uk Fri May 4 04:06:43 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 4 04:16:36 2007 Subject: cabal-upload & cabal-install In-Reply-To: <20070503232703.GA8984@soi.city.ac.uk> References: <1178225128.9770.141.camel@localhost> <20070503232703.GA8984@soi.city.ac.uk> Message-ID: <1178266003.9770.181.camel@localhost> On Fri, 2007-05-04 at 00:27 +0100, Ross Paterson wrote: > On Thu, May 03, 2007 at 09:45:28PM +0100, Duncan Coutts wrote: > > What do we need to do next? Should we invite a little bit of wider > > testing on cabal-install + hackage and get some user feedback. If that's > > good we should actively advertise and push it. > > I think slowly building the user base among early adopters (as now) will > be the most useful. There's a GSoC project to extend the web interface, > which will involve changes and the risk of temporary breakage. We won't > be ready for everyone till after that. Right, sure. So just get Haskell hackers using it for the moment, hackers who are tolerant of a bit of churn. > As far as I know, the main thing missing from cabal-install is > documentation. There's a tricky issue of how it should relate to > a system package manager, but that will have to wait. I think it should default to --user-install. Partly just because this means it'll "Just Work"tm for everyone without supplying additional options and without confusing error messages (like /usr/local: permission denied). > > This would be a great way to do distributed testing and a way of finding > > out which packages are well used and tested. If summary info is on the > > website it also allows users to find out if a package is likely to work > > on their machine. > > Sounds like a great idea. Another possibility is to have buildbots > feeding this info back for all packages. Although the number of people we ought to be able to get using cabal-install is probably orders of magnitude greater than the number we can get as buildbot clients. Duncan From duncan.coutts at worc.ox.ac.uk Fri May 4 04:12:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 4 04:22:18 2007 Subject: cabal-upload & cabal-install In-Reply-To: <1F408B12-4F0B-44CF-993A-8AEEE8E136F7@cs.chalmers.se> References: <1178225128.9770.141.camel@localhost> <1F408B12-4F0B-44CF-993A-8AEEE8E136F7@cs.chalmers.se> Message-ID: <1178266345.9770.184.camel@localhost> On Fri, 2007-05-04 at 10:10 +0200, Bjorn Bringert wrote: > On May 3, 2007, at 22:45 , Duncan Coutts wrote: > > > ... > > I was also trying cabal-upload. I found that cabal-upload needs some > > functions from the HTTP lib that are not actually exported. In > > particular the stuff to do with authorisation in the Browser > > module. It > > looks like it ought to be exported since it isn't actually used > > internally. When I do patch the HTTP lib to export that, cabal-upload > > works for me. I uploaded filepath-1.0 today using it. > > I think that's just a problem with the versioned dependency in cabal- > upload.cabal. HTTP-3000.0.0 should already have those exports. Feel > free to fix it Right ok. I'll fix the version of cabal-upload's http dep. > (I don't have a lot of time right now with the baby). And congratulations! :-) Duncan From duncan.coutts at worc.ox.ac.uk Fri May 4 05:51:48 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 4 06:01:41 2007 Subject: cabal "fails" with no explanation In-Reply-To: <20070504021955.GA3839@localhost.localdomain> References: <20070504021955.GA3839@localhost.localdomain> Message-ID: <1178272308.9770.189.camel@localhost> On Thu, 2007-05-03 at 19:19 -0700, Stefan O'Rear wrote: > stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 > cleaning... > stefan@stefans:/usr/local/src/xmonad$ echo $? > 1 > stefan@stefans:/usr/local/src/xmonad$ ghc -V > The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 > stefan@stefans:/usr/local/src/xmonad$ > > configure, build, and install all also work but return 1. I cannot reproduce this. I'm using GHC-6.6 and latest darcs version of Cabal-1.1.7. > The same issue is observed with X11-extras. I didn't try that one. Duncan From conal at conal.net Fri May 4 15:02:33 2007 From: conal at conal.net (Conal Elliott) Date: Fri May 4 14:59:46 2007 Subject: Integrating Cabal, Haddock, HsColour In-Reply-To: <46305A28.1080102@gmail.com> References: <462A7532.60402@di.unipi.it> <46305A28.1080102@gmail.com> Message-ID: BTW, see also http://haskell.org/haskellwiki/Cabal-make, which automates haddock & hscolour use and a few more things, via simple make files. I like Cabal integration, so I'm all for Roberto's Cabal improvements. - Conal On 4/26/07, Simon Marlow wrote: > > Roberto Zunino wrote: > > I've just extended Cabal so to generate docs with links to highlighted > > sources. Now > > > > ./Setup configure > > ./Setup haddock --link-to-hscolour > > ./Setup hscolour --css my_own_stylesheet.css > > > > generates HTML as this one: (run on Cabal itself) > > > > > http://www.di.unipi.it/~zunino/tmp/dist/doc/html/Cabal/Distribution-Program.html#v%3AwithProgramFlag > > > > Click on the "Source" links on the right. You will be sent to the exact > > line. The whole Cabal docs+sources are online. Colours have been chosen > > to match my emacs configuration :-P . > > > > This relies on a couple of minor tweaks to Haddock and HsColour which I > > darcs-sent this morning to the authors. > > > > Comments are welcome. > > > > - Is this worth including in the next Cabal version? > > Looks really nice! (BTW, cabal-devel@haskell.org is a better place to > discuss > Cabal improvements). > > I'm happy for it to go in. > > > - Are the options above good choices? > > I'd make 'Setup haddock --hscolour' do both steps. > > > - Is the directory tree OK? Currently Haddock creates (under > dist/doc/html) > > Looks fine. > > Cheers, > Simon > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070504/3c49dbba/attachment.htm From bertram.felgenhauer at googlemail.com Fri May 4 22:24:12 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri May 4 22:21:28 2007 Subject: cabal "fails" with no explanation In-Reply-To: <20070504021955.GA3839@localhost.localdomain> References: <20070504021955.GA3839@localhost.localdomain> Message-ID: <20070505022412.GA4544@zombie.inf.tu-dresden.de> Stefan O'Rear wrote: > stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 > cleaning... > stefan@stefans:/usr/local/src/xmonad$ echo $? > 1 > stefan@stefans:/usr/local/src/xmonad$ ghc -V > The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 That's a ghci regression. I've sent a patch to cvs-ghc for this but it's awaiting moderator's approval. you can find it at http://int-e.home.tlink.de/haskell/fix-ghci-exit-code.patch I guess I should open a trac ticket. Maybe tomorrow. HTH, Bertram From stefanor at cox.net Fri May 4 22:37:03 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri May 4 22:34:14 2007 Subject: cabal "fails" with no explanation In-Reply-To: <20070505022412.GA4544@zombie.inf.tu-dresden.de> References: <20070504021955.GA3839@localhost.localdomain> <20070505022412.GA4544@zombie.inf.tu-dresden.de> Message-ID: <20070505023703.GA3925@localhost.localdomain> On Sat, May 05, 2007 at 04:24:12AM +0200, Bertram Felgenhauer wrote: > Stefan O'Rear wrote: > > stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 > > cleaning... > > stefan@stefans:/usr/local/src/xmonad$ echo $? > > 1 > > stefan@stefans:/usr/local/src/xmonad$ ghc -V > > The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 > > That's a ghci regression. I've sent a patch to cvs-ghc for this but > it's awaiting moderator's approval. you can find it at > > http://int-e.home.tlink.de/haskell/fix-ghci-exit-code.patch > > I guess I should open a trac ticket. Maybe tomorrow. Sorry, but you're too late. I saw the patch on cvs-ghc@ a day or two ago and realized that was my problem. (thanks anyway) Stefan From zunino at di.unipi.it Sun May 6 13:16:06 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Sun May 6 13:13:22 2007 Subject: Integrating Cabal, Haddock, HsColour In-Reply-To: <46305A28.1080102@gmail.com> References: <462A7532.60402@di.unipi.it> <46305A28.1080102@gmail.com> Message-ID: <463E0D56.4030606@di.unipi.it> Simon Marlow wrote: > Looks really nice! (BTW, cabal-devel@haskell.org is a better place to > discuss Cabal improvements). Thanks! (I didn't find the cabal-devel list because http://www.haskell.org/cabal/ only mentions the libraries list.) > I'm happy for it to go in. Does this imply the my Haddock patch for %{LINE} I sent you some time ago is also in? ;-) > I'd make 'Setup haddock --hscolour' do both steps. Ok, I'm doing this. Zun. From zunino at di.unipi.it Sun May 6 15:40:02 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Sun May 6 15:37:39 2007 Subject: Integrating Cabal, Haddock, HsColour In-Reply-To: <463E0D56.4030606@di.unipi.it> References: <462A7532.60402@di.unipi.it> <46305A28.1080102@gmail.com> <463E0D56.4030606@di.unipi.it> Message-ID: <463E2F12.9050408@di.unipi.it> Here's my final proposal. If everything is fine, I'll write the docs and submit the patch. New options: ** configure --with-hscolour=PATH give the path to hscolour --hscolour-args=ARGS give the args to hscolour ** haddock --executables Run Haddock for Executables targets --hscolour[=PATH] Also run hscolour (using PATH as the stylesheet, if any) ** hscolour --executables Run hscolour for Executables targets --css=PATH Use a cascading style sheet The --executables flag makes the doc-generating process to run for all stanzas in the .cabal file, i.e. for generating docs for "executable" pakages (Current patch also fixes related bug #102). Note the --css flag to hscolour. This is very much needed: hscolour expects the CSS file to be copied in the right directory, so either Cabal or the user has to copy the CSS file. Very often, if not always, you want to pass this flag to ./Setup hscolour, so that Cabal does it for you. Related to the above, ./Setup haddock --hscolour can take the PATH to the CSS file. I'm not particulary happy about this, because it feels a bit ad-hoc w.r.t. having a --with-hscolour-flags=[--css=...] , but the latter seemed overkill to me. Zun. From duncan.coutts at worc.ox.ac.uk Sun May 6 16:07:38 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 6 16:17:24 2007 Subject: Integrating Cabal, Haddock, HsColour In-Reply-To: <463E0D56.4030606@di.unipi.it> References: <462A7532.60402@di.unipi.it> <46305A28.1080102@gmail.com> <463E0D56.4030606@di.unipi.it> Message-ID: <1178482058.9770.263.camel@localhost> On Sun, 2007-05-06 at 19:16 +0200, Roberto Zunino wrote: > Simon Marlow wrote: > > Looks really nice! (BTW, cabal-devel@haskell.org is a better place to > > discuss Cabal improvements). > > Thanks! (I didn't find the cabal-devel list because > http://www.haskell.org/cabal/ only mentions the libraries list.) Good point. I've added a link. Duncan From duncan.coutts at worc.ox.ac.uk Mon May 7 05:27:36 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 7 05:38:56 2007 Subject: patch applied (cabal-install): Use user installs by default In-Reply-To: <463EE15C.9080309@gmail.com> References: <20070504111244.GA4660@cvs.haskell.org> <463EE15C.9080309@gmail.com> Message-ID: <1178530056.16518.19.camel@localhost> On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > Fri May 4 03:46:52 PDT 2007 Duncan Coutts > > * Use user installs by default > > So it "Just Works"tm without needing extra options or sudo fiddling. > > If you care you can still do sudo fiddling and --global-install > > This is inconsistent with Cabal and ghc-pkg, which both use global installs by > default. At the time we felt that global installs were the more common case. I > know this isn't a clear-cut issue though, and there are good arguments on both > sides. For example, one could argue that only the system's package manager > should install packages globally, so since we're bypassing the system package > manager we should default to user installs. > > However, I'm more concerned that we are consistent, and avoid surprising > behaviour where possible. The surprising behaviour I was trying to avoid was that by default it'd fail with an unhelpful error message. Having it work seems to be a better default. When doing manual, configure, build, install steps people are familiar with the notion that the install step needs to be done as root. When we are installing a whole set of packages automagically we don't quite have the same connection to the individual build steps and we kind of expect things to "Just Work"tm without a great deal of intervention. The only way we can do this is if you always run cabal-install as root. We'd have to make it clearer to people through the command line UI that this is the thing to do. This is also a slightly thing to get right, since if the user runs cabal-install update as non-root then the package db gets downloaded to their $HOME/.cabal-install/packages but if you then do cabal-install install as root then /root/.cabal-install/packages or /var/cache/cabal-install/packages probably is not up to date. As it happens, I'm not sure that --global by default for ghc-pkg and --user by default for cabal-install isn't right. The difference is in who is likely to be using the command and what level of control they expect. I'm cc'ing cabal-devel. Hopefully we can get some more opinions on this. Duncan From simonmarhaskell at gmail.com Thu May 10 04:25:41 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 10 04:22:39 2007 Subject: patch applied (cabal-install): Use user installs by default In-Reply-To: <1178530056.16518.19.camel@localhost> References: <20070504111244.GA4660@cvs.haskell.org> <463EE15C.9080309@gmail.com> <1178530056.16518.19.camel@localhost> Message-ID: <4642D705.5020709@gmail.com> Duncan Coutts wrote: > On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote: >> Duncan Coutts wrote: >>> Fri May 4 03:46:52 PDT 2007 Duncan Coutts >>> * Use user installs by default >>> So it "Just Works"tm without needing extra options or sudo fiddling. >>> If you care you can still do sudo fiddling and --global-install >> This is inconsistent with Cabal and ghc-pkg, which both use global installs by >> default. At the time we felt that global installs were the more common case. I >> know this isn't a clear-cut issue though, and there are good arguments on both >> sides. For example, one could argue that only the system's package manager >> should install packages globally, so since we're bypassing the system package >> manager we should default to user installs. >> >> However, I'm more concerned that we are consistent, and avoid surprising >> behaviour where possible. > > The surprising behaviour I was trying to avoid was that by default it'd > fail with an unhelpful error message. Having it work seems to be a > better default. > > When doing manual, configure, build, install steps people are familiar > with the notion that the install step needs to be done as root. When we > are installing a whole set of packages automagically we don't quite have > the same connection to the individual build steps and we kind of expect > things to "Just Work"tm without a great deal of intervention. > > The only way we can do this is if you always run cabal-install as root. > We'd have to make it clearer to people through the command line UI that > this is the thing to do. This is also a slightly thing to get right, > since if the user runs cabal-install update as non-root then the package > db gets downloaded to their $HOME/.cabal-install/packages but if you > then do cabal-install install as root then /root/.cabal-install/packages > or /var/cache/cabal-install/packages probably is not up to date. > > As it happens, I'm not sure that --global by default for ghc-pkg and > --user by default for cabal-install isn't right. The difference is in > who is likely to be using the command and what level of control they > expect. > > I'm cc'ing cabal-devel. Hopefully we can get some more opinions on this. We certainly shouldn't advocate running cabal-install as root (or should we? isn't emerge typically run as root in Gentoo?). I'm concerned that the unsuspecting user might end up with a mixture of globally-installed and locally-installed packages, leading to confusion later on. (See [1] for example) I think this can be solved with decent diagnostics. e.g.: $ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only. cabal-install could drop its permissions for the non-install steps, perhaps. Replace "as root" with "as administrator" for Windows. [1] http://gimbo.org.uk/blog/2007/04/27/haskell-packages-gotcha-global-vs-per-user-package-databases/ From duncan.coutts at worc.ox.ac.uk Thu May 10 04:54:24 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 10 05:05:31 2007 Subject: patch applied (cabal-install): Use user installs by default In-Reply-To: <4642D705.5020709@gmail.com> References: <20070504111244.GA4660@cvs.haskell.org> <463EE15C.9080309@gmail.com> <1178530056.16518.19.camel@localhost> <4642D705.5020709@gmail.com> Message-ID: <1178787265.16518.288.camel@localhost> On Thu, 2007-05-10 at 09:25 +0100, Simon Marlow wrote: > We certainly shouldn't advocate running cabal-install as root (or should we? > isn't emerge typically run as root in Gentoo?). Yes, gentoo's emerge and all other system packager tools I know of run as root (apt, yum etc). > I'm concerned that the unsuspecting user might end up with a mixture of > globally-installed and locally-installed packages, leading to confusion later > on. (See [1] for example) That one looks like it could be explained with nicer diagnostics from ghc. Eg it could say which package version it was using (and perhaps which package db it was from), like it currently has a nice diagnostic if you try and use a module that is hidden. Especially if the package db is inconsistent (eg files or deps missing) the user could be told about that. There are quite a number of ways of corrupting the package db and getting confusing errors as a result. > I think this can be solved with decent diagnostics. e.g.: > > $ cabal-install foo > You don't have permission to install packages globally (for all users). > Either: run cabal-install as root, or add the --user flag to install > packages for the current user only. This is nice, though actually doing these checks is not completely trivial. To be accurate we would want to check if the directory(s) we would install into are writable and if the global package.conf file is writable. Checking the latter is a bit dodgy since cabal isn't supposed to know about the existence of that file. > cabal-install could drop its permissions for the non-install steps, perhaps. > Replace "as root" with "as administrator" for Windows. Sounds like scary posix stuff :-) Do we have functions for changing user / dropping privileges ? I think we should check what the equivalent perl, ruby, python, erlang package distribution systems do. Duncan From bringert at cs.chalmers.se Thu May 10 08:01:30 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu May 10 07:56:30 2007 Subject: Stack overflow on hackage upload Message-ID: I can't seem to upload the new GD release to hackage: $ cabal-upload dist/gd-3000.1.0.tar.gz Uploading dist/gd-3000.1.0.tar.gz... ERROR: 500 Internal Server Error 500 Internal Server Error

500 Internal Server Error

stack overflow

Haskell CGI on Apache/2.0.54 (Debian GNU/Linux) at hackage.haskell.org, port 80
I get the same error when using my web browser to upload. I have attached the tarball I tried to upload. /Bj?rn -------------- next part -------------- A non-text attachment was scrubbed... Name: gd-3000.1.0.tar.gz Type: application/x-gzip Size: 4204 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070510/091525f0/gd-3000.1.0.tar.bin From ross at soi.city.ac.uk Thu May 10 10:27:13 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 10 10:24:09 2007 Subject: Stack overflow on hackage upload In-Reply-To: References: Message-ID: <20070510142713.GA4203@soi.city.ac.uk> On Thu, May 10, 2007 at 02:01:30PM +0200, Bjorn Bringert wrote: > I can't seem to upload the new GD release to hackage: Sorry about that. Fixed now. From duncan.coutts at worc.ox.ac.uk Thu May 10 17:30:17 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 10 17:41:23 2007 Subject: Stack overflow on hackage upload In-Reply-To: <20070510142713.GA4203@soi.city.ac.uk> References: <20070510142713.GA4203@soi.city.ac.uk> Message-ID: <1178832617.20151.19.camel@localhost> On Thu, 2007-05-10 at 15:27 +0100, Ross Paterson wrote: > On Thu, May 10, 2007 at 02:01:30PM +0200, Bjorn Bringert wrote: > > I can't seem to upload the new GD release to hackage: > > Sorry about that. Fixed now. I was hoping this might be the same bug that prevents me from uploading cabal-1.1.6.2.tar.gz but it seems not. I still get 400 error during upload after a few 100k. I suspect it's a server side limit on the upload size. Cabal-1.1.6 is just under 500k and Cabal-1.1.6.2 is just over. Perhaps I should try and reduce the size of the tarball by taking the built docs out (I'm not sure why they're in there, that's just what the current cabal makefile does). In case anyone else wants to try, the tarball is on the Cabal website: http://haskell.org/cabal/download.html Duncan From ross at soi.city.ac.uk Thu May 10 19:14:31 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 10 19:11:23 2007 Subject: Stack overflow on hackage upload In-Reply-To: <1178832617.20151.19.camel@localhost> References: <20070510142713.GA4203@soi.city.ac.uk> <1178832617.20151.19.camel@localhost> Message-ID: <20070510231431.GA9977@soi.city.ac.uk> On Thu, May 10, 2007 at 10:30:17PM +0100, Duncan Coutts wrote: > I was hoping this might be the same bug that prevents me from uploading > cabal-1.1.6.2.tar.gz but it seems not. I still get 400 error during > upload after a few 100k. > > I suspect it's a server side limit on the upload size. Cabal-1.1.6 is > just under 500k and Cabal-1.1.6.2 is just over. Perhaps I should try and > reduce the size of the tarball by taking the built docs out (I'm not > sure why they're in there, that's just what the current cabal makefile > does). The problem is probably the use of getInputFPS for the uploaded file -- a lazy bytestring version would be handy. From bos at serpentine.com Fri May 11 01:53:20 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri May 11 01:50:35 2007 Subject: Who should be generating lists of files? Message-ID: <464404D0.2020706@serpentine.com> As part of cabal-rpm, I'd like to be able to package up profiling versions of libraries in a separate system-level package from normal libraries, to reduce bloat. What's the best way for me to get a list of the files that would be installed by Setup copy, and determining which are profiling files vs normal? Should I be faking this up inside cabal-rpm, or pushing the knowledge out to Cabal itself? References: <20070510142713.GA4203@soi.city.ac.uk> <1178832617.20151.19.camel@localhost> <20070510231431.GA9977@soi.city.ac.uk> Message-ID: <8FFD408B-4444-4C9F-B4F4-D707E2CC7C30@cs.chalmers.se> On May 11, 2007, at 1:14 , Ross Paterson wrote: > On Thu, May 10, 2007 at 10:30:17PM +0100, Duncan Coutts wrote: >> I was hoping this might be the same bug that prevents me from >> uploading >> cabal-1.1.6.2.tar.gz but it seems not. I still get 400 error during >> upload after a few 100k. >> >> I suspect it's a server side limit on the upload size. Cabal-1.1.6 is >> just under 500k and Cabal-1.1.6.2 is just over. Perhaps I should >> try and >> reduce the size of the tarball by taking the built docs out (I'm not >> sure why they're in there, that's just what the current cabal >> makefile >> does). > > The problem is probably the use of getInputFPS for the uploaded > file -- > a lazy bytestring version would be handy. getInputFPS already returns a lazy ByteString, iirc. Besides, even strict bytestrings should work fine with 500k, right? /Bj?rn From ross at soi.city.ac.uk Fri May 11 06:39:35 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri May 11 06:36:25 2007 Subject: Stack overflow on hackage upload In-Reply-To: <8FFD408B-4444-4C9F-B4F4-D707E2CC7C30@cs.chalmers.se> References: <20070510142713.GA4203@soi.city.ac.uk> <1178832617.20151.19.camel@localhost> <20070510231431.GA9977@soi.city.ac.uk> <8FFD408B-4444-4C9F-B4F4-D707E2CC7C30@cs.chalmers.se> Message-ID: <20070511103935.GA2980@soi.city.ac.uk> On Fri, May 11, 2007 at 11:05:22AM +0200, Bjorn Bringert wrote: > On May 11, 2007, at 1:14 , Ross Paterson wrote: > >On Thu, May 10, 2007 at 10:30:17PM +0100, Duncan Coutts wrote: > >>I suspect it's a server side limit on the upload size. > > > >The problem is probably the use of getInputFPS for the uploaded > >file -- a lazy bytestring version would be handy. > > getInputFPS already returns a lazy ByteString, iirc. Besides, even > strict bytestrings should work fine with 500k, right? Ah yes, getInputFPS works fine with large files. So much for that theory. The problem is in the package cabal-1.1.6.2.tar.gz itself: the name of the tar file, directory, .cabal file and package must match exactly. As the error message says: could not extract cabal-1.1.6.2/cabal.cabal from cabal-1.1.6.2.tar.gz From duncan.coutts at worc.ox.ac.uk Fri May 11 07:01:33 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 11 07:12:36 2007 Subject: Stack overflow on hackage upload In-Reply-To: <20070511103935.GA2980@soi.city.ac.uk> References: <20070510142713.GA4203@soi.city.ac.uk> <1178832617.20151.19.camel@localhost> <20070510231431.GA9977@soi.city.ac.uk> <8FFD408B-4444-4C9F-B4F4-D707E2CC7C30@cs.chalmers.se> <20070511103935.GA2980@soi.city.ac.uk> Message-ID: <1178881293.20151.45.camel@localhost> On Fri, 2007-05-11 at 11:39 +0100, Ross Paterson wrote: > On Fri, May 11, 2007 at 11:05:22AM +0200, Bjorn Bringert wrote: > > On May 11, 2007, at 1:14 , Ross Paterson wrote: > > >On Thu, May 10, 2007 at 10:30:17PM +0100, Duncan Coutts wrote: > > >>I suspect it's a server side limit on the upload size. > > > > > >The problem is probably the use of getInputFPS for the uploaded > > >file -- a lazy bytestring version would be handy. > > > > getInputFPS already returns a lazy ByteString, iirc. Besides, even > > strict bytestrings should work fine with 500k, right? > > Ah yes, getInputFPS works fine with large files. So much for that theory. > > The problem is in the package cabal-1.1.6.2.tar.gz itself: the name of > the tar file, directory, .cabal file and package must match exactly. > As the error message says: > > could not extract cabal-1.1.6.2/cabal.cabal from cabal-1.1.6.2.tar.gz Ah! Getting that error message would have been very handy, rather than a generic apache 400 error page. Right, I'll fix it and upload. Thanks for investigating. Duncan From igloo at earth.li Fri May 11 12:28:31 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri May 11 12:25:19 2007 Subject: Who should be generating lists of files? In-Reply-To: <464404D0.2020706@serpentine.com> References: <464404D0.2020706@serpentine.com> Message-ID: <20070511162831.GA30353@matrix.chaos.earth.li> On Thu, May 10, 2007 at 10:53:20PM -0700, Bryan O'Sullivan wrote: > As part of cabal-rpm, I'd like to be able to package up profiling > versions of libraries in a separate system-level package from normal > libraries, to reduce bloat. Agreed; for Debian we'd ideally have ./Setup copy --dev ./Setup copy --prof ./Setup copy --doc to copy the "normal" libraries, the profiling libraries and the haddock docs respectively. > What's the best way for me to get a list of the files that would be > installed by Setup copy, and determining which are profiling files vs > normal? Should I be faking this up inside cabal-rpm, or pushing the > knowledge out to Cabal itself? There could then also be a --list-files flag which only lists which files it would install (presumably you'd first run "./Setup copy" to put them all in place, and then "./Setup copy --list-files --dev" etc to find out which files you need to take for which package). In case it is helpful, what I currently do is: PROF_FILE = \( -name "*.p_*" -o -name "lib*_p.a" \) # dev files: find tmp/usr/lib -type f ! $(PROF_FILE) find tmp -type d -empty # prof files: find tmp/usr/lib -type f $(PROF_FILE) # doc files: echo "tmp/usr/share/*/doc/html/*" Thanks Ian From igloo at earth.li Fri May 11 12:48:14 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri May 11 12:45:01 2007 Subject: patch applied (cabal-install): Use user installs by default In-Reply-To: <4642D705.5020709@gmail.com> References: <20070504111244.GA4660@cvs.haskell.org> <463EE15C.9080309@gmail.com> <1178530056.16518.19.camel@localhost> <4642D705.5020709@gmail.com> Message-ID: <20070511164814.GB30353@matrix.chaos.earth.li> On Thu, May 10, 2007 at 09:25:41AM +0100, Simon Marlow wrote: > > $ cabal-install foo > You don't have permission to install packages globally (for all users). > Either: run cabal-install as root, or add the --user flag to install > packages for the current user only. > > cabal-install could drop its permissions for the non-install steps, > perhaps. Replace "as root" with "as administrator" for Windows. Alternatively, cabal-install -rsudo foo or cabal-install -rootcmd=sudo foo (as a user) could call "sudo whatever" when it needs to do something as root. This would probably mean re-executing itself (or a separate binary) with an --I've-built-it-just-install-it-from=/tmp/... flag. This is what various Debian tools do, although it's slightly nicer in those cases as they are just calling a couple of shell commands. Thanks Ian From adrian at highcreativity.com Sat May 12 22:00:38 2007 From: adrian at highcreativity.com (Adrian Burciu) Date: Sat May 12 21:57:21 2007 Subject: cabal-install build-dep error Message-ID: <8ed2ffc60705121900h552e6987mbbb7fe9efe08431d@mail.gmail.com> Hello, I am a beginner in Haskell, and I am having a problem using cabal-install when I try to install the dependencies for a .cabal file. If I use I am able to install every package, one by one. When I installed cabal-install I had no problems and everything went on smoothly. These are the last lines when I installed it: [16 of 16] Compiling Main ( src/CabalInstall.hs, dist/build/cabal-install/cabal-install-tmp/Main.o ) Linking dist/build/cabal-install/cabal-install ... optimus:/usr/local/cabal-install_0 turingson$ sudo runghc Setup.lhs install Installing: /usr/local/lib/cabal-install-0.3.0/ghc-6.6 & /usr/local/bin cabal-install-0.3.0... optimus:/usr/local/cabal-install_0 turingson$ Here is the error I am getting when I try to use build-dep: optimus:/usr/local/hope turingson$ sudo cabal-install build-dep hope.cabal cabal-install: hope.cabal:9: Parse of field 'build-depends' failed: optimus:/usr/local/hope turingson$ That is the only error I am getting. Here is part of the content of the hope.cabal file: License-file: LICENSE Build-depends: base, network, mtl, parsec Do you know what I may be doing wrong or what can I do to work this around? Thanks, Adrian From nanardon at nanardon.zarb.org Sun May 13 15:56:39 2007 From: nanardon at nanardon.zarb.org (Olivier Thauvin) Date: Sun May 13 15:53:34 2007 Subject: cabal-install build-dep error In-Reply-To: <8ed2ffc60705121900h552e6987mbbb7fe9efe08431d@mail.gmail.com> References: <8ed2ffc60705121900h552e6987mbbb7fe9efe08431d@mail.gmail.com> Message-ID: <200705132156.51594.nanardon@nanardon.zarb.org> Le dimanche 13 mai 2007, Adrian Burciu a ?crit?: > Hello, > > I am a beginner in Haskell, and I am having a problem using > cabal-install when I try to install the dependencies for a .cabal > file. > > If I use I am able to > install every package, one by one. When I installed cabal-install I > had no problems and everything went on smoothly. These are the last > lines when I installed it: > > [16 of 16] Compiling Main ( src/CabalInstall.hs, > dist/build/cabal-install/cabal-install-tmp/Main.o ) > Linking dist/build/cabal-install/cabal-install ... > optimus:/usr/local/cabal-install_0 turingson$ sudo runghc Setup.lhs install > Installing: /usr/local/lib/cabal-install-0.3.0/ghc-6.6 & > /usr/local/bin cabal-install-0.3.0... > optimus:/usr/local/cabal-install_0 turingson$ > > Here is the error I am getting when I try to use build-dep: > > optimus:/usr/local/hope turingson$ sudo cabal-install build-dep hope.cabal > cabal-install: hope.cabal:9: Parse of field 'build-depends' failed: > optimus:/usr/local/hope turingson$ > > That is the only error I am getting. Here is part of the content of > the hope.cabal file: > License-file: LICENSE > Build-depends: > base, > network, > mtl, > parsec > > Do you know what I may be doing wrong or what can I do to work this around? I am not an expert but I think all words should be on only one line, after Build-depends:. Hope this help. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070513/f91a532b/attachment.bin From simonmarhaskell at gmail.com Tue May 15 04:11:38 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 15 04:08:20 2007 Subject: patch applied (cabal-install): Use user installs by default In-Reply-To: <20070511164814.GB30353@matrix.chaos.earth.li> References: <20070504111244.GA4660@cvs.haskell.org> <463EE15C.9080309@gmail.com> <1178530056.16518.19.camel@localhost> <4642D705.5020709@gmail.com> <20070511164814.GB30353@matrix.chaos.earth.li> Message-ID: <46496B3A.9040006@gmail.com> Ian Lynagh wrote: > On Thu, May 10, 2007 at 09:25:41AM +0100, Simon Marlow wrote: >> $ cabal-install foo >> You don't have permission to install packages globally (for all users). >> Either: run cabal-install as root, or add the --user flag to install >> packages for the current user only. >> >> cabal-install could drop its permissions for the non-install steps, >> perhaps. Replace "as root" with "as administrator" for Windows. > > Alternatively, > > cabal-install -rsudo foo > or > cabal-install -rootcmd=sudo foo > > (as a user) could call "sudo whatever" when it needs to do something as > root. This would probably mean re-executing itself (or a separate > binary) with an > > --I've-built-it-just-install-it-from=/tmp/... > > flag. This is what various Debian tools do, although it's slightly nicer > in those cases as they are just calling a couple of shell commands. Looks fine to me. Cheers, Simon From ross at soi.city.ac.uk Tue May 15 19:07:42 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue May 15 19:04:18 2007 Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock In-Reply-To: <20070219173658.GA15877@soi.city.ac.uk> References: <83vej5fvrq.fsf@bishop.syntaxpolice.org> <837ivlfv90.fsf@bishop.syntaxpolice.org> <20070219173658.GA15877@soi.city.ac.uk> Message-ID: <20070515230742.GA14283@soi.city.ac.uk> On Mon, Feb 19, 2007 at 05:36:58PM +0000, Ross Paterson wrote: > On Fri, Jan 19, 2007 at 05:18:07PM -0800, Conal Elliott wrote: > > So now I have just a new pair of flags enable-use-packages & > > disable-use-packages, which control whether haddock gets > > automatically-generated --use-package flags. > > There's a similar (but simpler) problem with generating Haddock > documentation for HackageDB. The trouble is that --use-package is > half right: it gives the interface file you want, but the wrong URL for > cross-references. (And there's no way to override it, because haddock > doesn't know which package a --read-interface option relates to.) > > For HackageDB, I think the appropriate thing would be for Cabal to use > ghc-pkg to get the haddock-interfaces field (instead of asking haddock to > ask ghc-pkg for it), but for the user to be able to override the HTML URL > at configure time. For HackageDB, a suitable template would be > > http://hackage.haskell.org/packages/archive/$pkg/$pkgid.misc/doc/html > or > http://hackage.haskell.org/packages/archive/$pkg/latest.misc/doc/html I've now implemented this (new option --html-location to setup haddock, rather than configure), and removed the --disable-use-packages and --enable-use-packages options. From simonmarhaskell at gmail.com Wed May 23 08:07:20 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 23 08:03:40 2007 Subject: Trac should send bug updates to this list? Message-ID: <46542E78.1050709@microsoft.com> We were musing on #ghc today about how visible (or not) the Cabal Trac is. I personally visit it very rarely. It would probably help if Trac sent bug updates to this list. Igloo had a recollection that Isaac didn't like the idea - Isaac, any comments? We could create a separate list if necessary, but I don't honestly think the extra volume will be a problem. Cheers, Simon From ijones at syntaxpolice.org Wed May 23 12:47:43 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Wed May 23 12:43:54 2007 Subject: Trac should send bug updates to this list? In-Reply-To: <46542E78.1050709@microsoft.com> References: <46542E78.1050709@microsoft.com> Message-ID: <4654702F.3010507@syntaxpolice.org> Simon Marlow wrote: > We were musing on #ghc today about how visible (or not) the Cabal Trac > is. I personally visit it very rarely. > > It would probably help if Trac sent bug updates to this list. Igloo had > a recollection that Isaac didn't like the idea - Isaac, any comments? > We could create a separate list if necessary, but I don't honestly think > the extra volume will be a problem. I don't recall objecting to bug reports from trac; they're a little annoying sometimes because they're not really formatted that well so you can tell what the change is, but they're OK. Go for it :) peace, isaac From simonmarhaskell at gmail.com Thu May 24 07:17:32 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 24 07:14:16 2007 Subject: Trac should send bug updates to this list? In-Reply-To: <4654702F.3010507@syntaxpolice.org> References: <46542E78.1050709@microsoft.com> <4654702F.3010507@syntaxpolice.org> Message-ID: <4655744C.4030204@gmail.com> Isaac Jones wrote: > Simon Marlow wrote: >> We were musing on #ghc today about how visible (or not) the Cabal Trac >> is. I personally visit it very rarely. >> >> It would probably help if Trac sent bug updates to this list. Igloo >> had a recollection that Isaac didn't like the idea - Isaac, any >> comments? We could create a separate list if necessary, but I don't >> honestly think the extra volume will be a problem. > > I don't recall objecting to bug reports from trac; they're a little > annoying sometimes because they're not really formatted that well so you > can tell what the change is, but they're OK. > > Go for it :) Ok, I've set up the Trac end of things, but we need to allow emails from trac@galois.com to this list. Isaac, I think you're the only one with admin rights for this list, could you set it up? Cheers, Simon From igloo at earth.li Sat May 26 18:26:39 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat May 26 18:22:37 2007 Subject: Bugs and interface changes Message-ID: <20070526222639.GA1579@matrix.chaos.earth.li> Hi all, I've gone through the Cabal bugs and tried to make sure that those that mean interface changes are marked as high priority. Any of these that we can get done before the next round of releases will hopefully mean fewer headaches in the longrun. By the way, do bugs get automatically assigned to ijones? That doesn't seem very useful to me. Thanks Ian From nominolo at googlemail.com Sat May 26 20:22:22 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat May 26 20:18:20 2007 Subject: Hi Folks! I'll be your biat.. er SoC student for the following 3 months... Message-ID: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> .. and as you probably all know, I am going to implement cabal-configurations. (And for those who didn't know--SoC stands for Summer of Code and Google pays me for fixing your problems!) My mentor is Isaac Jones, aka. SyntaxNinja. I'll be working based on this e-mail http://www.mail-archive.com/cabal-devel@haskell.org/msg00195.html, as this is the one linked from the bug tracker. I'll also consider the previous discussions on this mailing list as some guidelines (motivation, ideas behind it, etc.). Here's a snipped of the official project timeline (http://code.google.com/support/bin/answer.py?answer=60325&topic=10729): .----------------------------------------------------- May 28: Students begin coding for their GSoC projects; Google begins issuing initial student payments Interim Period: Mentors give students a helping hand and guidance on their projects July 9: Students upload code to code.google.com/hosting; mentors begin mid-term evaluations July 16: Mid-term evaluation deadline; Google begins issuing mid-term student payments August 20: Students upload code to code.google.com/hosting; mentors begin final evaluations; students begin final program evaluations August 31: Final evaluation deadline; Google begins issuing student and mentoring organization payments '----------------------------------------------------- There are some minor modifications I have to / want to make. Firstly, I'll won't be able to work full time for the first two weeks as I have exams in the first and a summer course in the second. In essence, I assume that I'll work about half the time. Secondly, I plan to use darcs locally and push to some haskell.org SoC repo every day; this way I can't be blamed for loss of work if my disk crashes and you can see (and maybe even use) my latest version. Isaac also suggested that I maintain a wiki page where I post weekly progress reports. My blog is on Planet Haskell, but I'd rather not spam this with this kind of stuff. (But I will use it for announcing notable progress that might be helpful for others, or for getting attention/input on certain community-relevant design decisions.) The current schedule Isaac and I have put up looks roughly like this: Week 1: Parser & unit tests for parser - This should be relatively straightforward. I'll refrain from using Parsec, though, in order to avoid dependecies. Week 2-3: Constraint solver implementation and testing - I'll start with the naive algorithm, but I guess I need to add some more clever testing. After that, we, in principle, have cabal-configurations. But I'm afraid that's just the beginning of the real work. Week 4: Study a variety of packages and their needs, select a handful to write configurations for (I plan to ask for some suggestions a bit earlier). Write the configurations and suggest any needed improvements to syntax or capabilities (discuss on list). Post examples for everyone to look at (using IRC, wiki, and list). Week 5-8: Most likely there will come up some problems, feature request bug-reports or similar. I therefore reserve these for handling those tasks. Due to latency of communication over internet, I'll probably have some time to fill. But I guess the bug tracker will always be helpful with that. Week 9: Integration into mainline Cabal branch and work with Duncan to prepare a release candidate. (Might be scheduled earlier if things go well) Week 10-12: Analyze most important Cabal bugs and fix them, meanwhile, support release candidate. _ |_| This is obviously a rather loose schedule, so if you have any comments/critics/suggestions, feel free to post them here. Regards, / Thomas PS: Duncan / Isaac, can one of you get me that darcs + trac account? (If I don't get any response here, I'll try again in private.) -- "Remember! Everytime you say 'Web 2.0' God kills a startup!" - userfriendly.org, Jul 31, 2006 From nominolo at googlemail.com Sat May 26 20:26:21 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat May 26 20:22:18 2007 Subject: Hi Folks! I'll be your biat.. er SoC student for the following 3 months... In-Reply-To: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> References: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> Message-ID: <916b84820705261726i4e29bdd1y11fe5eb03698b73c@mail.gmail.com> > Week 2-3: Constraint solver implementation and testing > - I'll start with the naive algorithm, but I guess I need to add some > more clever testing. s/clever testing/clever optimizations/ From nominolo at googlemail.com Sun May 27 15:18:36 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun May 27 15:14:32 2007 Subject: Hi Folks! I'll be your biat.. er SoC student for the following 3 months... In-Reply-To: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> References: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> Message-ID: <916b84820705271218q33e71e90s481f02f8cf0401f3@mail.gmail.com> The Wiki-page is at http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations On 5/27/07, Thomas Schilling wrote: > .. and as you probably all know, I am going to implement > cabal-configurations. (And for those who didn't know--SoC stands for > Summer of Code and Google pays me for fixing your problems!) My mentor > is Isaac Jones, aka. SyntaxNinja. > > I'll be working based on this e-mail > http://www.mail-archive.com/cabal-devel@haskell.org/msg00195.html, as > this is the one linked from the bug tracker. I'll also consider the > previous discussions on this mailing list as some guidelines > (motivation, ideas behind it, etc.). > > Here's a snipped of the official project timeline > (http://code.google.com/support/bin/answer.py?answer=60325&topic=10729): > > .----------------------------------------------------- > May 28: Students begin coding for their GSoC projects; Google begins > issuing initial student payments > > Interim Period: Mentors give students a helping hand and guidance on > their projects > > July 9: Students upload code to code.google.com/hosting; mentors begin > mid-term evaluations > > July 16: Mid-term evaluation deadline; Google begins issuing mid-term > student payments > > August 20: Students upload code to code.google.com/hosting; mentors > begin final evaluations; students begin final program evaluations > > August 31: Final evaluation deadline; Google begins issuing student > and mentoring organization payments > '----------------------------------------------------- > > There are some minor modifications I have to / want to make. Firstly, > I'll won't be able to work full time for the first two weeks as I have > exams in the first and a summer course in the second. In essence, I > assume that I'll work about half the time. Secondly, I plan to use > darcs locally and push to some haskell.org SoC repo every day; this > way I can't be blamed for loss of work if my disk crashes and you can > see (and maybe even use) my latest version. Isaac also suggested that > I maintain a wiki page where I post weekly progress reports. My blog > is on Planet Haskell, but I'd rather not spam this with this kind of > stuff. (But I will use it for announcing notable progress that might > be helpful for others, or for getting attention/input on certain > community-relevant design decisions.) > > The current schedule Isaac and I have put up looks roughly like this: > > Week 1: Parser & unit tests for parser > - This should be relatively straightforward. I'll refrain from using > Parsec, though, in order to avoid dependecies. > > Week 2-3: Constraint solver implementation and testing > - I'll start with the naive algorithm, but I guess I need to add some > more clever testing. > > After that, we, in principle, have cabal-configurations. But I'm > afraid that's just the beginning of the real work. > > Week 4: Study a variety of packages and their needs, select a handful > to write configurations for (I plan to ask for some suggestions a bit > earlier). Write the configurations and suggest any needed > improvements to syntax or capabilities (discuss on list). Post > examples for everyone to look at (using IRC, wiki, and list). > > Week 5-8: Most likely there will come up some problems, feature > request bug-reports or similar. I therefore reserve these for > handling those tasks. Due to latency of communication over internet, > I'll probably have some time to fill. But I guess the bug tracker > will always be helpful with that. > > Week 9: Integration into mainline Cabal branch and work with Duncan to > prepare a release candidate. (Might be scheduled earlier if things go > well) > > Week 10-12: Analyze most important Cabal bugs and fix them, meanwhile, > support release candidate. > _ > |_| > > This is obviously a rather loose schedule, so if you have any > comments/critics/suggestions, feel free to post them here. > > Regards, > > / Thomas > > PS: Duncan / Isaac, can one of you get me that darcs + trac account? > (If I don't get any response here, I'll try again in private.) > > -- > "Remember! Everytime you say 'Web 2.0' God kills a startup!" - > userfriendly.org, Jul 31, 2006 > -- "Remember! Everytime you say 'Web 2.0' God kills a startup!" - userfriendly.org, Jul 31, 2006 From ndmitchell at gmail.com Sun May 27 17:46:45 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 27 17:42:39 2007 Subject: Plain email addresses on hackage Message-ID: <404396ef0705271446v17fa5753i1d7e07b77ea26a70@mail.gmail.com> Hi When email addresses are in a .cabal file, they are including on the hackage website in plain text. For example: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/derive-0.1 Can someone please hide these email addresses in some way? Thanks Neil From duncan.coutts at worc.ox.ac.uk Sun May 27 18:03:24 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 27 17:58:41 2007 Subject: Hi Folks! I'll be your biat.. er SoC student for the following 3 months... In-Reply-To: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> References: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> Message-ID: <1180303404.13344.120.camel@localhost> On Sun, 2007-05-27 at 02:22 +0200, Thomas Schilling wrote: > .. and as you probably all know, I am going to implement > cabal-configurations. (And for those who didn't know--SoC stands for > Summer of Code and Google pays me for fixing your problems!) My mentor > is Isaac Jones, aka. SyntaxNinja. > > I'll be working based on this e-mail > http://www.mail-archive.com/cabal-devel@haskell.org/msg00195.html, as > this is the one linked from the bug tracker. The one you really want is the one you've got linked from the CabalConfigurations wiki page, ie http://www.mail-archive.com/cabal-devel@haskell.org/msg00282.html "Configurations proposal, take n" sent by Ian, summarising the proposal that we seemed to agree on. Duncan From nominolo at googlemail.com Sun May 27 19:39:17 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun May 27 19:35:13 2007 Subject: Hi Folks! I'll be your biat.. er SoC student for the following 3 months... In-Reply-To: <1180303404.13344.120.camel@localhost> References: <916b84820705261722x32c9543fhe73b8fc77d1bfe8@mail.gmail.com> <1180303404.13344.120.camel@localhost> Message-ID: <916b84820705271639m2ee7f787w426809870485247a@mail.gmail.com> Oh, right. That was a wrong copy'n'paste. Sorry. I'm of course working on that "take n" proposal. The wiki page is ATM work in progress. I'll put a formal grammar up until the end of the week. In any case though, I guess the syntax is not the most important part, though having common agreement would be best, of course. Thomas On 5/28/07, Duncan Coutts wrote: > On Sun, 2007-05-27 at 02:22 +0200, Thomas Schilling wrote: > > .. and as you probably all know, I am going to implement > > cabal-configurations. (And for those who didn't know--SoC stands for > > Summer of Code and Google pays me for fixing your problems!) My mentor > > is Isaac Jones, aka. SyntaxNinja. > > > > I'll be working based on this e-mail > > http://www.mail-archive.com/cabal-devel@haskell.org/msg00195.html, as > > this is the one linked from the bug tracker. > > The one you really want is the one you've got linked from the > CabalConfigurations wiki page, ie > > http://www.mail-archive.com/cabal-devel@haskell.org/msg00282.html > > "Configurations proposal, take n" sent by Ian, summarising the proposal > that we seemed to agree on. > > Duncan > > -- "Remember! Everytime you say 'Web 2.0' God kills a startup!" - userfriendly.org, Jul 31, 2006 From ross at soi.city.ac.uk Tue May 29 06:55:49 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue May 29 06:51:42 2007 Subject: Plain email addresses on hackage In-Reply-To: <404396ef0705271446v17fa5753i1d7e07b77ea26a70@mail.gmail.com> References: <404396ef0705271446v17fa5753i1d7e07b77ea26a70@mail.gmail.com> Message-ID: <20070529105549.GA2604@soi.city.ac.uk> On Sun, May 27, 2007 at 10:46:45PM +0100, Neil Mitchell wrote: > When email addresses are in a .cabal file, they are including on the > hackage website in plain text. For example: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/derive-0.1 > > Can someone please hide these email addresses in some way? They could be obfuscated on the web page, but this would gain little, as they're still in the .cabal file (and the tarball that contains it). After all, by releasing a package you're publishing its contents. Shy folk will need to modify the addresses at source. From zunino at di.unipi.it Wed May 30 16:30:22 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Wed May 30 16:26:29 2007 Subject: HsColour integration (patch) Message-ID: <465DDEDE.7010601@di.unipi.it> I am sending a patch[1] for integrating Cabal and HsColour + Haddock. Here is the result of running it on the base package: http://www.di.unipi.it/~zunino/tmp/base/index.html The above was generated by ./Setup configure ./Setup haddock --hscolour=hscolour.css Requirements: HsColour >=1.8, my hscolour.css file[2] (or your own, of course!), darcs Haddock + a link-breaking-bug fix (already sent) + any version bump (required: haddock > 0.8). Enjoy, Zun. [1] http://www.di.unipi.it/~zunino/tmp/cabal-hscolour-20070530 [2] http://www.di.unipi.it/~zunino/tmp/hscolour-emacs.css From ross at soi.city.ac.uk Wed May 30 20:03:43 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed May 30 19:59:29 2007 Subject: Cabal for the GHC build Message-ID: <20070531000343.GA21482@soi.city.ac.uk> It's a pity that even simple libraries need a 67-line Setup.hs to make the GHC build work. How about moving the --ghc-option and --configure-option flags into Cabal? --configure-option might be a better idea than the current behaviour of "setup configure" in defaultUserHooks, namely to pass through all unrecognized arguments. From bringert at cs.chalmers.se Thu May 31 06:10:22 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu May 31 06:04:35 2007 Subject: Cabal for the GHC build In-Reply-To: <20070531000343.GA21482@soi.city.ac.uk> References: <20070531000343.GA21482@soi.city.ac.uk> Message-ID: <618E7053-263A-4212-A54D-948FC1A1CB78@cs.chalmers.se> On May 31, 2007, at 2:03 , Ross Paterson wrote: > It's a pity that even simple libraries need a 67-line Setup.hs to > make the > GHC build work. How about moving the --ghc-option and --configure- > option > flags into Cabal? --configure-option might be a better idea than the > current behaviour of "setup configure" in defaultUserHooks, namely to > pass through all unrecognized arguments. I agree that this is a problem. At the moment a lot of darcs versions of packages are incompatible with the last Cabal release solely because of this. /Bj?rn