October 2008 - Glasgow-haskell-users

System.Process.runInteractiveCommand, exit_group ()
by Johannes Waldmann 06 Oct '08

06 Oct '08

Dear all, I have a Haskell program (compiled with -threaded) that calls an external executable via System.Process.runInteractiveCommand (and then I do waitForProcess). The external program finishes with exit_group () (I don't have source, but I see it from strace). Then, my Haskell program dies immediately. Is exit_group () the reason? How can I prevent this? Thanks - J.W.

1 0

Is -fvia-C still needed?
by leledumbo 05 Oct '08

05 Oct '08

I notice that speed from code generated by -fasm and -fvia-C isn't significant, furthermore -fvia-C takes longer time. So, why ghc still needs gcc (at least on Windows)? -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19663119.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 8

One stage2 compiler hanging around after head build (Solaris/x86 buildbot)
by Karel Gardas 05 Oct '08

05 Oct '08

Hello, month or so ago I've noticed that one compiler instance is hanging around and spending 100% of CPU for nothing after a build of head (I'm not sure if it also happens on stable) on my Solaris/x86 buildbot. I've thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated the compiler now to 6.8.3, but the hangup happens again and now I've noted that in fact it's the stage2 compiler: -bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar -bash-3.2$ my question is: is it just me who is affected by this or is it a well known issue in GHC build framework? Thanks, Karel

2 6

isTypeId, isValueId
by Serge D. Mechveliani 05 Oct '08

05 Oct '08

People, I need to implement the functions isTypeId, isValueId :: String -> Bool which check whether the argument fits respectively the syntax of a type identifier and of a value identifier -- in the Haskell-98 syntax for a program. The argument is produced by lexLots. For example, my program applies lexLots "ab-(f_21 <Ab:c" --> -- I expect: ["ab", "-", "(", "f_21", "<", "Ab", ":", "c"] -- 1 2 3 4 Then, I think, only (1), (2), (3) and (4) are type or value identifiers ... What is the most regular expression for isTypeId, isValueId ? I presume to consider first the Standard library, and if fail, then the GHC library. Thank you in advance for your advice. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

could not find link destinations
by Wolfgang Jeltsch 03 Oct '08

03 Oct '08

Hello, I built GHC 6.10.0.20080927 on Debian GNU/Linux for i386. At the end of the build process I got numerous warnings of the form “could not find link destinations for: […]”. Is this intensional? Best wishes, Wolfgang

2 1

Re: planning for ghc-6.10.1 and hackage
by Duncan Coutts 02 Oct '08

02 Oct '08

On Wed, 2008-10-01 at 23:35 -0600, humasect wrote: > Duncan, > > > Since nothing (relatively) is dependant on base 4, why not call it > 'base-4' ? Or hide it like 'ghc' and some other packages are hidden > from inclusion when not explicitly referenced. It is called base-4, it's name is base and the version number is 4. I think what you're asking is why we do not call it "base4-0" or something and the reason is because that looses the connection between versions of packages. Though on the plus side it'd force everyone to specify a major api version, but the right way to do that is to require closed version ranges on base in .cabal files (and other packages that follow the package versioning policy) > Or.. in theory if someone or something can go through all cabal and > add "&& base < 4" through a Hackage filter? <- my apologies I am not > that knowledgeable, but this is what I did for example with my project > that uses storablevector. Yes, that would work if every package on hackage were updated or if we could adjust the .cabal file for every package. Well, it would work for runghc Setup configure, the automatic dependency resolver in cabal-install would still need fixing if we want to continue using that. Don and I have spent the last 6 hours discussing the problem and we are now at the stage where we think it might be solvable. I'm going to work on it all day tomorrow and we'll see where we can get. Duncan

1 0

Inferred type is less polymorphic than expected, depends on order
by Jason Dagit 02 Oct '08

02 Oct '08

I was wondering if someone could help me understand why reording the case statements changes the type inference for this code. 1) I find the error message a bit confusing. 2) I don't understand why it's a problem in one order and not the other. I've tried to send this as literate haskell in hopes that you can just copy and paste to a file and run the example. This happens with or without GADTs, this version doesn't have them but they don't turn out to make any difference. \begin{code} {-# LANGUAGE ExistentialQuantification, RankNTypes #-} module Main where data Sealed a = forall x. Sealed (a x) -- Or equivalently: -- data Sealed a where -- Sealed :: a x -> Sealed a \end{code} Originally, I noticed this in a monad context...The original was much more complicated. But, we can simplify it even more, so keep reading. goodOrder :: Monad m => (forall y z. p x y -> q y z -> q x z) -> m (Sealed (p x)) -> (forall b. m (Sealed (q b))) -> m (Sealed (q x)) goodOrder f mx my = do Sealed x <- mx Sealed y <- my return (Sealed (f x y)) badOrder :: Monad m => (forall y z. p x y -> q y z -> q x z) -> m (Sealed (p x)) -> (forall b. m (Sealed (q b))) -> m (Sealed (q x)) badOrder f mx my = do Sealed y <- my Sealed x <- mx return (Sealed (f x y)) Several helpful people in #haskell helped me converge on this greatly simplified version below. \begin{code} f :: p x y -> q y z -> q x z f = undefined \end{code} \begin{code} badOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q x)) badOrder sx sy = case sy of Sealed y -> case sx of Sealed x -> Sealed (f x y) \end{code} \begin{code} goodOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q x)) goodOrder sx sy = case sx of Sealed x -> case sy of Sealed y -> Sealed (f x y) \end{code} \begin{code} main = return () \end{code} This gives the error: $ ghc --make Reorder.lhs [1 of 1] Compiling Main ( Reorder.lhs, Reorder.o ) Reorder.lhs:52:29: Inferred type is less polymorphic than expected Quantified type variable `x' is mentioned in the environment: y :: q x x1 (bound at Reorder.lhs:51:24) When checking an existential match that binds x :: p x2 x The pattern(s) have type(s): Sealed (p x2) The body has type: Sealed (q x2) In a case alternative: Sealed x -> Sealed (f x y) In the expression: case sx of Sealed x -> Sealed (f x y) After discussing this a bit, I think what may be happening in the badOrder case is that the existentially bound type of x is bound after the type `b' in the type of y, leading to the error message. I would appreciate help understanding this, even if the help is, "Go read paper X, Y, and Z." Thanks! Jason

1 0

GHC on Solaris/SPARC?
by Elliott Slaughter 01 Oct '08

01 Oct '08

Hi, I am having trouble with precompiled binary http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-sparc-sun-solaris2.t… . My first problem was that the machine is 64-bit SPARC while the binary seems to be 32-bit. Since the dynamically linked GHC binary requires additional .so files to run, any libs which I try to compile on the machine itself run into ELF class incompatibility errors. So I tried installing prebuilt packages from http://sunfreeware.com/, and spent a couple hours grokking the Solaris package system before I figured out how to extract the right files. Now I think I have the right libs installed, but when I try to run GHC, I get this: -bash-3.00$ runhaskell Setup configure ld.so.1: ghc-6.8.3: fatal: relocation error: file /home/.../lib/libncurses.so.5: symbol main: referenced symbol not found (FYI, I got ncurses 5.6 from http://sunfreeware.com/programlistsparc10.html#ncurses.) Any suggestions would be welcome, thanks in advance. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert

3 5