- Glasgow-haskell-users

RE: redirecting stdin/stdout
by Simon Marlow 21 Aug '02

21 Aug '02

> I would like to be able to semi-permanently redirect stdout > particularly. That is, say something like: > > main = do > h <- openFile "myoutput" WriteMode > setStdOut h > ..crux of the program.. > hClose h > > where any call which uses stdout either explicitly or > implicitly (through > putStr and the like) is redirecto to h. > > I didn't see anything of this sort in either the std libs IO or in the > GHC.IO/IOBase modules...would such a thingbe possible? Yes, it is entirely possible to do this, and in fact we used to have such a thing (withStdout, withStderr) which got dropped when I re-implemented the I/O system. It's not immediately clear what the interface should be, though. If we have setStdout :: Handle -> IO () what happens to the original handle? It's unfortunately not possible to make stdout then be equal (in the == sense) to the handle passed in, although stdout would from then on behave like the other handle. Since in Haskell it is illegal to have two handles that refer to the same file, without the handles being equal, the original handle would have to be closed. Also there's a slight complication caused by GHC's representation of handles. Some handles have two independent "sides" to cope with the fact that a read/write stream (eg. a socket) needs two separate buffers. It wouldn't be possible to do setStdout with a stream-type Handle (or perhaps you just get the output side of the stream Handle). Cheers, Simon

3 2

redirecting stdin/stdout
by Hal Daume III 20 Aug '02

20 Aug '02

I would like to be able to semi-permanently redirect stdout particularly. That is, say something like: main = do h <- openFile "myoutput" WriteMode setStdOut h ..crux of the program.. hClose h where any call which uses stdout either explicitly or implicitly (through putStr and the like) is redirecto to h. I didn't see anything of this sort in either the std libs IO or in the GHC.IO/IOBase modules...would such a thingbe possible? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

Re: Question about error message
by Paulo Sequeira 20 Aug '02

20 Aug '02

