Re: ANNOUNCE: GHC version 6.8.2
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 stuff like gmp. In other words, your average Mac doesn't have gmp installed. Just because I happen to have gmp on my Mac, I don't want to build a dependency into all binaries generated by ghc that prevent me from using these binaries on other Macs. Right, the (hets) binaries that we create also depend on readline-5 that is not installed on average Macs. Therefore we've invented this GNUreadline framework, which can be at least copied into one's home directory (without too much effort). Do you think ghc should provide readline-5 as internal library, too? I wouldn't mind giving up this dylib and framework confusion, but wasn't there a license problem (maybe for our GNUreadline framework, too)? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 linking other programs with the stage1 compiler, the internal gmp wins. Hmm, that's interesting. The internal GMP should only be built if HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should always use the internal one, and there shouldn't be an external one to use anyway. 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 used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it. The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 recently changed the behaviour of getHomeDirectory? In fact, it was introduced in GHC 6.4 and has always had the same behaviour, calling SHGetFolderPath on Windows. Thanks, Simon. Yes, I was originally under that mistaken impression, but Duncan set me straight. I am glad that %HOMEPATH% is not being used, though ShGetFolderPath sometimes gives the wrong answer on Vista. So having a customizable notion of home directory on Windows would be a new feature for getHomeDirectory. For GHCi it would be rescuing a recently removed one. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr performance
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 Yes, exactly. touch# generates no code, but it is vitally important because if the ForeignPtr is referencing data in the heap (like mallocForeignPtrBytes does), it prevents the data from being GC'd before the operation completes. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ForeignPtr performance
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# generates no code, but it is vitally important because if the ForeignPtr is referencing data in the heap (like mallocForeignPtrBytes does), it prevents the data from being GC'd before the operation completes. a bit more details for Scott: generated code is like this: ptr - unsafeForeignPtrToPtr fptr yourAction ptr touch# fptr without touch, the *last* action where fptr involved is its conversion to ptr. GHC Runtime (not optimizer as i said) have no idea that ptr and fptr is the same object, so after conversion it feels free to dispose object pointed by fptr if GC occurs. this means that during execution of your action data pointed by fptr/ptr may be suddenly freed, allocated by other object, bang! the touch pseudo-action is performed *after* your action and references fptr again. so Runtime thinks there is one more usage of fptr after yourAction and it doesn't dispose this chunk of memory if GC occurs during your action (unfortunately it's not mentioned anywhere on the Web) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ForeignPtr performance
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 do anything? Does if affect the scheduling of collections? Does it mark the fptr object with some flag when its allocated? What if, for example, if I put the touch# behind a branch that is conditional on run-time values? How would this affect things? I'm sure the answer to this is detailed and involves a lot of specifics about GHC that I probably won't grasp, and maybe it isn't appropriate for the whole list, but if there happens to be a short answer, or there's a reference you can point me to, I'd appreciate it. Thanks, Scott On Dec 17, 2007 4:12 AM, Bulat Ziganshin [EMAIL PROTECTED] 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 data were accessed so it doesn't free the memory Yes, exactly. touch# generates no code, but it is vitally important because if the ForeignPtr is referencing data in the heap (like mallocForeignPtrBytes does), it prevents the data from being GC'd before the operation completes. a bit more details for Scott: generated code is like this: ptr - unsafeForeignPtrToPtr fptr yourAction ptr touch# fptr without touch, the *last* action where fptr involved is its conversion to ptr. GHC Runtime (not optimizer as i said) have no idea that ptr and fptr is the same object, so after conversion it feels free to dispose object pointed by fptr if GC occurs. this means that during execution of your action data pointed by fptr/ptr may be suddenly freed, allocated by other object, bang! the touch pseudo-action is performed *after* your action and references fptr again. so Runtime thinks there is one more usage of fptr after yourAction and it doesn't dispose this chunk of memory if GC occurs during your action (unfortunately it's not mentioned anywhere on the Web) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr performance
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, at runtime, it doesn't do anything? Does if affect the scheduling of collections? Does it mark the fptr object with some flag when its allocated? What if, for example, if I put the touch# behind a branch that is conditional on run-time values? How would this affect things? It's not as complicated as you think. touch# takes a single argument, and does nothing with it; it's only purpose is to ensure that the value passed as its argument is alive as far as the rest of the compiler and runtime is concerned. There's no special mechanism at work here: touch# is just like an ordinary IO operation, except that its implementation is empty, and the compiler cannot use this fact for optimisation purposes. The compiler therefore arranges that the argument to touch# is available, just as it would for any other function. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GADT pattern match in non-rigid context
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 = []
--
[1 of 1] Compiling Data2( Data2.hs, interpreted )
Data2.hs:12:9:
GADT pattern match in non-rigid context for `CC'
Tell GHC HQ if you'd like this to unify the context
In the pattern: CC
In the definition of `rewrapCC': rewrapCC CC = []
This code is from the Uniplate benchmarking code, which runs the
Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos
code uses GADT's, so the program first needs to convert from standard
data structures to GADT's before it can work, then back at the end.
It's the problem of converting from a GADT to a normal data structure
that is failing.
So is there an easy workaround? Or should I be asking GHC HQ to unify things?
Thanks
Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GADT pattern match in non-rigid context
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 non-rigid context
|
| 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 = []
| --
|
| [1 of 1] Compiling Data2( Data2.hs, interpreted )
|
| Data2.hs:12:9:
| GADT pattern match in non-rigid context for `CC'
| Tell GHC HQ if you'd like this to unify the context
| In the pattern: CC
| In the definition of `rewrapCC': rewrapCC CC = []
|
| This code is from the Uniplate benchmarking code, which runs the
| Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos
| code uses GADT's, so the program first needs to convert from standard
| data structures to GADT's before it can work, then back at the end.
| It's the problem of converting from a GADT to a normal data structure
| that is failing.
|
| So is there an easy workaround? Or should I be asking GHC HQ to unify things?
|
| Thanks
|
| Neil
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT pattern match in non-rigid context
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: glasgow-haskell-users@haskell.org
| Subject: GADT pattern match in non-rigid context
|
| 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 = []
| --
|
| [1 of 1] Compiling Data2( Data2.hs, interpreted )
|
| Data2.hs:12:9:
| GADT pattern match in non-rigid context for `CC'
| Tell GHC HQ if you'd like this to unify the context
| In the pattern: CC
| In the definition of `rewrapCC': rewrapCC CC = []
|
| This code is from the Uniplate benchmarking code, which runs the
| Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos
| code uses GADT's, so the program first needs to convert from standard
| data structures to GADT's before it can work, then back at the end.
| It's the problem of converting from a GADT to a normal data structure
| that is failing.
|
| So is there an easy workaround? Or should I be asking GHC HQ to unify
things?
|
| Thanks
|
| Neil
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 happen is that it is going to complain about some missing libraries or similar. configure will crash already, because utils/pwd/pwd has been built with newer libs. C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type Relations
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 Num are addable, etc.. However, how can I (if I can) represent the fact that you can coerce a type a to a type b? A particular example of that is the fromInteger function from Num class where you say that if your type a is of class Num, you must be able to coerce an Int to a. I would like to define a relation between types and then say that two types are in the relation if they define the coerce function. Something I imagine would be: typerelation Coercible a b where coerce :: a - b And then you would define instances of Coercible if you could define the function coerce between the types. You could then define function only over types which can be coerced from one to the other. Any suggestions on how to do something like this? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Performance bug maybe
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, MaybeBug.o )
Linking MaybeBug ...
./MaybeBug +RTS -tstderr
-1452071552
191905792
ghc: 800037360 bytes, 4 GCs, 40960/40960 avg/max bytes residency (1
samples), 383M in use, 0.00 INIT (0.00 elapsed), 3.96 MUT (4.36
elapsed), 0.00 GC (0.00 elapsed) :ghc
real0m4.408s
user0m3.960s
sys 0m0.448s
ghc --make -O2 MaybeBug.hs -DSLOW -no-recomp; time ./MaybeBug +RTS -tstderr
[1 of 1] Compiling Main ( MaybeBug.hs, MaybeBug.o )
Linking MaybeBug ...
./MaybeBug +RTS -tstderr
-1452071552
191905792
ghc: 437408 bytes, 6106 GCs, 400588800/400588800 avg/max bytes
residency (2 samples), 765M in use, 0.00 INIT (0.00 elapsed), 9.71 MUT
(10.53 elapsed), 0.05 GC (0.08 elapsed) :ghc
real0m10.717s
user0m9.761s
sys 0m0.876s
==
There are two functions, initArray1 and initArray2, that have exactly
the same implementation. I use them to initialize two arrays. If I use
initArray1 on the first, and initArray2 on the second, then things get
inlined and specialized wonderfully and no heap is used. If I use
initArray1 to initialize both arrays, then less inlining happens.
Since I'm doing possibly dangerous things with unsafePerformIO, I'm
inclined to think this is not a bug, but I'm still wondering what's
going on.
On that note: is this use of unsafePerformIO in fact dangerous? I'm
aware that allocating memory inside unsafePerformIO is not wise,
especially when that function is to be inlined. If the function body
is duplicated at the call site, I might get two identical arrays where
I could have one that is shared. I can live with that possibility, but
I'm more worried about the allocation being floated out of the
unsafePerformIO, and having unintended sharing. Can this happen, the
way I've written it? The inlining seems to be crucial for performance,
so that constructor specialization can kick in.
If there's a better way to do truly polymorphic unboxed immutable
arrays, I'm all ears. (I'm aware of Bulat's ArrayRef library, but it
doesn't seem to be maintained.. is it?)
Scott
{-# LANGUAGE CPP,BangPatterns #-}
import Foreign
import Control.Monad
import Data.ByteString.Internal
n = 1
main =
let
a = initArray1 n (\i - i*i)
#ifdef SLOW
b = initArray1 n (\i - i*i*i)
#else
b = initArray2 n (\i - i*i*i)
#endif
sumArray ar !s !i
| i==n = s
| otherwise = sumArray ar (s+(ar`at`i)) (i+1)
in
do
print $ sumArray a 0 0
print $ sumArray b 0 0
data Arr a = Arr Int (ForeignPtr a)
initArray1 size f =
unsafePerformIO $
do
fp - mallocForeignPtrArray size -- is this bad?
withForeignPtr fp $ \p -
let init !i | i==size = return ()
| otherwise = pokeElemOff p i (f i) init (i+1)
in init 0
return (Arr size fp)
{-# INLINE initArray1 #-}
initArray2 size f =
unsafePerformIO $
do
fp - mallocForeignPtrArray size
withForeignPtr fp $ \p -
let init !i | i==size = return ()
| otherwise = pokeElemOff p i (f i) init (i+1)
in init 0
return (Arr size fp)
{-# INLINE initArray2 #-}
at (Arr size fp) i = inlinePerformIO $ withForeignPtr fp $ \p - peekElemOff p i
{-# INLINE at #-}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type Relations
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é Mailing List. This list is more about using GHC, not so much about topics related to the language Haskell as such. Sorry, You're right. I posted here in fact because I was hoping it would be a GHC extension of some sort. Cheers, Paulo Matos Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type Relations
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 ... it defines a property of the type a. Basically all types a of class Num are addable, etc.. However, how can I (if I can) represent the fact that you can coerce a type a to a type b? A particular example of that is the fromInteger function from Num class where you say that if your type a is of class Num, you must be able to coerce an Int to a. I would like to define a relation between types and then say that two types are in the relation if they define the coerce function. Something I imagine would be: typerelation Coercible a b where coerce :: a - b And then you would define instances of Coercible if you could define the function coerce between the types. You could then define function only over types which can be coerced from one to the other. Any suggestions on how to do something like this? Isn’t this what multi-parameter type classes are about? By the way, such questions are better asked on the Haskell Mailing List or the Haskell Café Mailing List. This list is more about using GHC, not so much about topics related to the language Haskell as such. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 convention too prevalent to not have one in a running system, unless you try really hard. But I've only seen it used for two things that I remember: - dot-files (and sometimes non-dot ones for IMHO ill-behaved programs) as a per-user search and automatic generation location - default location for shells (graphical file search as well as command-line) - which IMO should be controllable by a different variable - and '~' as a sort of synonym, I guess, even in some contexts that don't allow arbitrary environment variable substitution? any others? Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr performance
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 data were accessed so it doesn't free the memory Yes, exactly. touch# generates no code, but it is vitally important because if the ForeignPtr is referencing data in the heap (like mallocForeignPtrBytes does), it prevents the data from being GC'd before the operation completes. a bit more details for Scott: generated code is like this: ptr - unsafeForeignPtrToPtr fptr yourAction ptr touch# fptr without touch, the *last* action where fptr involved is its conversion to ptr. GHC Runtime (not optimizer as i said) have no idea that ptr and fptr is the same object, so after conversion it feels free to dispose object pointed by fptr if GC occurs. this means that during execution of your action data pointed by fptr/ptr may be suddenly freed, allocated by other object, bang! I'd like to elaborate that ptr, as far as the GC is concerned is *not a pointer at all*, it is an integer memory address. So it doesn't keep anything alive, you need to hold on to fptr if you want the value to exist. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haddock won't build on 6.8.1
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, Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddock won't build on 6.8.1
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... 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, Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
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 patch to Trac (http://hackage.haskell.org/trac/ghc/ticket/1987). -Felix ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddock won't build on 6.8.1
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 of package directory-1.0.0.0, which is hidden Any ideas? We're waiting for a release of haddock 0.9 in the mean time you could patch it: # Cabal 1.2 expects the pre-processed sources in a different location: mkdir -p dist/build/haddock/haddock-tmp cp src/HaddockLex.hs src/HaddockParse.hs src/HsParser.hs dist/build/haddock/haddock-tmp/ # Add in the extra split-base deps sed -i -e '/build-depends:/a \ ,array, containers, directory, pretty, process' haddock.cabal Taken from: http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/haddock/haddock-0.8.ebuild Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. A binary distribution for Mac OS X 10.5 (Leopard) is available from http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 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. I just updated the binary distribution at http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 It *definitely* does not require any version of GMP to be pre- installed anymore. All that is needed it MacPort's readline. Ian, can you please update the binary on the download page? Manuel PS: Moreover, binaries produced by the above compiler will run on any Leopard box. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 in linking other programs with the stage1 compiler, the internal gmp wins. Hmm, that's interesting. The internal GMP should only be built if HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should always use the internal one, and there shouldn't be an external one to use anyway. At least on Mac OS (and also on Windows) and probably any other platform, except Linux, this is IMHO the wrong policy. FWIW, the current build system uses the internal GMP even if another one is installed (at least a non-framework one). However, the behaviour is a bit flacky (eg, if package readline is also used, it uses the external GMP due to some difference between the Darwin linker and other Unix linkers). It also needs to recompile installPackage and ifBuildable with the stage1 compiler (like the stuff below utils/) as both go into a binary distribution. I have fixed this all and am currently validating a patch. 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 used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it. The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space. Sure we waste some space, but the alternative is worse. Programs compiled with GHC will essentially not run on any computer, but the one where they were compiled. For example, the number of Macs with gmp installed is minuscule. The default should be to build programs that run everywhere with minimal hassle (not programs that save some space, but are unusable on most computers). Manuel PS: Readline is a different matter. It is used by ghci, so needs to be installed with ghc, but this dependency does not propagate into compiled programs, unless a program explicitly uses package readline (at which point I believe it is on this program's developer to make sure their users have readline available). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 /opt/local/lib/libgmp.3.dylib is (somehow) stored in the binary, but libgmp.3.dylib will be found in any other path, too. Possibly the DYLD_LIBRARY_PATH has to be set for uncommon paths. Today I did some digging around the source of dyld (the dynamic loader) to understand its behavior when loading frameworks, and ended up learning about how it loads ordinary libraries as well. In particular, if otool -L lists a dependency on /opt/local/lib/libgmp.3.dylib, then the loader will look for all of the following: - [[dir]]/opt/local/lib/libgmp.3.dylib where [[dir]] is any entry from the colon-separated variable $DYLD_ROOT_PATH - /opt/local/lib/libgmp.3.dylib - [[dir]]/libgmp.3.dylib, where [[dir]] is any entry from the following colon-separated variables: - LD_LIBRARY_PATH - DYLD_LIBRARY_PATH - DYLD_FALLBACK_LIBRARY_PATH If DYLD_FALLBACK_LIBRARY_PATH is not set in the environment, it defaults to: $HOME/lib:/usr/local/lib:/usr/lib The rest of the variables listed above default to empty. So in conclusion, there should be no harm with linking OS X binaries against absolute paths like /opt/local. In fact, it might be preferable, since it lets us support both users of MacPorts and users who have GMP stored in a standard location. (Of course, this doesn't address the question of whether dynamically linking against GMP is good to begin with.) Best, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
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 used on other computers you shold be able to set HaveLibGmp = NO HaveFrameworkGMP = NO in mk/build.mk, although I'm not sure I've ever tried it. The disadvantages of using it are it might be out of date (we had some Windows segfaults a while ago that were fixed by updating the in-tree gmp) and wasted space. Sure we waste some space, but the alternative is worse. Programs compiled with GHC will essentially not run on any computer, but the one where they were compiled. For example, the number of Macs with gmp installed is minuscule. The default should be to build programs that run everywhere with minimal hassle (not programs that save some space, but are unusable on most computers). My understanding was that one major reason to dynamically link against GMP is to satisfy the LGPL, not just to save disk space. I found a couple old but relevant posts by Wolfgang Thaller, who originally created HaskellSupport.framework (now GMP.framework): http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003494.html http://www.haskell.org/pipermail/cvs-ghc/2005-March/023769.html The gist of those posts is the following: - Statically linking against GMP puts extra license requirements on any ghc-compiled program; thus, dynamic linking is preferable. - On OS X, installing new frameworks is very easy (just drag-and-drop the framework into ~/Library/Frameworks or /Library/Frameworks; the former doesn't even need admin privileges). This doesn't seem like much to ask of users. Best, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
