
"Simon Peyton-Jones"
writes: So far we have not been regarding 6.2 as ultra-urgent because we don't know of anyone who is really stuck with 6.0. Please let us know if you are in fact stuck.
I already mentioned that I really need large file support, and I'd add that I have some problems with profiling (segfaults, internal errors¹), both under 6.0 and 6.0.1. Is this known and/or fixed? And was there any answer to the original question:
The 'strange selectee 29' crash that you reported earlier is fixed in 6.2. I saw your '.hp file contains NULs' reoprt, but there's not much we can do without a test case, unfortunately. I've never seen this one myself. Are there any other profiling bugs that I missed? (apart from the 'entries field is zero' bug in SourceForge)?
When can we expect 6.2?
I can work e.g. the large file issue by using multiple files, but as it's going to be fixed RSN, I haven't bothered yet. An approximate schedule would be nice, I promise not to blame anybody if it doesn't hold. :-)
We're removing a lot of old/deprecated stuff in 6.2, so I want to be sure we haven't broken anything before doing the release. The best estimate I can give is 4-6 weeks, but it could be sooner if things settle down quickly. Cheers, Simon

"Simon Marlow"
The 'strange selectee 29' crash that you reported earlier is fixed in 6.2.
Okay.
I saw your '.hp file contains NULs' reoprt, but there's not much we can do without a test case, unfortunately. I've never seen this one myself.
I've only seen it once, and I was using a vim script on the file. Not everything shipped with Red Hat 9 is rock solid, so it might be a vim bug.
Are there any other profiling bugs that I missed?
I've also gotten segmentation fault (w/ 6.0) when doing -h and -p simultaneously. I'm not sure if I can reproduce it, but I'll save a snapshot if it happens again in a reproducible manner. I did a quick test now (v. 6.0.1), and it worked okay.
The best estimate I can give is 4-6 weeks, but it could be sooner if things settle down quickly.
Great! -kzm -- If I haven't seen further, it is by standing in the footprints of giants

We're removing a lot of old/deprecated stuff in 6.2, so I want to be sure we haven't broken anything before doing the release. The best estimate I can give is 4-6 weeks, but it could be sooner if things settle down quickly.
talking about broken things: I've been reluctant to mention it so far, because I can't even give a reproducable example, and the problem only occurs on very large projects, so without a clue as to what might cause it, I certainly couldn't narrow down such an example, should I manage to pin down one. there seems to be a problem in ghc --make's recompilation dependency checks, which means that recompilation might produce inconsistent executables. the usual effect is a problem-free rebuild, followed by inexplicable crashes of the executable. removing the .hi/.o files and calling ghc --make again reliably solves the problem, which is why I suspect recompilation-only dependency checks (type/class changes not propagated to dependent modules?). sorry about this rather useless piece of information, but perhaps other people on this list have other parts of the puzzle, and it would be nice to get rid of this (haskell programs don't crash like this!-). cheers, claus

On Fri, Sep 26, 2003 at 02:07:57PM +0100, Claus Reinke wrote:
talking about broken things: I've been reluctant to mention it so far, because I can't even give a reproducable example, and the problem only occurs on very large projects, so without a clue as to what might cause it, I certainly couldn't narrow down such an example, should I manage to pin down one.
there seems to be a problem in ghc --make's recompilation dependency checks,
I have noticed that if you make 2 programs in the same directory then you can end up with the first Main.o being used for the second program (at least I assumed that was what was happening. I didn't actually investigate). I can't remember if the new behaviour was in 6.0.1 or not. I don't know if this can actually causes crashes rather than just a program that does what you don't want or a link failure, though. Ian
participants (4)
-
Claus Reinke
-
Ian Lynagh
-
ketil@ii.uib.no
-
Simon Marlow