perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be
called and the maximum heap size set to just under that, since it is the
point that the OS will forcefully kill the program anyway.
John
--
John Meacham - ⑆repetae.net⑆john⑈
__
On Apr 18, 2006, at 4:05 PM, Ravi Nanavati wrote:
I recently discovered that I'm running into the IORef / garbage
collection issue described in the ghc user guide (at the bottom of the
following page):
http://www.haskell.org/ghc/docs/6.4/html/users_guide/faster.html
I did a bit of back-and-f
On Tue, Apr 18, 2006 at 10:26:18AM +0400, Bulat Ziganshin wrote:
> > FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
> > find this can be faster once your projects grow beyond a certain size as
> > it takes ghc a while to figure out which files need to be rebuilt with
> > --
I recently discovered that I'm running into the IORef / garbage
collection issue described in the ghc user guide (at the bottom of the
following page):
http://www.haskell.org/ghc/docs/6.4/html/users_guide/faster.html
Increasing the heap and allocation area size (with -H, -M and -A) helped
improv
Hello Simon,
Tuesday, April 18, 2006, 3:02:20 PM, you wrote:
>> if that is due to the time of reading .hi files, my alternative Binary
>> library should help in some future
> I'd be suprised if you could improve on GHC's binary library. Using
> BinMem (reading/writing directly to memory), GHC'
On Mon, Apr 17, 2006 at 01:20:34PM +0200, Marc Weber wrote:
> GHC stage restriction: `view'
> is used in a top-level splice, and must be imported, not
> defined locally
The solution was to change
where elemFromList = listToMaybe $ drop 1 $(dropWhile (/= view) $ (xs++[x]))
into :
where elemFromLis
Simon Marlow wrote:
I'm rolling and uploading the 6.4.2 bits now, and this patch didn't make
it in, sorry. We can put together a patchset for building on Solaris
and make it available separately. Can you send me a working patch? Did
the DriverState patch I posted earlier work?
I've integra
Christian Maeder wrote:
Simon Marlow wrote:
This bit of Makefile code is possibly going wrong for you:
-include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/config.mk
-include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/version.mk
you're right!
Try this instead:
$ make
Volker Stolz wrote:
venus [14:45:44]> echo foo | tr a-z A-Z
foo
venus [14:46:11]> echo foo | tr [a-z] [A-Z]
FOO
[..]
Maybe it's safe to switch to the bracketed version these days...
This also works fine on Linnix and FreeBSD.
Finding the correct 'tr' on Solaris is probably more tedious.
the b
Simon Marlow wrote:
This bit of Makefile code is possibly going wrong for you:
-include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/config.mk
-include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/version.mk
you're right!
Try this instead:
$ make Project=Ghc ProjectDirecto
* Simon Marlow <[EMAIL PROTECTED]>:
> This bit of Makefile code is possibly going wrong for you:
>
> -include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/config.mk
> -include $(shell echo $(ProjectDirectory) | tr A-Z a-z)/mk/version.mk
>
> Try this instead:
>
>$ make Project=Ghc P
This is a bug. I'm committing a fix as I type.
Thanks for boiling it down.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Einar Karttunen
| Sent: 16 April 2006 13:57
| To: Rene de Visser
| Cc: glasgow-haskell-users@has
Christian Maeder wrote:
Simon Marlow wrote:
GhcBinDistDirs is set by ghc/mk/config.mk, which is included by the
top-level Makefile.
I see, there's another mk/config.mk in the subdirectory "ghc"
$ make show Project=Ghc VALUE=GhcBinDistDirs
GhcBinDistDirs="ghc libraries hslibs"
in this
David Roundy wrote:
I'm getting the following error when bootstrapping the ghc head darcs
repository:
/usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types
-istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck
-istage1/deSugar -istage1/coreSyn -istage1/spe
Hi all,
I'm getting the following error when bootstrapping the ghc head darcs
repository:
/usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types
-istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck
-istage1/deSugar -istage1/coreSyn -istage1/specialise -ista
Bulat Ziganshin wrote:
Hello John,
Tuesday, April 18, 2006, 3:25:35 AM, you wrote:
FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
find this can be faster once your projects grow beyond a certain size as
it takes ghc a while to figure out which files need to be rebuilt
Hi all,
I'm getting the following error when bootstrapping the ghc head darcs
repository:
/usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types
-istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck
-istage1/deSugar -istage1/coreSyn -istage1/specialise -ista
[ replaying on glasgow-haskell-users@haskell.org ]
Paul A. Steckler wrote:
[Apologies for the cross-post from Haskell Cafe, but I got no responses
there.]
I need a Linux ghc 6.2.1 built with glibc-2.4. The existing 6.2.1 RPM,
built with glibc-2.3, works mostly OK, but with some programs, the
g
Frederik Eaton wrote:
I have a project which currently uses Cabal, and I would like to
switch to using a plain Makefile.
I have two examples of projects that use Makefiles, darcs and jhc, but
they both appear to hand-code the list of dependencies for
executables. The "-M" option to ghc should
Hello Neil,
Tuesday, April 18, 2006, 3:36:12 AM, you wrote:
> If you are not using any GHC specific features, then I find that using
> Hugs for compiler errors, then once Hugs is happy moving on to GHC can
> massively speed up development time.
it's also my beloved path of work. compiler-specifi
Hello John,
Tuesday, April 18, 2006, 3:25:35 AM, you wrote:
> FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
> find this can be faster once your projects grow beyond a certain size as
> it takes ghc a while to figure out which files need to be rebuilt with
> --make
if th
Frederik Eaton wrote:
Hi all,
I have a project which currently uses Cabal, and I would like to
switch to using a plain Makefile.
I use something like the attached Makefile. I don't have any experience with big projects though, so
it could be that regenerating dependencies all the time is exp
22 matches
Mail list logo
