- Glasgow-haskell-users

ghc cvs breaks LINE pragma?
by John Meacham 14 Dec '03

14 Dec '03

I use this little script called with ghc -pgmF ./drift -F ; cat ./drift #!/bin/ash if grep -q '{-!' $2; then echo DrIFT $2 -o $3; DrIFT $2 -o $3; else echo "{-# LINE \"$1\" 0 #-}" >> $3 cat $2 >> $3; fi however it seems to have stopped working with ghc cvs rather than 6.01. it dies with a 'lexical error' on the LINE pragmas generated by the script and DrIFT. any idea what the problem is? John PS. on another tangent (although this is is probably a library issue), I tried modifying my code to use the new Data.Generics rather than Strafunski, and found that Data could not be derived because instances for a lot of built in classes don't exist and it is unclear how to write them by hand. is it possible to retroactivly add a 'deriving' clause to something that was declared in another unmodifyable module? or can we make sure that all predefined (and library) types derive Data? -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 1

forkProcess type changed?
by George Russell 11 Dec '03

11 Dec '03

For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () -> IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () -> IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process?

3 2

RE: forkProcess type changed?
by Simon Marlow 11 Dec '03

11 Dec '03

> For the development snapshot 6.3.20031201, System.Posix.forkProcess > has the type IO () -> IO System.Posix.Types.ProcessID. In 6.0.1 > it has type IO () -> IO (Maybe System.Posix.Types.ProcessID). Is > this change intentional, and if so how are you supposed to test > after the fork if this is the parent or child process? Yes, this is intentional. It turned out to be far too difficult to implement forkProcess as it was previously defined (problems with what happens when the current thread returns in the child process was one difficulty, IIRC). The previous implementation had some serious bugs. See the docs for the new version here: http://www.haskell.org/ghc/docs/6.2/html/libraries/unix/System.Posix.Pro cess.html#v%3AforkProcess Cheers, Simon

1 0

RE: import modules from a different directory
by Simon Marlow 11 Dec '03

11 Dec '03

