- cabal-devel - Haskell.org

Auto generating hoogle database from cabal
by Erik de Castro Lopo 10 Jun '13

10 Jun '13

Hi all, Anyone know the status of adding the ability to generate hoogle database from cabal? I've found these: http://hackage.haskell.org/trac/hackage/ticket/402 https://code.google.com/p/ndmitchell/issues/detail?id=80 but they seem un-finished or incomplete. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

Password recovery on trac
by David Fox 10 Jun '13

10 Jun '13

The page at http://hackage.haskell.org/trac/hackage/reset_password says Trac Error The password file could not be updated. Trac requires read and write access to both the password file and its parent directory. when I try to recover my password. Could someone take a look at this? Thanks. -david

1 0

Mac .app and .framework bundle building
by Irene Knapp 05 Jun '13

05 Jun '13

Hi, all! The other day, I created an issue over on GitHub with my thoughts on a family of related features that I have now begun implementing, to support the building of Mac bundles. As anyone who's used the platform probably knows, these are a way of distributing libraries and applications as specially-structured directory trees. They are particularly important because the Mac's GUI API, Cocoa, *requires* a .app wrapper around any executable which uses the display. Command-line programs which attempted to access the display used to behave strangely and never take focus, but since Mountain Lion introduced sandboxing, they no longer even run. This makes libraries such as SDL and its peer glow rather pointless for Haskell developers, unless we can build them into bundles. I have specific thoughts on implementation, which I wrote up on the ticket, but as I've begun work on this I've additionally noticed some related features which, since I'm now doing this "for real" and not "just for me" like my previous work in this area, really need discussion before being implemented. I've linked to the ticket below, but for those on their phones, :), I'm also summarizing and repeating most of what I said there, here. I'll put the most controversial part first: I'm doing this as two new top-level components, Framework and App respectively, as peers to Library, Executable, TestSuite, and all our other favorites. This allows a single .cabal file to contain instructions for both regular Unix-style and fancy Mac-style, and even to install both side-by-side if desired. This is particularly important in the case that one wants to build a .app bundle which contains some command-line support tools, which is not a hugely uncommon pattern in software designed for developers. It does create some duplication of information; for example, if one wants to build a Library on non-Mac platforms, but instead build a Framework on the Mac, then one must include all the options for both, keep ithem in synch, and conditionalize the buildable: option based on the platform. However, I don't see this duplication as being any worse than what most .cabal files in the wild already do for test suites. I will note that somebody else might wish to work on a feature to define variables in a .cabal file, with sets of option-value pairs as their values, with the goal of reducing duplication... but I don't have time myself. A subsidiary feature is the building of Apple's Interface Builder .xib documents into .nib documents (.xib is a source file and .nib is its compiled form), by shelling out to Apple's command-line tool. This is one of the things I've already gotten working and just need to forward-port from my two-year-old fork to my current fork, so it shouldn't be a big deal or raise major design questions. Another issue is Apple's Info.plist files, which are XML in a well-documented format, that goes inside the bundle. The last time I worked on this, Duncan expressed a strong desire for them to be generated; I believe his argument reduced to wanting Cabal, as a matter of pride, to be the authoritative owner of package metadata. They do overlap slightly with what we currently have, mostly in the authorship information. They also have version numbers, but I don't think offhand that they're in a compatible format with ours. Mostly, however, they contain Apple-specific information such as category in their store; bundle identifier in reverse-DNS style; document-type definitions which include identifiers, filename extension mappings, and the like; ... They are fairly complex in that way. It would be a pain to describe them in our .cabal file, and the information would be useless for other component-types. So, I'm not inclined to do this. I expect to have no difficulty with .app bundles, because those also I previously had working. However, .framework bundles present a different can of worms. It is certainly of some use to create a .framework which contains Haskell code intended to be used from a C application. But, it would be really nice if we could actually use our own .frameworks from Haskell. To do this, the .hi and installed-package-info files need to reside inside the .framework directory... and need to use relative paths, which I haven't looked into the feasibility of, since the point of a .framework is that it can be relocated in the filesystem. I think that if this can be done, that will be sufficient to make these beasts load properly, but does anybody see any other obstacles? My old patches for C-side main() and other supporting things I don't remember regarding hybrid C-Haskell programs will also be needed, but I'm fairly sure those got merged recently. (I wasn't involved, since I had long since given up getting them through review, so I'm not sure exactly which patches made it.) Another point - I've been operating under the assumption that Framework components will have names, unlike Library components. I can't easily use the package name for them, as is done for Library components, because the Unix convention is lower-case and the Mac convention is uppercase, and you will recall that I consider it important to support both component types in one .cabal file. But this makes things inconsistent and I'd rather like it if that inconsistency were resolved by allowing multiple Library components, with names. It would be useful to me personally; I've got another project that is broken into several pieces, which right now each have their own .cabal files out of necessity, but which I would rather merge together to make their building and testing (drastically) simpler. I'm willing to do that work, once I'm done with the rest of this, but I wouldn't hold up the merge of bundles on it; it's not crucial to them. What do people think? Having written all this, it has actually made me think twice about the wisdom of making Haskell-package .framework bundles at all - it might be better to stick with just .app bundles. But I really, really wanted to not try to run without a .nib in my fork of glfw and its Haskell wrapper, because running without a .nib is both buggy and rather hard to maintain, since it unnecessarily puts things into imperative code that are better done through GUI tools. Does anybody have an opinion? Since obviously nobody is waiting eagerly for this, I see no reason to push out a release with just .app support; I'd rather get everything working before merging, even the hard bits. The brave can experiment with my new fork anyway in the meantime, since it's on GitHub. Whew! Thank you for reading this far. :) I should make this shorter, but I'm in a rush to get home just at the moment... References: https://github.com/haskell/cabal/issues/1355 https://github.com/IreneKnapp/cabal/ -- Irene Knapp

