- Glasgow-haskell-users

Getting the file descriptor from a handle, without closing it
by Volker Wysk 01 Oct '11

01 Oct '11

Hello! I need to get the file descriptors of some handles, but the handles should not be modified. They should not be closed by the operation. I guess, that the handle gets closed for a reason. But I'm using the revealed file descriptors in a way which should pose no problems for the integrity of the GHC library. In order to make a non-closing handleToFd function, I'm studying GHC's library source code. But there's a lot which I can't make much sense, because it uses non-standard language features (GHC extensions), which I'm not familiar with. I don't mean you to explain these GHC extensions to me. I just want to give an impression of the problems I encounter: 1. data FD = FD { fdFD :: {-# UNPACK #-} !CInt, fdIsNonBlocking :: {-# UNPACK #-} !Int } What is that exclamation mark? And that "{-# UNPACK #-}"? 2. handleToFd' :: Handle -> Handle__ -> IO (Handle__, Fd) handleToFd' h h_@Handle__{haType=_,..} = do case cast haDevice of -- ... haDevice should be a function. How could you cast it? 3. data Handle__ = forall dev enc_state dec_state . (IODevice dev, BufferedIO dev, Typeable dev) => Handle__ { -- ... } deriving Typeable What's that "forall" thing? 4. handleToFd' h h_@Handle__{haType=_,..} = do case cast haDevice of Nothing -> -- ... Just fd -> do -- ... return (Handle__{haType=ClosedHandle,..}, Fd (fromIntegral (FD.fdFD fd))) What's this ".." inside "Handle__{haType=ClosedHandle,..}"? If anyone can point out to me, how this non-blocking handleToFd function should be made, I would be grateful. Greetings Volker Wysk

2 2

Segfault while building GHC HEAD on Mac OS X 10.7/XCode 4.1
by Johan Tibell 30 Sep '11

30 Sep '11

The build fails with a segfault when building HEAD using GHC 7.2, OS X 10.7, and XCode 4.1 Any ideas? tibbe@redwood:ghc (master)$ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -H64m -O -fasm -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -dcore-lint -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Debug.hs -o libraries/ghc-prim/dist-install/build/GHC/Debug.o make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Debug.o] Segmentation fault: 11 make: *** [all] Error 2

2 1

Associativity of the generic representation of sum types
by Bas van Dijk 26 Sep '11

26 Sep '11

Hello, I just used the new GHC generics together with the DefaultSignatures extension to provide a default generic implementation for toJSON and parseJSON in the aeson package: https://github.com/mailrank/aeson/pull/26 It appears that the generic representation of a sum type has a tree shape as in: (a :+: b) :+: (c :+: d) In my case this tree-shaped representation is problematic when parsing a JSON value to this type. My overloaded parsing function is parameterized with a key which specifies which of the a, b, c or d constructors to parse. When it encounters a constructor it checks if it matches the key, if so it is parsed, if not parsing will fail. Because of the tree-shaped representation of sum types I have to recursively parse the left and right branch and join them using <|>: https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3… I don't know for sure but I suspect that this can cause memory leaks since the <|> has to keep the right value in memory when it is parsing the left. Ideally the generic representation of sum types is right associative as in: a :+: (b :+: (c :+: d)) This way I only have to check if 'a' matches, if it does the right branch can be forgotten. Is there a good reason for not having it right associative? Regards, Bas

2 7

#ifdef'd code in Printer.c
by Nathan Howell 25 Sep '11

25 Sep '11

For production debugging, I find printObj and friends to be rather useful... and I wonder if it would be a good idea to make these part of the release builds, instead of being relegated to -debug? Alternatively, should these debugging functions be moved to a separate library? I have some other heap debugging functions that I'd like to include but they take a dependency on libxml2... which seems fine for hackage but probably not the GHC RTS. I've investigated doing this from cabal-install but there doesn't seem to be support for building libraries for the full RTS build matrix (threaded/profiling/debugging). -n

1 0

RE: Proposal: Add default instances for Functor and Applicative
by Simon Peyton-Jones 25 Sep '11

25 Sep '11

| With regard to [1], default superclass instances, is there already a plan to | implement them? And if so, when is it expected to be finished? | | [1] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances It definitely won't be in 7.4 I'm afraid. One thing that would be motivating would be a list of people who actively want default superclass instances and why you want them. My own priorities for implementing stuff are much influenced by what GHC's users seem to value. I've added an "Applications" section to [1]; do add yourself and sketch how you'd use the new feature. Simon

1 0

Evaluating type expressions in GHCi
by Sean Leather 23 Sep '11

23 Sep '11

I would like to ask GHCi for the type that a type expression will evaluate to, once all definitions of type synonyms and (when possible) type families have been inlined. It appears that I can do some part of this for type T by using ":t undefined :: T": type family F a type instance F Int = Bool type instance F Bool = Int type instance F (a, b) = (F a, F b) ghci> :t undefined :: F (Int, Bool) undefined :: F (Int, Bool) :: (Bool, Int) I also get what I expect here: ghci> :t undefined :: F (a, Bool) undefined :: F (a, Bool) :: (F a, Int) Of course, this doesn't work on types of kinds other than *. Is it possible and worth having another GHCi command to perform this operation for any types? It could be the type analogue to :t such that it evaluates the type and gives its kind. Regards, Sean

