- Glasgow-haskell-users

RE: Bug? [was: Implicit params]
by Simon Peyton-Jones 15 Nov '02

15 Nov '02

| > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? Interesting. I hadn't thought of that. Yes, I think you can consider it a bug, or at least the lack of a feature. I'll fix it next week S

1 0

RE: Help: Windows ghc profiler errors
by Simon Marlow 15 Nov '02

15 Nov '02

> I want to profile my Haskell program (it solves the Queens and Knights > problem stated here: > http://www.itasoftware.com/careers/programmers.php ). > I'm compiling with GHC 5.04.1 under Windows NT using the > following command > line (as per the Users Guide): > > >ghc -prof -auto-all -o queens --make Main > > > When I run the program with the following command lines I get: > > >queens > queens: fatal error: evacuate: strange closure type 1696 Profiling is broken on Windows in 5.04.1. I think we know what the problem is, and it will be working again in 5.04.2. Sorry about that. Cheers, Simon

1 0

RE: bug in unix/System/Posix/Files.hsc
by Simon Marlow 15 Nov '02

15 Nov '02

> In local.glasgow-haskell-users, you wrote: > > readSymbolicLink is broken, it assumes that readlink(2) > null terminates its > > result when it doesn't. this causes all sorts of badness. > > This should fix it, although all my CVS trees are hosed right now > (now how did I manage to break something in the backup tree?) and I > can't actually test it: <patch snipped> Thanks, I'll check it in. As you probably guessed, this stuff hasn't had any testing yet. Cheers, Simon

1 0

bug in unix/System/Posix/Files.hsc
by John Meacham 15 Nov '02

15 Nov '02

readSymbolicLink is broken, it assumes that readlink(2) null terminates its result when it doesn't. this causes all sorts of badness. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

RE: strange error
by Simon Marlow 14 Nov '02

14 Nov '02

> sorry for the terse error report, but I was on my way out the door and > didn't want this to slip through. It appeared after running a rather > large complicated haskell program all night, the next morning it had > crashed with > fatal error: evacuate: strange closure type 55436 There has been one bug found in the garbage collector since 5.04.1, which might have caused this. Presumably if you ran the same program under the same conditions it would fail in the same way (how long does it take to fail?). Is there any chance you could compile up the latest CVS sources from the 5.04 branch and see if using that compiler helps? Cheers, Simon

2 1

Help: Windows ghc profiler errors
by Bayley, Alistair 14 Nov '02

14 Nov '02

I want to profile my Haskell program (it solves the Queens and Knights problem stated here: http://www.itasoftware.com/careers/programmers.php ). I'm compiling with GHC 5.04.1 under Windows NT using the following command line (as per the Users Guide): >ghc -prof -auto-all -o queens --make Main When I run the program with the following command lines I get: >queens queens: fatal error: evacuate: strange closure type 1696 >queens +RTS queens: fatal error: evacuate: strange closure type 1728 >queens +RTS -p queens: fatal error: evacuate: strange closure type 1760 (I have no idea if the change in closure type is significant, but it is quite clearly related to the command line options used.) The program works without profiling (whether or not it produces the correct answers is another matter). I just want to practice profiling and optimising Haskell programs. I've also tried running the profiler with a minimal program: > module Main where > main :: IO () > main = do putStrLn "hello world" ... and I get a segmentation fault. Anyway, I've had a quick look through the last couple of months of mailing list archives and haven't noticed anything related to this error. Any ideas? Thanks, Alistair. ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

1 0

-Werror Request
by Ashley Yakeley 14 Nov '02

14 Nov '02

If it's not too much work, I'd like to request a "-Werror" option for GHC that would turn warnings into errors. Sometimes warnings one would like to catch get lost in a long make process. Thanks... -- Ashley Yakeley, Seattle WA

1 0

strange error
by John Meacham 14 Nov '02

14 Nov '02

fatal error: evacuate: strange closure type 55436 although I have not been able to reproduce it... -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 1

Re: Record of STRefs better than STRef to a Record?
by Jorge Adriano 14 Nov '02

14 Nov '02

> > I'm passing that 'record' around as an implicit value. The record as > > STRefs that I use to collect info, but it also has some pure fields with > > 'read-only' info. Something like, <opss let me change 'max' to 'm'> > > data E s = E{ > > refi :: STRef s Int, > > refc :: STRef s Char, > > m :: Int > > } > > > > In some functions I might need only some pure fields, and none of the > > STRefs, but since I pass something of type 'E s' around, everything ends > > up beeing monadic. > > there is no reason why that should be the case. you only need to be > within the ST monad when you read the references, so if in some function > you only look at the pure values, it can have a pure type. > hope this helped > iavor That's what I thought, untill I tried it. Well, actually you must be right since the pure field defines a pure (projection) function... Hmmm, ok, can someone explain this to me, data E s = E{ refi :: STRef s Int, refc :: STRef s Char, m :: Int } -- this is fine, obviously... pure :: E s -> Int pure e = m e -- but this is not... pure2 :: (?e :: E s) => Int pure2 = m (?e) Why exactly isn't this allowed? What is the workaround? Error msg: ------------------------------------------------------------------------ Ambiguous constraint `?e :: E s' At least one of the forall'd type variables mentioned by the constraint must be reachable from the type after the '=>' In the type: forall s. (?e :: E s) => Int While checking the type signature for `pure2' Failed, modules loaded: none. -------------------------------------------------------------------------- Thanks, J.A.

1 0

Record of STRefs better than STRef to a Record?
by Jorge Adriano 13 Nov '02

13 Nov '02

Hi all, If I use an STRef to a record, will a new record be created each time I want to update a single field? Or can I expect GHC to optimize it and have the field of the record updated in place? Right now I'm using a record of STRefs, like: data E s = E{ refi :: STRef s Int, refc :: STRef s Char } but it can get a little messy, since thread s propagates to every datatype that uses the record type in it's definition. Thanks, J.A.

2 2