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
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
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
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 large
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 (WRITE
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. It's the
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 that
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 openFile.
2009/4/22 Neil Mitchell ndmitch...@gmail.com:
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
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).
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
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
On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh ig...@earth.li 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
On Apr 22, 2009, at 22:00 , Alexander Dunlap wrote:
On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh ig...@earth.li 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
14 matches
Mail list logo
