- Glasgow-haskell-users

Increasing heap size
by Dmitri Pissarenko 15 Feb '05

15 Feb '05

Hello! I have problems when building a large haskell system (haskell-jvm bridge). The compiler complains (see below) that the heap size is too small and limited to about 268 MB. <error-messages> $ make C:/Programme/haskell-jvm-bridge-0.3-RC1/bin/MakeJVMModule HelloWorld_JVM < HelloWorld_JVM.list Created HelloWorld_JVM.hs C:/Programme/haskell-jvm-bridge-0.3-RC1/bin/MakeClassModule -import Header_Java -import Header_JavaX `echo java_lang_System | sed -e 's/_/\./g; s/ \.\./_/g'` Created Class_java_lang_System.hs for classes java.lang.System ghc -H600M -package javavm -c Class_java_lang_System.hs -o Class_java_lang_System.o GHC's heap exhausted: current limit is 268435456 bytes; Use the `-H<size>' option to increase the total heap size. make: *** [Class_java_lang_System.o] Error 251 </error-messages> How can I increase the heap size of ghc? I tried to use option -H600M but then I still get the same error. Is there any alternative to building this system on a more powerful computer? Thanks in advance Dmitri Pissarenko PS: I'm building this system under Windows using MingW MSYS. -- Dmitri Pissarenko Software Engineer http://dapissarenko.com

1 0

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 15 Feb '05

15 Feb '05

Grab the STABLE snapshot after tonight's build, or get it directly from CVS (checkout the tag ghc-6-4-branch). Cheers, Simon On 15 February 2005 13:05, Patrick Scheibe wrote: > Hi Simon, > > thank you for having a look at this. I will test it and I hope can > compile wxHaskell tonight. > > Where is the fixed version of the ghc? Is it one of the stable night > releases or should I make a update of the developer cvs tree of ghc?? > > Cheers > Patrick > > On Tuesday 15 February 2005 12:25, Simon Marlow wrote: >> Thanks this looks like a bug that was introduced recently. Now >> fixed. >> >> Cheers, >> Simon >> >> On 08 February 2005 11:43, Patrick Scheibe wrote: >>> Hi, >>> >>>> Could you tell us what command line was supposed to generate the >>>> Map.d.in or Map.d file? It may be a bug, there were a few changes >>>> in the driver recently. >>>> >>>> Cheers, >>>> Simon >>> >>> I hope I can help you. It would be better Daan would have a look, >>> because it is his code and he knows exactly what he has done. >>> >>> If I understand the things right, then the following call does the >>> depency check. >>> >>> make-hs-deps =$(HC) $(2) $(3) -M -optdep-f -optdep$(basename >>> $(1)).d.in && \ sed -e 's|$(basename >>> $(2))|$(basename $(1))|' -e 's|\.hi|\.o|g' $(basename $ (1)).d.in > >>> $(basename $(1)).d && \ $(call >>> silent-remove-file,$(basename $(1)).d.in) >>> >>> I think the important thing you want to know is that ghc is called >>> with the -M option!? Here is a comment I found in the Makefile. It >>> is probably usefull: >>> >>> <comment> >>> # Dependencies are handled (almost) automatically: no need for >>> "make depend" :-) # >>> # Makefile implementation notes: >>> # >>> # The dependency (.d) files are generated together with object files >>> using # the compiler -M switch. Such dependency file is later >>> processed # by sed to prepend the proper directory to the target and >>> to move it # into the proper (imports) directory. The way dependency >>> files are handled # was 'discovered' by Tom Tromey, and described by >>> Paul Smith, # see "advanced auto-dependency generation" at: >>> # "http://make.paulandlesley.org/autodep.html" >>> # >>> # (Unfortunately, there are situations where this method doesn't >>> work for Haskell # modules -- but these situations are exteremely >>> rare in practice, nothing that # can't be solved by a "make clean; >>> make" command. I believe that in the end # this method is much >>> more robust than "make depend".) # # We use a single makefile in >>> order to correctly resolve dependencies # between the different >>> projects -- a recursive make fails to do that, # see "recursive >>> make considered harmfull" at: # >>> "http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html" # >>> (We might use include files in the future to split this file in >>> smaller chunks.) # # We don't use implicit rules (i.e. "%.o: %.c") >>> as the VPATH mechanism can't # deal with modules with the same name >>> in different directories :-( # # We edit (sed) the haskell >>> dependency files to change dependencies on .hi # files to .o files. >>> We just disregard .hi files and assume they are always # generated >>> together with the .o file. This allows us to leave out the implicit >>> # rule for interface files ("%.hi: %.o"). </comment> >>> >>> I sent a copy to Daan and hope he joins the discussion and/or it him >>> fixing the problem without much expenditure of time. >>> >>> Cheers >>> Patrick >>> >>>> On 07 February 2005 19:28, Patrick Scheibe wrote: >>>>> It seems that there are changes in the OpenGl library during the >>>>> last month. So I decided to load a really young cvs version of the >>>>> ghc (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. >>>>> >>>>> My Problem is, that I also need the wxHaskell library. This >>>>> compilation fails with the message: >>>>> >>>>> <wxoutput> >>>>> ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi >>>>> out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec >>>>> -iout/wxdirect sed: kann out/wxdirect/Map.d.in nicht lesen: Datei >>>>> oder Verzeichnis nicht gefunden make: *** [out/wxdirect/Map.o] >>>>> Fehler 2 </wxoutput> >>>>> >>>>> The third line is german and means "sed: unable to read >>>>> out/wxdirect/Map.d.in: File not found". >>>>> This or an almost similar error appears when I use the cvs >>>>> version of wxhaskell. >>>>> >>>>> I'm also in contact with Daan Leijen, the main developer of >>>>> wxHaskell. He said: >>>>> >>>>> <daan> >>>>> Darn, it seems that ghc changed its options or something. My >>>>> makefile generates dependency files (".d" files) using ghc. Since >>>>> "sed" can't find the file, it is either not generated or it is put >>>>> at the wrong directory. Can you look around in your file system if >>>>> there is a Map.d or Map.d.in file somewhere around (maybe >>>>> Map.hs.d.in ?) I guess it is still in the source directory >>>>> instead of the out/... directory.

