- Glasgow-haskell-users

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

RE: GHC-problem with parsing infix type synonyms - bug?
by Simon Marlow 17 Feb '05

17 Feb '05

On 16 February 2005 14:41, Johan Glimming wrote: > I read from the type-extensions.html part of the GHC 6.2 manual: > > "After expanding type synonyms, GHC does validity checking on types, > looking for the following mal-formedness which isn't detected simply > by kind checking: ... Partially-applied type synonym." > > However, when entering: > > > infix 9 :-+-: > > type (f :-+-: g) t o1 o2 = Either (f t o1 o2) (g t o1 o2) > > or simpler variations e.g. without brackets, except where no arguments > are present after (f :-+-: g), I get parse errors (yes, _parse_) on > this very line. > > Also, the above works for data, and the "lexical syntax is the same as > that for data constructors" [someone had read this somewhere]. I think the syntax used in your type synonym declaration isn't supported at the moment. For consistency it probably should be. Cheers, Simon

2 1

duplicate import warning
by John Meacham 16 Feb '05

16 Feb '05

In 6.4 the duplicate import warning seems to be triggered overzealously, even when one import is qualified and the other isn't. import qualified Data.Map import Data.Map(Map) foo :: Map Int Int foo = Data.Map.empty main = do print foo produces: Foo.hs:1:0: Warning: `Map' is imported more than once: imported from Data.Map at Foo.hs:3:16-18 imported from Data.Map at Foo.hs:2:0-24 -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: writing to stdout in an windows app without a console
by Simon Marlow 16 Feb '05

16 Feb '05

On 16 February 2005 14:06, Duncan Coutts wrote: > On Wed, 2005-02-16 at 14:31 +0200, Krasimir Angelov wrote: >> On Wed, 16 Feb 2005 12:01:06 +0000, Duncan Coutts >> <duncan.coutts(a)worc.ox.ac.uk> wrote: >>> What's your opinion of making writing to stdout fail without >>> raising an exception when the application is compiled with >>> --subsystem >>> windows? >> >> I think the current behaviour is the right one. After all we don't >> have valid stdout/stdin and I don't see any reason to hide this. > > True, but it's not the behaviour that other windows programming > systems implement: > > For example MS's C library happily ignores output to stdout: > > #include <stdio.h> > > int main () { > int res_code = fprintf(stdout, "hello world!\n"); > fprintf(stderr, "res_code = %d\n", res_code); > > return 0; > } > > now compiling with mingw's gcc: > gcc testio.c -Xlinker --subsystem -Xlinker windows > > and from a windows console (ie not a msys / cygwin window) > > a.exe 2> err > > then saying "type err" gives us the output: > res_code = 13 I've seen this behaviour vary between versions of Windows (maybe even between versions of msvcrt, MS's C library). A strange experience we had with the Visual Studio extension was that I was initially just doing output to stderr from the DLL for debugging, which worked fine on my machine but crashed on other people's machines. We had to remove all uses of stdout/stderr from the Haskell DLL (including the runtime!) to get it going reliably. Cheers, Simon

2 1

GHC-problem with parsing infix type synonyms - bug?
by Johan Glimming 16 Feb '05

16 Feb '05

Hi I read from the type-extensions.html part of the GHC 6.2 manual: "After expanding type synonyms, GHC does validity checking on types, looking for the following mal-formedness which isn't detected simply by kind checking: ... Partially-applied type synonym." However, when entering: > infix 9 :-+-: > type (f :-+-: g) t o1 o2 = Either (f t o1 o2) (g t o1 o2) or simpler variations e.g. without brackets, except where no arguments are present after (f :-+-: g), I get parse errors (yes, _parse_) on this very line. Also, the above works for data, and the "lexical syntax is the same as that for data constructors" [someone had read this somewhere]. Best Wishes, Johan Glimming

1 0

writing to stdout in an windows app without a console
by Duncan Coutts 16 Feb '05

16 Feb '05

This might be a bug report but it's definitely a question on what the behaviour should be: On windows if you link using "--subsystem windows" then your program starts without popping up a console. This is good for GUI apps (and we would like to make it the default when using gtk2hs on win32 by adding --subsystem windows to the linker flags in the gtk package file). Apparently, Windows default behaviour if a program without a console (ie a gui program linked using --subsystem windows) writes to stdout is to silently discard the output. Though exactly which bit of the windows tech stack implements this behaviour I am not sure. With ghc on windows, upon writing to stdout you get an IO exception: Fail: <stdout>: hPutChar: failed (Bad file descriptor) One can see how this is reasonable behaviour since there really isn't any output handle (unlike on unix where there would be a valid stdout fd but it'd be connected to /dev/null). On the other hand it is not so helpful since it means anyone who's not aware of this behaviour will bring their program to a immediate halt without any obvious explanation as to what went wrong. In fact the only way to see what really happened is from a windows console: hello.exe 2> err.txt So the stdout is still disconnected from the console (despite launching the program from the console!) but stderr, where the IO exception message gets written, can be captured. So I'm wondering if it would be better to arrange that output to stdout/stderr gets silently discarded in the case that stdout/stderr are not connected rather than raising an exception. I have no idea how difficult this hack would be to implement. Otherwise for our windows users who ask: "how do I get rid of that ugly black window behind my gui app?" we'll have to say "use --subsystem windows BUT!... never use print/putStr and friends or your program will be killed instantly! This includes making sure any other Haskell libraries you use do not use the standard output or print any error messages (eg using Debug.Trace)" Duncan

2 4

definition of take
by Jorge Adriano Aires 16 Feb '05

16 Feb '05

Hi, I don't know much about the internals of GHC, but I like look around once in a while to learn a few things. I was wondering about the definition of take, which is, for Ints: --------------------------------------------------------------------- takeUInt :: Int# -> [b] -> [b] takeUInt n xs | n >=# 0# = take_unsafe_UInt n xs | otherwise = [] take_unsafe_UInt :: Int# -> [b] -> [b] take_unsafe_UInt 0# _ = [] take_unsafe_UInt m ls = case ls of [] -> [] (x:xs) -> x : take_unsafe_UInt (m -# 1#) xs --------------------------------------------------------------------- Wouldn't pattern matching against 1# instead of 0#, like in the following definition, be better in terms of garbage collecting the list or what it depends on? ----------------------------------------------------------------------- takeUInt :: Int# -> [b] -> [b] takeUInt 0# _ = [] takeUInt n xs | n ># 0# = take_unsafe_UInt n xs | otherwise = [] take_unsafe_UInt :: Int# -> [b] -> [b] take_unsafe_UInt 1# (x:xs) = [x] take_unsafe_UInt m ls = case ls of [] -> [] (x:xs) -> x : take_unsafe_UInt (m -# 1#) xs ------------------------------------------------------------------ My guess would be that, if we're consuming a (take n xs) lazily, with the first definition garbage collecting would happen when the last element had been consumed and with the second, when the last element had been produced - (which is when we find out there are no more elements to consume in each case). Thanks, and sorry if the question is to naive, J.A.

1 0