October 2003 - Glasgow-haskell-users

Re: package treating
by Serge D. Mechveliani 23 Oct '03

23 Oct '03

Thanks to Simon Marlow for the explanations. > > By the way, I somehow lost the way to the Postscript file of the > > GHC User Guide, how does one get it? > > http://www.haskell.org/ghc/documentation.html > With .ps, I sometimes print the Manual to the paper, to book. Say, print the pages 1 -- 300. I do not know how to do this with .html. I can convert some small part to .ps when viewing .html. But it is desirable to be able to convert it all to one .ps file. I am sorry for the ignorance, but does .html replace fully .ps ? On DoCon test for GHC --------------------- is suggestion to use DoCon for the automatic GHC test. For many years, almost any new GHC version has a bug which is displayed by 1) `making' DoCon ported from the last GHC version, 2) running T_.test. Simon Marlow wrote that the reason for not doing this is that it is a lot of code for the nightly builds. But DoCon source + manual.ps make a file docon-xxx.zip of about 800 K byte, 5 times smaller than ghc-src. It builds in a couple of minutes, it is 20 times faster than ghc builds from source. On last reliable GHC version ---------------------------- For any occasion: it is good to always keep available on public the latest reliable GHC version. For example, the DoCon program failed (so far) with ghc-6.0.1, due to the gc bug in ghc. And the DoCon Installing guide says: "it was tested for ghc-5.02.2 ...". At least, DoCon user should be able to download and install this ghc-5.02.2 (in this particular case, I suspect, 5.04 fits). With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Optimization options?
by Simon Marlow 23 Oct '03

23 Oct '03

> User's Guide 6.2 says: > > "So, when we want very fast code, we use: -O -fvia-C." > > but I've seen programs which use the (apparently > undocumented) -O2-for-C flag too. -O2-for-C was removed (from the docs at least) for three reasons: - it is equivalent to -optc-O2 - GCC has a recent history of bugs in -O2, and we didn't want to encourage people to use known-broken compiler options. - it makes very little difference anyway. Cheers, Simon

1 0

RE: Posible bug while optimizing? (Was: RULES for SPECIALIZ(E)ations)
by Simon Peyton-Jones 23 Oct '03

23 Oct '03

Oh yes, this is a bug all right. I'm looking into it. Thanks for reporting it S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Juanma Barranquero | Sent: 22 October 2003 09:58 | To: GHC users | Subject: Re: Posible bug while optimizing? (Was: RULES for SPECIALIZ(E)ations) | | An even simpler example, with just one module: | | ------------------------------------------------------- | module Test where | | import Data.List (genericLength) | | {-# RULES | "genericLength/length" genericLength = length | #-} | ------------------------------------------------------- | | D:\...\hask> ghc -O -fglasgow-exts --make Test.hs | Chasing modules from: Test.hs | Compiling Test ( Test.hs, ./Test.o ) | | D:\...\hask> ghc -O -fglasgow-exts --make Test.hs | Chasing modules from: Test.hs | Skipping Test ( Test.hs, ./Test.o ) | | tcLookupGlobal (id): `Data.List.genericLength' is not in scope | When checking the transformation rule "genericLength/length" | | Surely that *must* be a bug, mustn't? | | | | Juanma | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Re: <interactive>: internal error, ghc-6.0.1
by Serge D. Mechveliani 22 Oct '03

22 Oct '03