1 0

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 15 Feb '05

15 Feb '05

Thanks this looks like a bug that was introduced recently. Now fixed. Cheers, Simon On 08 February 2005 11:43, Patrick Scheibe wrote: > Hi, > >> >> Could you tell us what command line was supposed to generate the >> Map.d.in or Map.d file? It may be a bug, there were a few changes >> in the driver recently. >> >> Cheers, >> Simon > > > I hope I can help you. It would be better Daan would have a look, > because it is his code and he knows exactly what he has done. > > If I understand the things right, then the following call does the > depency check. > > make-hs-deps =$(HC) $(2) $(3) -M -optdep-f -optdep$(basename > $(1)).d.in && \ > sed -e 's|$(basename $(2))|$(basename $(1))|' -e > 's|\.hi|\.o|g' $(basename $ > (1)).d.in > $(basename $(1)).d && \ > $(call silent-remove-file,$(basename $(1)).d.in) > > I think the important thing you want to know is that ghc is called > with the -M option!? Here is a comment I found in the Makefile. It is > probably usefull: > > <comment> > # Dependencies are handled (almost) automatically: no need for "make > depend" :-) > # > # Makefile implementation notes: > # > # The dependency (.d) files are generated together with object files > using # the compiler -M switch. Such dependency file is later > processed # by sed to prepend the proper directory to the target and > to move it # into the proper (imports) directory. The way dependency > files are handled # was 'discovered' by Tom Tromey, and described by > Paul Smith, # see "advanced auto-dependency generation" at: > # "http://make.paulandlesley.org/autodep.html" > # > # (Unfortunately, there are situations where this method doesn't work > for Haskell > # modules -- but these situations are exteremely rare in practice, > nothing that > # can't be solved by a "make clean; make" command. I believe that in > the end # this method is much more robust than "make depend".) > # > # We use a single makefile in order to correctly resolve dependencies > # between the different projects -- a recursive make fails to do that, > # see "recursive make considered harmfull" at: > # "http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html" > # (We might use include files in the future to split this file in > smaller chunks.) > # > # We don't use implicit rules (i.e. "%.o: %.c") as the VPATH > mechanism can't # deal with modules with the same name in different > directories :-( # > # We edit (sed) the haskell dependency files to change dependencies > on .hi # files to .o files. We just disregard .hi files and assume > they are always # generated together with the .o file. This allows us > to leave out the implicit > # rule for interface files ("%.hi: %.o"). > </comment> > > I sent a copy to Daan and hope he joins the discussion and/or it him > fixing the problem without much expenditure of time. > > Cheers > Patrick > > >> On 07 February 2005 19:28, Patrick Scheibe wrote: >>> It seems that there are changes in the OpenGl library during the >>> last month. So I decided to load a really young cvs version of the >>> ghc (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. >>> >>> My Problem is, that I also need the wxHaskell library. This >>> compilation fails with the message: >>> >>> <wxoutput> >>> ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi >>> out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec >>> -iout/wxdirect sed: kann out/wxdirect/Map.d.in nicht lesen: Datei >>> oder Verzeichnis nicht gefunden make: *** [out/wxdirect/Map.o] >>> Fehler 2 </wxoutput> >>> >>> The third line is german and means "sed: unable to read >>> out/wxdirect/Map.d.in: File not found". >>> This or an almost similar error appears when I use the cvs version >>> of wxhaskell. >>> >>> I'm also in contact with Daan Leijen, the main developer of >>> wxHaskell. He said: >>> >>> <daan> >>> Darn, it seems that ghc changed its options or something. My >>> makefile generates dependency files (".d" files) using ghc. Since >>> "sed" can't find the file, it is either not generated or it is put >>> at the wrong directory. Can you look around in your file system if >>> there is a Map.d or Map.d.in file somewhere around (maybe >>> Map.hs.d.in ?) I guess it >>> is still in the source directory instead of the out/... directory.

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 15 Feb '05

