[darcs-devel] [issue1026] pull => bug in get_extra commuting patch (2.x)

[Thorkil Naur]

Thorkil Naur <naur at post11.tele.dk> added the comment:

What Simon PJ seems to be doing here (or rather: What the darcs-all script is 
doing on his behalf) is to do a darcs pull from the GHC HEAD repository into the 
libraries/array repository. I tried that on an Intel Mac OS X 10.5 and got this 
reaction:

> thorkil-naurs-intel-mac-mini:repo thorkilnaur$ darcs --exact-version
> darcs compiled on Aug  7 2008, at 21:50:40
> # configured Mon Jun 23 18:19:52 PDT 2008
> ./configure /usr/local/share/config.site /usr/local/etc/config.site
> 
> Context:
> 
> [TAG 2.0.2
> David Roundy <droundy at darcs.net>**20080624012041] 
> 
> thorkil-naurs-intel-mac-mini:repo thorkilnaur$ cp -R 
/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-
copying-20070713_1212/ghc/libraries/array array
> thorkil-naurs-intel-mac-mini:repo thorkilnaur$ cd array/
> thorkil-naurs-intel-mac-mini:array thorkilnaur$ darcs pull 
/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-
copying-20070713_1212/ghc --repodir .
> This is the GHC darcs repository (HEAD branch)
> 
> For more information, visit the GHC developer wiki at
>   http://hackage.haskell.org/trac/ghc
> **********************
> darcs: bug in get_extra commuting patch:
> Fri Apr 22 19:00:49 CEST 2005  sof
>   * [project @ 2005-04-22 17:00:49 by sof]
>   [mingw only]
>   Better handling of I/O request abortions upon throwing an exception
>   to a Haskell thread. As was, a thread blocked on an I/O request was
>   simply unblocked, but its corresponding worker thread wasn't notified
>   that the request had been abandoned.
>   
>   This manifested itself in GHCi upon Ctrl-C being hit at the prompt -- the
>   worker thread blocked waiting for input on stdin prior to Ctrl-C would
>   stick around even though its corresponding Haskell thread had been
>   thrown an Interrupted exception. The upshot was that the worker would
>   consume the next character typed in after Ctrl-C, but then just dropping
>   it. Dealing with this turned out to be even more interesting due to
>   Win32 aborting any console reads when Ctrl-C/Break events are delivered.
>   
>   The story could be improved upon (at the cost of portability) by making
>   the Scheduler able to abort worker thread system calls; as is, requests
>   are cooperatively abandoned. Maybe later.
>   
>   Also included are other minor tidyups to Ctrl-C handling under mingw.
>   
>   Merge to STABLE.
> thorkil-naurs-intel-mac-mini:array thorkilnaur$ 

A similar thing happened on a PPC Mac OS X with:

> Thorkil-Naurs-Computer:~/tn/test/darcs/Issue/1026/work/repo/array thorkilnaur$ 
darcs --exact-version
> darcs compiled on May  8 2007, at 09:50:57
> # configured Fri Jun 16 14:55:21 EDT 2006
> ./configure --no-create --no-recursion
> 
> Context:
> 
> [TAG 1.0.8
> Tommy Pettersson <ptp at lysator.liu.se>**20060616160213] 

Finally, I tried the latest (I presume) darcs on (another) PPC Mac OS X that 
hosts a darcs buildbot slave:

> thorkil-naurs-mac-mini:array thorkilnaur$ 
'/Users/thorkilnaur/tn/buildbot/darcs/thorkil_mac/thorkil tn20/build/darcs' --
version
> 2.0.2 (+ 119 patches)

Same reaction. So I would conclude: This reaction has been present for a while 
and it is not gone.

----------
nosy: +thorkilnaur

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue1026>
__________________________________