- Glasgow-haskell-users

REQ: add a non-closing version of handleToFd
by Volker Wysk 06 Oct '11

06 Oct '11

Hello The function to extract a file descriptor from a handle, handleToFd, closes the handle as a side effect. This appears to be necessary in the general case, otherwise the implementers wouldn't have made it this way. But there are cases in which it isn't necessary to close the handle. For instance, this little function needs to extract the file descriptor, but there is no need to close, or change, the handle. isatty :: Handle -- ^ Handle to check -> IO Bool -- ^ Whether the handle is connected to a terminal isatty h = do fd <- handleToFd_noclose h isterm <- {# call isatty as hssh_c_isatty #} -- this is c2hs ((fromIntegral fd) :: CInt) return (isterm /= (0::CInt)) handleToFd_noclose :: Handle -> IO Fd -- to be implemented The isatty above can't be implemented with things the way they are. To me, this is a serious drawback. The cases, in which the handle needs to be closed, should be identified, and documented. Then, a version of handleToFd, which doesn't close the handle can be implemented. Cheers Volker

4 3

Mysterious function timer_settime
by Volker Wysk 06 Oct '11

06 Oct '11

Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html ~/src/hsshellscript-3.0.0 $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a fine little test program src/test.hs: import HsShellScript main = (outm "3\n1\n2\n") -|- exec "/usr/bin/sort" ["-n"] But this doesn't work. It generates a mysterious error message: ~/src/hsshellscript-3.0.0 $ src/test test: <stderr>: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument "timer_settime" occurs only in the generated test binary. It doesn't occur anywhere in the library or in "/usr/bin/sort": ~/src/hsshellscript-3.0.0 $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. ~/src/hsshellscript-3.0.0 $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Thanks for any help, Volker W.

2 3

Re: [Pkg-haskell-maintainers] libffi soname change upcoming
by Joachim Breitner 04 Oct '11

04 Oct '11

Hi, Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose: > > The question that has to be answered first is: Assume the libraries do > > not depend on libffi themselves, and only ghc does. Now you update > > libffi and ghc gets rebuilds, what will happen: > > > > A) The haskell ABIs stay the same, the existing library packages can > > still be used. Great. > > > > B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries, > > but oh well, not bad thanks to BD-Uninstallable-support in wanna-build > > and autosigning. > > > > C) The haskell ABIs do not change, but the old library builds are > > broken nevertheless. Big mess. Hard to recover from, because builds are > > not ordered automatically any more. Needs lots of NMUes and Dep-Waits. > > sorry, I don't get the `C' case. why should these be broken by a libffi or > libgmp change? Maybe it’s an unrealistic example, but I could imagine that ghc some data type (size) defined by libffi is used when generating code for a haskell library under the assumption that it has the same structure/size in the run time system and/or other used haskell libraries. But instead of making blind guesses, maybe GHC upstream can enlighten us: Is it safe to build ghc and a Haskell library, then upgrade libffi to a new version (with soname bump), rebuild ghc, but use the previous library build? > > Removing the libffi dependencies from the haskell libraries makes C > > possible and only helps with A. So until someone investigates this, I’d > > rather err on the safe side, leave the dependencies in, and fix the > > issue by rebuilding all haskell libraries when you upload the new ffi > > soname to unstable. > > well, with binNMU orgies like this you'll pull in any new or tightened > dependencies for shared libraries. Not depending on these unused libraries > does avoid this. True. I agree that it would be nice and worthwhile to remove the libffi dependency from the libraries, but only if it is actually safe and scenario C is guaranteed not to happen. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 4

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 29 Sep '11

29 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