Hi Magnus,
How does a distro get to be added like that?
check out http://hackage.haskell.org/trac/hackage/ticket/570.
Take care,
Peter
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
This is the easiest way conceptually. You can also try to --reinstall every
package that 'ghc-pkg check' report is broken. If you pick up the right
version and compilation options will match there is a high chance you can
fix this state. I've done this before and it worked.
Best regards,
I started that way but quickly ran into issues about compilers
toolchain for certain packages: I am on windows and some core packages
require mingw toolchain.
2011/2/1 Krzysztof Skrzętnicki gte...@gmail.com:
This is the easiest way conceptually. You can also try to --reinstall every
package
AFAIK GHC on Windows comes with it's own mingw, but I'm not sure if the
toolchain is complete. But I wouldn't try to reinstall core packages anyway.
They are best picked from installation package.
Best regards,
Krzysztof Skrzętnicki
2011/2/1 Arnaud Bailly arnaud.oq...@gmail.com
I started that
On Tue, Feb 1, 2011 at 1:16 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote:
Hi,
Thanks for your answers.
I did
cabal upgrade yesod
As for the user/global issue, I think I tried a user install, this is
default isn't it?
Looks like I will have to reinstall everything :-(
Well, since you
That's what my experience tell me :-)
I guess it is mainly my private packages that are screwed up. I will
first try moving this out of the way before reinstalling Haskell
Platform.
On Tue, Feb 1, 2011 at 1:41 PM, Antoine Latter aslat...@gmail.com wrote:
On Tue, Feb 1, 2011 at 1:16 AM, Arnaud
On Mon, Jan 31, 2011 at 11:16 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote:
Hi,
Thanks for your answers.
I did
cabal upgrade yesod
I think 'upgrade' is deprecated, and known to break things on occasion
(or at least have unexpected behavior--I'm not clear on the details).
You can use
On Monday 31 January 2011 23:59:57, Arnaud Bailly wrote:
Hello,
I recently tried to upgrade some package (eg. yesod) and it seems
that, in the process, I screwed up my Haskell packages setup.
Big time.
When I am trying to do a simple:
ghc --make Crete1941
It fails with message:
On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote:
Hello,
I recently tried to upgrade some package (eg. yesod) and it seems
that, in the process, I screwed up my Haskell packages setup.
When I am trying to do a simple:
ghc --make Crete1941
What command(s) did you
Hi,
Thanks for your answers.
I did
cabal upgrade yesod
As for the user/global issue, I think I tried a user install, this is
default isn't it?
Looks like I will have to reinstall everything :-(
Arnaud
On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote:
On Mon, Jan 31,
Andrew U. Frank fran...@geoinfo.tuwien.ac.at writes:
i try to use jsmw. i see that there are multiple example files in a
directory. this directory is not included in darcs and does not download
automatically. is there an easy way to download directories (i can get
the files individually with
On Thu, 2009-06-18 at 23:26 -0500, Vasili I. Galchin wrote:
Hello,
Haskell packages on Hackage can be hosted anywhere, yes?
Yes.
If a Haskell package is hosted on Hackage, how often is it
backed up?
It's not especially wise to rely on Hackage for your backup needs since
it
ok ... thx
On Sun, Jun 21, 2009 at 12:14 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk
wrote:
On Thu, 2009-06-18 at 23:26 -0500, Vasili I. Galchin wrote:
Hello,
Haskell packages on Hackage can be hosted anywhere, yes?
Yes.
If a Haskell package is hosted on Hackage, how
vigalchin:
Hello,
Haskell packages on Hackage can be hosted anywhere, yes?
If a Haskell package is hosted on Hackage, how often is it backed up?
Nightly.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
A reminder:
When I wanted to upgrade to yi 0.4.6.2, I needed to download the new package
list first
cabal update#download list of new packages
cabal upgrade #install newer versions of all packages
see cabal help upgrade for more, for upgrading a single package
cabal upgrade yi
Regards,
Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin:
[…]
2. If we already have a Cabal package, why do we also need seperate
packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
If I want to install gtk2hs on Debian, I’d like gtk (the C library) to be
automatically
Austin:
Of course, if you are doing haskell development, the best possible way
to go (IMO) full-blown cabal install since you will always get the
most up-to-date code
Let's say I go and compile a library from sources and install it through
Cabal.
How can I update the binary version of the
Excerpts from Cetin Sert's message of Tue Sep 23 05:55:21 -0500 2008:
Let's say I go and compile a library from sources and install it through
Cabal.
How can I update the binary version of the library Cabal installed after
recompiling the library using newer/modified sources?
I'm not quite
2008/9/23 Cetin Sert [EMAIL PROTECTED]:
Austin:
Let's say I go and compile a library from sources and install it through
Cabal.
How can I update the binary version of the library Cabal installed after
recompiling the library using newer/modified sources?
That should happen automatically
Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008:
That should happen automatically with cabal-install if the version
number in the .cabal file has changed.
There doesn't seem to be a good way of forcing cabal-install to
recreate a build (eg, if you want to
Does that answer your query?
Yep it does, ^__^ Thank you very much.
Cetin
2008/9/23 Austin Seipp [EMAIL PROTECTED]
Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008:
That should happen automatically with cabal-install if the version
number in the .cabal file has
Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
1. How is putting something into a Cabal package different from just
handing somebody the source code and telling them to run ghc --make?
Cabal can handle things for you like when your package depends on
external data
andrewcoppin:
Ivan Lazar Miljenovic wrote:
On Sat, 20 Sep 2008 23:38:16 -0700
Don Stewart [EMAIL PROTECTED] wrote:
And by now you know where which distro has it:
http://aur.archlinux.org/packages.php?ID=18343
I'm sorry, Don, but you're late... Gentoo had it last night
Austin Seipp wrote:
Cabal can handle things for you like when your package depends on
external data files; when cabal compiles the code it autogenerates a
module which you import that will give you the path name to where-ever
it is installed, which is nifty in case you for example are uploading
Has there ever been a discussion of typed, user-definable,
user-processable source code annotations for Haskell?
afair it was on haskell-prime list
http://hackage.haskell.org/trac/haskell-prime/ticket/88
if you can call that a discussion :-)
signature.asc
Description: OpenPGP digital
Am Dienstag, 9. September 2008 15:46 schrieb Sean Leather:
[…]
Testing non-exported functionality without exporting the test interface
seems difficult in general. Is there a way to hide part of a module
interface with Cabal? Then, you could have a 'test' function exported from
each module
Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott:
[…]
My current leaning is to split a package foo into packages foo
and foo-test
What benefit does this provide?
It keeps the library and its dependencies small.
Do you publish foo-test on Hackage? If yes than the
If I do foo and foo-test, then I would probably place foo-test on Hackage.
Alternatively, just give foo a pointer to the location of the foo-test darcs
repo location. But then it might not be easy for users to keep the versions
in sync.
On Wed, Sep 10, 2008 at 10:24 AM, Wolfgang Jeltsch
[EMAIL
Sean Leather wrote:
How do folks like to package up QuickCheck tests for their
libraries? In the main library? As a separate repo package?
Same repo separate package? Keeping tests with the tested code
allows testing of non-exported functionality, but can add quite a
Ketil Malde wrote:
Conal Elliott [EMAIL PROTECTED] writes:
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right.
Another option might be to have the test command build via 'ghc
--make' instead of Cabal - this way,
Sean Leather wrote:
My tests are making use of a nice console test runner I wrote that
supports both HUnit and QuickCheck (and is extensible to other test
providers by the user):
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
The description
2008/9/9 Conal Elliott [EMAIL PROTECTED]:
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite
On Tue, Sep 9, 2008 at 2:05 PM, Dougal Stanton [EMAIL PROTECTED] wrote:
If they're in a separate package it's less easy to wire quickcheck
tests into the commit procedure.
And by package there, I mean repo. Obviously ;-)
D
___
Haskell-Cafe mailing
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.
I have QuickCheck
Thanks, Sean.
On Tue, Sep 9, 2008 at 3:46 PM, Sean Leather [EMAIL PROTECTED] wrote:
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.
I have QuickCheck
Hi Sean.
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right. I have:
Flag test
Description: Enable testing
Default: False
And I get Warning: unamb.cabal: Unknown section type: flag ignoring
If I indent, I
Conal Elliott [EMAIL PROTECTED] writes:
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right.
Another option might be to have the test command build via 'ghc
--make' instead of Cabal - this way, you can avoid mentioning
2008/9/9 Conal Elliott [EMAIL PROTECTED]:
Hi Sean.
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right. I have:
Flag test
Description: Enable testing
Default: False
And I get Warning: unamb.cabal: Unknown
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right.
This is also my first time, so I'm not sure exactly what I'm doing right. ;)
I have:
Flag test
Description: Enable testing
Default: False
And I get
My tests are making use of a nice console test runner I wrote that
supports both HUnit and QuickCheck (and is extensible to other test
providers by the user):
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
The description looks great! I might have to try it out.
2008/9/9 Conal Elliott [EMAIL PROTECTED]:
Where do you like to place your tests? In the functionality modules? A
parallel structure? A single Test.hs file somewhere?
The last time I had a chance to experiment with how to do this I used
a single Test.hs for the whole project and I think that
2008/9/9 Sean Leather [EMAIL PROTECTED]:
My tests are making use of a nice console test runner I wrote that
supports both HUnit and QuickCheck (and is extensible to other test
providers by the user):
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
The description
Jason Dagit wrote:
On the other hand, specifying tests was
as simple as starting a function name with prop_ [...]
which of course reminds us of JUnit of the dark ages (up to 3.8),
before they finally used annotations to declare test cases.
Has there ever been a discussion of typed,
On Thu, 27 Sep 2007, bbrown wrote:
If I have a set of haskell code and I create a directory with the source that
has the following imports.
(some_dir/MyLib.hs)
module MyLib where
And then I want to use that set of code at the top level directory, eg:
MyTest.hs
import MyLib
How would I
On Thu, Sep 27, 2007 at 06:10:37PM -0400, bbrown wrote:
If I have a set of haskell code and I create a directory with the source that
has the following imports.
(some_dir/MyLib.hs)
module MyLib where
And then I want to use that set of code at the top level directory, eg:
MyTest.hs
I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module name with a .
Marc Weber wrote:
I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module
Simon and I have been thinking about fixing this, and we think we might
actually do so for GHC 6.6. Your message provoked us to write up the
design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads; for example
Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we
might actually do so for GHC 6.6. Your message provoked us to write
up the design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads;
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote:
I don't think this solves the whole problem. Suppose M1 needs to use A.B.C
from P1 *and* A.B.C from P2
For a simple example of a case where this might arise, suppose M1 is the
migration module for data (stored in a database,
Simon,
We covered this extensively in the Cabal vs Haskell thread starting
here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html
You concluded it by saying on April 22:
And this observation points towards a simpler solution: rather than
invisibly pre-pend the package
Apologies to Brian for the multiple copies, this wasn't originally
sent to the list.
On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote:
I'm wondering: would it not be easier to just make it that the package name
is prepended to the hierarchical module name, so the modules would instead
be
David House wrote:
Apologies to Brian for the multiple copies, this wasn't originally
sent to the list.
On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote:
I'm wondering: would it not be easier to just make it that the
package name is prepended to the hierarchical module name, so the
modules
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
Hi -
At the moment there is a problem in that two packages P and Q could contain
the same hierarchical module eg Data.Foo, and the only way for user code to
ensure the right Data.Foo is used is to ensure that packages P and Q are
searched
Robert Dockins wrote:
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
[snip]
I'm wondering: would it not be easier to just make it that the
package name is prepended to the hierarchical module name, so the
modules would instead be called by the names P.Data.Foo and
Q.Data.Bar?
[snip
56 matches
Mail list logo
