Re: 6.10.3 plans

2009-04-22 Thread Brandon S. Allbery KF8NH
On Apr 22, 2009, at 22:00 , Alexander Dunlap wrote: On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh wrote: An exception to this rule is that we will probably also rebundle time in the bindists, as that has little chance of breaking anything else. Would this be a good time to add the "time" pack

Re: 6.10.3 plans

2009-04-22 Thread Alexander Dunlap
On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh wrote: > > Hi all, > > Due to some problems with the handling of ^C in ghci, we are planning to > do a 6.10.3 release. > > The idea is that, rather than being a full-blown release process, > including all the various fixes that have been made since 6.10.

Re: 6.10.3 plans

2009-04-22 Thread Sigbjorn Finne
Hi Ian, thanks for the update on plans and the willingness to jump in and do another release cycle so soon after 6.10.2. The suggested fixes seem agreeable to me, but I have one _minor_ additional request for 6.10.3 if you end having to rebuild 'base' -- add a DEPRECATED (or some such) to Foreign

6.10.3 plans

2009-04-22 Thread Ian Lynagh
Hi all, Due to some problems with the handling of ^C in ghci, we are planning to do a 6.10.3 release. The idea is that, rather than being a full-blown release process, including all the various fixes that have been made since 6.10.2, we will only do what is necessary to resolve the ^C issue. By

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Felix Martini
2009/4/22 Simon Marlow: > You might want to run the process under ProcMon and see if you can > figure out what's going on (if you can bear to use ProcMon, it's a > very poor replacement for strace IMO). You could try StraceNT instead (not as good as strace though).

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Neil Mitchell
>> I have many threads, which read and write files. Every so often one >> thread will write a file, then another thread will read the same file >> - but fail during the open call. There are locks to ensure that the >> write call finishes before the read call begins. I modified the code >> to give:

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Simon Marlow
2009/4/22 Neil Mitchell : > I've got a multi-threaded application which occasionally generates > failures in openFile. I haven't been able to reproduce the errors > reliably, the code is way too large to send over, and any small > attempts at invoking the same problem don't seem to work. Despite th

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Neil Mitchell
Bulat: I haven't tried moving to Posix calls, I'll try that next - although I was hoping the application wouldn't be posix dependent. >> readFile calls openFile >>= hGetContents. It's the openFile that >> causes the problem, so READ START happens before openFile and READ >> STOP happens after open

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Claus Reinke
do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) ; return res Unless you've defined your own version of 'readFile', to mean read entire file now, the first 'print' is optimistic and the second 'print' is a lie. readFile calls openFile >>= hGetContents. It's the openFile th

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Neil Mitchell
Hi Claus, >> do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) >> ; return res > > Unless you've defined your own version of 'readFile', to mean read > entire file now, the first 'print' is optimistic and the second 'print' is a > lie. readFile calls openFile >>= hGetContents.

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Claus Reinke
do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x) ; return res Unless you've defined your own version of 'readFile', to mean read entire file now, the first 'print' is optimistic and the second 'print' is a lie. Claus do print ("WRITE START",x); writeFile x src ; print ("

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Bulat Ziganshin
Hello Neil, Wednesday, April 22, 2009, 4:22:01 PM, you wrote: you can try to use POSIX open/read/write/close calls > Hi, > I've got a multi-threaded application which occasionally generates > failures in openFile. I haven't been able to reproduce the errors > reliably, the code is way too larg

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Neil Mitchell
>  Is it too difficult to try this on Linux or Mac, just to see >  if it shows up there as well? Yes ;-) I might be able to try it on Linux next week, but that's as far as I'm likely to be able to go. If I get any results I'll email them in. Thanks Neil _

Re: writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Jason Dusek
Is it too difficult to try this on Linux or Mac, just to see if it shows up there as well? -- Jason Dusek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

writeFile/readFile on multiple threads leads to error

2009-04-22 Thread Neil Mitchell
Hi, I've got a multi-threaded application which occasionally generates failures in openFile. I haven't been able to reproduce the errors reliably, the code is way too large to send over, and any small attempts at invoking the same problem don't seem to work. Despite the uselessness of the bug repo

Re: No "last core parallel slowdown" on OS X

2009-04-22 Thread Dave Bayer
My first post was comparing almost identical machines: Different Q6600 steppings (the earlier chip makes a good space heater!) on different motherboards, same memory, both stock speeds. In a few weeks when the semester ends, I'll be able to try Linux -vs- BSD -vs- OS X on identical hardware