February 2005 - Glasgow-haskell-users

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 17 Feb '05

17 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

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