Hi,
I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6,
because I've also installed stuff depending on 6.4.2, like wxHaskell,
for instance. Now I see a new version of mtl, which I also have
installed, depends on 6.6.1, while all of the rest of the stuff is
lagging behind with
Duncan Coutts [EMAIL PROTECTED] writes:
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.
However in this case the Monad operations can
| However when I do this:
|
| newtype Quaternion = Q (Vec4 Double)
|
| Everything is ruined. Functions like peek and vadd are no longer inlined,
| intermediate linked lists are created all over the place. The Quaternion
| Storable instance looks like this
Turns out this is a perf bug in 6.8 that
Manuel M T Chakravarty wrote:
To use this binary distribution, you need to have readline from
MacPorts installed.
Manuel
PS: This time around, there should be no dependency on MacPorts' gmp,
but this is hard for me to test locally.
What does your otool -L say to your binary?
otool -L
Oops, I sent this previously from my @gentoo address so it got rejected
by the mailing list. Re-sending my reply in case anyone other than
Dinko Tenev is interested.
On Thu, 2007-12-13 at 11:25 +0200, Dinko Tenev wrote:
Hi,
I'm using GHC on Gentoo, and so far I've had to stay clear of GHC
On Dec 12, 2007 7:44 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
The GHC Team is pleased to announce a new patchlevel release of GHC.
With the Windows release of GHC 6.8.2, GHCi does not find .ghci in
%HOME% (though it finds it in the current directory):
C:\wrk echo %HOME%
C:\home
C:\wrk ghci
With the Windows release of GHC 6.8.2, GHCi does not find .ghci in
%HOME% (though it finds it in the current directory):
try %HOMEDRIVE% %HOMEPATH% instead?
or the result of 'System.Directory.getHomeDirectory'.
you might have set %HOME% to help some unix software
along, but this variable
On Dec 13, 2007 2:05 PM, Claus Reinke [EMAIL PROTECTED] wrote:
try %HOMEDRIVE% %HOMEPATH% instead?
Doesn't work either.
you might have set %HOME% to help some unix software
along, but this variable doesn't seem to exist by default.
It worked in 6.8.1.
With which I mean, GHCi had no trouble
Juanma Barranquero wrote:
On Dec 13, 2007 2:05 PM, Claus Reinke [EMAIL PROTECTED] wrote:
try %HOMEDRIVE% %HOMEPATH% instead?
Doesn't work either.
you might have set %HOME% to help some unix software
along, but this variable doesn't seem to exist by default.
It worked in 6.8.1.
With
On Dec 13, 2007 4:20 PM, Juanma Barranquero [EMAIL PROTECTED] wrote:
I suppose that is a fix for some people; it is a regression for me...
In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
does: use HOME if defined, else use ShGetFolderPath to find the
Windows-defined home
On Dec 13, 2007 4:13 PM, Simon Marlow [EMAIL PROTECTED] wrote:
Yes, see this ticket which was fixed in 6.8.2:
I suppose that is a fix for some people; it is a regression for me...
GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever
getHomeDirectory says your home
I've just downloaded the vs integration packagewhich looks
greatbut it comes with 6.6.1, and I was hoping to move to
6.8.2does anyone know how to do this?
Lead Broadcast and Corporate Architect
Technology London
(44) 0207 284 7596
I suppose that is a fix for some people; it is a regression for me...
In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
does: use HOME if defined, else use ShGetFolderPath to find the
Windows-defined home directory.
in the interest of backwards-compatibility, perhaps.
but as
Duncan Coutts wrote:
Sadly not because portage is not clever enough to deal with the kind of
dependencies you end up with by doing that. Portage does not know that
some libs are installed for one ghc and some for another, so it'd try
and satisfy a dependency for mtl using the mtl you'd
Ahhh okin eclipse it was trivial.but I'd much prefer it to be in
VS.
-Original Message-
From: Simon Marlow [mailto:[EMAIL PROTECTED]
Sent: 13 December 2007 16:22
To: Nicholls, Mark
Cc: glasgow-haskell-users@haskell.org
Subject: Re: upgrading visual studio integration to use
Nicholls, Mark wrote:
I’ve just downloaded the vs integration package….which looks great….but
it comes with 6.6.1, and I was hoping to move to 6.8.2….does anyone know
how to do this?
No, someone needs to rebuild Visual Haskell using 6.8.2, and test it etc.
There have been lots of changes in
On Dec 13, 2007 4:49 PM, Claus Reinke [EMAIL PROTECTED] wrote:
in the interest of backwards-compatibility, perhaps.
That is a good reason, yes.
but as the links i gave should demonstrate, there is no
%HOME% on windows, unless you invent it.
Sorry, it's not me who invented it. There are many
On Thu, 2007-12-13 at 16:06 +, [EMAIL PROTECTED] wrote:
Duncan Coutts wrote:
Sadly not because portage is not clever enough to deal with the kind of
dependencies you end up with by doing that. Portage does not know that
some libs are installed for one ghc and some for another,
Sorry, it's not me who invented it. There are many tools (from Unix
origin) that use HOME in Windows if defined. In fact, let me think...
oh, yeah, I remember, GHCi itself used it until this very same
morning... :)
yes, but ghc/ghci switched from unix-emulated to windows-native
long ago -
On Dec 13, 2007 6:03 PM, Claus Reinke [EMAIL PROTECTED] wrote:
perhaps my fault for filing that ticket in absolutes, which led
to a fix replacing, rather than augmenting, the old, erroneous
behaviour.
It's not a matter of fault, but sure it would've been wiser to
suggest (or implement) the
Duncan Coutts wrote:
We could slot multiple versions of a lib for the same ghc, but not slot
ghc itself.
Why not library slots named
ghc-6.4
ghc-6.6
ghc-6.8
(or finer), each depending on the repective compiler slot?
The different slots of gtk+ also
Hi Manuel,
On Thu, Dec 13, 2007 at 04:29:13PM +1100, Manuel M T Chakravarty wrote:
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
=
Will this also work with Tiger or do I have to upgrade?
-Alex-
Manuel M T Chakravarty wrote:
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
Distribution.Simple.PreProcess could be extended to register
SearchPath as a preprocessor for .ehs files (see stuff near
PPSuffixHandler). Of course, this requires changing Cabal.
Alternately, I think the same effect could be had using Cabal's
UserHooks (see stuff near hookedPreProcessors).
That
On Dec 13, 2007 11:31 PM, Yitzchak Gale [EMAIL PROTECTED] wrote:
I agree, that is closer to the correct behavior.
Except that on Vista ShGetFolderPath is deprecated.
Use ShGetKnownFolderPath instead on Vista.
Aha, I didn't know that. Thanks.
Also, %HOMEPATH% is unsuitable for a Unix-style
Juanma Barranquero wrote:
In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
does: use HOME if defined, else use ShGetFolderPath to find the
Windows-defined home directory.
I agree, that is closer to the correct behavior.
Except that on Vista ShGetFolderPath is deprecated.
Use
On Thu, 2007-12-13 at 17:09 +, [EMAIL PROTECTED] wrote:
Until portage actually can do this in a better way,
you would have to multiply ebuilds
(probably each with common import and a one-line variable setting)
(I don't know the exact restrictions on portage version strings):
Right
Christian Maeder:
Manuel M T Chakravarty wrote:
To use this binary distribution, you need to have readline from
MacPorts installed.
Manuel
PS: This time around, there should be no dependency on MacPorts'
gmp,
but this is hard for me to test locally.
What does your otool -L say to your
Alex Jacobson:
Will this also work with Tiger or do I have to upgrade?
I don't know. I have no box with Tiger to test. Give it a try. The
worst that can happen is that it is going to complain about some
missing libraries or similar.
Manuel
Manuel M T Chakravarty wrote:
Ian Lynagh
On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty wrote:
otool -L compiler/stage2/ghc-6.8.2
/opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
current version 8.1.0)
Yes, it does. That's very strange for the *stage2* compiler. I ran
otool on pwd and
30 matches
Mail list logo
