May 2007 - cabal-devel

HsColour integration (patch)
by Roberto Zunino 15 Jun '07

15 Jun '07

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

3 4

Bugs and interface changes
by Ian Lynagh 07 Jun '07

07 Jun '07

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

2 1

Cabal for the GHC build
by Ross Paterson 31 May '07

31 May '07

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.

2 1

Plain email addresses on hackage
by Neil Mitchell 29 May '07

29 May '07

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

2 1

Hi Folks! I'll be your biat.. er SoC student for the following 3 months...
by Thomas Schilling 28 May '07

28 May '07

.. 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

2 4

Trac should send bug updates to this list?
by Simon Marlow 24 May '07

24 May '07

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

2 2

[Conal Elliott] Re: getting cabal to pass more info to haddock
by Isaac Jones 16 May '07

16 May '07

3 7

Re: patch applied (cabal-install): Use user installs by default
by Duncan Coutts 15 May '07

15 May '07

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 <duncan.coutts(a)worc.ox.ac.uk> > > * 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

3 4

cabal-install build-dep error
by Adrian Burciu 14 May '07

14 May '07

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 <sudo cabal-install install package_name> 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

2 1

Who should be generating lists of files?
by Bryan O'Sullivan 12 May '07

12 May '07

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? <b

2 1