gmane.comp.lang.haskell.cabal.devel

Re: Progress: GSoC - Improve the feedback of the cabal-installdependency solver

Martin Ruderer — 2013-06-18T09:20:04

That would be cool.

I wonder if reaching a Fail-Node means permadeath or not.
"A big set of conflicts fell on your head. You are stumbling back down
the stairs.."

Meanwhile, I am just trying to make it less wordy ;-)

Ciao, Martin

On Fri, Jun 14, 2013 at 3:35 AM, Conrad Parker <conrad< at >metadecks.org> wrote:

Re: Progress: GSoC - Improve the feedback of the cabal-installdependency solver

Conrad Parker — 2013-06-14T01:35:31

That's a pretty cool UI you've got there. However it's a bit wordy,
perhaps you could draw the tree visually and allow the user to
navigate it that way?

 ------                             -  Package boundary
 |....|      ############           #  Untraversed dependency
 |....|      #          #           .  A cabal file
 |.$..+########         #           $  Some quantity of bugs
 |....|       #      ---+---        +  A version choice
 ------       #      |.....|        |  Package boundary
              #      |.!...|        !  A magic pragma
              #      |.....|
              #      |..< at >..|        < at >  The user
   ----       #      |.....|
   |..|       #######+..D..|        D  A red dragon book
   |<.+###    #      |.....|        <  Stairs to a higher level dependency
   ----  #    #      |.?...|        ?  A magic script
         ######      -------

Conrad.

Progress: GSoC - Improve the feedback of the cabal-install dependencysolver

Martin Ruderer — 2013-06-13T15:55:21

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

Auto generating hoogle database from cabal

Erik de Castro Lopo — 2013-06-10T20:49:10

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

Password recovery on trac

David Fox — 2013-06-10T13:43:54

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

Mac .app and .framework bundle building

Irene Knapp — 2013-06-05T22:04:35

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 pr

Divinsia - Lista dos aprovados em vestibular

David Anderson — 2013-06-05T11:40:28

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 CORDEIR

ANNOUNCE: haskell-packages-0.1

Roman Cheplyaka — 2013-05-27T16:31:33

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

Re: [Haskell-cafe] How to throw an error if using "cabal-install"

Ryan Newton — 2013-05-23T15:30:54

Great!  Thanks.  I adapted that trick and it worked fine:

https://github.com/rrnewton/haskell-lockfree-queue/blob/cb8ca1a5d8b4c02e45eeca54fbc66f0c58aeff56/AtomicPrimops/Setup.hs



On Wed, May 22, 2013 at 11:53 PM, Carter Schonwald <
carter.schonwald< at >gmail.com> wrote:

Hackage 2 trustees

Erik Hesselink — 2013-05-23T09:00:14

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

Re: How to throw an error if using "cabal-install" < version XYZ?

Roman Cheplyaka — 2013-05-23T05:42:44

Perhaps I'm missing something, but why not just

  cabal-version:       >=1.18

?

It will constrain the Cabal version, not cabal-install, but judging from
the fix[1] this is what you actually need.

[1]: https://github.com/haskell/cabal/commit/d148336e97cda2e3585c453cf9af61bc3635131a

Roman

* Ryan Newton <rrnewton< at >gmail.com> [2013-05-22 22:50:08-0400]

How to throw an error if using "cabal-install" < version XYZ?

Ryan Newton — 2013-05-23T02:50:08

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

Hackage2 does not always read the package category properly

Henk-Jan van Tuyl — 2013-05-22T14:25:11

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

Re: install --builddir

Duncan Coutts — 2013-04-15T14:52:44

I'm sure that's exactly what is going on. It is using that directory to
store the build artefacts and that is not supposed to be shared with any
other package.


You could just call it with builddir set to a fresh directory (e.g. with
a wrapper script like cabal-dev). If you want to set it statically and
with a shared location then perhaps we could do something like allow
vars in the builddir, like we allow vars in the install dirs. A patch to
do that shouldn't be too difficult if you'd like to have a go. See the
InstallDirs and path template stuff

Duncan

Re: hackage 2: alpha testing, testers wanted!

Duncan Coutts — 2013-04-15T14:46:04

Ta.


Great. So that was after I changed it to use 403.


I'll assume it was the changes I made rather than chrome changes. :-)

Duncan

Close to release candidate

Johan Tibell — 2013-04-12T16:55: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.

Re: hackage 2: alpha testing, testers wanted!

Lennart Kolmodin — 2013-04-10T19:58:57

2013/4/5 Duncan Coutts <duncan< at >well-typed.com>


I just tried again, and it worked. Now I also upgraded the account. I tried
again to login to the upgraded account, it worked.

I was using Chrome 26 when I tried to login a few days ago, now I'm using
Chrome 27.

install --builddir

Benjamin Scarlet — 2013-04-09T12:46:52

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 u

patch applied (hackage-server): "Remove the basic html package pagesfrom the core and candidate features" and 4 others

2013-04-08T21:55:52

Fri Mar 29 18:14:30 GMT 2013  Duncan Coutts <duncan< at >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< at >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

Cabal sandbox and rebuild of added sources

Daniel Trstenjak — 2013-04-07T20:05:40

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

Re: Cabal sandbox and rebuild of added sources

Mikhail Glushenkov — 2013-04-08T14:46:34

Hi,

On Sun, Apr 7, 2013 at 10:05 PM, Daniel Trstenjak
<daniel.trstenjak< at >gmail.com> wrote:

Good point. It makes sense to reinstall add-source dependencies if "."
is one of the targets. Filed an issue:
https://github.com/haskell/cabal/issues/1265