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
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.
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
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
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).
>> 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:
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
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
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
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.
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 ("
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
> 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
_
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
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
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
16 matches
Mail list logo