> Anybody has the experience of importing a module from a different > directory?In my code, i need to import a module that is not > in the current > directory. How can I do that in GHC? GHC-specific questions are best asked on glasgow-haskell-users(a)haskell.org (where I've sent this followup). You'll find the -i option to GHC will do what you want. Documentation is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… Cheers, Simon

1 0

Making GHCi object files on MacOS
by George Russell 10 Dec '03

10 Dec '03

Section 4.10.3 of the GHC manual tells me to use ld -r --whole-archive to convert a .a file into a .o file suitable for GHCi. However these options only work for GNU ld, which doesn't seem to be available on MacOS (uname -srv gives me "Darwin 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC"). Specifically, I tried compiling the GNU binutils but got a message from its ./configure telling me that this wouldn't work for the ld directory. I presume there must be some way of producing GHCi object files on MacOS, but how is it done? Thanks

3 5

Re: incompatible signatur syntax within instance definition
by Christian Maeder 10 Dec '03

10 Dec '03

Fergus Henderson wrote: > I think the issue here is that in ghc (with -fglasgow-exts), > the "a" here refers to the same type variable "a" in the > top of the instance declaration, which has already been > constained, and cannot be constrained again. Is that a bug or a feature? > With Haskell 98, it is a fresh type variable, for > which the constraint is necessary. Ok, if I view the local function as a new/independent function, I accept to add the Constraint, but that should be acceptable for ghc -fglasgow-exts as well (as is for hugs with extensions). > Try renaming the type variable as "b" in the inner declaration: > the following should work both with and without -fglasgow-exts. > > showsl :: Show b => List b -> ShowS Yes, this works, but I never thought that the choice of "a" or "b" would matter. Christian >>>instance Show a => Show (List a) where >>> showsPrec _ Nil = showString "[]" >>> showsPrec _ l = >>> showString "[" . showsl l . showString "]" >>> where -- showsl :: List a -> ShowS -- for ghc >>> -- showsl :: Show a => List a -> ShowS -- for hugs

3 5

Re: ghc fails "hello world" on ppc
by frederik＠ugcs.caltech.edu 10 Dec '03

10 Dec '03

I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? frederik(a)ugcs.caltech.edu writes: > $ uname -a > Linux fly 2.4.19-quiet #10 Tue Jan 12 17:02:50 PST 1904 ppc GNU/Linux > $ cat > test.hs > main = > do > putStr "hello\n" > putStr "world\n" > $ ghc --make test.hs && ./a.out > Chasing modules from: test.hs > Compiling Main ( test.hs, ./test.o ) > Linking ... > world > world > > On my i386 machine it works correctly: > > $ ghc --make test.hs && ./a.out > Chasing modules from: test.hs > Compiling Main ( test.hs, ./test.o ) > Linking ... > hello > world > > Various permutations of the original program produce the same result > on the ppc: > ---------------------------------------------------------------- > import System.IO > main = > do > hSetBuffering stdout NoBuffering > putStr "hello\n" > putStr "world\n" > ---------------------------------------------------------------- > import System.IO > main = > do > hSetBuffering stdout NoBuffering > putStrLn "hello" > putStrLn "world" > ---------------------------------------------------------------- > main = > do > putStrLn "hello" > putStrLn "world" > ---------------------------------------------------------------- > etc., except that anything with putStrLn prints > hello > hello > instead of > world > world > > > TIA. > > Frederik Eaton

1 0

RE: replacement of main
by Simon Marlow 09 Dec '03

09 Dec '03

> > > when I compile everything > > > > ghc Halleg.hs Game.hs stub.c -L....(additional paths > for allegro)... > > > -lalleg(a few libs needed) -no-hs-main -o game > > > > > > I get this cryptic error: > > > ---- > > > tcLookup: 'main' is not in scope > > > In the first argument of 'GHC.TopHandler.runIO', namely 'main' > > > When checking the type of 'main' > > > ---- > > > > Which version of GHC is it that you're using? > > 6.0.1 I can't manage to get this error by doing the obvious things. Could you try to cut down the example (to one Haskell module module preferably) and send us the code and the complete command line to reproduce the error? Cheers, Simon

1 0

RE: replacement of main
by Simon Marlow 08 Dec '03

08 Dec '03

> ok, I guess this is not something you do every day; > I am making a language binding for the library Allegro which has some > weird things going on. I need to make a main() in C. > > so I followed the manual, I export my non-main haskell entrypoint > and call it from the C main which basically is copy-paste from the > docs. > > when I compile everything > > ghc Halleg.hs Game.hs stub.c -L....(additional paths for allegro)... > -lalleg(a few libs needed) -no-hs-main -o game > > I get this cryptic error: > ---- > tcLookup: 'main' is not in scope > In the first argument of 'GHC.TopHandler.runIO', namely 'main' > When checking the type of 'main' > ---- Which version of GHC is it that you're using? Cheers, Simon

2 1

RE: Template Haskell and the command line
by Simon Marlow 08 Dec '03

08 Dec '03

> Template Haskell is frightfully good and we want to get rid of cpp and > use it instead, but there's one tiny problem, namely that for cpp it > is possible to define variables on the command line > (-DSIMON=MARLOW and so > on) while with Template Haskell it doesn't seem to be. Could there be > some kind of dictionary, like the cpp environment variables, which the > Template Haskell code has access to? > > One obvious way would be to accept the -D/-U arguments, and > provide Haskell > functions which look at them. > > Of course one /could/ presumably use System.getArgs and > analyse the arguments > to ghc oneself, but that would mean making guesses about the > current GHC syntax. > > In the meantime we shall still replace cpp with Template > Haskell, but find > another way. Thanks for Template Haskell! What's wrong with using environment variables, with System.Envorinment.getEnv? To use your example, you would write: $ SIMON=MARLOW foo Cheers, Simon

1 0