1 0

Divin�sia - Lista dos aprovados em vestibular
by David Anderson 05 Jun '13

05 Jun '13

Divinésia ALINE MOURA FERREIRA, LARESSA RAMOS FERREIRA, FERNANDA LEONTSINIS CARVALHO BRANCO, NATIELLY ALEXANDRE CARNEIRO, JOÃO CARLOS MOREIRA DE CARVALHO, CLAUDIO LUIS GOMES PEREIRA, MARIA CECILIA ALBUQUERQUE CORDEIRO, ISABELLE PEREIRA DA SILVA. RUI ANDRADE DA SILVA, ELIANA DANTAS RIBEIRO, MATHEUS FERNANDES CAMPOS, JOSE VALDIR TEIXEIRA BRAGA FILHO, VINICIUS CANDIDO DOS REIS. Bom Jesus de Goiás. Vitória da Conquista ANA MARA DE SOUSA PEREIRA, LUANA FERNANDA FERNANDES ANDRADE, FRANCISCO ROGER GARCIA DE ALMEIDA, POLLYANNA DE O, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELLA FERNANDES DA SILVA, MARIA JOSÉ DA SILVA FERREIRA, JÉSSICA VENTURA FREIRE. SOLANGE PAULINO CORREIA, BRUNA KETHEY DA SILVA PEIXOTO, LUIS HENRIQUE FREITAS GOMES, HELIO SOARES DE ARAUJO, RENER QUEIROZ VIEIRA. Barra do Garças. Alterosa ALINE MOURA FERREIRA, LARESSA RAMOS FERREIRA, FERNANDA LEONTSINIS CARVALHO BRANCO, NATIELLY ALEXANDRE CARNEIRO, JOÃO CARLOS MOREIRA DE CARVALHO, CLAUDIO LUIS GOMES PEREIRA, MARIA CECILIA ALBUQUERQUE CORDEIRO, ISABELLE PEREIRA DA SILVA. RUI ANDRADE DA SILVA, ELIANA DANTAS RIBEIRO, MATHEUS FERNANDES CAMPOS, JOSE VALDIR TEIXEIRA BRAGA FILHO, VINICIUS CANDIDO DOS REIS. Barra do Garças.

1 0

ANNOUNCE: haskell-packages-0.1
by Roman Cheplyaka 27 May '13

27 May '13

