- Glasgow-haskell-users

small errors in ghc 6.6
by Bulat Ziganshin 20 Sep '06

20 Sep '06

Hello glasgow-haskell-users, i've put my hands on the ghc 6.6/mingw32 dated 1st september (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-…) overall, compilation of my 5 kloc application was fine. on the 6.2->6.4 transition, i was bitten by two API changes, but this time all APIs and language features i used remains stable. it's great! the most funny part was that parallel arrays are still work :))) nevertheless, i've captured several minor problems: 1. ghc +RTS -A10m aborts with the message: ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The parameter is incorrect. although i guess that it was already fixed since 1st September. btw, how about adding using various RTS switches to ghc as test cases? GHC is very large program and any problems with RTS flags would be captured in this way 2. ghc compilation don't includes directory where Rts.h, Stg.h and similar files resides, "$(GHC)\lib\i386-unknown-mingw32\include" on my installation. it results in failing of via-C compilation, compilation of *stub.c files, and inclusion of "Typeable.h". i was going around this problem by using -I switch. it's possible that it's just packaging problem. again - isn't it possible to catch this problem by testsuite? imho, that this error was not catched means that windows version isn't really tested by anyone? how about trying to build various packages on mingw32 version as test before releasing 6.6? 3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

one more typo
by Bulat Ziganshin 19 Sep '06

19 Sep '06

Hello glasgow-haskell-users, 7.4.10 of user guide say: -- f and g assume that 'a' is already in scope f = \(x::Int, y) -> x g (x::a) = x seems that f definition should contain 'a' -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Change Data.Bits.rotate to rotate Integer (unbounded) types
by Peter Tanski 19 Sep '06

19 Sep '06

Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits, would it be all right to change the operation of rotate, rotateL and rotateR over unbounded types (to my knowledge, currently only Integer)? I would like to change rotate, rotateL and rotateR to actually rotate (not shift) Integers. -Pete

4 6

Help with unregisterised build
by Peter Tanski 16 Sep '06

16 Sep '06

Hello Jeremy, I don't know if anyone has gotten back to you on this yet. I have not myself done an unregisterised build of GHC before, but I thought you should at least hear something. The people who know about this all seem to be at the ICFP programme that has been going on since Thursday; they should be back next week. In the meantime, some work has been done recently on the way GHC puts out assembler--not quite the same problem as a multiply-defined-symbol error--but you might consider grabbing darcs and trying to build from the HEAD branch. See <http://hackage.haskell.org/trac/ghc/wiki/Building/ GettingTheSources>. -Pete Jeremy Wazny wrote: > I've attempted to build an installation of GHC which uses > unregisterised libraries, but have not had much success. I am new to > GHC's build system and would be grateful for some advice. > > I'm trying to build the 6.4.2 source distribution on an x86 linux > machine, using GHC 6.4.2 (the "Generic Linux with glibc2.3" version on > the download page.) The target is the same machine. > > I've created a mk/build.mk file containing just the line: > > GhcUnregisterised = YES > > which, according to the comment in mk/config.mk, ought to build the > unregisterised libraries that I'm after (and use them by default.) > > I run configure as follows: > > ./configure --prefix="$HOME"/ghc_u > > and then simply "make". > > After some time, the build fails with the following: > > ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude > -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O > Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Base.lhs -o > GHC/Base.o -ohi GHC/Base.hi > /tmp/ghc4237.s: Assembler messages: > /tmp/ghc4237.s:17: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:29: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:41: Error: symbol `__stg_split_marker' is already > defined > /tmp/ghc4237.s:53: Error: symbol `__stg_split_marker' is already > defined > > .... This goes on for a while ... > > <<ghc: 124912780 bytes, 12 GCs, 808164/1513632 avg/max bytes residency > (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.59 MUT (2.39 > elapsed), 0.10 GC (0.09 elapsed) :ghc>> > make[2]: *** [GHC/Base.o] Error 1 > make[1]: *** [all] Error 1 > make[1]: Leaving directory > `/mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries' > make: *** [build] Error 1 > > > I've also tried with the following build.mk > (I was guessing the -fvia-C might avoid the above assembler problem.): > > GhcUnregisterised = YES > GhcLibHcOpts = -O -fvia-C > > but it fails in the same way. > > I'm not sure what to do at this point. > Am I missing something in the build.mk? > > Is there likely to be anything else that needs to be tweaked? > > Has anybody had any success with this sort of thing before?

1 0

Build failures in packages built with GHC 6.6
by Duncan Coutts 14 Sep '06

14 Sep '06

Hi folks, Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how: http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix. One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs). Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release. BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay. Duncan (wearing his Cabal release manager hat and his Gentoo hat)