On Wed, Oct 22, 2003 at 12:23:51PM +0100, Simon Marlow wrote: > > This is on > > ghc-6.0.1 > > installed from RPM on Red Hat Linux release 7.3 (Valhalla), > > i-386 unknown. > > > > Probably, you can reduce the example several times more. > > > > ghci Main +RTS -M1m -RTS > > > > ..> : Main > > ..> main > > ... > > (<interactive>: internal error: thread_stack: > > weird activation record found on stack: 1564 > > Please report this as a bug to glasgow-haskell-bugs(a)haskell.org .. > > > > Probably, the interpreter manages memory in a wrong way. > > Can you reproduce the effect? > That's a bug, thanks for the report. > > Just out of interest, why are you passing the -M1m flag to ghci? This > sets a bound of 1M on GHC's memory, and causes the compacting GC to kick > in when this bound is approached (which will be almost immediately). > The bug was in the compacting garbage collector, which explains why it > hasn't shown up until now. I was deliberately passing various -Mxx flags to ghci because wanted to find where this simple program manages wrongly the memory. I did this `instead' of increasing the list [1..n] in the example. And I started this test after DoCon's real test crashed in ghci, within reasonable memory, somewhat about -M40m. And generally, it is desirable for the tool to allow, if the user ask this, doing large computation in posibly small space, even by spending much more time. The smaller space suffices, the more flexy and nicer the tool is -- this is my idea. With kind regards, ------------------ Serge Mechveliani mechvel(a)botik.ru

1 0

RE: RULES for SPECIALIZ(E)ations
by Simon Peyton-Jones 22 Oct '03

22 Oct '03

| | I suppose I'm being bitten by User's Guide 7.8.2: | | "If more than one rule matches a call, GHC will choose one arbitrarily | to apply." | | even if a bit later it says: | | "So a rule only matches if the types match too." | | Am I understanding right and it's that so? I think so. After all, the types match for count/generic too. Maybe you want a rule genericLength = length which will replace a call to (genericLength at type Int) by a call to length? You can also use "phases" to control order of rule application (albeit it's crude). http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#PHA SE-CONTROL Simon

2 3

RE: package treating
by Simon Marlow 22 Oct '03

22 Oct '03

> Now, does the package > > Package {name = "docon", > import_dirs = ["$(e)"], > source_dirs = [], > library_dirs = ["$(e)"], > hs_libraries = ["HSdocon"], > extra_libraries = [], > include_dirs = [], > c_includes = [], > package_deps = ["data"], > extra_ghc_opts = [$(extraPackageOpts)], > extra_cc_opts = [], > extra_ld_opts = [] > } > e = .../source/export > extraPackageOpts = such and such complier flags > > > specify of what it is intended? > In particular, what should be package_deps = [ ?? ] > ? package_deps should be a list of packages on which this package depends. More precisely, for every module M imported by a module in your package, if M is from another package P, you should include P in package_deps. That is, package_deps doesn't need to be transitively closed. Cheers, Simon

1 0

Re: package treating
by Serge D. Mechveliani 22 Oct '03

22 Oct '03

On Tue, Oct 21, 2003 at 02:03:03PM +0100, Simon Marlow wrote: > > > I presumed that, as the ghci > > command loads all usable libraries, then > > > > ghci -package-conf myPackage.conf -package myPackage > > > > will load all that `ghci' loads + > > what is specified in myPackage.conf. > > > > But, probably, this is not (should not be?) so: the option > > > > -package-conf myPackage.conf > > > > fully replaces the configuration, and the package search is done > > only according to what is specified in > > myPackage.conf > > , right? > No, packages are loaded on a demand-driven basis. Packages must have > correct dependencies specified, so that GHC can ensure that they are > loaded in dependency order. The -package-conf flag does not cause the > configuration to be "fully replaced". It is hard to understand how do they work. In my real practice, the project creates a package docon which refers to the .a, .o libraries in $(e)/ that are build earlier by `making' the project (.o library appears a bit later, at the stage of creating the package by ghc-pkg ... -u -g ). The project imports and re-exports Data.FiniteMap, (maybe, Data.Set,) and all the Standard library modules. The package should work both as ghci $dOpts UserModule and as ghc $dOpts --make UserModule with dOpts = -package-conf docon.conf -package docon Now, does the package Package {name = "docon", import_dirs = ["$(e)"], source_dirs = [], library_dirs = ["$(e)"], hs_libraries = ["HSdocon"], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = ["data"], extra_ghc_opts = [$(extraPackageOpts)], extra_cc_opts = [], extra_ld_opts = [] } e = .../source/export extraPackageOpts = such and such complier flags specify of what it is intended? In particular, what should be package_deps = [ ?? ] ? Thank you in advance for the advice, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghci & TclHaskell
by Volker Stolz 22 Oct '03

22 Oct '03

