- Glasgow-haskell-users

"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 08 Sep '06

08 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

lexically-scoped type variables in GHC 6.6
by Ross Paterson 07 Sep '06

07 Sep '06

With reference to the documentation that just appeared in darcs: Result type signatures are now equivalent to attaching the signature to the rhs, i.e. redundant. How about finishing the decoupling of type variable binding from pattern type signatures by introducing an (optional) pattern form forall v1 ... vk. C p1 ... pn mimicking the datatype declaration for an existential (with vi scoping over pj, guards, where decls and the rhs), so the example would become data T = forall a. MkT [a] k :: T -> T k (forall a. MkT [t]) = MkT t3 where t3::[a] = [t,t,t]

3 3

6.6 candidate
by J. Garrett Morris 06 Sep '06

06 Sep '06

Hello, I successfully downloaded and installed ghc-6.5.20060901 on Windows XP (SP2 etc.). However, when attempting to build fps-0.8, I received a large number of errors stemming from gcc being unable to find Stg.h or HsBase.h. As far as I could tell using -v, gcc is still being passed the old path to the include files (ghc-dir\include, perhaps) whereas said files were actually located in ghc-dir\lib\i386-unknown-mingw32\include. Moving the files from the new location to the old solved the compilation problem. Was this a problem in the distributed build, or did I do something wrong when I was installing it? Thanks. /g -- It is myself I have never met, whose face is pasted on the underside of my mind.

3 2

Floating point problems
by Jamie Brandon 05 Sep '06

05 Sep '06

I recently defied my supervisor and used Haskell to write my coursework instead of C. All went well until I needed floating point and started having odd results. As far as I can tell it isn't substantially affecting my results but it is rather embarrassing after slagging off C so much. Here are some examples: *Main> 0.2 + 0.1 0.30000000000000004 *Main> 0.200000000000000 + 0.100000000000000000 0.30000000000000004 *Main> 0.3 + 0.1 0.4 *Main> 0.2 + 0.1 0.30000000000000004 *Main> it + 0.1 0.4 I assume this is a result of the discrepancy between binary and decimal representations of the numbers. Is there any way around? For a start, it would be nice to have a simple way to get 0.1 + 0.2 == 0.3 = True This is with GHC 6.4.1 and GCC 4.0.3 Thanks, Jamie

9 16

GHC non-termination
by Robert Dockins 05 Sep '06

05 Sep '06

Hello all, I've discovered that GHC doesn't deal very well with the following program. It appears to diverge when running the following program with 'runghc'. The main compiler can also be persuaded to diverge in a similar fashion. Hugs exhibits correct behavior, ie, it prints "hello". This is with GHC 6.4.2. I've tested on linux x86 and PPC OS X. newtype Mu a = Roll { unroll :: Mu a -> a } omega :: a omega = (\x -> (unroll x) x) (Roll (\x -> (unroll x) x)) main = putStrLn "hello" Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 2

Program slower with local definitions
by Michael Marte 05 Sep '06

05 Sep '06

Hello *, I noticed a five percent speed up by making local definitions global. This is the first version with local definitions: f = <some expression based on mySet> where mySet = foldl (flip Set.insert) Set.empty myList myList = <some constant list> Then I moved mySet and myList to the top level which gave me the speed up. Shouldn't both versions show the same behaviour with regard to run time? Doesn't the compiler lift mySet and myList to top level automatically? Are myList and mySet evaluated in every call to f when defined locally? I am using ghc 6.4.2 on Windows XP. Michael

3 2