February 2005 - Glasgow-haskell-users

Fixing Parser.y for correct infix type synonyms
by Johan Glimming 17 Feb '05

17 Feb '05

Hi I am looking into the ghc source code for the first time in order to see if I can understand why type synonyms are not correctly parsed with the ghc extension for infix :-*-: etc. I note that the following is present in the file Parser.y in ghc-6.4.20050216/ghc/compiler/parser and I assume it here ghc is parsing the type declarations? tycl_decl :: { LTyClDecl RdrName } : 'type' syn_hdr '=' ctype -- Note ctype, not sigtype. -- We allow an explicit for-all but we don't insert one -- in type Foo a = (b,b) -- Instead we just say b is out of scope { sL (comb2 $1 $>) $ let (tc,tvs) = $2 in TySynonym tc tvs $4 } on the next line happy is probably given instructions how to parse data declarations? | 'data' tycl_hdr constrs deriving { L (comb4 $1 $2 $3 $4) (mkTyData DataType $2 Nothing (reverse (unLoc $3)) (unLoc $4)) } Now, can someone explain what happens here, e.g. what is the difference between parsing of data and type synonyms? I guess (!) that the handling of infixes is merely an issue in the parser, and would not affect much else in ghc? Johan Glimming.

1 0

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

17 Feb '05

On 17 February 2005 16:25, Georg Martius wrote: > Another bug in ghc! >> /usr/bin/ghc -M wxcore/src/Graphics/UI/WXCore/WxcClassTypes.hs \ >> -iout/wxcore/imports -Iwxc/include -iwxcore/src \ >> -odir out/wxcore/imports/Graphics/UI/WXCore/ produces (among >> others): >> out/wxcore/imports/Graphics/UI/WXCore//Graphics/UI/WXCore/WxcClassTypes. o >> : \ wxcore/src/Graphics/UI/WXCore/WxcClassTypes.hs > where you see that the -odir is not handled correctly. This is correct behaviour for -odir. The docs describe it: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html Cheers, Simon

2 1

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

17 Feb '05

On 17 February 2005 14:54, Daan Leijen wrote: >> A more general question: We doesn't -ohi dir/filename.hi is not >> reflected in the dependencies. >> I tried: >> >>> ghc -M -odir out -ohi out/A.hi A.hs >> >> but nothing changed. > > Simon?? This is because ghc -M works like --make, in that it traverses the module dependency graph. When multiple modules are being considered, the -ohi flag doesn't make much sense (which module does it apply to?). The right way is to use -hidir/-hisuf, which are honoured by -M and --make. Cheers, Simon

2 1

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

17 Feb '05

On 17 February 2005 13:48, Daan Leijen wrote: > Secondly, maybe ghc should not generate the spurious extra rules? > (and generate exactly what it generated at version 6.2.2). What do > you think Simon? ghc -M now works like --make and GHCi: it follows dependencies. In fact, it's using the same code internally (previously there was some duplication). Partly the reason for this change was we needed enhancements to the dependency tracking for the new .hs-boot mechanism. There's no way to make ghc -M *not* follow dependencies. I assume that what you're doing is generating dependencies for each source file separately, right? I wonder if perhaps we should have a way to prevent ghc -M from generating dependencies on files that aren't explicitly mentioned on the command line. >> 3. Package stuff >> I included package files in the new style to the configure script. >> Problem: the environment variable are not substituted any longer by >> ghc-pkg ? > > Simon? That's right, I was too lazy to implement it, and in any case it's slightly dubious - the expansion happened after parsing, so can an environment variable expansion result in multiple list items? Mostly we pre-process our package.conf files using CPP instead of using environment variables, or we use autoconf. Could you do that? Cheers, Simon

1 0

Re: ghc-cvs-snapshot with wxHaskell
by Georg Martius 17 Feb '05

17 Feb '05

