Am 22.11.2010 23:16, schrieb Permjacov Evgeniy:
> current cabal-install (0.8.2) cannot be compiled with ghc-7.0.1 set of
> boot libraries. It requires cabal 1.8.* wich fails to compile. Does
> anyone worked this out ?
You can re-use your old cabal binary (if you still have it) that was
compiled wi
At 2010-09-22T16:11:34+10:00, Ivan Lazar Miljenovic wrote:
> So remove the -- from the front of the line to get it working.
Thanks very much. That works. I'd read the header in the config file
which said that lines beginning with `--' were comments, but somehow
missed uncommenting the line I wa
On Fri, Aug 20, 2010 at 7:14 AM, Johan Tibell wrote:
> On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann <
> waldm...@imn.htwk-leipzig.de> wrote:
>
>> Of course I understand "lack of developer time".
>> Could any of this be forked out as student projects?
>>
>
> These kind of projects are perfect
Johannes Waldmann imn.htwk-leipzig.de> writes:
> I will teach a course (Sept. - Jan.)
noh, it's Oct. - Jan.
otherwise it'd be too much of a good thing ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listin
> Could any of this be forked out as student projects?
I will teach a course (Sept. - Jan.) that introduces Haskell
(students know Java). Part of the coursework is a programming project.
I could assign some cabal tickets - but perhaps that's a bit far-fetched
(requires understanding of the ghc in
Johannes Waldmann writes:
> Daniel Fischer web.de> writes:
>
>> The problem is that otherpackages may depend on them too, so when cabal
>> automatically reinstalls, those can break.
>
> how can this be - if the re-installed package is compiled
> from the exact original source (as I just learne
On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann <
waldm...@imn.htwk-leipzig.de> wrote:
> Of course I understand "lack of developer time".
> Could any of this be forked out as student projects?
>
These kind of projects are perfect for Google Summer of Code. We had two
Cabal projects this year (
Daniel Fischer web.de> writes:
> The problem is that otherpackages may depend on them too, so when cabal
> automatically reinstalls, those can break.
how can this be - if the re-installed package is compiled
from the exact original source (as I just learned, cabal stores the sources)?
or do y
On Mon, 2009-11-09 at 16:02 +, Michael Fan wrote:
> I figured it out. It appears to be "Colour" package specific.
> The datadir still point to "c:\Program File" even with --user.
> I manually edit the dist/setup-config and get Colour installed.
> After that, other packages seem working fine.
>
I figured it out. It appears to be "Colour" package specific.
The datadir still point to "c:\Program File" even with --user.
I manually edit the dist/setup-config and get Colour installed.
After that, other packages seem working fine.
Jian Fan wrote:
> Does cabal install --user or --prefix work o
> Is there any %LOCALAPPDATA% on Windows XP? If not, what is the
> difference between %LOCALAPPDATA% and %APPDATA% in Windows Vista/7?
XP does not define the %LOCALAPPDATA% environment variable, but it is
equivalent to %USERPROFILE%\Local Settings\Application Data.
Data in local application data
Hello,
On Sat, Mar 07, 2009 at 05:51:56PM -0800, Ahn, Ki Yung wrote:
> I sometimes clean up .ghc and .cabal in my home directory to start from
> scratch because of dependency loopholes (cabal-install does not have
> remove option yet, so it's hard to fix when such loophole happens).
You may use g
Ahn, Ki Yung 쓴 글:
> Dear Haskellers and especially who are working on cabal-install
> and debian packaging,
>
> I sometimes clean up .ghc and .cabal in my home directory to start from
> scratch because of dependency loopholes (cabal-install does not have
> remove option yet, so it's hard to fix wh
On Mon, 2008-11-24 at 15:16 +0100, Thomas Hartman wrote:
> I have run into another issue with cabal packaging, which seems
> related to the issues discussed above. (see attached tar file for
> complete example of failure scenario)
>
> If I have a cabal package that depends on two other packages
>
Don Stewart wrote:
> [...]
>
> Note that packages that depend on the 'experimental' versions of things
> (in particular Haxml 1.19.* can't be packaged for Arch either, as we can
> only install one version of the haskell-haxml package).
In this case we definetely need haxml-1.19. IIRC we even comm
deduktionstheorem:
> Thomas Hartman wrote:
> > When I specify
> >
> > Build-Depends: base, parsec, HaXml >= 1.19.4
> >
> > in xml-parsec.cabal
> >
> > it does install correctly.
>
> I just fixed xml-parsec.cabal and uploaded it on hackage:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/p
On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote:
> This is all news to me, and un-googleable to boot:
>
> http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1
>
> (no results)
It finds something for me (with the right spelling of prefe
Thomas Hartman wrote:
> When I specify
>
> Build-Depends: base, parsec, HaXml >= 1.19.4
>
> in xml-parsec.cabal
>
> it does install correctly.
I just fixed xml-parsec.cabal and uploaded it on hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3
>
> [...]
>
/
This is all news to me, and un-googleable to boot:
http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1
(no results)
So yes, I think this referred-versions machinery should at least be
made more transparent for situations when it does the wron
On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote:
> When I specify
>
> Build-Depends: base, parsec, HaXml >= 1.19.4
>
> in xml-parsec.cabal
>
> it does install correctly.
Yes, saying what version it needs is a good thing. It's all guesses
otherwise.
> I guess what happens is that cabal
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
I guess what happens is that cabal install takes the earliest version
of a package registered to try to build. I guess that's a reasonable
default.
What seems unreasonable to me is that
I just noticed this is also reported as a 6.8 build failure on hackage itself.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-hsp-template
2008/6/2 Thomas Hartman <[EMAIL PROTECTED]>:
> Can cabal install be made to work for this package?
> *
> [EMAIL PROTECTED]:~>sudo cabal
On Wed, 2007-11-28 at 21:00 +0100, Thomas Schilling wrote:
> On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote:
> > [EMAIL PROTECTED]: .../software/haskell > cd cabal
> > [EMAIL PROTECTED]: .../haskell/cabal > runhaskell Setup.lhs configure
> >
> > Distribution/Simple/NHC.hs:77:1: lexical err
On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote:
> Don Stewart wrote:
> > ben.franksen:
> >> cabal: dist/Conftest.c: openFile: does not exist (No such file or
> >> directory)
> >
> > This one is due to having an out of date cabal. Upgrade to darcs cabal,
> > then rebuild cabal-install, and t
Don Stewart wrote:
> ben.franksen:
>> cabal: dist/Conftest.c: openFile: does not exist (No such file or
>> directory)
>
> This one is due to having an out of date cabal. Upgrade to darcs cabal,
> then rebuild cabal-install, and things should go fine.
Ok. So the package is broken in that it doesn'
25 matches
Mail list logo
