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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Monday, May 24, 2010 6:33 PM
To: [hidden email]
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, May 25, 2010 4:04 PM
To: [hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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: ?
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Henrik Johansen [[hidden email]]
Sent: Wednesday, May 26, 2010 5:35 AM
To: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project