Hi, Patrick and I found some answers to the questions/problems we encountered. Finally got the thing to work. (patches appended) Versions: ghc-6.4.20050215 wxHaskell-0.8. 1. dep-files the new ghc produces a different dependency file. It includes also dependencies for imported modules. i.e. > module A import B it generates: > B.o : B.hs > A.o : A.hs > A.o : B.hi where as the old ghc omitted the first line, which is not necessary IMO. The problem with the wx-Makefile is now that the .o and .hi files should reside in another directory namely out/... The current approach is to use "sed". However on the new depfiles it generates rules, which are not correct and which lead to the problems Patrick experiences. I have a possible fix: add -odir out/... to the call of ghc -M. This produces correct paths for the .o files. use "grep" to filter module A Problem: the .hi files have still the source path. Question @Daan: Why do they have to by in out/...? It seams to complicate the thing. Solution: "sed" I fixed that in "makefile.lib". Now the dependency stuff seams to work fine. No double compilation anymore. 2. correct import-search path the make file calls ghc from the wxHaskell-root. Therefore -icurrent/source/path has to be included. I fixed that in "makefile". 3. Package stuff I included package files in the new style to the configure script. Problem: the environment variable are not substituted any longer by ghc-pkg ? My hack: let configure sustitude the variable, i.e. configure:750 > wxhlibdir="${libdir}" . . > import-dirs: ${wxhlibdir}/imports instead of > import-dirs: \${wxhlibdir}/imports This might cause problems with the rpm install stuff. Additionally, I had problems with the license field. It seams to be a choice rather a text-field. I took BSD3 since it worked. @Simon: How can I add a custom license like "wxWindows" @Daan: Please complete the package files. There are a couple of new entries. Also some exports from wxcore might be better in the hidden-modules field. Honestly I have no idea where it is for. A had to add a > extra-libs : wxc-gtk2.4.2-0.8 to wxcore package info. This seams not quite portable :-). @Daan: please replace this by a proper variable 4. Module name clash ghc complained: wxdirect/src/Set.hs:1:0: Module `Set' is a member of package data-1.0. To compile this module, please use -ignore-package data-1.0. I love ghc's error messages! Great job Simon! @Daan: the configure script uses /usr as a default prefix. I think /usr/local is more standard here. Additionally the modules are installed to <prefix>/lib/imports. I would rather like <prefix>/lib/wxHaskell/imports. How do we make sure that nobody else wants to use the path lib/imports? This is a fairly common, or at least non-specific, directory name in my eyes. Cheers, Georg On Thu, 17 Feb 2005 00:44:23 +0100, Patrick Scheibe <mai99dnn(a)studserv.uni-leipzig.de> wrote: > On Wednesday 16 February 2005 16:48, you wrote: >> Hi Simon and Daan. >> >> I took the stable ghc source from yesterday, 15th of february. >> I think Simon fixed the creation of .depfiles problem, am I right? >> Touching of these files is unnecessary now. >> >> In earlier versions the ghc seems to make the right thing when you call >> ghc -M ./dir1/dir2/src/Moduldir/Modul.hs >> >> Now there are errors when you call it from outside the modulpath: >> > Could not find module `ParseEiffel': >> > use -v to see a list of the files searched for >> > (imported from wxdirect/src/CompileDefs.hs) >> >> I fixed this with giving the -i./dir1/dir2/src option to every call. >> @Simon: is this a feature? Do I make something strange with this fix? >> >> Now the compilation runs fine (:-) but when I do a make install, the >> makefile begins to compile again!?? After a while of compilation it breaks >> with a "no rule to make.." error. How can ghc forget the compiled stuff? >> The objects are definitely there, so there is no need to recompile WX.o, >> ... >> >> @Daan: I tried to delete the dependency wx from the install rule of the >> makefile but that >> doesn't matter. I would like to install it by myself to see if the lib is >> working. Do you have a quick bad fix of this? >> >> Cheers >> Patrick > -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

2 4

