Henry, Whatever fix we want is fine with me, provided we fix it :)
Re #next:, it will silently truncate and does not complain on stream exhaustion. Both are *BAD* when they happen by surprise; when they are good, IMHO one should use specific selectors that clarify that the code is authorized to think for us. See http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware http://code.google.com/p/pharo/wiki/ProposalForConsistentStreamsBehavior I prefer Dolphin's approach to the problems, but since I cannot unilaterally adopt it, I have chosen the alternate selectors for my own work. Code I write will require #nextOne, #nextMany:, and #nextAvailable:, etc. Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Henrik Johansen [[email protected]] Sent: Wednesday, May 26, 2010 5:35 AM To: [email protected] Subject: Re: [Pharo-project] ConnectionQueue defect in 1.0 Yes, it is broken. To me, removing the return of true, and changing the method comment to reflect the real return values seem like the "simplest" solution. There seems to have been some issues related to clock wraparound fixed around the time of the method time stamps, not sure if the ^true was just a way to align better with the comment, or a real fix for something though :/ Cheers, Henry On May 25, 2010, at 8:58 44PM, Schwab,Wilhelm K wrote: > Hello all, > > Please see attached - CAREFULLY :) It turns out that NetworkSmokeTest will > fail in your images, for want of #nextMany: and other additions I have made > to streams. > PS. What is wrong with next: ? _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
