June 2013 - cabal-devel

Hackage 2 trustees
by Erik Hesselink 11 Sep '13

11 Sep '13

Hi all, I just upgraded our internal hackage to the latest HEAD. I found that the behavior of the 'trustees' group has changed. Previously, they could upload any (existing) package, but that doesn't work anymore. This functionality was very useful for us, since otherwise, we'd have to add all our coders as maintainers to all our packages. I've patched our local code, but my question is: * Is this a bug and should I push a patch? * Is this intended and should I push a patch to the text at http://hackage.typlab.com/packages/trustees/, since it doesn't correspond to the current behavior? Regards, Erik

2 1

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 21 Jul '13

21 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

patch applied (hackage-server): "Compatibility with happstack-server 7.1.7"
by devnull＠community.haskell.org 27 Jun '13

27 Jun '13

Thu Jun 27 15:50:22 BST 2013 edsko(a)well-typed.com * Compatibility with happstack-server 7.1.7 Ignore-this: b785ffe4499352dc530226fd19245b3 'escape' disappeared. Added as 'uriEscape' in Util.Happstack. M ./Distribution/Server/Framework/Resource.hs -7 +6 M ./Distribution/Server/Util/Happstack.hs -3 +9

1 0

haddock arguments
by Benjamin Scarlet 23 Jun '13

23 Jun '13

Distribution.Simple.Setup.HaddockFlags(haddockProgramArgs) is a [(String, [String])]. What does it mean? I've got a package with a largish file which makes haddock blow it's stack, so it needs ghc rts options. I can do this on the command line with +RTS -K32M -RTS. Can I bake it into my package somehow? I'm trying messing with the haddock flags in the haddockHook in the package description, but I'm not getting the result I want. Thanks, Ben Scarlet

2 2

Progress: GSoC - Improve the feedback of the cabal-install dependency solver
by Martin Ruderer 18 Jun '13

18 Jun '13

Hey all, we are nearing the end of the "Students get to know mentors, read documentation, get up to speed to begin working on their projects"-Phase and I would like to tell you what I have done so far and how you can follow my progress in the future, if you like. I have forked cabal at https://github.com/mr-/cabal and I have set up a little blog at http://cabal-summer.blogspot.de/ . So far, I have written an IDE to navigate the dependency tree interactively. However the output is not very user-friendly yet. This I will focus on in the immediate future. If you have any comments on what you would like to see done, or more concretely, have suggestions for useful commands to walk the tree, I would be very grateful. Ciao, Martin

2 2

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

11 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 06 Jun '13

06 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