- Glasgow-haskell-users

@-bindings broken in 6.0?
by John Meacham 18 Jun '03

18 Jun '03

change in list comprehension parsing? after I upgraded to ghc 6.0 there were some odd syntax errors on list comprehensions which i did not get before, making sure i put spaces between all symbols seems to fix them.. was something changed about how they are parsed which breaks code that used to work? just curious. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

isEmptyChan blocks?
by Peter Strand 17 Jun '03

17 Jun '03

Hi, I noticed that isEmptyChan blocks if the channel is already waited on by readChan, is this the intended behaviour? At least I was a bit surprised by a blocking predicate.. Example program: import Control.Concurrent main = do ch <- newChan let loop = do threadDelay 1000000 -- make sure readChan executes isEmptyChan ch print "not reached" loop forkIO loop readChan ch This happens both with 5.04.2 and 6.0, on linux. When compiled, "Fail: thread blocked indefinitely" is printed, ghci just blocks. The corresponding program with MVars doesn't block. /Peter

1 0

RE: 5.04.3: update_fwd: unknown/strange object
by Simon Marlow 17 Jun '03

17 Jun '03

> I build by new DoCon program under ghc-5.04.3, > > installed from RPM to i386-unknown, RedHat Linux. > > Under -Onot, the command make space=-M22m docon > builds the thing successfully. > And for less memory, say, ... 16m ..., > it ends with > > ... > pol/Pgcd_.hs:184: > Warning: No explicit method nor default method for `toSquareFree' > In the instance declaration for `GCDRing (Pol a)' > > =================== INTERFACE HAS CHANGED ==================== > No old interface available > > ghc-5.04.3: fatal error: update_fwd: unknown/strange object 38344 > make: *** [obj] Error 254 > > > I expected of GHC to report of exhausted memory. > Probably, such behavior is not fatal for may aims, > but if you consider this as an interesting bug, I could send the > archive. I'll be interested to know whether you can repeat this with 6.0. If so, yes I'd like to see the sources. Cheers, Simon

2 1

5.04.3: update_fwd: unknown/strange object
by Serge D. Mechveliani 17 Jun '03

17 Jun '03

Dear GHC team, I build by new DoCon program under ghc-5.04.3, installed from RPM to i386-unknown, RedHat Linux. Under -Onot, the command make space=-M22m docon builds the thing successfully. And for less memory, say, ... 16m ..., it ends with ... pol/Pgcd_.hs:184: Warning: No explicit method nor default method for `toSquareFree' In the instance declaration for `GCDRing (Pol a)' =================== INTERFACE HAS CHANGED ==================== No old interface available ghc-5.04.3: fatal error: update_fwd: unknown/strange object 38344 make: *** [obj] Error 254 I expected of GHC to report of exhausted memory. Probably, such behavior is not fatal for may aims, but if you consider this as an interesting bug, I could send the archive. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: problems with working with Handles
by Simon Peyton-Jones 17 Jun '03

17 Jun '03

| Prelude Strategies IO> hClose h | Prelude Strategies IO> length cs | 737535 | Prelude Strategies IO> | | Note that you have to use -package Strategies option. I couldn't find | this module in the hierarchical libraries. The same works in GHC 5.04.3 | | To GHC developers: | What is the status of this module? | Can I assume that future versions of GHC will have it? It's called Control.Parallel.Strategies. Current plan is to leave it there, and ship it with future versions of GHC. Simon

1 0

"How do I find out a function's strictness?"
by Francis Girard 17 Jun '03

17 Jun '03

Hi, In the ghc manual I read : "How do I find out a function's strictness?" Don't guess-look it up. Look for your function in the interface file, then for the third field in the pragma; it should say __S <string>. The <string> gives the strictness of the function's arguments. L is lazy (bad), S and E are strict (good), P is "primitive" (good), U(...) is strict and "unpackable" (very good), and A is absent (very good). -- When I look in the *.hi binary files generated by ghc with ghc --show-iface, I don't see anything like "__S" anywhere. Where should I look ? Thank you Francis Girard francis.girard(a)free.fr LE CONQUET, France

1 0

Re: [Gtk2hs-users] ghci-5.04.3 and ghc-6.0
by Duncan Coutts 16 Jun '03

16 Jun '03

