David T. Lewis uploaded a new version of NetworkTests to project The Trunk:
http://source.squeak.org/trunk/NetworkTests-dtl.33.mcz ==================== Summary ==================== Name: NetworkTests-dtl.33 Author: dtl Time: 3 November 2012, 2:17:02.043 pm UUID: 3071c11f-8cef-43a2-b1b8-88c573ef9daf Ancestors: NetworkTests-ul.32 Fix SocketTest>>testSendTimeout to accommodate platform differences. Explanation: #sendDone means that the platform is reporting a send operation complete. The platform may or may not be able to accept addition write requests while sending is in process, depending on the buffering capability of the underlying platform. On Windows, the next write request fails immediately if a prior send is not complete, while unix platforms may be able to accept and buffer additional writes. Therefore change the test to expect a timeout exception to eventually occur, but not necessary on the next write operation. =============== Diff against NetworkTests-ul.32 =============== Item was changed: ----- Method: SocketTest>>testSendTimeout (in category 'tests') ----- testSendTimeout "Test data transfer and related methods" + | buffer ex | - | buffer | self testServerAccept. buffer := ByteArray new: 1000. + + "Write to the socket until the platform reports that sending is not complete." [serverSocket sendDone] whileTrue:[ serverSocket sendSomeData: buffer. ]. + + "The network layer is now either blocked or in the process of sending data in its buffers. + It may or may not be able buffer additional write requests, depending on the platform + implemention. Keep sending data until the network reports that it is unable to process + the request, at which time a exception will be raised. On Windows, the exception will + be raised on the next write request, while unix platforms may provide additional buffering + that permit write requests to continue being accepted." + ex := nil. + [[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] + on: ConnectionTimedOut + do: [ :e | ex := e ]. + ex isNil] whileTrue: []. + self assert: ex notNil. - self should:[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] - raise: ConnectionTimedOut. ! |
This should get us to either 4 or 5 remaining test failures on the squeakci.org
tests, depending on VM. I'll note for the record that SocketTest>>testSocketReuse fails on my computer at home (SuSE Linux), but passes on squeakci.org. I presume this is due to another platform difference, but it's not showing up on the radar for our Squeak 4.4 release preparation so I'm not going to worry about it right now. Dave On Sat, Nov 03, 2012 at 06:17:47PM +0000, [hidden email] wrote: > David T. Lewis uploaded a new version of NetworkTests to project The Trunk: > http://source.squeak.org/trunk/NetworkTests-dtl.33.mcz > > ==================== Summary ==================== > > Name: NetworkTests-dtl.33 > Author: dtl > Time: 3 November 2012, 2:17:02.043 pm > UUID: 3071c11f-8cef-43a2-b1b8-88c573ef9daf > Ancestors: NetworkTests-ul.32 > > Fix SocketTest>>testSendTimeout to accommodate platform differences. > > Explanation: #sendDone means that the platform is reporting a send operation complete. The platform may or may not be able to accept addition write requests while sending is in process, depending on the buffering capability of the underlying platform. On Windows, the next write request fails immediately if a prior send is not complete, while unix platforms may be able to accept and buffer additional writes. Therefore change the test to expect a timeout exception to eventually occur, but not necessary on the next write operation. > > =============== Diff against NetworkTests-ul.32 =============== > > Item was changed: > ----- Method: SocketTest>>testSendTimeout (in category 'tests') ----- > testSendTimeout > "Test data transfer and related methods" > > + | buffer ex | > - | buffer | > self testServerAccept. > buffer := ByteArray new: 1000. > + > + "Write to the socket until the platform reports that sending is not complete." > [serverSocket sendDone] whileTrue:[ > serverSocket sendSomeData: buffer. > ]. > + > + "The network layer is now either blocked or in the process of sending data in its buffers. > + It may or may not be able buffer additional write requests, depending on the platform > + implemention. Keep sending data until the network reports that it is unable to process > + the request, at which time a exception will be raised. On Windows, the exception will > + be raised on the next write request, while unix platforms may provide additional buffering > + that permit write requests to continue being accepted." > + ex := nil. > + [[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] > + on: ConnectionTimedOut > + do: [ :e | ex := e ]. > + ex isNil] whileTrue: []. > + self assert: ex notNil. > - self should:[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] > - raise: ConnectionTimedOut. > ! > |
On 3 November 2012 18:26, David T. Lewis <[hidden email]> wrote:
> This should get us to either 4 or 5 remaining test failures on the squeakci.org > tests, depending on VM. I'll note for the record that SocketTest>>testSocketReuse Yep, confirmed. Thanks! > fails on my computer at home (SuSE Linux), but passes on squeakci.org. I presume > this is due to another platform difference, but it's not showing up on the radar > for our Squeak 4.4 release preparation so I'm not going to worry about it right now. Agreed: we can figure out how to isolate ourselves from platforms (or expose the differences more clearly) in another release. I'd like to get 4.4 out the door! frank > Dave > > > On Sat, Nov 03, 2012 at 06:17:47PM +0000, [hidden email] wrote: >> David T. Lewis uploaded a new version of NetworkTests to project The Trunk: >> http://source.squeak.org/trunk/NetworkTests-dtl.33.mcz >> >> ==================== Summary ==================== >> >> Name: NetworkTests-dtl.33 >> Author: dtl >> Time: 3 November 2012, 2:17:02.043 pm >> UUID: 3071c11f-8cef-43a2-b1b8-88c573ef9daf >> Ancestors: NetworkTests-ul.32 >> >> Fix SocketTest>>testSendTimeout to accommodate platform differences. >> >> Explanation: #sendDone means that the platform is reporting a send operation complete. The platform may or may not be able to accept addition write requests while sending is in process, depending on the buffering capability of the underlying platform. On Windows, the next write request fails immediately if a prior send is not complete, while unix platforms may be able to accept and buffer additional writes. Therefore change the test to expect a timeout exception to eventually occur, but not necessary on the next write operation. >> >> =============== Diff against NetworkTests-ul.32 =============== >> >> Item was changed: >> ----- Method: SocketTest>>testSendTimeout (in category 'tests') ----- >> testSendTimeout >> "Test data transfer and related methods" >> >> + | buffer ex | >> - | buffer | >> self testServerAccept. >> buffer := ByteArray new: 1000. >> + >> + "Write to the socket until the platform reports that sending is not complete." >> [serverSocket sendDone] whileTrue:[ >> serverSocket sendSomeData: buffer. >> ]. >> + >> + "The network layer is now either blocked or in the process of sending data in its buffers. >> + It may or may not be able buffer additional write requests, depending on the platform >> + implemention. Keep sending data until the network reports that it is unable to process >> + the request, at which time a exception will be raised. On Windows, the exception will >> + be raised on the next write request, while unix platforms may provide additional buffering >> + that permit write requests to continue being accepted." >> + ex := nil. >> + [[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] >> + on: ConnectionTimedOut >> + do: [ :e | ex := e ]. >> + ex isNil] whileTrue: []. >> + self assert: ex notNil. >> - self should:[serverSocket sendSomeData: buffer startIndex: 1 count: buffer size for: 1] >> - raise: ConnectionTimedOut. >> ! >> > |
In reply to this post by David T. Lewis
Hi,
This should get us to either 4 or 5 remaining test failures on the squeakci.org tests, depending on VM. I'll note for the record that SocketTest>>testSocketReuse fails on my computer at home (SuSE Linux), but passes on squeakci.org. I presume this is due to another platform difference, but it's not showing up on the radar for our Squeak 4.4 release preparation so I'm not going to worry about it right now.as I managed to bring my Windows 7 Laptop but not the power supply I ran the tests under XP, current update. I updated to Trunk #12269, disabled the IPV6 preference and got: 3264 run, 3239 passes, 18 expected failures, 6 failures, 1 errors, 0 unexpected passes, http://i.minus.com/iMxj47re2dyfN.PNG The error console roughly translates to: getnameinfo: the requested name is valid and was found in the database. It does not have the correct associated data ehich should be evaluated. Cheers Herbert |
On Sat, Nov 03, 2012 at 10:11:23PM +0100, Herbert K?nig wrote:
> Hi, > > >This should get us to either 4 or 5 remaining test failures on the > >squeakci.org tests, depending on VM. I'll note for the record that > >SocketTest>>testSocketReuse fails on my computer at home (SuSE Linux), > >but passes on squeakci.org. I presume this is due to another platform > >difference, but it's not showing up on the radar for our Squeak 4.4 > >release preparation so I'm not going to worry about it right now. > as I managed to bring my Windows 7 Laptop but not the power supply I ran > the tests under XP, current update. > I updated to Trunk #12269, disabled the IPV6 preference and got: > > 3264 run, 3239 passes, 18 expected failures, 6 failures, 1 errors, 0 > unexpected passes, > http://i.minus.com/iMxj47re2dyfN.PNG > The error console roughly translates to: getnameinfo: the requested name > is valid and was found in the database. It does not have the correct > associated data ehich should be evaluated. The MCWorkingCopyTest>>testSimpleMerge failure is an interesting one. I think I managed to reproduce it in my image by running the tests a few times. It seems that MCMockClassA and MCMockClassB can be left in an unexpected state by a previous test run. Reloading the Tests-cwp.175.mcz package puts them back to "normal" and the test starts working again. This looks like some kind of problem in the test itself, and not something related to Windows. Dave |
In reply to this post by Herbert König
On Sat, Nov 3, 2012 at 10:11 PM, Herbert König <[hidden email]> wrote:
> Hi, > > This should get us to either 4 or 5 remaining test failures on the > squeakci.org tests, depending on VM. I'll note for the record that > SocketTest>>testSocketReuse fails on my computer at home (SuSE Linux), but > passes on squeakci.org. I presume this is due to another platform > difference, but it's not showing up on the radar for our Squeak 4.4 release > preparation so I'm not going to worry about it right now. > > as I managed to bring my Windows 7 Laptop but not the power supply I ran the > tests under XP, current update. > I updated to Trunk #12269, disabled the IPV6 preference and got: > > 3264 run, 3239 passes, 18 expected failures, 6 failures, 1 errors, 0 > unexpected passes, > http://i.minus.com/iMxj47re2dyfN.PNG > The error console roughly translates to: getnameinfo: the requested name is > valid and was found in the database. It does not have the correct associated > data ehich should be evaluated. > > Cheers > > Herbert > > > DosFileDirectory>>relativeNameIfAbsoluteFor: aFileName "Answer either the relative name for aFileName, if aFileName names a file in me or subdirectories, or aFileName's absolute path if it isn't in me or subdirectories. P.S. Ths is what I'd expect relativeNameFor: to do, but it is taken and means exactly the opposite, i.e. the absolute path for a relative name." | fullNameSize fullName fileNameSize | (aFileName isEmpty or: [aFileName first ~= self driveName first]) ifTrue: [self error: 'this method expects an absolute filename']. fullNameSize := (fullName := self fullName) size. fileNameSize := aFileName size. ^(aFileName beginsWith: fullName) ifTrue: [(fileNameSize = fullNameSize or: [fileNameSize - 1 = fullNameSize and: [(aFileName at: fileNameSize) = self pathNameDelimiter]]) ifTrue: [self class currentDirectoryNickname] ifFalse: [aFileName copyFrom: fullNameSize + 2 to: fileNameSize]] ifFalse: [aFileName] "SourceFiles asArray collect: [:sf| FileDirectory default relativeNameIfAbsoluteFor: sf fullName]" "FileDirectory default relativeNameIfAbsoluteFor: FileDirectory default fullName" "should be dot" "FileDirectory default relativeNameIfAbsoluteFor: FileDirectory default fullName, FileDirectory default slash" "should also be dot" Karl |
Free forum by Nabble | Edit this page |