RE: compiling GHC with a custom path to GCC
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 12:54, Seth Kurtzberg wrote: > Here are the bug reports: > http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_statu s=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=WAITING&bug_sta tus=SUSPENDED&field0-0-0=product&type0-0-0=substring&value0-0-0=internal &field0-0-1=component&type0-0-1=substring&value0-0-1=internal&field0-0-2 =short_desc&type0-0-2=substring&value0-0-2=internal&field0-0-3=status_wh iteboard&type0-0-3=substring&value0-0-3=internal&field1-0-0=product&type 1-0-0=substring&value1-0-0=compiler&field1-0-1=component&type1-0-1=subst ring&value1-0-1=compiler&field1-0-2=short_desc&type1-0-2=substring&value 1-0-2=compiler&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0 -3=compiler&field2-0-0=product&type2-0-0=substring&value2-0-0=error&fiel d2-0-1=component&type2-0-1=substring&value2-0-1=error&field2-0-2=short_d esc&type2-0-2=substring&value2-0-2=error&field2-0-3=status_whiteboard&ty pe2-0-3=substring&value2-0-3=error Zarro Boogs found. Cheers, Simon

1 0

RE: compiling GHC with a custom path to GCC
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 12:05, Seth Kurtzberg wrote: > I'm not positive about 2.95, but I know that on 3.x it crashes in > different places, and even compiling different source files. With > each 3.x release, they fix some of them, but others pop up to take > their place. Clearly the gcc people don't know what's going on. Are you sure this isn't a hardware problem on your system? gcc crashing randomly is usually an indicator of bad memory or similar. Cheers, Simon

2 2

RE: compiling GHC with a custom path to GCC
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 11:49, Seth Kurtzberg wrote: > Simon Marlow wrote: > >> On 17 February 2005 11:12, Remi Turk wrote: >> >> >> >>> when compiling the new ghc pre-releases made my gcc 2.95.3 die >>> with "internal compiler error", I tried to compile it with gcc >>> 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that >>> died, compiled+installed gcc 3.4.3, tried again, say it die again >>> and only then noticed it was actually still using 2.95.3 ;) but >>> had quite some difficulty to actually get it to compile with, in >>> my case, /usr/local/bin/gcc3 >>> >>> When using the following command-line >>> >>> CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl >>> --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 >>> >>> stage1 still used gcc 2.95.3 to compile stage2 (okay, for >>> --with-gcc that's documented) >>> >>> >> >> Really? --with-gcc should set the gcc for stage1, AFAIK. Is there >> a bug here? >> >> I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look >> into whether there's a workaround, otherwise we're hosed on FreeBSD >> 4.x. >> >> > This is a known problem in all the 3.x compilers, and also occurs, > although less often, with 2.9x versions. I've seen no difference in > frequency comparing FreeBSD to Linux and NetBSD. > > The only solution, which is of course highly annoying, is to simply > restart the make. For whatever reason this always works, sometimes > until the end of the build, and sometimes until some other crash. My > theory is that it is related to the temporary files that gcc creates, > mostly for templates. > > While a royal PITA, the resulting code is correct. A known problem? Is there any open bug in the gcc bug database I can look at? Cheers, Simon

3 5

RE: Increasing heap size
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 10:55, Dmitri Pissarenko wrote: >> Actually you need to use the -M option to increase the heap size >> beyond this limit on Windows. I'll see if I can fix the message. > > Thanks for your answer! > > I tried to use option "+RTS -c -RTS" and then it worked without > changing the heap size (AFAIK this switches garbage collection to a > more efficient algorithm). Using +RTS -c -RTS turns on in-place compacting collection, which will use less memory but takes longer. If you use +RTS -M<size> -RTS, then GHC will automatically turn on compacting collection when the program's memory requirements approach <size>. Cheers, Simon

1 0

RE: Increasing heap size
by Simon Marlow 17 Feb '05

17 Feb '05

On 15 February 2005 20:12, Dmitri Pissarenko wrote: > 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. Actually you need to use the -M option to increase the heap size beyond this limit on Windows. I'll see if I can fix the message. Cheers, Simon

2 1