- cabal-devel - Haskell.org

Close to release candidate
by Johan Tibell 12 Apr '13

12 Apr '13

Hi all, Today I merged Mikhail's sandbox UI changes. I believe this is the biggest hurdle to get the next release out. We have a few remaining tickets: https://github.com/haskell/cabal/issues?milestone=20&state=open and then we should be good to go. I will start with #1106. I think we can punt on #1143. #1197 is important however. -- Johan

1 0

patch applied (hackage-server): "Remove the basic html package pages from the core and candidate features" and 4 others
by devnull＠community.haskell.org 08 Apr '13

08 Apr '13

Fri Mar 29 18:14:30 GMT 2013 Duncan Coutts <duncan(a)community.haskell.org> * Remove the basic html package pages from the core and candidate features Ignore-this: d1d21177dadd082d176d78130db247a2 M ./Distribution/Server/Features/Core.hs -39 +1 M ./Distribution/Server/Features/PackageCandidates.hs -20 +1 Sat Mar 30 08:50:03 GMT 2013 Duncan Coutts <duncan(a)community.haskell.org> * Simplify Hook interface and remove a few unused feature hooks Ignore-this: 66d7b02693ae0ee3168ca4f98fcdd17e M ./Distribution/Server/Features/Core.hs -36 +22 M ./Distribution/Server/Features/DownloadCount.hs -1 +1 M ./Distribution/Server/Features/Html.hs -4 +4 M ./Distribution/Server/Features/NameSearch.hs -6 +6 M ./Distribution/Server/Features/PackageCandidates.hs -31 +22 M ./Distribution/Server/Features/PackageList.hs -9 +9 M ./Distribution/Server/Features/PreferredVersions.hs -7 +7 M ./Distribution/Server/Features/RecentPackages.hs -1 +1 M ./Distribution/Server/Features/Tags.hs -4 +4 M ./Distribution/Server/Features/Upload.hs -15 +3 M ./Distribution/Server/Features/Users.hs -19 +7 M ./Distribution/Server/Framework/Hook.hs -46 +15 Mon Apr 8 22:08:11 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Change http code for the legacy passwd auth failure Ignore-this: cd56b7525cfaac2d5bba8c30ea17a3f2 When someone tries to authenticate for a user account that has a legacy password, we previously returned 401 without any auth methods. It turns out that returning 401 in this case is a violation of the http spec because you must provide at least one auth method. So change it to use 403 Forbidden. M ./Distribution/Server/Features/LegacyPasswds.hs -1 +1 Mon Apr 8 22:13:44 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Fix name of template in user signup feature Ignore-this: 883829d860f59407c1a89a9dbf1b564a M ./Distribution/Server/Features/UserSignup.hs -1 +1 Mon Apr 8 22:14:51 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Do not offer http basic authentication Ignore-this: 47a9f1430c007f50f9a3549f24a29b04 We still accept it if the client offers it pre-emptively. M ./Distribution/Server/Framework/Auth.hs -10 +11

1 0

Cabal sandbox and rebuild of added sources
by Daniel Trstenjak 08 Apr '13

08 Apr '13

Hi, I just tried the sandbox functionality of cabal with the current version on github (b89d894947a9ec6fde78ebc6e7f6978f0b117eb1). If the source added by 'cabal sandbox-add-source' changes, than it gets rebuild by calling 'cabal sandbox-build', but not if I'm just calling 'cabal sandbox-install'. Is there a reason for this behavior? Greetings, Daniel

2 1

hackage trac
by Ian Lynagh 05 Apr '13

05 Apr '13

Hi all, A few IPs were hammering http://hackage.haskell.org/trac/hackage/wiki/HackageDB today which (is probably what) caused abbot to become inaccessible. /srv/trac/hackage/db/trac.db is 613MB, which seems rather suspicious: /srv/trac/ghc/db/trac.db is only 359MB. I wonder if it is full of spam? I'm also not able to load http://hackage.haskell.org/trac/hackage/wiki/HackageDB?action=history (it just times out). Could someone take a look please? Or perhaps the Cabal wiki should be moved elsewhere (github?) and the trac instance disabled? Thanks Ian