15 Feb '05

On 14 February 2005 17:23, Ross Paterson wrote: > If a program calls exitWith, runghc produces an extra line of output: > *** Exception: exit: ExitSuccess > or > *** Exception: exit: ExitFailure 3 > and then exits with status 0. It should do what a ghc-compiled > program does: silently exit with the appropriate status. Fixed, thanks. Simon

1 0

RE: Haddock chokes on '#'
by Simon Marlow 14 Feb '05

14 Feb '05

On 11 February 2005 17:44, Peter Simons wrote: > Processing the file > >> module Test where >> >> -- |Haddock chokes on this. >> >> (#) :: a -> (a -> b) -> b >> a # f = f a > > with Haddock 0.6 gives an error: > > | haddock test.hs > | test.hs:5:3: Parse error > > Since GHC deals with this code just fine, I suppose this is > a bug. Haddock parses GHC extensions by default, so its syntax corresponds to GHC with -fglasgow-exts. This could be considered a bug, but it probably won't get fixed (unless someone sends me a patch...). Cheers, Simon

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 14 Feb '05

14 Feb '05

On 13 February 2005 21:30, Stephane Bortzmeyer wrote: > On Thu, Feb 10, 2005 at 01:11:48PM -0000, > Simon Marlow <simonmar(a)microsoft.com> wrote > a message of 17 lines which said: > >> We are finally at the release candidate stage for GHC 6.4. >> Snapshots with versions 6.4.20050209 and later should be considered >> release candidates for 6.4. > > One of my platforms is still not recognized: > > preston:~/tmp/ghc-6.4.20050212 % ./configure > configure: loading site script /usr/local/etc/config.site > configure: creating cache /usr/local/var/tmp/config.cache > checking build system type... sparc64-unknown-netbsd2.0.1 > checking host system type... sparc64-unknown-netbsd2.0.1 > checking target system type... sparc64-unknown-netbsd2.0.1 > Unrecognised platform: sparc64-unknown-netbsd2.0.1 > > Now, I understand that it is a rather uncommon platform but I would > like to run darcs on it. > > ghc runs fine on my other UltraSparc 10, which runs > Debian/GNU/Linux. hugs runs fine on the Sparc/NetBSD. > > I've read > http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l#SEC-BOOTING-FROM-HC > but it is still unclear for me. When I compile ghc on the Sparc / > Debian, no ".hc" files are produced. You really need to go through the cross-compilation process to get GHC built on your platform. Follow the instructions in section 10.2 to get an unregisterised build, and from that you can build GHC again to get a registerised version. (in theory it's possible to cross-compile straight to a registerised version since your target architecture is already supported, but we haven't gone to the trouble of testing and documenting that process, so you'd be on your own). Cheers, Simon

1 0

RE: GHC 6.4 release candidates available [GHCi loads incorrectly]
by Simon Marlow 14 Feb '05

14 Feb '05

On 11 February 2005 14:10, Simon David Foster wrote: > And one other niggle, if you try and load a module which doesn't exist > with :m, it doesn't load it, but it still appends it to command-line; > > Prelude> :m + My.Module > > Top level: > Failed to load interface for `My.Module': > Could not find module `My.Module': > use -v to see a list of the files searched for > Prelude My.Module> Another good bug, now fixed. Keep em coming! Cheers, Simon

1 0

RE: Problem when compiling ghc-6.4 with itself
by Simon Marlow 14 Feb '05

14 Feb '05

On 12 February 2005 18:30, Alain Cremieux wrote: > When compiling ghc-6.4.20050211 with itself, I get : > > /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O > -i../../lib/compat -Rghc-timing -Wall Main.hs > ../../lib/compat/Compat/RawSystem.hs:19: ../../includes/ghcconfig.h: > No such file or directory > > > I verified the version of ghc : > > /usr/local/bin/ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.4.20050211 Thanks, I've just fixed this. Cheers, Simon

1 0

RE: Can't install package
by Simon Marlow 14 Feb '05

14 Feb '05

On 14 February 2005 14:42, Dmitri Pissarenko wrote: > I get the error message > > Reading package info from "javavm.ghc-pkg" > Fail: Unexpected token > > What is wrong in javavm.ghc-pkg? You have: extra_ld_opts = [ "-Wl,-rpath,c:/Programme/haskell-jvm-bridge-0.3-RC1/lib/"-L ] } That -L at the end looks like the problem. Cheers, Simon

2 1

Can't install package
by Dmitri Pissarenko 14 Feb '05

14 Feb '05

Hello! I am trying to install the package for Haskell-JVM bridge (see http://sourceforge.net/projects/jvm-bridge) I have problems with gch-pkg. When I enter ghc-pkg -a -i javavm.ghc-pkg where javavm.ghc-pkg is the file given in the attachment, I get the error message Reading package info from "javavm.ghc-pkg" Fail: Unexpected token What is wrong in javavm.ghc-pkg? TIA Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com

1 0