August 2003 - Glasgow-haskell-users

preemptive getLine on cygwin?
by Claus Reinke 11 Aug '03

11 Aug '03

I seem to have some problems understanding preemptive getLine behaviour on cygwin, and wonder whether this is a known/fixed bug/feature (I haven't switched to ghc-6.. yet), or whether anyone has experience with this (behaviour on solaris, with an even older ghc is more or less as expected). Claus -- consider the following example. compile, run, and whenever the -- program waits for input, enter the next natural number, starting -- from 1. note that the program preempts the first input and may -- or may not accept input after the second output.. module Main where import IO main = do hGetBuffering stdin >>= print hGetLine stdin >>= print hGetLine stdin >>= print ------- win98, cygwin $ ./Getline LineBuffering "" 1 "1" $ cat | ./Getline BlockBuffering Nothing 1 "1" 2 "2" 3 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 ------- solaris $ ./GetLine LineBuffering 1 "1" 2 "2" $ cat | ./GetLine BlockBuffering Nothing 1 "1" 2 "2" 3 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.02.3

1 0

RE: strange behaviour
by Simon Marlow 11 Aug '03

11 Aug '03

> My point here is to know, what's the reason for the different > behaviour, rather than discussing the > correctness of using unsafePerformIO. The reason is this: GHC uses a lazy evaluation strategy, as opposed to fully-lazy. Under lazy evaluation, the unsafePerformIO expression in your example will be evaluated each time main is invoked. When -O is turned on, GHC performs some transformations on the code that have the effect of changing the evaluation strategy to "almost fully-lazy". That is, there will be some more sharing, but not necessarily as much as you would get in a compiler that implements fully-lazy evaluation. Indeed, even without -O, you might get a bit more sharing than you would under pure lazy evaluation. Of course, you should never write any code that depends on any of this. Cheers, Simon

2 1

RE: strange behaviour
by Simon Marlow 11 Aug '03

11 Aug '03

> It's correct behaviour to print "test" any number of > times. Haskell is non-strict, which only means that things > aren't evaluated unless needed. It's not (defined to be) > lazy, which would mean that named expressions would be > evaluated at most once (though ghc meets this). It's also > not defined to be "fully lazy" meaning that unnamed > expressions would be evaluated at most once in any given > closure. So GHC is entirely within its rights to evaluate > <<unsafePerformIO (print "test")>> any number of times, or > possible even none, since it knows that that expression > always returns the same value (). It wouldn't be correct to not evaluate it at all: it might be _|_ or raise an exception. Cheers, Simon

1 0

strange behaviour
by David Sabel 11 Aug '03

11 Aug '03

Hi, the following "toy" program has a strange behaviour, when compiling with ghc5.04.3 an no optimisation (-O0) module Main(main) where import System.IO.Unsafe main = case unsafePerformIO (print "test") of () -> main ok, probably I use unsafePerformIO in an "unsafe" way and so on, but executing the program prints infinitely often "test" on the screen, but I think it would be correct to do so one time? I think it has something to do with exporting main, because the following program module Main(main) where import System.IO.Unsafe main = seq f (return ()) f = case unsafePerformIO (print "test") of () -> f behaves ok. Does someone, what's the reason for this? Thanks, David

2 2

RE: linker errors
by Simon Marlow 11 Aug '03

11 Aug '03

Hi, > Passing "-O" flag to ghc has solved the problem for > now. But since a lot more code is yet to be written, > I will keep my fingers crossed if the "-O" flag will > continue to avoid the "undefined symbol" problem at > the link-stage. > > Looking at the intermediate code generated by ghc with > "-ddump-ds" option, it seems that ghc is generating > code that groups functions involved in certain > call-chains (whether contributing to recursion or > not), difines them in a "__letrec" block, and puts > them in a tuple, and generates outer definititons of > these functions by using differfent elements in the > tuple. This bug has been fixed, sorry for not noticing before. The fix wasn't merged into 6.0.1, but it will be in 6.2. Cheers, Simon

1 0

award-winning
by a_tripp2＠pacbell.net 09 Aug '03

09 Aug '03

POSSIBLE TROJAN DETECTED! WARNING.. Most users dont realize they have a virus, and find out after its too late. Norton Antivirus Stops hackers, trojans and viruses in their tracks! btw, you look great today. Total PC Protection RIGHT NOW. http://dsajoAS@profitableproducts.com/default.asp?id=3000 ps. dont want any more of this shit? http://FDSA2PP@profitableproducts.com/remove/remove.html

1 0

RE: linker errors
by A.P. Rao 08 Aug '03

08 Aug '03

Passing "-O" flag to ghc has solved the problem for now. But since a lot more code is yet to be written, I will keep my fingers crossed if the "-O" flag will continue to avoid the "undefined symbol" problem at the link-stage. Looking at the intermediate code generated by ghc with "-ddump-ds" option, it seems that ghc is generating code that groups functions involved in certain call-chains (whether contributing to recursion or not), difines them in a "__letrec" block, and puts them in a tuple, and generates outer definititons of these functions by using differfent elements in the tuple. While I don't understand why this is done, it is very unreasonable to fix a limit of 62 for such tuple-sizes, because this limit can easily be exceeded by good, hand-written code, for example, when implementing parsers for complicated language definitions (not because the user-code uses big tuples, but because of the tuples generated by ghc itself). Manually analysing and restructuring the code in such cases to work around this compiler limitation is not realistic. Is this limitation purely a result of using Base-62 numbers in compiler/basicTypes/Unique.lhs ? If so, will changing this one file and redefining the mAX_TUPLE_SIZE fix the problem? The best solution perhaps is to avoid generation of such tuples altogether. I also see the following note in ghc.spec file. Is that related to the current issue ? If so, is this limitation non-existent in that particular version of GHC? ------------------- * Thu Sep 16 1999 Manuel Chakravarty - modified for GHC 4.04, patchlevel 1 (no more 62 tuple stuff); ------------------- I wish I could volunteer to fix this problem, but I don't understand what is really going on. Will somebody who knows the internals of GHC fix this? Or, is this such a low-priority task that it will never get scheduled ? Unfortunately, neither of the other two Haskell compilers are alternative solutions due to other limitations. Thanks, A.P. Rao. --- "A.P. Rao" <aprao(a)yahoo.com> wrote: > > The code is hand-written and the maximum tuple-size > used is 4. It works fine in Hugs. It uses the Parsec > library (not the version in GHC's "text" package, > but > from a local copy. The ParsecPrim.hs was replaced by > the version from Parsec's web-site -- it works as I > expected, but not the one distributed with GHC or > Hugs). > > The code makes straight-forward use of Parsec > combinators for parsing ASN.1, and I can't see a > nesting of anything close to 62 mutually recursive > functions. > > If there is a "readme" type of document that > explains > the names and the tables generated in the ".hc" > files, > it may help me track down what construct is causing > this problem. Right now, I can't recognize anything > in the lines surrounding the place where this > DataziTuple_Z73T_con_info symbol is used in the > ".hc" > file. > > Thanks, > A.P. Rao. > --- Simon Peyton-Jones <simonpj(a)microsoft.com> > wrote: > > One of GHC's infelicities is that it only supports > > tuples up to a > > certain size -- currently 62. > > You just can't get bigger tuples. Your program > uses > > a 73-tuple. My > > guess is that your code is generated by some other > > program that's > > generating big tuples? > > > > The only workaround is to nest your tuples. > > > > It would really be much better if GHC complained > in > > the front end about > > over-size tuples. I'll fix that. The "real" fix > > (arbitrary size > > tuples) isn't really hard, but it involves real > work > > so we keep > > postponing it on the gounds that it seldom bites. > > So please continue to > > say if it bites you, so that we know. > > > > It used to be the case that simply having a nest > of > > more than 62 > > mutually-recursive functions would trigger this > bug, > > but that should no > > longer be the case with 6.0. Please say if that > is > > happening. > > > > Simon > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Fwd: Re: The place that saved me
by buta＠yahoo.com 08 Aug '03

08 Aug '03

whats up. I thought you might be interested in this. not only that but you just owe it to yourself and your family, simply put, your matched with the cheapest possible mortgage available for your loan. >----------- http://r.aol.com/cgi/redir-complex?url=http://lowinterest@onlinesaleew.com/… >----------- dont want me to write any more? http://r.aol.com/cgi/redir-complex?url=http://43@onlinesaleew.com/auto/inde…

1 0

RE: link statically with libc?
by Simon Marlow 08 Aug '03

08 Aug '03

> in traditional Sun javac, you get something that basically looks like: > > for (int i=0; i<1000; i++) { > if i outside of arr bounds, throw exception > acc += arr[i]; > } > > but the IBM compiler will lift this out (under certain > circumstances -- for instance, if 'acc' is not in scope of > the catch) to: > > if 0 outside of arr bounds || 999 outside of arr bounds, > throw exception > for (int i=0; i<1000; i++) { > // look ma, no checks > acc += arr[i]; > } > > does GHC do anything similar to this, or are we getting hit > with array checks at each and every read/write (modulo, of > course, full laziness)? No, we don't do anything that clever. Some of the bulk array operations are written in such a way to eliminate obviously-true bound checks (eg. listArray doesn't do a bound check for every element), but that's about it. Cheers, Simon

1 0

RE: link statically with libc?
by Hal Daume 07 Aug '03

07 Aug '03

> > I don't know how the Ada guys do it. Perhaps they have an alternate > > set of compiled libraries with bounds-checking turned off? > > Me neither, I've just heard the idea discussed, not the actual > technology. I know O'Caml does this too (-unsafe as a compiler flag gives you unsafe array accesses). I've found in that context, I get as much as a 15% speedup over not having -unsafe. Admittedly this is on an extremely array-intensive application, but it certainly can be a win. On a related note, I know that the IBM Java compiler (I'm blanking on the name right now) gets a lot of its speedups over Sun by lifting bounds checks out of loops. That is, if you have: for (int i=0; i<1000; i++) { acc += arr[i]; } in traditional Sun javac, you get something that basically looks like: for (int i=0; i<1000; i++) { if i outside of arr bounds, throw exception acc += arr[i]; } but the IBM compiler will lift this out (under certain circumstances -- for instance, if 'acc' is not in scope of the catch) to: if 0 outside of arr bounds || 999 outside of arr bounds, throw exception for (int i=0; i<1000; i++) { // look ma, no checks acc += arr[i]; } does GHC do anything similar to this, or are we getting hit with array checks at each and every read/write (modulo, of course, full laziness)? - Hal

1 0