I agree that the patch is ugly (sorry :-) ), but it does fix the problem on my machine.
Steve, Can this patch (or a similar fix) get merged in. Carl _____ From: Xinan Wu [mailto:wuxi...@gmail.com] To: Steve Steiner (listsin) [mailto:list...@integrateddevcorp.com] Cc: Carl Zmola [mailto:czm...@woti.com], fab-user [mailto:fab-u...@nongnu.org] Sent: Fri, 07 Aug 2009 12:21:51 -0400 Subject: Re: [Fab-user] status of "occasional droped lines of output" bug 32 this was my fix, but it's a bit ugly... please try and at least make sure functionality is fixed. === quoted ealier email === The reason is .splitlines() does not put an empty str at the end of array when the last char in out is \n, so the leftover logic is incorrect. (I am using python 2.5, don't know if 2.6 changes this, unlikely though) The code in old 0.1.1 was in fact pretty solid except it didn't handle \r case. The patch I included in my first email wasn't as solid. Here's a probably better fix but still a bit ugly :) diff -ur fabric-0.9b1-original/fabric/network.py fabric-0.9b1/fabric/network.py --- fabric-0.9b1-original/fabric/network.py 2009-07-02 21:36:15.000000000 -0700 +++ fabric-0.9b1/fabric/network.py 2009-07-12 23:56:45.000000000 -0700 @@ -319,9 +319,10 @@ # leftovers, if any. if '\n' in out or '\r' in out: parts = out.splitlines() + if out[len(out)-1] in '\r\n': + parts.append('') line = leftovers + parts.pop(0) - if parts: - leftovers = parts.pop() + leftovers = parts.pop() while parts or line: # Write stderr to our own stderr. out_stream = stderr and sys.stderr or sys.stdout On Fri, Aug 7, 2009 at 7:25 AM, Steve Steiner (listsin)<list...@integrateddevcorp.com> wrote: > > On Aug 6, 2009, at 10:36 PM, Carl Zmola wrote: > > I have reproduced this at home and at work. > > Apparently, someone has a 100% reproducible case on his local machine. > My Spidey sense is tickled in three areas. > 1> Non-flushing on the remote side > 2> Manglement on the receiving side > 3> Thread shenanigans with filling up the output list > I think 2 is most likely (and easiest to test/diagnose anyway). > The return string is handled by passing an empty list to the thread to be > filled up. > Then a simple "".join() is being applied to that result. > I'm guessing that there's an encoding/string/buffer type mismatch and things > are not joining properly rather than the output buffer on the other side not > being flushed. > If whoever has a reproducible local case could put some debugging output in > operations.py around line 435 to dump out the contents of 'capture' before > it's "".joined, I'm gonna' bet that the reason for the missing data will > become apparent pretty quickly. > Thanks, > S > > _______________________________________________ > Fab-user mailing list > Fab-user@nongnu.org > http://lists.nongnu.org/mailman/listinfo/fab-user > >
_______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
