[Pharo-project] ConnectionQueue defect in 1.0
Hello all, Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas? Bill
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. I will try to get them packaged for release, but if nothing else, please take a careful look at ConnectionQueue, which appears to be broken in 1.x, and hopefully fixed by the attached. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Monday, May 24, 2010 6:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] ConnectionQueue defect in 1.0 Hello all, Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas? Billx
bill can you open a new bug entry. There are too much activities so that we could remember all the information passing around :) Stef On May 25, 2010, at 8:58 PM, 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. I will try to get them packaged for release, but if nothing else, please take a careful look at ConnectionQueue, which appears to be broken in 1.x, and hopefully fixed by the attached.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Monday, May 24, 2010 6:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] ConnectionQueue defect in 1.0
Hello all,
Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas?
Billx
<SocketWoes.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, #2476 is a first attempt at a report. At least it captures the defect and the change set, such as it is. I did not discover the tests' dependence on my stream changes until I tried it in 1.1 beta, and then I remembered that the changes are important to it; among them is #nextMany:, which is intended to not truncate and to raise an error on exhaustion. Perhaps someone can think of a way to rewrite the test so that it will work with the methods in the image?? My ideas on streams are documented on the wiki; there are two overlapping entries, one of which contains some interesting thoughts by Nicolas, and the other some more detail on my alternate selector idea. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Tuesday, May 25, 2010 4:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] ConnectionQueue defect in 1.0 bill can you open a new bug entry. There are too much activities so that we could remember all the information passing around :) Stef On May 25, 2010, at 8:58 PM, 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. I will try to get them packaged for release, but if nothing else, please take a careful look at ConnectionQueue, which appears to be broken in 1.x, and hopefully fixed by the attached.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Monday, May 24, 2010 6:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] ConnectionQueue defect in 1.0
Hello all,
Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas?
Billx
<SocketWoes.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: ?
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen@veloxit.no] Sent: Wednesday, May 26, 2010 5:35 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Henrik Johansen -
Schwab,Wilhelm K -
Stéphane Ducasse