7 11

deep record update
by Barney Hilken 20 Sep '11

20 Sep '11

All this talk about records got me thinking. I don't really like the current syntax for record update (because it looks too much like function application) but here is an extension to it which might be useful. If you use nested records, many languages allow you to update the inner records directly, for example rect.bottomLeft.xCoord += 3. We could allow a similar thing in Haskell by extending the syntax like this: fbind -> qvar = exp | qvar { fbind1 , ... , fbindn } then rec { l1 { l2 = x }} would mean rec { l1 = (l1 rec) { l2 = x }} The advantage (apart from convenience) is that we don't have to repeat rec, which could be a complex expression. Is this any use? Barney.

3 2

Re: [patch] Don't detect libiconv/libcharset on Windows to avoid changing GHCs build behavior on windows with newer mingw installs
by Bill Tutt 18 Sep '11

18 Sep '11

After I made this change I got the following results from ghc-HEAD with the newer mingw and bootstrapping from 7.0.2. The only worrying failures were the rts/5250 (esp alignment) and the simplCore/should_compile cases. I'm hoping the simplCore cases should be related to those Integer changes folks have been talking about recently. OVERALL SUMMARY for test run started at now 2961 total tests, which gave rise to 9214 test cases, of which 0 caused framework failures 6571 were skipped 2561 expected passes 63 expected failures 3 unexpected passes 16 unexpected failures Unexpected passes: hsc2hs 3837 (normal) hsc2hs hsc2hs001 (normal) hsc2hs hsc2hs002 (normal) Cause: Testsuite still flags these as broken on Windows, but the trac bug was resolved ages ago in ghc-HEAD Unexpected failures: ../../libraries/random/tests rangeTest [bad exit code] (normal) Test case doesn't realize that wchar_t is Word16 on Windows instead of Int32 as it is on other Unix machines. (e.g. pgj's x86 FreeBSD builder output) ghci/linking ghcilink006 [bad exit code] (normal) (stdc++) stdc++.dll doesn't exist on Windows (shocker) ghci/scripts ghci038 [bad stdout] (ghci) New contents in .script file doesn't match .stdout content lib/IO 3307 [bad exit code] (normal) lib/IO environment001 [bad stdout] (normal) Windows consoles don't default to UTF-8. (i.e. fails when run from clean cmd.exe as well as the mingw window I launched it from) I wonder what happens if run from PowerShell ISE.... Can't tell atm, apparently I don't have that installed on my Win7 machine. I'll need to set the console window to UTF-8 and see what happens. perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) All over memory threshold. plugins plugins04 [stderr mismatch] (normal) ./<filename> -> .\<filename> change in output caused by a newer mingw? rename/should_compile/T3103 T3103 [stderr mismatch] (normal) ./<filename> -> .\<filename> change in output caused by a newer mingw? rts 5250 [bad exit code] (normal) Wrong exit code (expected 0 , actual 1 ) Stdout: esp not aligned correctly: 22de44 Stderr: simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm) Possible fallout from integer change?? diffs follow: simplCore/should_compile T4908: Is this part of the integer changes? Actual stderr output differs from expected: --- ./simplCore/should_compile/T4908.stderr 2011-09-15 11:03:34 -0400 +++ ./simplCore/should_compile/T4908.comp.stderr 2011-09-17 02:05:45 -0400 @@ -11,10 +11,10 @@ \ (sc :: GHC.Prim.Int#) (sc1 :: GHC.Types.Int) (sc2 :: GHC.Prim.Int#) -> - case sc of ds { + case sc2 of ds { __DEFAULT -> - case sc2 of ds1 { - __DEFAULT -> T4908.f_$s$wf (GHC.Prim.-# ds 1) sc1 ds1; + case sc of ds1 { + __DEFAULT -> T4908.f_$s$wf ds1 sc1 (GHC.Prim.-# ds 1); 0 -> GHC.Types.True }; 0 -> GHC.Types.True @@ -38,7 +38,7 @@ case w of _ { (a, b) -> case b of _ { GHC.Types.I# ds1 -> case ds1 of ds2 { - __DEFAULT -> T4908.f_$s$wf (GHC.Prim.-# ds 1) a ds2; + __DEFAULT -> T4908.f_$s$wf ds2 a (GHC.Prim.-# ds 1); 0 -> GHC.Types.True } } @@ -69,7 +69,7 @@ forall (sc :: GHC.Prim.Int#) (sc1 :: GHC.Types.Int) (sc2 :: GHC.Prim.Int#). - T4908.$wf sc (sc1, GHC.Types.I# sc2) + T4908.$wf sc2 (sc1, GHC.Types.I# sc) = T4908.f_$s$wf sc sc1 sc2 *** unexpected failure for T4908(optasm) simplCore/should_compile spec-inline: Is this part of the integer changes? Actual stderr output differs from expected: --- ./simplCore/should_compile/spec-inline.stderr 2011-09-15 11:03:34 -0400 +++ ./simplCore/should_compile/spec-inline.comp.stderr 2011-09-17 02:09:05 -0400 @@ -21,19 +21,19 @@ GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# - (GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# sc1 sc1) sc1) sc1) sc1) - sc1) - sc1 } in - case GHC.Prim.<=# sc 0 of _ { + (GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# sc sc) sc) sc) sc) + sc) + sc } in + case GHC.Prim.<=# sc1 0 of _ { GHC.Types.False -> - case GHC.Prim.<# sc 100 of _ { + case GHC.Prim.<# sc1 100 of _ { GHC.Types.False -> - case GHC.Prim.<# sc 500 of _ { + case GHC.Prim.<# sc1 500 of _ { GHC.Types.False -> - Roman.foo_$s$wgo (GHC.Prim.-# sc 1) (GHC.Prim.+# a a); - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# sc 3) a + Roman.foo_$s$wgo (GHC.Prim.+# a a) (GHC.Prim.-# sc1 1); + GHC.Types.True -> Roman.foo_$s$wgo a (GHC.Prim.-# sc1 3) }; - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# sc 2) sc1 + GHC.Types.True -> Roman.foo_$s$wgo sc (GHC.Prim.-# sc1 2) }; GHC.Types.True -> 0 } @@ -69,7 +69,7 @@ ipv) ipv } in case w of _ { - Data.Maybe.Nothing -> Roman.foo_$s$wgo 10 a; + Data.Maybe.Nothing -> Roman.foo_$s$wgo a 10; Data.Maybe.Just n -> case n of _ { GHC.Types.I# x2 -> case GHC.Prim.<=# x2 0 of _ { @@ -78,10 +78,10 @@ GHC.Types.False -> case GHC.Prim.<# x2 500 of _ { GHC.Types.False -> - Roman.foo_$s$wgo (GHC.Prim.-# x2 1) (GHC.Prim.+# a a); - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# x2 3) a + Roman.foo_$s$wgo (GHC.Prim.+# a a) (GHC.Prim.-# x2 1); + GHC.Types.True -> Roman.foo_$s$wgo a (GHC.Prim.-# x2 3) }; - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# x2 2) ipv + GHC.Types.True -> Roman.foo_$s$wgo ipv (GHC.Prim.-# x2 2) }; GHC.Types.True -> 0 } @@ -140,15 +140,15 @@ Roman.foo = \ (n :: GHC.Types.Int) -> case n of _ { GHC.Types.I# ipv -> - case Roman.foo_$s$wgo ipv 6 of ww { __DEFAULT -> GHC.Types.I# ww } + case Roman.foo_$s$wgo 6 ipv of ww { __DEFAULT -> GHC.Types.I# ww } } ------ Local rules for imported ids -------- "SC:$wgo0" [ALWAYS] forall (sc :: GHC.Prim.Int#) (sc1 :: GHC.Prim.Int#). - Roman.$wgo (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc)) - (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc1)) + Roman.$wgo (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc1)) + (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc)) = Roman.foo_$s$wgo sc sc1 *** unexpected failure for spec-inline(optasm)

1 1

Re: Windows build problems
by Bill Tutt 16 Sep '11

16 Sep '11

>From Daniel Fischer: > I'm trying to set up a build/test environment on Windows. > Building ghc (sh validate) fails after a while due to flex and bison > crashing. Those two come with git and even > $ flex --version > (or bison) crashes, so they seem truly hosed. > Do I need flex/bison at all to build ghc? > It seems they're not used on linux for building ghc. > So, if not, how do I configure things that the build doesn't try to use > bison/flex? > If yes, would installing flex and bison from gnuwin32 work? I ran into this issue last night as well. See http://hackage.haskell.org/trac/ghc/ticket/5489 flex appears to be required from integer-gmp's ./configure for one of GMP's demo programs. (a calculator demo I think) I'm trying to see if a slightly newer msys installation process as listed in the Trac bug will take care of it. However, last night I got a stage 1 ghc seg fault while compiling some Haskell code further along in the build. I currently have a devel1 build in progress to see what I come up with next. I also ran into: http://hackage.haskell.org/trac/ghc/ticket/5488 about bootstrapping using the Windows 7.2.1 standalone bits to bootstrap ghc-HEAD. If the devel1 build doesn't give any useful symptoms to pass along I'll probably retry the build using the Haskell Platform compiler. Fyi, Bill

4 6

Use -V0 causes space to leak?
by Neil Davies 16 Sep '11

16 Sep '11

Hi I have some long running (multi-gigabit, multi-cpu hour) programs and as part of trying to speed up I thought I would set the -V0 flag - when I did this there was a slow space leak that caused it to blow the heap. Anyone out there have an explanation? Is there some garbage collection thing associated with something that -V0 suppresses? Cheers Neil

2 1