Ok, you got me. My wording was not careful, so I must rectify. If you try let xyz = do getLine in do p <- xyz; putStr p you'll see that in xyz I'm not really discarding the string read (you caught it later in p). Definitively, Alastair's explanation is more correct than mine and it didn't lead you to a misunderstanding. You must understand that do notation is mostly syntactic sugar. It is more familiar to write do p <- getLine; putStr p than to write getLine >>= (\ p -> putStr p) What I really mean by "discarding" was that, if you write do getLine; stmt you would simply won't have at hand the line read in stmt because the value was not bound to any variable. Note that the previous line is equivalent to getLine >> do stmt or, by the definition of >> getLine >>= (\ _ -> do stmt) See it? Also, note that when you write do getLine in GHCi, it is GHCi who is "discarding" the string. (mmm, would this last statement be also misleading?) Hope I'm now explaining myself better. Paulo. ----- Original Message ----- From: Seth Kurtzberg <seth(a)cql.com> To: Paulo Sequeira <otro_paulo(a)hotmail.com> Sent: Saturday, August 17, 2002 7:25 PM Subject: Re: Question about error message > Paulo, and also Alastair, > > Thanks for the responses. And, from a practical perspective, Paulo's > workaround is interesting (and also works). But ... > > Wait a minute. The type (according to GHCI) of both: > > xyz = do getLine > > and > > abc = do p <- getLine > return p > > is IO String. And, in fact, both expressions indeed return the String part of > the IO String. So (I'm playing devil's advocate here) you are asserting that > it is correct for one entity of type IO String to provoke different behavior > than another entity of type IO String. All "IO String"s are not created > equal. > > I don't see, fundamentally, how it violates referential integrity or any other > functional programming principle to stick a value somewhere and not use it. > It might not be very intelligent, or useful, but that is irrelevant from the > theoretical perspective. > > And, the restriction has a negative impact on code reuse. I shouldn't need to > define both "abc" and "xyz" in the above example, which do the same thing, > merely because sometimes I want the result and other times I don't. > > On Saturday 17 August 2002 16:14, you wrote: > > Perhaps it will help if you recall the meaning of the do notation, > > according to the Haskell98 Report. > > > > do {e} = e > > do {e;stmts} = e >> do {stmts} > > do {p <- e; stmts} = > > let > > ok p = do {stmts} > > ok _ = fail "..." > > in e >>= ok > > do {let decls; stmts} = let decls in do {stmts} > > > > > > Note that "do p <-e" only has meaning when is followed by something else > > (e.g. an expresion). One way to explain it is that it only makes sense to > > introduce "p" to use it later (e.g. you are reading a string and binding it > > to "p" to parse it later). If you are only interested in the side effects > > of "getLine", you should write: > > > > main = do getLine > > > > This will effectively read a line and discard it afterwards. Try it. > > > > Paulo. > > > > ----- Original Message ----- > > From: Seth Kurtzberg <seth(a)cql.com> > > To: <glasgow-haskell-users(a)haskell.org> > > Sent: Saturday, August 17, 2002 2:23 PM > > Subject: Question about error message > > > > > Hello, all > > > > > > There is an error message that I get from GHCI that I do not understand. > > > Usually it is caused by a syntax error or an indentation error, but I > > > have occasionally seen it in other contexts and I'd like to understand > > > what it > > > > is > > > > > trying to tell me. > > > > > > The message is that the last statement in a do construct must be an > > > > expression > > > > > (exact text below). > > > > > > I believe this occurs when the last statement in the do construct has a > > > > type > > > > > other than "IO ()". The documentation (or perhaps Simon Thompson's or > > > > Paul > > > > > Hudak's book; they get jumbled together in my mind) states that all > > > statements in a do construct have type "IO ()"; but this is clearly not > > > correct, as in: > > > > > > do line <- getLine > > > putStrLn line > > > > > > where the first statement has type IO String. > > > > > > Here is an example. This code is useless but it is not obvious to me why > > > > it > > > > > is incorrect: > > > > > > main = do line <- getLine > > > > > > producing the error: > > > > > > <interactive>:1: The last statement in a 'do' construct must be an > > > > expression > > > > > (This also limits the ability to enter monadic programming to the > > > interpreter.) > > > > > > TIA, > > > > > > -- > > > Seth Kurtzberg > > > M. I. S. Corp > > > seth(a)cql.com > > > 1-480-661-1849 (GMT-7) > > > > > > _______________________________________________ > > > Glasgow-haskell-users mailing list > > > Glasgow-haskell-users(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- > Seth Kurtzberg > M. I. S. Corp > seth(a)cql.com > 1-480-661-1849 (GMT-7) >

3 2

RE: weird floating point exception with -Rghc-timing
by Simon Marlow 19 Aug '02

19 Aug '02

> It seems that if compilation is not required, or if > compilation is very > fast, ghc -Rghc-timing will throw up a Floating point exception: > > [hdaume@hal3 timing]$ ls > Timing.hs > [hdaume@hal3 timing]$ cat Timing.hs > module Timing where > > timing = undefined > > [hdaume@hal3 timing]$ ghc -Rghc-timing Timing.hs -c > <<ghc: 9358352 bytes, Floating point exception This is a divide-by-zero bug in the code that generates the stats, which I think I've fixed. You must have some custom heap settings that are triggering this though: is your GHC_RTS environment variable set to anything? Cheers, Simon

1 0

weird floating point exception with -Rghc-timing
by Hal Daume III 19 Aug '02

19 Aug '02

It seems that if compilation is not required, or if compilation is very fast, ghc -Rghc-timing will throw up a Floating point exception: [hdaume@hal3 timing]$ ls Timing.hs [hdaume@hal3 timing]$ cat Timing.hs module Timing where timing = undefined [hdaume@hal3 timing]$ ghc -Rghc-timing Timing.hs -c <<ghc: 9358352 bytes, Floating point exception [hdaume@hal3 timing]$ ls Timing.hi Timing.hs Timing.o [hdaume@hal3 timing]$ rm *.hi *.o [hdaume@hal3 timing]$ ghc Timing.hs -c [hdaume@hal3 timing]$ ls Timing.hi Timing.hs Timing.o [hdaume@hal3 timing]$ Am I right or is something else going on here...? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: ghc 5.04 -- make -prof -auto-all under WinNT
by Simon Marlow 19 Aug '02

