- Glasgow-haskell-users

segfault/massive memory use when using Data.Bits.shiftL
by Ganesh Sittampalam 28 Feb '05

28 Feb '05

Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh

3 4

Re: GHC 6.4 release candidates available
by Malcolm Wallace 28 Feb '05

28 Feb '05

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > I think I've fixed this (on the head anyway; simon will merge to branch > shortly). Care to try again? Yup, the toplevel rigid type-variable problem seems to have been fixed, thanks. nhc98 now builds as expected with ghc-6.4. BTW, there seems to be a small documentation-packaging fault in the linux binary distribution. You may be aware of it already. $ make install ... if test -d share/html; \ then cp -r share/html/* /usr/malcolm/local/share/ghc-6.4.20050227/html; \ fi for i in share/*.ps; do \ cp $i /usr/malcolm/local/share/ghc-6.4.20050227 ; \ done cp: cannot stat `share/*.ps': No such file or directory $ Regards, Malcolm

1 0

RE: ghc HEAD and tee
by Simon Marlow 28 Feb '05

28 Feb '05

On 25 February 2005 15:48, Christian Maeder wrote: > we used redirect output of ghc via "tee" (within a Makefile). With the > new ghc this randomly fails now. Does anyone have an explanation for > this? > > ghc <<omitted args>> 2>&1 | tee log > > yields: > > Skipping Main ( hets.hs, hets.o ) > Linking ... > tee: write error > > > The linked binary and the log file are ok afterwards (and the mere > size of the log is also no problem). Hmm, I can't reproduce this behaviour, and I can't imagine what the problem is: the error message claims a write error, so that would seem to indicate some kind of problem writing the log file, which can't be affected by GHC. Or perhaps that's just a generic error message from tee. Can you give any more details that might help us to reproduce it? Cheers, Simon

1 0

RE: 6.2.2 x86_64 build failing
by Simon Marlow 28 Feb '05

28 Feb '05

On 28 February 2005 05:38, Kip Macy wrote: > In a clean tree I configured: > ./configure --prefix=/u/kmacy/usr/x86_64 > --with-ghc=/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64/ghc/compiler/ghc -inplace > > where the ghc-inplace is unregisterised, points to stage1, and is > known to compile "Hello World" > > > gcc -E -undef -traditional -P -I../includes -x c > prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl > < prelude/primops.txt > primop-data-decl.hs-incl > /bin/sh: line 1: 14846 Segmentation fault (core dumped) > ../utils/genprimopcode/genprimopcode --data-decl <prelude/primops.txt >> primop-data-decl.hs-incl > gmake[2]: *** [primop-data-decl.hs-incl] Error 139 > gmake[2]: *** Deleting file `primop-data-decl.hs-incl' > gmake[1]: *** [boot] Error 1 > gmake[1]: Leaving directory > `/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64-clean/ghc' > gmake: *** [build] Error 1 It looks like genprimopcode is crashing. This is significant, because genprimopcode is the first Haskell program to be compiled and run by the compiler that you are bootstrapping with, so this indicates that even though your unregisterised stage1 is known to compile "hello world", it still has some problems. Try adding -debug when compiling genprimopcode, and run it with gdb to get a backtrace. Cheers, Simon

1 0

[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
by SourceForge.net 28 Feb '05

28 Feb '05

Feature Requests item #1153029, was opened at 2005-02-27 20:24 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_… Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern jnewbern(a)yahoo.com ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-02-28 11:01 Message: Logged In: YES user_id=48280 You can use hierarchical module names with --make, but your module names must be a lexically correct; that is, each component must begin with an upper case letter. App.Main would work, app.Main is not a module name. More information on hierarchical modules here: http://www.haskell.org/hierarchical-modules/ and in the GHC User Guide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_…

1 0

6.2.2 x86_64 build failing
by Kip Macy 27 Feb '05

27 Feb '05

In a clean tree I configured: ./configure --prefix=/u/kmacy/usr/x86_64 --with-ghc=/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64/ghc/compiler/ghc-inplace where the ghc-inplace is unregisterised, points to stage1, and is known to compile "Hello World" gcc -E -undef -traditional -P -I../includes -x c prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl < prelude/primops.txt > primop-data-decl.hs-incl /bin/sh: line 1: 14846 Segmentation fault (core dumped) ../utils/genprimopcode/genprimopcode --data-decl <prelude/primops.txt >primop-data-decl.hs-incl gmake[2]: *** [primop-data-decl.hs-incl] Error 139 gmake[2]: *** Deleting file `primop-data-decl.hs-incl' gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64-clean/ghc' gmake: *** [build] Error 1

1 0

[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
by SourceForge.net 27 Feb '05

27 Feb '05

Feature Requests item #1153029, was opened at 2005-02-27 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern jnewbern(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_…

1 0

build failure
by Kip Macy 25 Feb '05

25 Feb '05

I've followed the instructions for building on the host for an unregistered x86_64 build, but when I do: cd glafp-utils/ & make boot && make I get: <...> ls/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs ghc-6.4.20050224: Can't find codeGen/ClosureInfo.lhs-boot (imported from absCSyn/AbsCSyn.lhs) <<ghc: 153327128 bytes, 67 GCs, 2285585/5010648 avg/max bytes residency (4 samples), 20M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (4.42 elapsed), 0.13 GC (0.14 elapsed) :ghc>> make[2]: *** [depend] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/u/kmacy/src/ghc-6.2.2/ghc' make: *** [build] Error 1 [1] + Done cd glafp-utils/

2 1

GHCi and C++.
by Lemmih 25 Feb '05

25 Feb '05

Greetings fellow Haskellers and other readers, During my ongoing research on "doing whatever I feel like", I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. -- Friendly, Lemmih

4 6

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 25 Feb '05

25 Feb '05

On 24 February 2005 20:11, Sven Panne wrote: > Simon Marlow wrote: >> On 22 February 2005 19:37, Duncan Coutts wrote: >>> Excellent! Thanks a lot. >>> Any hint as to when the next Haddock release will be? >> Maybe when I've got this GHC release out of the way and my hair has >> grown back :-S > > Before we do a release, I think two issues should be solved IMHO: > > * The table/CSS chaos on the contents page has to be cleaned up, > the package ids on the right look like being layout by somebody > drunk... %-) They don't look too bad to me... a bit far to the right, perhaps, but not too bad. Perhaps some lines in that table would help, or alternating grey/white background for the rows? > * The state of the +/- buttons should be remembered when using > backward/forward in a browser (cookies + ECMA script?). If anyone knows how to do this, then please go ahead. I don't think it's urgent for the release though - by default the collapsible sections are now expanded, and anyway the right way to use the contents page is to middle-click on the module name in Firefox ;-) Cheers, Simon

2 1