6 11

Re: Defining CH executables in cabal files
by Duncan Coutts 04 Apr '13

04 Apr '13

On Thu, 2013-04-04 at 15:46 +0100, Rob Stewart wrote: > Hi Duncan, Edsko. > > I'd like to know where I should most appropriately submit a bug > report, or indeed whether the behaviour that I am experiencing is a > bug or a user misuse of cabal. It's a consequence of a misunderstanding of how package names affect types and how different cabal constructs give you different package names. > I have packaged up a very simple send/receive example into a cabalised > archive. In there is a README that describes the problem succinctly, > though I will repeat here for convenience. It appears to be weirdness > with main-is and hs-source-dirs. In the .cabal file, there are three > executables of the same Receiver.hs file - a receiver of a CH message. > One appears to be defined in such a way that the CH primitives `match` > and `expect` are *not* receiving the message types that are being sent > by Sender.hs. The problem is that your three programs are using different types. ch-receiver-1 and ch-receiver-2 use the type cabal-with-ch-executables-1.0:Bar.Baz.Types.Msg while ch-receiver-3 uses the type Bar.Baz.Types.Msg Those are the fully-qualified names of those types and they are different, so they are different types, so have different Typeable fingerprints and so the `expect` does not match them. So as you can see, the fully qualified name of a type includes its package id, and in the first case it has the package name cabal-with-ch-executables-1.0 while in the second case it is the "home" package, which has no name (or if you like, it's called ""). Code in a library has fully qualified names that include the package name. Code in a top level executable is in the "home" package. The way you've constructed your three programs, the first two put the module in a library and the third puts it in the top level executable, so according to ghc it really is a different module. So lets look at your cabal file: > library > default-language: Haskell2010 > exposed-modules: Bar.Baz.Types > , Bar.Baz.Identify > build-depends: base >= 4 && < 5 > , binary >= 0.6.3.0 > , bytestring >= 0.9.2 > , distributed-process >= 0.4.2 > , network > , network-transport > , network-transport-tcp > hs-source-dirs: src > GHC-Options: -Wall > > -- Works > Executable ch-receiver-1 > default-language: Haskell2010 > main-is: Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > hs-source-dirs: examples > ghc-options: -Wall > > -- Works > Executable ch-receiver-2 > default-language: Haskell2010 > main-is: Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > hs-source-dirs: src/Bar/Baz > ghc-options: -Wall > > -- Doesn't work > Executable ch-receiver-3 > default-language: Haskell2010 > main-is: Bar/Baz/Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > > -- I don't understand why these below are now needed?? > , binary >= 0.6.3.0 > , bytestring >= 0.9.2 > , distributed-process >= 0.4.2 > , network > , network-transport > , network-transport-tcp > hs-source-dirs: src > ghc-options: -Wall So you have the first two executables depending on the library and they pick up their Bar.Baz.Types module from the library. Your third executable also depends on the library but the way you have the sources organised means that you're getting the modules from the source files and not from the library. This is because you're using the hs-source-dirs as src, which is where the modules for the library live. ghc will always pick local source files over modules from packages. This is also why you needed those extra dependencies, your executable is including those modules directly (you'll notice they're recompiled for the 3rd exe). The solution is that when you want to have an exe in a package depend on a lib in the same package, you need to separate the src dirs, as you did with the first one (hs-source-dirs: examples). Clear as mud? What would be good is if cabal would warn when the same module can be found both in a local lib that we depend on, and as a source file, because that's probably a mistake. It might also be good if we could tell ghc where to get the modules from explicitly, rather than rely on its behaviour about preferring src modules to package modules. Duncan

1 0

patch applied (hackage-server): "Add link to cabal file editing to maintainers page"
by devnull＠community.haskell.org 27 Mar '13

27 Mar '13

Wed Mar 27 12:50:51 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Add link to cabal file editing to maintainers page Ignore-this: 99bf7ccf84a4cfeab89406c672fa1d7f M ./datafiles/templates/Html/maintain.html.st +5

1 0

patch applied (hackage-server): "Remove the google search from the package page" and 5 others
by devnull＠community.haskell.org 26 Mar '13

26 Mar '13

Thu Mar 14 17:37:47 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Remove the google search from the package page Ignore-this: 7c0346431aec1bc7f195cdd2037991c6 M ./Distribution/Server/Pages/Index.hs -8 Tue Mar 26 14:43:11 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Tweak page css based on feedback Ignore-this: 6b91314fa8fc506a02b42d30ac390161 Center content, bigger font, wider page body, no justification of text M ./datafiles/static/hackage.css -3 +2 Tue Mar 26 14:44:38 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Fix last few occurrences of HackageDB for simply Hackage Ignore-this: b4bf3d65b92523f8d3d5a4cc2a1392f5 M ./datafiles/templates/UserSignupReset/ResetConfirm.st -1 +1 M ./datafiles/templates/UserSignupReset/ResetEmailSent.st -1 +1 M ./datafiles/templates/UserSignupReset/ResetRequest.st -1 +1 M ./datafiles/templates/UserSignupReset/SignupConfirm.st -1 +1 M ./datafiles/templates/UserSignupReset/SignupEmailSent.st -1 +1 M ./datafiles/templates/accounts.html.st -1 +1 Tue Mar 26 18:24:00 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Redo the maintainer links and page based on feedback Ignore-this: 2805cd1d99d8f91721ca4671a3241ead The feedback was that the links for maintainers were confusing for ordinary users because it is not clear if they are allowed to use them or not, and "maintain" is not very descriptive as a link name. This patch removes the tags edit link from the package page. It moves the maintainer edit link to the bottom of the page and make it clearer that it is only for maintainers and trustees. The new maintainer page is now a lot clearer (and uses a template so easier to edit). M ./Distribution/Server/Features/Html.hs -29 +34 M ./Distribution/Server/Pages/Package.hs +11 A ./datafiles/templates/Html/ A ./datafiles/templates/Html/maintain.html.st Tue Mar 26 23:34:47 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Add feature for editing cabal files Ignore-this: 2d62a3ae7d5be1cf0b26045cdb623584 Maintainers and truestees can make new revisions without uploading a new tarball. Only certain changes are allowed. In particular adjusting dependency version constraints is allowed. M ./Distribution/Server/Features.hs +7 A ./Distribution/Server/Features/EditCabalFiles.hs M ./Distribution/Server/Framework/Resource.hs -2 +14 A ./datafiles/templates/EditCabalFile/ A ./datafiles/templates/EditCabalFile/cabalFileEditPage.html.st A ./datafiles/templates/EditCabalFile/cabalFilePublished.html.st M ./hackage-server.cabal +1 Tue Mar 26 23:37:15 GMT 2013 Duncan Coutts <duncan(a)well-typed.com> * Update the favicon to the haskell.org one Ignore-this: 349208e2a7bc61452918590bd87e1b9e M ./datafiles/static/favicon.ico

1 0

Code style guide?
by Ben Millwood 23 Mar '13

23 Mar '13

Hi everyone, Do we have a general notion of what we consider best practices for contributed code to Cabal? Perhaps we should formalise something? One of the reasons I wanted to get the wiki back online was in the hope that it had some pointers, but it doesn't seem to. (I've started migrating stuff anyway: have a look at https://github.com/haskell/cabal/wiki/Migration-from-trac for status). For example, many of the Cabal modules have explicit, and therefore quite long, import lists, with no clear organisation, and hence when adding new imports I have to read the entire list to make sure they are not already there, and then wonder where makes sense to insert them. Usually I just make something up with no pattern to it, and hence perpetuate the problem. I am happy to start things off with a proposal if no-one else wants to do the writing. Regards, Ben Millwood (benmachine)

6 12

Re: Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 22 Mar '13

22 Mar '13

On Mon, 2013-03-18 at 09:32 -0700, Iavor Diatchki wrote: > Hello, > > To me it seems that the dependency here is incorrect---as far as I > understand, GHC does not need to parse Cabal files, so it should not depend > on the code and the library to do so. Yes, GHC does not parse .cabal files. > Furthermore, what is the overall architecture of the whole thing? My > understanding has been that each implementation should have its own notion > of a "package", and cabal simply has support for working with the package > formats for each implementation. Thus, it seems that the package types and > code for (de)serializing them should be in the implementation (i.e., GHC), > not Cabal. I can see that it might make sense to have a common > representation about package meta-data (e.g., names, versions, license, > etc.), so perhaps these should all go in a separate package. This looks a > bit like the `cabal-types` that Duncan suggested, but I'd imagine that > Cabal would need more types than just package meta-data so this is not an > ideal name. The Cabal spec defines a few things that all Haskell implementations are supposed to support/provide. This covers the notion of an installed package (not .cabal source packages). It defines what it is, the meta-data that is stored and the format in which the implementation should accept it (ie the input format for ghc-pkg). So it's a compiler independent notion and the natural place to put the code to support it was the Cabal lib, so that's what happened. We can split that off into another package but it still makes sense for that package to provide a parser and pretty printer (because implementations have to accept them in the external format). So the natural way to partition things doesn't help us avoid ghc depending on a parser lib. > Finally, I agree that a "real" parser is good, but do you really want to > write it using Parsec? A sensible alternative would be to write a Happy > grammar. Having an actual grammar would both benefit users of the system, > and it would avoid the dependency on all those package. My experience of > having to maintain some largish Parsec (and in general, combinator based) > parsers, is that over the years the parsers get more and more complex, and > are quite hard to maintain. I'm somewhat repeating other parts of the thread at this point (see the discussion on "why not happy"), but I'd like to point out again that it is not simply the outline parser for cabal-style files that we're talking about. We also need parsers/pretty printers for all the various little types that make up the info about packages, like versions, package names, package ids, version constraints, module names, licenses etc etc. In the Cabal lib we have a type class with parser and pretty printer and all these various little types are instances. That stuff pretty much has to use a combinator lib because it needs to be compositional. You need to be able to reuse the version number parser in other parsers, or programs like cabal-install or the hackage-server need to reuse them as part of other parsers in their command line UI or config files, urls etc. So we have to use a combinator lib anyway. We currently also use this for parsing the fields of .cabal files and the InstalledPackageInfo. Currently we use ReadP from the base library which produces no error messages and has pretty bad performance in some cases (exploding memory use). It's that part particularly that should be using something like parsec. Happy simply isn't an option there. I could possibly use happy for the outline parser but it wouldn't buy us much. Duncan

2 2

RE: Advance notice that I'd like to make Cabal depend on parsec
by Simon Peyton-Jones 21 Mar '13

21 Mar '13

Is it essential, or even sensical, that the serialization format GHC needs for storing package info bear any relation to the human authored form? If not, the split out of the package types could be accomplished in a way where GHC uses simple show/read(P) style serialization for storage of package info, where as cabal-lib would use a lovely parsec parser for humans. I'd like this approach. Good idea -- esp if it makes the packaging story simpler. GHC already uses a binary format for interface files, so there’s no good reason to use a human-readable format for package data base stuff. For interface files you can read them with ghc --show-iface, and as Ian remarks something similar is already true for the package data base. Simon From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Mark Lentczner Sent: 17 March 2013 16:57 To: dag.odenhall(a)gmail.com Cc: Haskell Libraries; cabal-devel; Duncan Coutts; ghc-devs(a)haskell.org; Antoine Latter Subject: Re: Advance notice that I'd like to make Cabal depend on parsec This thread is raising all sorts of questions for me: Is it essential, or even sensical, that the serialization format GHC needs for storing package info bear any relation to the human authored form? If not, the split out of the package types could be accomplished in a way where GHC uses simple show/read(P) style serialization for storage of package info, where as cabal-lib would use a lovely parsec parser for humans. I'd like this approach. The issue of putting the yet one more HP package into GHC's core packages is increasing the exposure of the difficulty of the current GHC/HP relationship. See also threads in HP's mailing list for why can't we bump some packages in GHC's core set for the next HP release. The split arrangement is strange because we have two groups making up what is in the HP, but they have different processes and aims. The complex technical relationship between the moving parts only heightens the difficulty. Perhaps the major cause is that because GHC is shipped as a library itself, it exposes all it's package dependencies. And as it is a large, and growing, piece of software, the list only wants to grow. But I wonder how often GHC is used as a library itself? If not often, then perhaps GHC should be shipped as two parts: Just a compiler (plus the small number of packages that the compiler forces), and ghc-lib as an optional, even separate, package - perhaps one with even a traditional way of depending on other packages. In otherwords, users that wanted to incorporate the ghc-lib into their programs would depend, and download, and configure, and build, ghc-lib indpenendant of the GHC binaries installed on their system. Perhaps then, GHC, the compiler, built from ghc-lib, would be bootstrapped not from the past compiler, but from the past HP..... Okay, perhaps that is all just fantasy. But, no other programming system operates the way we do. They all fall into one of two camps: * The dominant implementation is maintained, built, and shipped along with a large collection of "common packages". Examples: Python, Ruby, PHP, Java. * The dominant implementation is shipped as a bare tool, and large common libraries are maintained and shipped independently. Examples: C++ (think g++ and boost), JavaScript (think browsers, and jQuery). We are in the middle and, I think, experiencing growing pains because of it. - Mark On Sat, Mar 16, 2013 at 3:42 PM, dag.odenhall(a)gmail.com<mailto:dag.odenhall@gmail.com> <dag.odenhall(a)gmail.com<mailto:dag.odenhall@gmail.com>> wrote: I'd love to have a proper parser and source-location-aware AST for sake of editor/IDE tools, so +1 from me. If you don't end up doing this after all, I'd still like to see your parser in a separate package, although I understand if you don't feel like maintaining two parsers especially given the tedious process for verifying they work similarly. I guess it could still be useful in the same way we find haskell-src-exts useful despite some incompatibilities with GHC. On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts <duncan.coutts(a)googlemail.com<mailto:duncan.coutts@googlemail.com>> wrote: Hi folks, I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package, rather than just a HP package. So this would affect both GHC and the HP, though I hope not too much. The rationale is that Cabal needs to parse things, like .cabal files and currently we do not have a decent parser in the core libraries. By decent I mean one that can produce error messages with source locations and that doesn't have unpredictable memory use. The only parser in the core libraries at the moment is Text.ParserCombinators.ReadP from the base package and that fails my "decent" criteria on both counts. Its idea of an error message is (), and on some largish .cabal files we take 100s of MB to parse (I realise that the ReadP in the base package is a cutdown version so I don't mean to malign all ReadP-style libs out there). Partly due to the performance problem, the terrible .cabal file error messages, and partly because Doaitse Swierstra keeps asking me if .cabal files have a grammar, I've been writing a new .cabal parser. It uses an alex lexer and a parsec parser. It's fast and the error messages are pretty good. I have reverse engineered a grammar that closely matches the existing parser and .cabal files in the wild, though I'm not sure Doaitse will be satisfied with the approach I've taken to handling layout. Why did I choose parsec? Practicality dictates that I can only use things in the core libraries, and the nearest thing we have to that is the parser lib that is in the HP. I tried to use happy but I could not construct a grammar/lexer combo to handle the layout (also, happy is not exactly known for its great error messages). I've been doing regression testing against hackage and I'm satisfied that the new parser matches close enough. I've uncovered all kinds of horrors with .cabal files in the wild relying on quirks of the old parser. I've made adjustments for most of them but I will be breaking a half dozen old packages (most of those don't actually build correctly because though their syntax errors are not picked up by the parser, they do cause failure eventually). So far I've just done the outline parser, not the individual field parsers. I'll be doing those next and then integrate. So this change is still a bit of a ways off, but I thought it'd be useful to warn people now. Duncan _______________________________________________ cabal-devel mailing list cabal-devel(a)haskell.org<mailto:cabal-devel@haskell.org> http://www.haskell.org/mailman/listinfo/cabal-devel

2 1