19 Aug '02

> I tried to compile the following little program (hallo.hs) > with ghc-5.04 --make -prof -auto: We have some problems with profiling on Windows in 5.04. At least one bug has been tracked down and fixed, and we'll try to make sure that profiling is working properly for 5.04.1. Sorry I can't offer any workarounds, other than to try using a Unix box of some description to do your profiling on. Cheers, Simon

1 0

Question about error message
by Seth Kurtzberg 17 Aug '02

17 Aug '02

Hello, all There is an error message that I get from GHCI that I do not understand. Usually it is caused by a syntax error or an indentation error, but I have occasionally seen it in other contexts and I'd like to understand what it is trying to tell me. The message is that the last statement in a do construct must be an expression (exact text below). I believe this occurs when the last statement in the do construct has a type other than "IO ()". The documentation (or perhaps Simon Thompson's or Paul Hudak's book; they get jumbled together in my mind) states that all statements in a do construct have type "IO ()"; but this is clearly not correct, as in: do line <- getLine putStrLn line where the first statement has type IO String. Here is an example. This code is useless but it is not obvious to me why it is incorrect: main = do line <- getLine producing the error: <interactive>:1: The last statement in a 'do' construct must be an expression (This also limits the ability to enter monadic programming to the interpreter.) TIA, -- Seth Kurtzberg M. I. S. Corp seth(a)cql.com 1-480-661-1849 (GMT-7)

3 2

RE: (not) catching ^C in ghc-built application
by Simon Marlow 16 Aug '02

16 Aug '02

> > I have a program, written in a mixture of Haskell and C, in > which the > > C part is supposed to handle a ^C interrupt, accomplished > through the > > usual signal() call. But when it is compiled by ghc, for > some reason > > the ghc RTS appears to trap the interrupt itself, and halts the > > program with the message > > prog: interrupted > > instead of allowing the newly installed C signal handler to run. > > I finally found the cause of this. The ghc RTS has a global variable > `interrupted', which is set by its interrupt handler, and tested by > various other parts of the scheduler. > > Guess what - my C routines also have a global variable called > `interrupted', and my own ^C interrupt handler was also setting > this variable. D'oh. If I change the name of my global variable, > then everything works as it ought to. > > I know it's a pain for you, but can I file this as a bug report > in ghc? Stealing simple and obvious global identifiers from the > user's namespace is rather dangerous, and even more so when it is > undocumented. These global "common" variables are a pain in the neck. There are 44 of these in GHC's RTS - we should really at the least initialise them so that you'll get a conflict if you define a global with the same name in your own code. Thanks for the report. Cheers, Simon

1 0

RE: intermediate hc files, where
by Simon Marlow 16 Aug '02

16 Aug '02

> I want to build ghc-5.02.3 from scratch, where can I find the > bootstrap files please? The website says they should be listed among > the downloads for the release, but this isn't so. Bootstrapping from .hc is a particularly tricky process at the moment. Unless you've seen it already, take a look at http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l What platform are you trying to build on? (.hc files are architecture-specific, except for "unregisterised" .hc files). Cheers, Simon

1 0

ghc 5.04 -- make -prof -auto-all under WinNT
by andreas.marth＠daimlerchrysler.com 15 Aug '02

15 Aug '02

Hallo! I tried to compile the following little program (hallo.hs) with ghc-5.04 --make -prof -auto: import System (getArgs) main :: IO () main= do args <- getArgs if args == [] then error "Aufruf: Filename Dimension1 Dimension2 ..." else prog (head args) (tail args) prog :: FilePath -> [String] -> IO () prog file dimZ = do cont <- readFile file putStr (file ++ "\n") putStr (show dimZ ++ "\n") let result = "Hello world!" writeFile (file++".out") ( result) The system is WinNT and compiling succeeded. But I got an a.out file while I should get a file hallo.exe (according to ghc --help). I renamed the program to hallo.exe and tried it. When I don't give any arguments it behaves like expected. If I give it one or more arguments it crashes. When I compile it only with ghc --make hallo.hs I also get an a.out file but this behaves well when renamed to hallo.exe. What is the problem? And what can I do to use the profiling? Thank, Andreas

1 0