Manuel M T Chakravarty wrote:
Actually, I think, we should use the gmp/ in the ghc repo by default (at
least on non-Linux). Why? I don't think it is nice to build binaries
by default that I can't copy to and run on another computer running the
same OS without having to install extra fancy
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:
It seems to be a matter of the precise ld call parameters whether the
gmp/ in the ghc repo is used or the external one. In using the stage1
compiler to link the stage2 compiler, the external one wins, but in
I wrote:
Removing support for %HOME% has suddenly broken many
programs. If people don't like it, we can consider
deprecating it in some future version of GHC, but for now
it should put back.
Simon Marlow wrote:
Only GHCi has changed here. Perhaps you're under the impression that we
Bulat Ziganshin wrote:
Hello Scott,
Sunday, December 16, 2007, 11:57:33 PM, you wrote:
My question is: what exactly does GHC.Prim.touch# do? This appears to
it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc
optimizer that data were accessed so it doesn't free the memory
Hello Simon,
Monday, December 17, 2007, 1:33:19 PM, you wrote:
My question is: what exactly does GHC.Prim.touch# do? This appears to
it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc
optimizer that data were accessed so it doesn't free the memory
Yes, exactly. touch#
Thanks for the response guys.
I'm still curious as to the specific mechanism by which a strictly
compile-time function affects the run-time behavior of the GC. Bulat
says that touch# makes the runtime aware that the fptr object is still
in use, but how does it do this if, at runtime, it doesn't
Scott Dillard wrote:
Thanks for the response guys.
I'm still curious as to the specific mechanism by which a strictly
compile-time function affects the run-time behavior of the GC. Bulat
says that touch# makes the runtime aware that the fptr object is still
in use, but how does it do this if,
Hi,
Upgrading from GHC 6.6 to 6.8 has caused some code to stop working:
--
{-# OPTIONS_GHC -fglasgow-exts #-}
module Data2 where
data CCompany
data Paradise :: * - * where
CC :: Paradise CCompany
rewrapCC CC = []
You should be giving a type signature to rewrap! That should fix it.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Neil Mitchell
| Sent: 17 December 2007 16:23
| To: glasgow-haskell-users@haskell.org
| Subject: GADT pattern match in
Hi Simon,
You should be giving a type signature to rewrap! That should fix it.
Thanks, all works fine now :-)
Neil
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Neil Mitchell
| Sent: 17 December 2007 16:23
| To:
I just built from source on Tiger fine.
-Alex-
Christian Maeder wrote:
Manuel M T Chakravarty wrote:
Alex Jacobson:
Will this also work with Tiger or do I have to upgrade?
it will not work on Tiger
I don't know. I have no box with Tiger to test. Give it a try. The
worst that can
Hello all,
I've came across a problem which would be best implemented if I could
define what I think to be a Type Relation. Let's consider classes as
being type properties.
When you say:
class Num a where
(+) :: a - a - a
...
it defines a property of the type a. Basically all types a of class
Hi,
I think I found a performance bug. Either that, or something is going
on that I don't understand.
I've attached an example program. Here's my session with it:
===
ghc --make -O2 MaybeBug.hs; time ./MaybeBug +RTS -tstderr
[1 of 1] Compiling Main ( MaybeBug.hs,
On Dec 17, 2007 8:36 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Isn't this what multi-parameter type classes are about?
I didn't know about those. I'll check them out. Thanks for the pointer.
By the way, such questions are better asked on the Haskell Mailing List or the
Haskell Café
Am Montag, 17. Dezember 2007 20:32 schrieb Paulo J. Matos:
Hello all,
I've came across a problem which would be best implemented if I could
define what I think to be a Type Relation. Let's consider classes as
being type properties.
When you say:
class Num a where
(+) :: a - a - a
...
Seth Kurtzberg wrote:
Isaac makes an important point (although I'm not sure it's
the point he intended to make :) ), there is really
nothing in the definition of UNIX itself that specifies
or requires a home directory. It's a convention followed
by shells, primarily.
$HOME is a
On Mon, Dec 17, 2007 at 02:12:31PM +0300, Bulat Ziganshin wrote:
Hello Simon,
Monday, December 17, 2007, 1:33:19 PM, you wrote:
My question is: what exactly does GHC.Prim.touch# do? This appears to
it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc
optimizer that
I see this:
$ runhaskell ./Setup.lhs build
Preprocessing executables for haddock-0.8...
shift/reduce conflicts: 5
Building haddock-0.8...
src/Main.hs:49:7:
Could not find module `System.Directory':
it is a member of package directory-1.0.0.0, which is hidden
Any ideas?
Thanks,
You probably need to add 'directory' to the depends in the .cabal file.
- Phil
On Dec 17, 2007 2:27 PM, Deborah Goldsmith [EMAIL PROTECTED] wrote:
I see this:
$ runhaskell ./Setup.lhs build
Preprocessing executables for haddock-0.8...
shift/reduce conflicts: 5
Building haddock-0.8...
On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:
Note that for data files like the .ghci file it's probably better to use
getAppUserDataDirectory ghci which will return $HOME/.ghci on unix
systems and C:/Documents And Settings/user/Application Data/ghci on
Windows.
I've added a proposal and a
On Mon, 2007-12-17 at 14:27 -0800, Deborah Goldsmith wrote:
I see this:
$ runhaskell ./Setup.lhs build
Preprocessing executables for haddock-0.8...
shift/reduce conflicts: 5
Building haddock-0.8...
src/Main.hs:49:7:
Could not find module `System.Directory':
it is a member
I wrote,
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC.
This
Ian Lynagh:
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty
wrote:
It seems to be a matter of the precise ld call parameters whether the
gmp/ in the ghc repo is used or the external one. In using the
stage1
compiler to link the stage2 compiler, the external one wins, but
On Dec 14, 2007 1:30 AM, Christian Maeder [EMAIL PROTECTED] wrote:
Ian Lynagh wrote:
Incidentally, I suspect the otool output actually means it depends on
/some/ libgmp.3.dylib, and it is using one that it found in
/opt/local/lib/libgmp.3.dylib, but I could be wrong.
The full path
On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Ian Lynagh:
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty
wrote:
Actually, I think, we should use the gmp/ in the ghc repo by default
If you want to use it when building a bindist that might be
25 matches
Mail list logo