I am happy to announce the first release of haskell-packages. http://haskell-suite.github.io/haskell-packages/ There are two cases when you may need haskell-packages: if you are writing a Haskell compiler (or any tool that processes Haskell source code, such as a static analyzer), or if you want to integrate with an existing Haskell compiler that uses haskell-packages. ## Writing a compiler If you are writing a compiler, you typically want to integrate it with Cabal, to be able to build ordinary Haskell packages. If you go the hard way, this involves: 1. **Parsing command line parameters**. Sounds easy — just take a list of files to compile. In reality you also need to handle package ids and package dbs, CPP options (`-DFOO=1`), language extension flags (`-XRankNTypes`) etc. To integrate with Cabal, you also need to tell it the list of installed packages, supported languages and extensions etc. 2. Actual **integration with Cabal** means understanding how Cabal works and hard-coding support for your compiler. And then getting it accepted and waiting for the next Cabal release. You may pretend that you are GHC or other compiler that is already supported by Cabal. It might work, but often it won't, for various reasons. Also, GHC's command line protocol is quite complex. 3. **Package management**. You need to implement a package db mechanism, which would let you to keep track of installed packages. Then you'd have to implement a `ghc-pkg`-like tool to manage those databases, for both Cabal and your users. **Or**, you can simply use this library! It already has command line options parsing, Cabal support, and package management. All you need to do is to provide the function to do actual compilation and tell a couple of other things about your compiler. See the `Distribution.HaskellSuite.Compiler` module for details. ## Using other compilers Some compilers produce artifacts that you may want to use. A good example is the `gen-iface` compiler from haskell-names which generates an *interface* for each module — the set of all named entities (functions, types, classes) that are exported by that module. This information can be then used either by other compilers, or by tools like IDEs. Assuming the compiler uses haskell-packages and exports its database type, it's very easy to use its artifacts. See `Distribution.HaskellSuite.Packages` for package resolution and `Distribution.HaskellSuite.Modules` for module resolution. ## Installation Note that haskell-packages uses (yet unreleased) haskell-src-exts 1.14. Get it [here][hse]. It doesn't matter what Cabal version you use together with haskell-packages, but if you want to invoke a haskell-packages compiler from Cabal (see [Usage](#usage)), you need to build our [fork of Cabal][Cabal]. Eventually it will be merged into Cabal. [hse]: https://github.com/haskell-suite/haskell-src-exts [Cabal]: https://github.com/feuerbach/Cabal ## Usage To compile a Haskell package using a haskell-packages tool: cabal install --haskell-suite -w $TOOL where `$TOOL` may be either a full path to the compiler, or just an executable name if it's in `$PATH`.

1 0

Re: [Haskell-cafe] How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

Great! Thanks. I adapted that trick and it worked fine: https://github.com/rrnewton/haskell-lockfree-queue/blob/cb8ca1a5d8b4c02e45e… On Wed, May 22, 2013 at 11:53 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > Hey Ryan, > I ran into a related issue, heres a a way you can do this safe IN the > cabal file (or at least you can modify my hack for your purposes) > > heres a link to the workaround I did for making LLVM-hs work across >= > 1.17 and < 1.17 cabal, but you could abuse it to make sure setup.hs barfs > on old cabal > https://github.com/bos/llvm/blob/master/base/Setup.hs#L89-L116 > > heres a quick one off gist that takes my trick and does something helpful > for you variant + makes sure the tool can't build otherwise > > https://gist.github.com/cartazio/5632636 > > I just wrote a snippet that you can just add to your setup.hs and it > should guarantee the setup.hs will barf with a helpful error message on > cabal < 1.17.0 > > > On Wed, May 22, 2013 at 10:50 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > >> A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was >> fixed recently that pertains to building C libraries with profiling. >> >> As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. >> Otherwise this package fails in weird ways at runtime (it's a nasty one). >> >> I noticed with some surprise the following sequence: >> >> * $ cabal --version* >> * cabal-install version 1.16.0.2* >> * using version 1.16.0.3 of the Cabal library* >> * $ cabal clean* >> * $ cabal install* >> * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* >> * #define VERSION_Cabal "1.17.0"* >> >> Alright, so that, in retrospect, makes sense. The version is which *my* >> library is linked with is the relevant one, not the one cabal-install was >> linked with [1]. >> >> So the natural next thought is to move the MIN_VERSION_Cabal test into >> Setup.hs, and force cabal to use it by setting the build type to Custom. >> But... I just learned from this ticket that the cabal macros are not >> available in Setup.hs: >> >> http://hackage.haskell.org/trac/hackage/ticket/326 >> >> Uh oh, what's left? >> >> -Ryan >> >> [1] P.S. Personally I'm now using a bash function like below, to force >> the two versions to be the same: >> >> function safe_cabal_install () { >> VER=`cabal --version | tail -n1 | awk '{ print $3 }'` >> cabal install --constraint="Cabal==$VER" $* >> } >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was fixed recently that pertains to building C libraries with profiling. As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. Otherwise this package fails in weird ways at runtime (it's a nasty one). I noticed with some surprise the following sequence: * $ cabal --version* * cabal-install version 1.16.0.2* * using version 1.16.0.3 of the Cabal library* * $ cabal clean* * $ cabal install* * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* * #define VERSION_Cabal "1.17.0"* Alright, so that, in retrospect, makes sense. The version is which *my* library is linked with is the relevant one, not the one cabal-install was linked with [1]. So the natural next thought is to move the MIN_VERSION_Cabal test into Setup.hs, and force cabal to use it by setting the build type to Custom. But... I just learned from this ticket that the cabal macros are not available in Setup.hs: http://hackage.haskell.org/trac/hackage/ticket/326 Uh oh, what's left? -Ryan [1] P.S. Personally I'm now using a bash function like below, to force the two versions to be the same: function safe_cabal_install () { VER=`cabal --version | tail -n1 | awk '{ print $3 }'` cabal install --constraint="Cabal==$VER" $* }