ghci doesn't automatically pick up libtcl & libtk, although they're in package.conf. LD_PRELOADing them works fine [plain ghc works as well]. Is this a feature? Tracing shows that libt{cl,k}83.so *are* opened. Changing the order in extra_libraries or moving them to extra_ld_opts doesn't help, either. > ghci -package TclHaskell ... Loading package TclHaskell ... linking ... /usr/local/lib/ghc-6.0.1//HSTclHaskell_cbits.o: unknown symbol `Tcl_AppendResult' ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1): can't load package `TclHaskell' > LD_PRELOAD=/usr/local/lib/libtcl83.so:/usr/local/lib/libtk83.so ghci -package TclHaskell ... Loading package TclHaskell ... linking ... done. Prelude> [Not that that's any useful, but conclusion about the above might be relevant for other packages. Skipping Main ( philos.hs, ./philos.o ) Ok, modules loaded: Main, ConcurrentDebug, CHD_ConcurrentSampleVar, CHD_Label, CHD_ConcurrentQSemN, CHD_ConcurrentQSem, CHD_ConcurrentCVar, CHD_ConcurrentMain, CHD_ConcurrentChannel, CHD_ConcurrentMVar, CHD_DebugMsgChan, CHD_BaseTypes, CHD_BaseFunctions, CHD_GuiConfigWindow, CHD_Enviroment, PriorDoubleChannel. Prelude Main> main No compiled code for Tcl ] Package.conf: Package {name = "TclHaskell", auto = False, import_dirs = ["/usr/local/lib/ghc-6.0.1/imports/tclhaskell/"], source_dirs = [], library_dirs = ["/usr/local/lib/ghc-6.0.1/"], hs_libraries = ["HSTclHaskell"], extra_libraries = ["tcl83", "tk83", "HSTclHaskell_cbits" ], include_dirs = ["/usr/local/lib/ghc-6.0.1/include"], c_includes = [], package_deps = ["rts", "lang", "concurrent", "data"], extra_ghc_opts = ["-fglasgow-exts", "-fvia-C"], extra_cc_opts = [], extra_ld_opts = ["-L/usr/local/lib", "-lncurses"], framework_dirs = [], extra_frameworks = []}] -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME

1 0

Re: GHC and gcc 3.3.1
by Jost Berthold 21 Oct '03

21 Oct '03

We have built GHC 6.2 for RedHat 9 in our department without problems (well... I checked out the sources approx. 2 weeks ago) using gcc-3.3.1 and a snapshot of ghc-6.1(20030829, rebuilt using binary ghc-6.1.20030803 and manually linking in a dummy __ctype_b). I only had problems because of the changed library (ghc fails when linking) and because I could not install an rpm on the machine. Now the build got through without problems, and it seems the compiler does what it should... Jost > Date: 21 Oct 2003 01:42:25 +0200 > From: Peter Simons <simons(a)cryp.to> > To: glasgow-haskell-users(a)haskell.org > Subject: GHC and gcc 3.3.1 > > Just curious: Has anyone successfully compiled GHC with gcc > 3.3.1 on Linux/x86? I'm having trouble here with both GHC > 6.0 and GHC-current. Is that just me? > > Peter

1 0

Re: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 21 Oct '03

21 Oct '03

Well, i found the reason why it did work with haskell and not with C. It was simply that for haskell i provided an arch via -optc-march=pentium3 and did not the same with C++ (... i should have read the sse option documentation). Thanks for the hint about strictness on large data structures. Regards, Andreas |---------+---------------------------> | | Michael Weber | | | <michaelw(a)foldr.| | | org> | | | | | | 21.10.2003 12:55| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| On Tue, Oct 21, 2003 at 12:03:34PM +0200, Andreas.Schroeder(a)gillardon.de wrote: > > Can't tell you, SSE is disabled by cygwin when i try -mfpmath=sse i get the > message If you compare one language with SSE enabled and another one without, this is like comparing apples and oranges, no? It's rather meaningless when trying to decide how good Haskell performs compared to C++. And I have no doubt your C++ colleagues will point you to it... ;) > Oh, and btw, using MinGW yields the same message for C/C++. > For haskell actually, it _makes_ a difference. Don't ask me why and how. It would be good to find out what is going on there before comparing values. BTW: my personal experience is that with bigger datastructure it gets worse for Haskell rather than better. Closures and copying add a lot of overhead and you really have to keep on eye on strictness. Cheers, Michael

1 0