- Glasgow-haskell-users

jadetex (was: Re: reaping fd's and flushing buffers)
by Michael Weber 09 Jan '03

09 Jan '03

On Thu, Jan 09, 2003 at 02:37:03AM -0800, William Lee Irwin III wrote: > On Mon, Jan 06, 2003 at 06:13:27AM -0800, William Lee Irwin III wrote: > > Thanks, I've started brewing up a tree and I'll take that for a spin > > when it's done cooking. > > ouch! jadetex needs an upgrade (ghc debian maintainer?). Probably related to this bug: http://bugs.debian.org/171985 ? (also includes hint for workaround) Cheers, Michael

1 0

RE: reaping fd's and flushing buffers
by Simon Marlow 09 Jan '03

09 Jan '03

> Sure enough, after I say that all my fd reaping issues are solved at > the Haskell level, I've been bitten by issues that look like the RTS > doing things behind my back wrt. reaping fd's etc. etc. > > Basically, while I used socketToHandle the fd's got closed > prematurely, > and once I eliminated all uses of it, the socket fd's appeared to leak > despite attempts to explicitly close them. > > Also, there were some very strange goings-on with respect to attempts > to flush buffers after the fd's they were being flushed to > were closed. > > So, what are the semantics here? I wouldn't rule out a bug here. Sockets are actually implemented as two independent handles internally, one each for the read side and write side so that each side gets a separate buffer and duplex reading/writing from different threads is supported. The programmer still just sees a single Handle. The tricky bit is knowing when the socket can be closed: both sides have to be unreferenced by the program. We handle this by having the read side point to the write side, and then place the finalizer on the write side. The finalizer should then only run when both sides are unreferenced (of course, it's always better to do the closing explicitly if you can). ... actually I've just looked at the code and it looks wrong, aargh! The finalizer is attached to the wrong side. If you have a source tree handy, try changing the following line in libraries/base/GHC/Handle.hs: addMVarFinalizer read_side (handleFinalizer read_side) to addMVarFinalizer write_side (handleFinalizer write_side) Cheers, Simon

2 2

RE: Linking with object files
by Simon Marlow 09 Jan '03

09 Jan '03

> On Wednesday 08 January 2003 5:00 pm, Simon Marlow wrote: > > What command line are you using? Here's what I did: > > > > ~/scratch > cat >foo.c > > ~/scratch > gcc -c foo.c > > ~/scratch > ghc --make hello.hs foo.o > > ghc-5.04.2: chasing modules from: hello.hs > > Skipping Main ( hello.hs, ./hello.o ) > > ghc: linking ... > > ~/scratch > > > The exact command line I'm using is.. > ghc --make -fglasgow-exts -Wall -o Main.exe Main.hs Fill.o Render.o > which gives.. > ghc-5.04.2: chasing modules from: Main.hs,Fill.o,Render.o > ghc-5.04.2: can't find module `Fill.o' (while processing "Fill.o") > > But playing about a bit, I found the solution. It doesn't like > upper case object file names. Not sure if that's by design or an > oversight. I've changed them to lower case and it works fine now. Eek! That's a bug, thanks! Cheers, Simon

1 0

RE: Linking with object files
by Simon Marlow 09 Jan '03

09 Jan '03

> On Wednesday 08 January 2003 10:04 am, Simon Marlow wrote: > > > I get the error.. can't find module 'foo.o' <while > processing "foo.o"> > > > > I think you must be using a version of GHC prior to 5.04.2. This > > functionality was fixed in 5.04.2. > > I just checked, it really is (or claims to be:-) version 5.04.2. > I get the same error using 5.04.2 under Linux too. What command line are you using? Here's what I did: ~/scratch > cat >foo.c ~/scratch > gcc -c foo.c ~/scratch > ghc --make hello.hs foo.o ghc-5.04.2: chasing modules from: hello.hs Skipping Main ( hello.hs, ./hello.o ) ghc: linking ... ~/scratch > Actually I was incorrect before: this has worked fine in 5.04, 5.04.1 and 5.04.2. The fix made in 5.04.2 was to pass files without a recognised extension through to the linker, to match the behaviour without --make. Cheers, Simon

2 1

emacs haskell-ghci mode hook
by Christian Maeder 08 Jan '03

08 Jan '03

Hi, running ghci (instead of hugs) in (GNU-) emacs is quite fun. But a few improvements could even increase the fun: a) adding arguments to the ghci was not well documented. So I appended the following (and a few more paths) to my .gnu-emacs: ;(add-hook 'haskell-mode-hook 'turn-on-haskell-hugs) (add-hook 'haskell-mode-hook 'turn-on-haskell-ghci) (setq haskell-ghci-program-args (append '("-fglasgow-exts") '("-fallow-overlapping-instances") '("-Wall") '("-package data") '("-i.:..") )) b) When an error occurs, the cursor jumps to the first error or warning. That's ok, but sometimes a warning is produced by an imported Module that has no errors and then this file is loaded into the buffer. Usually, I try to avoid all warnings, but I was not able to avoid: Warning: Module `I' is imported, but nothing from it is used (except perhaps to re-export instances visible in `I') Indeed I want to import only instances from `I'. Maybe the warning can be suppressed when I explicitely write "import I()" to indicate that I import nothing except instances. (I don't want to switch off that import warning completely.) c) Can someone supply emacs commands (and keys) to step through all the errors and warnings? Regards Christian

4 4

Two Questions: 'memory consumption' and '-pgmL'
by Peter Simons 08 Jan '03

08 Jan '03

Hi everybody, first of all, let me thank you for writing and maintaining this excellent compiler! I am using it a lot recently and I couldn't be more happy with it. Thanks! :-) I wouldn't be posting here, though, if hadn't had a questions ... So here I go: (1) Using the DtdToHaskell tool, I converted the XML Docbook DTD to Haskell code. The resulting parser is amazing: It is almost 4 megabyte large, 72800 lines of code. Now I tried to compile this beast and ran fresh out of memory. I fiddled with the RTS options to no avail. At some point GHC was consuming more than 800 megabytes of RAM, what resulted in serious thrashing (my machine has only 512 MB) and eventually the process was terminated. Does anyone have by any ideas how I could tackle this problem? Can I reduce GHC's memory requirements somehow? Can I split the module up and compile it in parts? In different phases? Anything? (If nothing comes up, I guess buying some more RAM is the answer.) (2) According to the documentation, GHC allows for setting the literate pre-processor to be used when compiling an .lhs file. This is supposed to occur with the '-pgmL' option, but no matter what I try, GHC always tells me: | ghc-5.04.2: unrecognised flags: -pgmL | Usage: For basic information, try the `--help' option. Am I doing something wrong or is the documentation out of synch with the implementation? Any comments will be appreciated! -peter P. S.: I am not subscribed to this list, so please Cc any replies to me.

1 0

trying to build from cvs - "cc1: bad value (athlonmp) for -march= switch"
by Shae Matijs Erisson 08 Jan '03

08 Jan '03

------------------------------------------------------------------------ ==fptools== make all -wr; in /home/shae/build/haskell/fpbuild/ghc/rts ------------------------------------------------------------------------ ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-O2 -optc-fomit-frame-pointer -optc-mpreferred-stack-boundary=2 -optc-march=athlonmp -optc-DTHREADED_RTS -H16m -O -O2 -static -c Adjustor.c -o Adjustor.o cc1: bad value (athlonmp) for -march= switch cc1: bad value (athlonmp) for -mcpu= switch make[2]: *** [Adjustor.o] Error 1 make[1]: *** [all] Error 1 running "gcc -v" gives: Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.2/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux Thread model: posix gcc version 3.2.2 20021231 (Debian prerelease) Athlon MP is the correct arch/cpu, and gcc 3.2.2 has -march=athlonmp available. Any ideas? -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion

1 0

RE: Linking with object files
by Simon Marlow 08 Jan '03

08 Jan '03

> I seem to be having some trouble doing this and have a couple > of questions.. > > The first question is how do you use --make option when doing this? > Section 4.5 of the users guide seems to contradictory to me. > > It states.. > "The command line must contain one source file or module name" This is wrong (or at least, out of date). I'll fix it. You can now specify any number of source files, module names, linkable objects and libraries on the command line in --make mode or GHCi. > and later.. > "If the program needs to be linked with additional objects (say, some > auxilliary C code), these can be specified on the command > line as usual." > > > ghc Main.hs foo.o > is OK, but whenever I try this... > > > ghc --make Main.hs foo.o > I get the error.. can't find module 'foo.o' <while processing "foo.o"> I think you must be using a version of GHC prior to 5.04.2. This functionality was fixed in 5.04.2. > The second question is what object formats does ghc > understand and is the > object file suffix significant? If I try elf format, this is > accepted without > complaint but I get a broken executable (though this could > well be because > my assembler has generated a broken elf file). Using coff > format seems OK. > The files have a ".o" suffix in both cases. > > FWIW, I'm using ghc 5.04.2 on Win32 with the nasm assembler. I'm not sure about this one - any Windows experts out there like to comment? My guess is that GHCi should load COFF objects only, but other kinds of objects might work when using the system linker (i.e. in batch mode). Cheers, Simon

2 1

RE: ghc more aggressive with Ints?
by Simon Peyton-Jones 08 Jan '03

08 Jan '03

| > sumMinusOnce l = foldr sumMinus (0,0) l | > where sumMinus c (a,b) = (a+c, c-b) | > | > sumMinusTwice l = (foldr (+) 0 l, foldr (-) 0 l) | Here, we see that for everything but INT, the ONCE version is about two | times slower. For the other versions | (say DOUBLE), the ONCE version is consistently two times slower. This | raises the question as to why. The reason turns out to be that Int enumerations [1..100] are carefully expanded to build (enumFromToInt 1# 100#) where enumFromToInt is a hand-written unboxed version of enumFromTo. So we get list deforestation from the fold/build. (Incidentally, this may not happen if there are several calls to sumMinusOnce, or it's exported, because the fold will only see the build if sumMinusOnce is inlined.) The Double version uses the vanilla numericEnumFromTo (as in the Report) which does not expand to a 'build'. So no fold/build happens. By adding more code to the Prelude, one could 'fix' this, by making numericEnumFromTo have a build version. Whether this is worth the bother is not clear to me. If anyone is motivated to do it (needs understanding of how RULES work) by all means do so. Simon | | Looking at the -ddump-simpl output, we can see why. In the sumMinusOnce | version, when given an Int type signature, the tuple gets | unboxed and the primitive GHC.Prim.+# and GHC.Prim.-# functions are | used. In the one where we've given a Double type signature, we don't get | this. The tuple still gets unboxed, but the non-unboxed functions | GHC.Float.plusDouble and GHC.Float.minusDouble functions are used instead. | | Perhaps more importantly, the Double version is left as a recursive call, | looking something like: | | > Main.$wgo = \w -> | > case w of | > (y:ys) -> case Main.$wgo ys of | > (# ww1, ww2 #) -> | > (# plusDouble ww1 y, minusDouble y ww2) #) | > [] -> (# 0, 0 #) | | (converted by hand from simpl-core to a more Haskelly syntax) | | However, the Int version becomes a very tight loop in which the list is | deforested. | | My understanding was that using list comprehensions like [1..100000] | together with foldr you would always get build/fold deforestation, but | this only seems to happen when the list is a list of Ints, not a list of | Doubles. | | If we change the Once function to: | | > i2d :: Int -> Double | > i2d = fromInteger.toInteger | > | > sumMinusOnce :: [Int] -> (Double, Double) | > sumMinusOnce l = foldr sumMinus (0,0) l | > where sumMinus c (a,b) = (a+i2d c, (i2d c)-b) | | then we do get full deforestation as we want. This new version, when run | with [1..250000], yields a time of | | 4.12u 0.23s 0:04.44 | | which is actually faster than the TWICE/DOUBLE version. | | So...why is GHC more aggressive with Ints than with Doubles and what are | the additional conditions under which fold/build deforestation occurs? | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ghc more aggressive with Ints?
by Hal Daume III 07 Jan '03

07 Jan '03

Hi, This is somewhat related to an earlier post about streaming by Jorge, and to a similar post by me a bunch of months back regarding multiple ways of writing a similar function. Many times when processing data which you need to process in more than once way, you have two options: (1) process it in one go and store intermediate results as, eg, tuples; (2) process it in more than one go. I've been told that the latter is the more "haskelly" way to do it, but I don't completely buy that. Especially in cases like Jorge's, since the data will not be able to be garbage collected between runs and thus the whole program will require a much larger stack/heap/whatever. In either case, consider the following (semantically equivalent) functions: > sumMinusOnce l = foldr sumMinus (0,0) l > where sumMinus c (a,b) = (a+c, c-b) > > sumMinusTwice l = (foldr (+) 0 l, foldr (-) 0 l) The first takes one pass over the data, while the second takes two. Now, we can give these functions various type signatures, Int, Integer, Float or Double (more, of course, but these are the basics). When the list is [1..250000], the timing results look like: | ONCE | TWICE --------+------------------------+------------------------ INT | 1.81u 0.18s 0:02.07 | 1.84u 0.15s 0:01.99 INTEGER | 9.77u 0.28s 0:10.29 | 5.07u 0.07s 0:05.23 FLOAT | 8.60u 0.30s 0:09.08 | 3.79u 0.16s 0:04.07 DOUBLE | 9.50u 0.25s 0:09.82 | 4.25u 0.16s 0:04.44 Here, we see that for everything but INT, the ONCE version is about two times slower. If we pump the input size up to [1..1000000], then the times for INT become INT | 16.38u 0.66s 0:17.22 | 20.75u 0.34s 0:21.33 Here, there's a much smaller difference in speed. For the other versions (say DOUBLE), the ONCE version is consistently two times slower. This raises the question as to why. Looking at the -ddump-simpl output, we can see why. In the sumMinusOnce version, when given an Int type signature, the tuple gets unboxed and the primitive GHC.Prim.+# and GHC.Prim.-# functions are used. In the one where we've given a Double type signature, we don't get this. The tuple still gets unboxed, but the non-unboxed functions GHC.Float.plusDouble and GHC.Float.minusDouble functions are used instead. Perhaps more importantly, the Double version is left as a recursive call, looking something like: > Main.$wgo = \w -> > case w of > (y:ys) -> case Main.$wgo ys of > (# ww1, ww2 #) -> > (# plusDouble ww1 y, minusDouble y ww2) #) > [] -> (# 0, 0 #) (converted by hand from simpl-core to a more Haskelly syntax) However, the Int version becomes a very tight loop in which the list is deforested. My understanding was that using list comprehensions like [1..100000] together with foldr you would always get build/fold deforestation, but this only seems to happen when the list is a list of Ints, not a list of Doubles. If we change the Once function to: > i2d :: Int -> Double > i2d = fromInteger.toInteger > > sumMinusOnce :: [Int] -> (Double, Double) > sumMinusOnce l = foldr sumMinus (0,0) l > where sumMinus c (a,b) = (a+i2d c, (i2d c)-b) then we do get full deforestation as we want. This new version, when run with [1..250000], yields a time of 4.12u 0.23s 0:04.44 which is actually faster than the TWICE/DOUBLE version. So...why is GHC more aggressive with Ints than with Doubles and what are the additional conditions under which fold/build deforestation occurs? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0