RE: strange selectee 11

2000-02-14 Thread Simon Peyton-Jones
This is a Bad Situation. It looks like a bug in the garbage collector, which are very hard to reproduce. It will probably go away if you change *anything* (heap size etc). Do pls try it with 4.06. If it happens there then we'd better get the source and see if we can reproduce it. Simon |

RE: strange selectee 11

2000-02-14 Thread Julian Seward (Intl Vendor)
Would upgrading to 4.06 be likely to help here? Maybe. Try. If your program relies on concurrency or non-blocking IO, it might help. J

RE: strange selectee 11

2000-02-14 Thread Julian Seward (Intl Vendor)
Thinking about this more, the error msg has a familiar sound to it. Did you use 4.04 patchlevel 0 or 1 ? pl 0 has some rts-ish probs which were fixed in pl1 (and of course in 4.06). J Would upgrading to 4.06 be likely to help here?

Re: strange selectee 11

2000-02-14 Thread Josef Sveningsson
Hi guys! On Mon, 14 Feb 2000, Alastair Reid wrote: Thinking about this more, the error msg has a familiar sound to it. Did you use 4.04 patchlevel 0 or 1 ? pl 0 has some rts-ish probs which were fixed in pl1 (and of course in 4.06). The Glorious Glasgow Haskell Compilation System,

Re: strange selectee 11

2000-02-14 Thread Alastair Reid
Thinking about this more, the error msg has a familiar sound to it. Did you use 4.04 patchlevel 0 or 1 ? pl 0 has some rts-ish probs which were fixed in pl1 (and of course in 4.06). The Glorious Glasgow Haskell Compilation System, version 4.04, patchlevel 1 My program is just a plain old

Re: strange selectee 11

2000-02-14 Thread Josef Sveningsson
Sorry for replying on my own posting but... On Mon, 14 Feb 2000, Josef Sveningsson wrote: I also managed to get the 'strange selectee' error but with number 27 instead while compiling. The thing is that I'm running ghc 4.06 . The file I compiled was a Lex generated file. OK, now you all

Trivial Haskell Concurrency problem

2000-02-14 Thread George Russell
Sorry if you don't want to be bothered with my problems, but I think this problem which I've just encountered is rather amusing. Is there a neat solution? I confess to finding concurrency problems difficult so there might be. I want to implement a type Flag. Each flag is either Up or Down.

Trivial Haskell Concurrency problem

2000-02-14 Thread Tom Pledger
Tom Pledger writes: [...] Something along these lines: But without the bug and the eccentricities. :-( [...] wasDown2 - sag flag2 This just moved the deadlock. Instead of doing a busy wait for a non-sagging flag2, we must put flag1 back up and try again from the beginning

Re: Trivial Haskell Concurrency problem

2000-02-14 Thread Michael Hobbs
George Russell wrote: The problem is that lowerFlags should appear to be atomic, so that if lowerFlags is called simultaneously in different threads, the result should be the same as if one of the calls completed before the other started. If you want lowerFlags to be atomic, in the global

Re: Trivial Haskell Concurrency problem

2000-02-14 Thread Michael Hobbs
George Russell wrote: What is the neatest solution? There is an obvious solution, which is to crudely sequence all calls to lowerFlags by making them lock a single global variable (created using, sigh, unsafePerformIO) but this doesn't seem very elegant. If MVar's were instances of Ord as

intro to profiling

2000-02-14 Thread Nick Eby
I am attempting to learn to use ghc's profiling utilities. I successfully compiled a program (without using -prof) that used the ListUtils library. When i went back to try and profile this program i did something like /ghc -c -O -prof -auto ListUtils.hs and got an error message to the effect of

Re: Trivial Haskell Concurrency problem

2000-02-14 Thread Michael Hobbs
Michael Hobbs wrote: (We're assuming that we can't lock them both simultaneously) I knew I should have read the literature on deadlock avoidance before posting that message. :-/ In fact, I should have used the word "atomically" above instead of "simultaneously". As it turns out, I believe that

Re: Trivial Haskell Concurrency problem

2000-02-14 Thread Michael Hobbs
Michael Hobbs wrote: Here's my stab at it. (NB: This is simply an off-the-cuff attempt. It looks like it should work right, but it is far from rigorously tested or analyzed.) grumble/ I discovered a path that would cause a deadlock in that code as well. However, I have a change that /should/

RE: [wish list] Lightweight extensible records for Haskell

2000-02-14 Thread Simon Peyton-Jones
| Could we please have lightweight extensible records for Haskell (as | in the paper by (Mark|Simon Peyton) Jones in the 1999 Haskell | Workshop). | | Seconded. | | Symmetric record catenation, as opposed to extensibility by one field | at a time, would make the Haskell even nicer for

Re: overlapping instances

2000-02-14 Thread Marcin 'Qrczak' Kowalczyk
Thu, 10 Feb 2000 23:00:08 +0300 (MSK), S.D.Mechveliani [EMAIL PROTECTED] pisze: Generally it does not fit into my mental model of a Haskell class. How could it be that adding an instance *constrains* what else we can do with a type (define an instance of another class)? In what way it

Re: overlapping instances

2000-02-14 Thread Tom Pledger
Marcin 'Qrczak' Kowalczyk writes: [...] However in the following case there is an ambiguity that I don't know how to resolve - overlapping instances don't solve what they seemed to claim to solve: classA a where ... class A a = B a where ... classC a where ...