4 5

"No child processes" in 6.6-candidate
by Serge D. Mechveliani 14 Sep '06

14 Sep '06

Dear GHC developers, Sometimes ghc-6.6-candidate reports -------------------------------------------------- runhaskell Setup.hs install --user ... *** Exception: waitForProcess: does not exist (No child processes) -------------------------------------------------- under Linux. This happens as follows. I build my large project (it uses Cabal, and it has some import loops) and install it. Then, I edit a bit, for example, the source module Dumatel.KBC, remove by rm -rf all the files from the installation directory ./inst/, and command make build (runhaskell Setup.hs build) make install (runhaskell Setup.hs install --user). It reports --------------------------------------------------- scico:~/dm/1.06/dm/source> make build runhaskell Setup.hs build Preprocessing library dumatel-1.6... Building dumatel-1.6... [10 of 38] Compiling Bool0[boot] ( Bool0.hs-boot, nothing ) [22 of 38] Compiling Dumatel.KBC ( Dumatel/KBC.hs, dist/build/Dumatel/KBC.o ) /usr/bin/ar: creating dist/build/libHSdumatel-1.6.a (looks all right: it re-compiles only the changed module and something which also may be necessary) scico:~/dm/1.06/dm/source> make install runhaskell Setup.hs install --user Installing: /home/mechvel/dm/1.06/dm/source/inst/lib/dumatel-1.6/ghc-6.5.20060831 & /home/mechvel/dm/1.06/dm/source/inst/bin dumatel-1.6... *** Exception: waitForProcess: does not exist (No child processes) make: *** [install] Error 1 ------------------------------------------------------------------ ghc-6.4.1 did `install' all right in approximately the same situation (the source modules where a bit different). Then, I remove all the files also from the `build' directory ./dist/ and do by new `build' and `install'. And then, it works. The matter is that compiling all modules by new slows down the process of developing a project. Can the above effect present a bug in the ghc + Cabal system? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Test Suite's Dependency on Quickcheck
by Brian Smith 13 Sep '06

13 Sep '06

If you build GHC with just the default settings, QuickCheck doesn't get pulled from Darcs and it is thus not built and installed into ghc-inplace. Because of this, many of the tests in the test suite fail: SampleVar001 Chan001 MVar001 QSemN001 QSem001 bytestring001 bytestring004 bytestring005 I think that the test suite should run without errors by default. What is the best way to deal with this situation? Probably the easiest thing to do would be to include QuickCheck as a "core package" as defined in the thread "Packages in GHC 6.6." Then QuickCheck would need to be copied into the ghc-6.6 branch. Thoughts? - Brian

3 3

3rd Cabal-1.1.6 release candiate
by Duncan Coutts 12 Sep '06

12 Sep '06

Hi all, I've put up a tarball for the third 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.3/cabal-1.1.5.9.3.tar.gz This is also included with very recent GHC 6.5 snapshots. Please test this with your packages and report any issues to cabal-devel(a)haskell.org We're particularly interested of course in anything that worked before and is now broken. Duncan

1 0

Re[2]: [GHC] #887: GHCi prints results of IO actions
by Bulat Ziganshin 08 Sep '06

08 Sep '06

Hello GHC, Friday, September 8, 2006, 12:28:47 PM, you wrote: > #887: GHCi prints results of IO actions > We changed it because a lot of the time it's very convenenient to see the > result of an action. But you have a good point. > What do others think? Return to old behaviour? Have another settable > option? Or what? i think that it should be controlled by option and enabled by default. you are right - it's very convenient. ghci used for debugging programs and learning language and in most cases we want to see maximum information about our commands. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Fwd: Re[2]: What causes hsc2hs "permission denied" errors during build?
by Brian Smith 07 Sep '06

07 Sep '06

On 9/7/06, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > > Hello Esa, > > Thursday, September 7, 2006, 1:34:13 PM, you wrote: > > > The problem is that removeFile is called for a file that has an open > handle, > > because the handle is not garbage collected yet. > > a workaround may be to call "performGC" just before removeFile hsc2hs generates an EXE file, then executes it, then waits for that process to finish, and then attempts to delete the file. The file is never opened by hsc2hs directly so the GC does not seem to be the cause. It seems that even though waitForProcess returns successfully, Windows still an open file handle for the EXE file when removeFile is called. That is really surprising because I expect that the file should be free to delete after waitForProcess has returned. I tried to rewrite the code so that it enters a remove-catch "permission denied"-sleep loop but I could not find a portable "sleep" IO action. For now, I just commented out the entire removeFile action. Regards, Brian

1 0