On 16 Jun 2003 16:59:07 +0900 Jens Petersen <petersen(a)redhat.com> wrote: > Did anyone ever manage to get gtk2hs working with ghci-5.04.3? > When I try to load it I get: > > % ghci-5.04.3 -package gtk2 > : > Loading package data ... linking ... done. > Loading package gtk2 ... > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol > __stginit_Arrow > whilst processing object file > /usr/lib/ghc-5.04.3/gtk2hs/gtk2hs.o My brief investigation into this revealed that __stginit_Arrow is defined in HSlang.o (ghci's object file for package lang) and this is the only standard package in which it is defined. __stginit_Arrow is indeed also defined in gtk2hs.o It is defined there because it is defined in gtk/misc/Arrow.o (in the buid tree). Itis defined there because Arrow is the name of the module and that symbol refers to the module initialisation function (or something like that, perhaps it's a module dependancy marker symbol). What seems to be happening is that the Arrow module in gtk2hs is clashing with the Arrow module in the lang package. As far as I can tell this all looks perfectly normal, so why don't we this kind of problem all the time? What's special about Arrow? How does it get resolved in the libHS*.a case? How does the system linker resolve the ambiguity when ghci's linker cannot? Duncan

1 0

RE: Multi-Run RTS Flag Request
by Simon Marlow 16 Jun '03

16 Jun '03

> Something that I would find useful for profiling would be an RTS flag > that made the program run several times. That way I can get more > accurate numbers in the profiling report. > > At the moment I usually rename main to main', and set up a main that > runs main' 100 times. You can write your own main() (in C) which does this fairly easily. See the User's Guide for details on using your own main(). You could even put your special main() into a package, so you could write ghc -package multi-run ... Cheers, Simon

1 0

Multi-Run RTS Flag Request
by Ashley Yakeley 15 Jun '03

15 Jun '03

Something that I would find useful for profiling would be an RTS flag that made the program run several times. That way I can get more accurate numbers in the profiling report. At the moment I usually rename main to main', and set up a main that runs main' 100 times. -- Ashley Yakeley, Seattle WA

1 0

Strange bug (in ghc?)
by Hampus Ram 14 Jun '03

14 Jun '03

Hi, the stangest bug I've ever experienced has manifested in my code and I badly need some help finding it. I'm currently writing a small lexer generator using template haskell. It is supposed to fit in nicely with Happy and is therefore of the "threaded monadic" type. However it does not work, or at lest not when the number of regexps get too big and I compile the code. Using it with ghci is never a problem but when compiling (no matter which optimisation level I use) it often hangs in the middle of lexing (it is not the generation of code that is the problem, but the generated code itself). Given the very same input it seems to hang (eating 100% cpu but without doing anything visible) at very different stages. Sometimes it outputs almost all tokens and sometimes it doesn't read more that one or two. This is strange behaviour from a pure function but may be due to lazyness. To add more strangeness to it all the following code does not work (the function lexer is the TH generated function, imports omitted): main = do [arg] <- getArgs str <- readFile arg putStrLn $ show $ lexer cont str 0 0 cont t s c l = case t of Token.To_Error -> error "" Token.To_Eof -> [] _ -> t : lexer cont s c l However if you change "case t of" to the more esoteric "case unsafePerformIO (putStrLn (show t) >> return t) of " it works like a charm. The same if you plug it into Happy. Using it with normal parameters it does not work, but generating it with -d does the trick. Something strange with lazyness comes into mind but I can't think of what. The second thing I can think of is the compiler infering strange types somehow. All TH generated code is untyped, but that should not give any trouble? What can it be? Is it some error in ghc, perhaps something connected with template haskell (I do have a slightly different version that generates a .hs file instead and that has not failed me yet)? Do anybody know what's wrong or can give me some pointers to how I can find out? I do not appreciate reading external core or so since the problem only occurs for large lexers (which currently generates a few thousand lines since it doesn't use tables but functions). It's the very same with both ghc 6.0 and yesterdays CVS version and -dcore-lint does not say anything. I should perhaps also say that "hangs" means that it hasn't produced any output after it has run for about one hour at ~100% cpu. That seems to me as quite a bit too much time for one to suspect that it just takes a lot of time to produce output... /Hampus - very confused ps. If you need more information (such as intenals of "lexer") just say so, i think this letter is big enough now :) ds. -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: d00ram(a)dtek.chalmers.se "Det är aldrig försent att ge upp"

1 1