2 1

Hackage2 does not always read the package category properly
by Henk-Jan van Tuyl 22 May '13

22 May '13

L.S., I found, amongst others, the SDL package (at page http://new-hackage.haskell.org/packages/ ) in the Unclassified category, while the cabal file of this package says "Foreign binding". On page http://new-hackage.haskell.org/package/SDL , clicking on the link "Foreign binding", leads to the top of the package listing, instead of the Foreign binding section. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

install --builddir
by Benjamin Scarlet 15 Apr '13

15 Apr '13

I'm having trouble with install --builddir. If I run $ cabal install --builddir /some/absolute/path test-framework I get an error after regex-posix is installed, during the build of test-framework: Text/Regex/Posix/Wrap.hsc:141:8: Could not find module `Text.Regex.Base.RegexLike' It is a member of the hidden package `regex-base-0.93.2'. Perhaps you need to add `regex-base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. But if I run $ cabal install --builddir /some/absolute/path regex-posix $ rm -r /some/absolute/path $ cabal install --builddir /some/absolute/path test-framework I do not get the error. Between experiments I'm removing my ~/.cabal and ~/.ghc and running cabal update. Naively, it looks to me like using an absolute builddir has changed things so successive packages share the same intermediate files, which in turn has caused a later package to erroneously recompile a previously generated file. My ultimate aim is only to be able to use cabal-dev for my development builds, but without writing into my source tree. Is there any way to specify a build directory outside the source of a package without it winding up shared? Could/should cabal instead create a separate subdirectory within the specified builddir for each package to be built, so that specifying an external location didn't break things? Thanks, Ben Scarlet

2 1

hackage 2: alpha testing, testers wanted!
by Duncan Coutts 15 Apr '13

15 Apr '13

Hi folks, I believe we're ready for alpha testing for hackage 2. The server is up at: http://new-hackage.haskell.org/ Key points: * All the old data is imported (including docs) * Uploading is enabled * Live mirroring is also enabled * Per-package maintainer groups are pre-populated * Existing users should be able to log in (after a one-time upgrade) I would like to invite everyone on this list to help out with the alpha testing and to report issues here on this list. Patches are even better. The server is up now so you'll get "instant patch gratification"tm if you chip in and fix things. In addition to any bugs you may discover, the server main page gives an overview of the features that are partially complete and could do with some love. When we're satisfied we'll move into beta testing and advertise more widely within the community (reddit etc). The doc builder is not set up yet, but the builder client code exists, just need to get that set up. In general the switch over plan remains that we run the two servers in parallel for long enough to sort out remaining issues (with help from the kind folks who volunteered as admins). Code and wiki ============= The code is all still in darcs. darcs get http://code.haskell.org/hackage-server/ The plan is to move it to github at some stage. The wiki content is still useful though starting to get a bit out of sync: http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0 We had to turn off wiki editing for most users because of spammers. If you'd like to work on the wiki, let me know and I'll give your account permission to edit it. Note also that I think Ben Millwood is planning to move the content to github at some stage, though we can still make improvements to the content in the meantime. Hackage Admins ============== I believe the following people volunteered to be admins, at least for the alpha/beta testing period: * Erik Hesselink * Ben Millwood * Johan Tibell If you folks (or anyone else who wants to volunteer) would like to confirm that then I'll add you to the admins group. User accounts ============= Existing users should be fine. That process should now be fairly smooth (testing welcome!). For new users, they can sign up with email confirmation. An administrator is needed to add a user into the uploaders group. Currently there's not a lot you can do with an account if you're not in the uploaders group. That may change in future if we implement "social" features. Hackage Trustees ================ In addition to admins we have the "trustees" group. This should eventually be a rather useful job. The idea is that the trustees don't upload packages but look after the health of the package collection as a whole (or some subset they're interested in), a bit like distro maintainers. Currently they can only edit package tags and upload docs (e.g. if the doc builder fails) but the plan is for them (as well as maintainers) to be able to edit package metadata, in particular the constraints on dependencies. Once we get there, that'll be a rather important job. So I'm also looking for volunteers there, both to be trustees and to help finish implementing the metadata-editing feature. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4