On Tue, Nov 20, 2012 at 1:10 PM, Gregory Guthrie guth...@mum.edu wrote:
Hmm,
Now when I tried to run Leksah, I get not only some broken packages (which
I can avoid for my current project), but:
** **
command line: cannot satisfy -package-id
I have a dream of one day being able to install leksah without having
to downgrade ghc. Right now I can't even install cabal-dev with cabal.
It will break ghc if I do.
2012/11/20 Johan Tibell johan.tib...@gmail.com:
On Tue, Nov 20, 2012 at 1:10 PM, Gregory Guthrie guth...@mum.edu wrote:
Hmm,
On 12-11-20 05:37 PM, Gregory Guthrie wrote:
No; the first sentence says that someone else had reported that testing on
Windows was hard to do because of (a perceived) lack of access to Windows by
Haskell developers... The implication is that Haskell developers (only/mainly)
use *nix.
I
On Tue, Nov 20, 2012 at 5:14 PM, Albert Y. C. Lai tre...@vex.net wrote:
On 12-11-20 05:37 PM, Gregory Guthrie wrote:
No; the first sentence says that someone else had reported that testing
on Windows was hard to do because of (a perceived) lack of access to
Windows by Haskell developers...
Why not? Either way, I am chiming in as a programmer of many years. Unless
using osx I stick with windows to avoid half-day forays into nettling
technical issues that are not related to the work I am paid to perform. I
would love for Haskell to work better there.
On Nov 20, 2012 5:21 PM, Johan
On 12-11-20 08:20 PM, Johan Tibell wrote:
This logic is flawed. More than 90% of computers having Windows doesn't
imply that 90% of all computers in a given household runs Windows.
What's the probability that your household has a Windows computer if
you're a programmer that don't live with your
On Tue, Nov 20, 2012 at 5:34 PM, Albert Y. C. Lai tre...@vex.net wrote:
This counter-argument is flawed. Why limit oneself to one's own household?
(Garage? Basement?) Get out more! Visit a friend. Talk to an internet cafe
owner for a special deal to run one's own programs. Rent virtual machine
Albert Y. C. Lai wrote:
Clearly, since 90% of computers have Windows, it should be trivial to
find one to test on, if a programmer wants to. Surely every programmer
is surrounded by Windows-using family and friends? (Perhaps to the
programmer's dismay, too, because the perpetual I've got a
Albert Y. C. Lai wrote:
This counter-argument is flawed. Why limit oneself to one's own
household? (Garage? Basement?) Get out more! Visit a friend.
If that friend is not a coder, they are unlikely to have the dev tools
installed.
Talk to an
internet cafe owner for a special deal to run
+1 to this. The friction of finding, setting up, and using Windows isn't
even comparable to just sshing into another unix box and testing something
quickly.
As a university student, I also find it relatively rare that I get to test
on a Windows machine. My personal computer runs linux, my
I follow the Cabal-messes threads with some interest, since that is the hardest
area for me since starting to use Haskell. Probably 40-60% of all package
install fail for some mysterious reason, with threats that trying to fix them
will break more things, which generally is true. :-)
I am not
Hi Greg,
On Mon, Nov 19, 2012 at 1:25 PM, Gregory Guthrie guth...@mum.edu wrote:
I follow the Cabal-messes threads with some interest, since that is the
hardest area for me since starting to use Haskell. Probably 40-60% of all
package install fail for some mysterious reason, with threats that
cabal install -v cabal-install
Not sure if you're running into this one, but a configuration that
wasn't working for me:
1) Install Haskell Platform
2) Install GHC 7.6.1
3) cabal install cabal-install
As I recall, the error had something to do with a Cabal-generated
'Paths' file assuming the
On Mon, Nov 19, 2012 at 2:55 PM, Greg Fitzgerald gari...@gmail.com wrote:
cabal install -v cabal-install
Not sure if you're running into this one, but a configuration that
wasn't working for me:
1) Install Haskell Platform
2) Install GHC 7.6.1
3) cabal install cabal-install
As I
I did a package check, and I always get a ton of these things:
Warning: haddock-html: E:\Plang\Haskell
Platform\lib\extralibs\doc\haskell-src-1.0.1.4\html doesn't exist or isn't a
directory
Which I think is just missing documentation, so I ignore them.
But this time I also got this:
The
Subject: Re: [Haskell-cafe] Cabal failures...
I'm not quite sure what's going on. I've CCed Andres, who wrote the new
constraint solver.
One especially confusing part is this:
C:\Users\guthrie\AppData\Local\Temp\Cabal-1.16.0.3-12392\Cabal-1.16.0.3\dist\set
up\setup.exe
configure --verbose=2 --ghc
On 12-11-19 04:25 PM, Gregory Guthrie wrote:
I am not exert in the area, but I wonder how /why/ this is different than other
package managers, like apt in Linux, I have never had any problems with it, and
I would think that their dependencies are of at least similar complexities.
I feel very
Hi all,
I've created bug fix release candidates for Cabal and cabal-install to
address the bugs found after the release. If everyone could take some
time to try them out, especially those who had issues with the
previous releases. To install the release candidates run:
cabal install
On Mon, Oct 15, 2012 at 7:16 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi all,
I've created bug fix release candidates for Cabal and cabal-install to
address the bugs found after the release.
Here's the list of fixed bugs:
Fixed since cabal-install-1.16.0:
* Fix installing from custom
Hi Johan,
On Mon, Oct 15, 2012 at 10:18 PM, Johan Tibell johan.tib...@gmail.com wrote:
Fixed since Cabal-1.16.0.1:
* Fixed warnings on the generated Paths module. The warnings are
generated by the flag '-fwarn-missing-import-lists'.
I tested this issue with Cabal-1.16.0.2 and the issue was
Hello,
I'm trying to understand Cabal dependencies.
Why does the following situation happen?
# cabal install xmobar --dry-run
Resolving dependencies...
In order, the following would be installed:
parsec-3.1.3 (reinstall) changes: mtl-2.1.1 - 2.0.1.0
xmobar-0.15 (new package)
Warning: The
On Sat, 2012-10-06 at 17:02 +0200, José Lopes wrote:
Hello,
Hello
I'm trying to understand Cabal dependencies.
Why does the following situation happen?
xmobar-0.15 depends on mtl-2.0.* and needs parsec
All packages that will be broken, depends on parsec.
But parsec is compiled with
OK.
But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
parsec to use mtl-2.1.1, while xmobar would use this parsec version?
In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are
considered two different libraries.
Thanks,
José
On 06-10-2012 17:17, Yuras Shumovich
On 6 October 2012 17:25, José Lopes jose.lo...@ist.utl.pt wrote:
OK.
But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for parsec to
use mtl-2.1.1, while xmobar would use this parsec version?
In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are considered
two different
On Sat, 2012-10-06 at 18:25 +0200, José Lopes wrote:
OK.
But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
parsec to use mtl-2.1.1, while xmobar would use this parsec version?
In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are
considered two different
OK. Got it!
Do you have any suggestions to install xmobar in this particular case?
Thanks,
José
On 06-10-2012 19:08, Yuras Shumovich wrote:
On Sat, 2012-10-06 at 18:25 +0200, José Lopes wrote:
OK.
But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
parsec to use mtl-2.1.1,
On Sat, 2012-10-06 at 22:40 +0200, José Lopes wrote:
OK. Got it!
Do you have any suggestions to install xmobar in this particular case?
In case of executables I usually rm -rf ~/.ghc, cabal install,
and rm -rf ~/.ghc again. Executables are still here (in ~/.cabal/bin),
but all libraries are
Thanks!
On 06-10-2012 23:07, Yuras Shumovich wrote:
On Sat, 2012-10-06 at 22:40 +0200, José Lopes wrote:
OK. Got it!
Do you have any suggestions to install xmobar in this particular case?
In case of executables I usually rm -rf ~/.ghc, cabal install,
and rm -rf ~/.ghc again. Executables are
Do you have any suggestions to install xmobar in this particular case?
In case of executables I usually rm -rf ~/.ghc, cabal install,
and rm -rf ~/.ghc again. Executables are still here (in ~/.cabal/bin),
but all libraries are lost. Warning: it may break your development
environment, so make
On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan b...@serpentine.com wrote:
On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan b...@serpentine.com
wrote:
The reason you're seeing build breakage is that the .cabal files of the
broken packages were edited in-place without communicating with
On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan
b...@serpentine.com
wrote:
Not to flog a dead horse, but:
...
Not to flog a dead horse, but:
All our builds broke again yesterday due to this bug. The package was
On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan b...@serpentine.comwrote:
The reason you're seeing build breakage is that the .cabal files of the
broken packages were edited in-place without communicating with any of the
package authors.
Not to flog a dead horse, but:
Just yesterday we
On Mon, Jul 30, 2012 at 3:33 PM, Ross Paterson r...@soi.city.ac.uk wrote:
On Mon, Jul 30, 2012 at 01:46:24PM +0100, Niklas Broberg wrote:
On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson r...@soi.city.ac.uk wrote:
As I understand it, the plan is to modify the following packages in
On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink hessel...@gmail.com wrote:
I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again?
Hang on a second.
The reason you're seeing build breakage is that the .cabal files of the
broken packages were edited in-place without
On Mon, Aug 27, 2012 at 7:52 PM, Bryan O'Sullivan b...@serpentine.com wrote:
On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink hessel...@gmail.com wrote:
I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it
again?
Hang on a second.
The reason you're seeing build breakage is
On Mon, Aug 27, 2012 at 10:52:59AM -0700, Bryan O'Sullivan wrote:
On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink hessel...@gmail.com wrote:
I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again?
Hang on a second.
The reason you're seeing build breakage is that
On Mon, Aug 27, 2012 at 07:39:39PM +0100, Erik Hesselink wrote:
If we do agree that we want to prevent this problem for a while (which
I'm not sure about), we should probably do it by preventing uploads
for packages like this. That way, package maintainers will know what
is going on, just like
On Mon, Aug 27, 2012 at 09:03:18PM +0100, Brent Yorgey wrote:
On Mon, Aug 27, 2012 at 10:52:59AM -0700, Bryan O'Sullivan wrote:
On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink hessel...@gmail.com wrote:
I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it
again?
On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink hessel...@gmail.comwrote:
Yes, you are right. So the question is how long to support systems
with the old cabal 0.10. This is the one included with the previous
haskell platform (and thus lots of linux distro's), which is less than
a year old.
On Mon, Aug 27, 2012 at 4:23 PM, Bryan O'Sullivan b...@serpentine.comwrote:
On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink hessel...@gmail.comwrote:
Yes, you are right. So the question is how long to support systems
with the old cabal 0.10. This is the one included with the previous
Well, this one looks like it was my fault because I never read this thread
and this morning I uploaded that package (abstract-deque) with the
conditional in the test-suite. The reason this conditional isn't there now
is that the package was hacked in place to remove tests, which is fine.
On Aug 27, 2012 8:40 PM, Erik Hesselink hessel...@gmail.com wrote:
The other question is how useful test suites in a released package
are. Aren't they much more useful (and used more often) in source
repositories?
Having tests available in a released package allows one to verify that the
On 8/27/12 6:27 PM, Tristan Seligmann wrote:
On Aug 27, 2012 8:40 PM, Erik Hesselink hessel...@gmail.com wrote:
The other question is how useful test suites in a released package
are. Aren't they much more useful (and used more often) in source
repositories?
Having tests available in a
Hi café,
I am successfully using a custom preprocessor to build my main
executable. In particular, I am using UUAGC to preprocess .ag files
into .hs files. My Setup.hs file uses 'uuagcLibUserHook' from the
package uuagc-cabal to do this, which in particular overrides Cabal's
'buildHook' for me.
On Sun, Aug 26, 2012 at 12:40 PM, Iain Nicol i...@thenicols.net wrote:
Hi café,
I am successfully using a custom preprocessor to build my main
executable. In particular, I am using UUAGC to preprocess .ag files
into .hs files. My Setup.hs file uses 'uuagcLibUserHook' from the
package
Johan Tibell wrote:
On Sun, Aug 26, 2012 at 12:40 PM, Iain Nicol i...@thenicols.net wrote:
Does anybody know if Cabal actually supports using custom
preprocessors for building a test-suite? If so, is 'buildHook' still
the right hook to override?
Try overriding the test hook.
Bleh; that's
On Sun, Aug 26, 2012 at 1:03 PM, Iain Nicol i...@thenicols.net wrote:
Johan Tibell wrote:
On Sun, Aug 26, 2012 at 12:40 PM, Iain Nicol i...@thenicols.net wrote:
Does anybody know if Cabal actually supports using custom
preprocessors for building a test-suite? If so, is 'buildHook' still
the
Of course! I will have a play this weekend. Thanks for the advice.
On Aug 3, 2012 10:45 PM, Nathan Howell nathan.d.how...@gmail.com wrote:
On Fri, Aug 3, 2012 at 2:35 PM, Benjamin Edwards edwards.b...@gmail.com
wrote:
I am struggling to get ctags and / or haskell mode to work with
cabal-dev.
Hello Café,
I am struggling to get ctags and / or haskell mode to work with cabal-dev.
This is quite annoying. Has anyone worked around this?
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Fri, Aug 3, 2012 at 2:35 PM, Benjamin Edwards edwards.b...@gmail.com wrote:
I am struggling to get ctags and / or haskell mode to work with cabal-dev.
This is quite annoying. Has anyone worked around this?
I use ghc-mod for vim and it sorta supports this... by adding
arbitrary flags to GHC
On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson r...@soi.city.ac.uk wrote:
As I understand it, the plan is to modify the following packages in
hackage in-situ to remove the test sections (which contain the troublesome
conditionals):
HUnit-1.2.5.0
bloomfilter-1.2.6.10
codemonitor-0.1
On Mon, Jul 30, 2012 at 01:46:24PM +0100, Niklas Broberg wrote:
On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson r...@soi.city.ac.uk wrote:
As I understand it, the plan is to modify the following packages in
hackage in-situ to remove the test sections (which contain the troublesome
On Fri, Jul 20, 2012 at 10:02:18AM +0100, Ross Paterson wrote:
On Fri, Jul 20, 2012 at 09:34:16AM +0100, Simon Hengel wrote:
Hi Ross,
can you fix this on Hackage? My suggested solution is to again just
remove the test-suite sections from the cabal file, if that is fine with
Richard.
On Wed, Jul 25, 2012 at 09:43:48AM +0100, Simon Hengel wrote:
On Fri, Jul 20, 2012 at 10:02:18AM +0100, Ross Paterson wrote:
On Fri, Jul 20, 2012 at 09:34:16AM +0100, Simon Hengel wrote:
Hi Ross,
can you fix this on Hackage? My suggested solution is to again just
remove the test-suite
On Mon, Jul 23, 2012 at 12:51:32PM -0500, Stephen Paul Weber wrote:
Currently you would have to do the upgrade manually, as `cabal-install
cabal-install` won't work (or alternatively edit your local
~/.cabl/packages/hackage.haskell.org/00-index.tar).
Pending a fix on hackage (hopefully)
On Monday, July 23, 2012, Simon Hengel wrote:
On Mon, Jul 23, 2012 at 12:51:32PM -0500, Stephen Paul Weber wrote:
Currently you would have to do the upgrade manually, as `cabal-install
cabal-install` won't work (or alternatively edit your local
Hi Ross,
can you fix this on Hackage? My suggested solution is to again just
remove the test-suite sections from the cabal file, if that is fine with
Richard.
The current situation is unfortunate, as it breaks almost all installs
from Hackage with cabal-install 0.10.2 / Cabal 1.10.1.0, e.g. you
Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with
Cabal-1.14.0) should fix the problem.
Currently you would have to do the upgrade manually, as `cabal-install
cabal-install` won't work (or alternatively edit your local
~/.cabl/packages/hackage.haskell.org/00-index.tar).
See my other
On Fri, Jul 20, 2012 at 09:34:16AM +0100, Simon Hengel wrote:
Hi Ross,
can you fix this on Hackage? My suggested solution is to again just
remove the test-suite sections from the cabal file, if that is fine with
Richard.
I'll modify the packages in-place if there's a consensus on what to do.
On Wed, Jul 18, 2012 at 05:51:51PM -0600, Richard G. wrote:
What's the best way to fix this? I can see two options:
- Move the test stanzas to a different Cabal file, allowing users to
perform the tests with a little fiddling.
- Remove the conditional statements from the test stanzas, which
Hi all,
All cabal installs using cabal-install-0.10.2 are currently failing
for us. This is due to the cabal file for HUnit-1.2.5.0, which was
recently uploaded to hackage. The ouput I'm getting from cabal is
just:
Reading available packages...
Resolving dependencies...
cabal: Couldn't read
Hi Erik,
A similar thing happened to me with the GraphViz package. As Duncan
explained to me, the problem is that Cabal-1.10.0.0 (and I believe also
1.10.1.0) incorrectly reports an error when conditionals are used in
test suites.
Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with
Hi Martijn,
Yes, upgrading will obviously fix things (we do use 0.14 on our
development machines), but we have not set up any infrastructure for
building a custom cabal on production servers. We just use the one
from the Ubuntu repositories, which uses Cabal 1.10.1.0 on oneiric. So
until we
On 18-07-12 17:37, Erik Hesselink wrote:
Hi Martijn,
Yes, upgrading will obviously fix things (we do use 0.14 on our
development machines)
Well, to me it wasn't entirely obvious that upgrading to Cabal-1.10.2.0
fixes the problem for cabal-install-0.12, and I still think this is a
good
CCing: Ross Paterson and Richard G.
On Wed, Jul 18, 2012 at 05:54:44PM +0200, Martijn Schrage wrote:
On 18-07-12 17:37, Erik Hesselink wrote:
Hi Martijn,
Yes, upgrading will obviously fix things (we do use 0.14 on our
development machines)
Well, to me it wasn't entirely obvious that
On Wed, Jul 18, 2012 at 05:16:19PM +0100, Simon Hengel wrote:
CCing: Ross Paterson and Richard G.
On Wed, Jul 18, 2012 at 05:54:44PM +0200, Martijn Schrage wrote:
On 18-07-12 17:37, Erik Hesselink wrote:
Hi Martijn,
Yes, upgrading will obviously fix things (we do use 0.14 on our
When using make (or, at least, GNU make) the -k option keeps going
as far as possible after a compilation error. It's handy during
developing--for instance, I know half of my code is busted, but I
just want to see if this file compiles. Is there a similar way to do
this with cabal? Thanks. --Omari
Hi,
the package http://hackage.haskell.org/package/haskelldb-hdbc-mysql/ the
use of HDBC 2.3.0
I'm using cabal-install 0.14, and with a fresh install (no packages already
installed), cabal-install tries to install HDBC-2.1.1 instead of, say,
HDBC-2.2.7.0.
The problem is that HDBC-2.1.1 is old
On Wed, Jul 4, 2012 at 3:58 PM, Yves Parès yves.pa...@gmail.com wrote:
Hi,
the package http://hackage.haskell.org/package/haskelldb-hdbc-mysql/ the use
of HDBC 2.3.0
I'm using cabal-install 0.14, and with a fresh install (no packages already
installed), cabal-install tries to install
On 12-07-04 10:58 AM, Yves Parès wrote:
the package http://hackage.haskell.org/package/haskelldb-hdbc-mysql/ the
use of HDBC 2.3.0
I'm using cabal-install 0.14, and with a fresh install (no packages
already installed), cabal-install tries to install HDBC-2.1.1 instead
of, say, HDBC-2.2.7.0.
Hello all!
I trust tried to install yesod using cabal install yesod-platform but the
installation aborted with the following error:
cabal: Error: some packages failed to install:
authenticate-1.2.1.1 depends on zlib-conduit-0.4.0.2 which failed to
install.
http-conduit-1.4.1.10 depends on
Hello Eric,
most packages fail to install because zlib-conduit fails to install.
The reason for this -- as can be seen in the last line -- is that the
tar archive from which the source is extracted is corrupted. Simply
run cabal install to try again. I suspect the source archives are
I tried running cabal install again, but just got the same error.
On Mon, Jul 2, 2012 at 10:34 PM, Alexander Foremny
alexanderfore...@gmail.com wrote:
Hello Eric,
most packages fail to install because zlib-conduit fails to install.
The reason for this -- as can be seen in the last line --
Apparently package archives are retained by cabal.
Try deleting ~/.cabal/packages/hackage.haskell.org/zlib-conduit-0.4.0.2.tar.gz
and try again.
Regards
Alexander Foremny
2012/7/3 Eric Macaulay elihul...@gmail.com:
I tried running cabal install again, but just got the same error.
On Mon,
Hi all,
I tried to install reactive-banana. This failed due to a dependency conflict,
and then I noticed there was a newer version of reactive-banana. So I did cabal
update, and tried to install again. But whatever I do, cabal keeps trying to
install fclabels, but fclabels is no longer a
Hi.
I tried to install reactive-banana. This failed due to a dependency conflict,
and then I noticed there was a newer version of reactive-banana. So I did
cabal update, and tried to install again. But whatever I do, cabal keeps
trying to install fclabels, but fclabels is no longer a
On 12-06-27 11:29 AM, Sjoerd Visscher wrote:
I tried to install reactive-banana. This failed due to a dependency conflict,
and then I noticed there was a newer version of reactive-banana. So I did cabal
update, and tried to install again. But whatever I do, cabal keeps trying to
install
Ah, ok. I wasn't aware how flags work in Cabal, thanks.
Makes me wonder why that flag was turned off on hackage.
http://hackage.haskell.org/package/reactive-banana
On Jun 27, 2012, at 5:51 PM, Andres Löh wrote:
Hi.
I tried to install reactive-banana. This failed due to a dependency
Hi.
On Wed, Jun 27, 2012 at 6:14 PM, Sjoerd Visscher sjo...@w3future.com wrote:
Ah, ok. I wasn't aware how flags work in Cabal, thanks.
Makes me wonder why that flag was turned off on hackage.
http://hackage.haskell.org/package/reactive-banana
I'm not sure it was turned off. I see that it
Given that I have the dependant packages already installed when I do
$ cabal install --dry-run --global buildwrapper Resolving dependencies... In
order, the following would be installed: mtl-2.1.1 (new version) aeson-0.6.0.2
(reinstall) changes: mtl-2.0.1.0 - 2.1.1 parsec-3.1.2 (reinstall)
Have solved the issue with help from JP Moresmau.
Used the command
cabal install --dry-run --verbose=3 --global build wrapper
And this gave enough detailed info to enable me to remove the conflict and
resolve the issue.
Thanks goes to JP !
On Wednesday, 9 May 2012 at 09:55, Graham Berks
Hi Cafe,
today I opened the command prompt and typed cabal install ftphs. Then I
read:
Resolving dependencies...
Configuring network-2.3.0.5...
And I started to feel confused. Because I already have installed that
package with that version! I continued reading:
cabal: The package has a
Hello Daniel,
Did you perhaps install a newer version of bytestring or parsec?
Jeff
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Indeed, it seems to be for parsec:
? ghc-pkg latest bytestring
bytestring-0.9.1.10
? ghc-pkg latest parsec
parsec-3.1.2
Haskell Platform versions: bytestring-0.9.1.10, parsec-3.1.1.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I have spent some time and, when I unregistered (with ghc-pkg unregister)
all dependencies (even indirect dependencies) I have installed since I have
the Haskell Platform, then the cabal install ftphs worked.
Now I feel I understand the problem, but still seems annoying.
Thanks for the pointer,
On Mar 16, 2012 3:12 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com
wrote:
On 17 March 2012 09:02, Erik de Castro Lopo mle...@mega-nerd.com wrote:
Ivan Lazar Miljenovic wrote:
One trivial solution is to assume ~/.cabal/bin is on the PATH and to
ignore system-wide packages, which I
Hi all,
With a base system with just ghc and cabal-install, if I try to install
bytestring-lexing I get:
$ cabal install bytestring-lexing
Resolving dependencies...
Configuring bytestring-lexing-0.4.0...
cabal: The program alex version =2.3 is required but it could not be found.
Hi,
Am Freitag, den 16.03.2012, 21:00 +1100 schrieb Erik de Castro Lopo:
With a base system with just ghc and cabal-install, if I try to install
bytestring-lexing I get:
$ cabal install bytestring-lexing
Resolving dependencies...
Configuring bytestring-lexing-0.4.0...
Joachim Breitner wrote:
no, cabal-install does not automatically install build-tools at all,
only Cabal checks them for compilation. I guess the reason is that
build-tools needs to be put on the PATH, and that is beyond the scope of
cabal-install.
This is rather sub-optimal.
One place where
On 16 March 2012 21:56, Erik de Castro Lopo mle...@mega-nerd.com wrote:
Joachim Breitner wrote:
no, cabal-install does not automatically install build-tools at all,
only Cabal checks them for compilation. I guess the reason is that
build-tools needs to be put on the PATH, and that is beyond
Alex is supplied as part of the Platform though which is the
recommended system for beginners, is Yesod currently in advance of the
Platform?
On 16 March 2012 10:56, Erik de Castro Lopo mle...@mega-nerd.com wrote:
The problem is that many of the people trying out Yesod are newcomers to
The Yesod docs all state very explicitly that we depend on the Haskell
Platform, and in particular that alex needs to be installed. However,
that doesn't stop this issue from confusing people.
I think a good short term solution could be what Alan Zimmerman did
with language-javascript: include
On 3/16/12 6:00 AM, Erik de Castro Lopo wrote:
Hi all,
With a base system with just ghc and cabal-install, if I try to install
bytestring-lexing I get:
$ cabal install bytestring-lexing
Resolving dependencies...
Configuring bytestring-lexing-0.4.0...
cabal: The program
Ivan Lazar Miljenovic wrote:
One trivial solution is to assume ~/.cabal/bin is on the PATH and to
ignore system-wide packages, which I think is even *more* sub-optimal
(why install a new version of alex when it's already available?).
The tool should only install alex in ~/.cabal/bin if alex
On 17 March 2012 09:02, Erik de Castro Lopo mle...@mega-nerd.com wrote:
Ivan Lazar Miljenovic wrote:
One trivial solution is to assume ~/.cabal/bin is on the PATH and to
ignore system-wide packages, which I think is even *more* sub-optimal
(why install a new version of alex when it's already
Hi all,
I've recently started to move my tests to use the new cabal test-suite
framework.
Old setup:
The cabal file compiles one library + a few executables. The library
contains almost all of the code and exposes the necessary modules for use
by the executables. The executables mainly consist
On Tue, Mar 13, 2012 at 11:16 AM, Ozgur Akgun ozgurak...@gmail.com wrote:
While waiting for a build to finish [ :) ], I just wanted to write an email
and check if this is intentional or only an oversight. Or maybe a technical
limitation for the time being?
If your library code and test code
On 13 March 2012 16:22, Antoine Latter aslat...@gmail.com wrote:
If your library code and test code are in separate sub-directories and
you reference your library as a package dependency for your test then
Cabal won't re-build your library.
Yay! That was it. Thanks.
Somehow I altered the
Alan Pogrebinschi alan...@gmail.com writes:
That Cabal-1.10.1.0 bug seems to be back, now with bytestring-0.9.2.1
just uploaded to hackage.
Thanks for the link! I was banging my head on against the virtual wall,
since all I'm getting is:
% cabal install -v biopsl
Reading
Same workaround as last time works
I.e:
tar -f ~/.cabal/packages/hackage.haskell.org/00-index.tar --delete
bytestring/0.9.2.1
This will only work until the next 'cabal update', right? Does anyone
have a better workaround?
This is the cabal-install shipped with Ubuntu 12.04 (i.e. the
101 - 200 of 913 matches
Mail list logo
