Hi Cam, The problem is likely to be the one pointed out by John
Alexandre On 30 Apr 2009, at 05:58, Cameron Sanders wrote: > Alexandre, you did mention having #port: sent to a ByteArray. It looks > like the last line of > FTPClient>>openPassiveDataConnection should be: > self openDataSocket: remoteHostAddress asSocketAddress port: dataPort > > instead of (current code): > self openDataSocket: remoteHostAddress port: dataPort > > With that change, the system drills on down and has a primitive > failure in #port (on a Mac). > > I will add "Socket allInstances size inspect" just above the #port: > method in Socket>>connectTo:port:. > > ... and the answer is SmallInteger: 7. > Anything else I should inspect in here? > > -Cam > PS: I am coming at this from the Monticello/FTP side, because my code > is on an ftp server. > > > On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote: > >> Does not work for me. The problem is probably different. I still >> get a >> 'Socket status must Unconnected before opening a new connection' >> >> Alexandre >> >> >> On 29 Apr 2009, at 21:39, Nicolas Cellier wrote: >> >>> Could you test if this fix works: >>> >>> PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2 >>> >>> 2009/4/29 Nicolas Cellier <[email protected]>: >>>> OK guys, I think you loaded my rollover stuff... >>>> Mea maxima culpa: >>>> >>>> #waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING! >>>> >>>> the former signals ConnectionClosed, while the later silently >>>> answer false... >>>> >>>> The reason it works on windws is probably I did not load my change >>>> (I >>>> used a different image...). >>>> >>>> Strangely, I used Monticello on squeaksource without encountering >>>> this bug... >>>> >>>> Nicolas >>>> >>>> 2009/4/29 Nicolas Cellier <[email protected]>: >>>>> Also note that it fails at the end of the progress bar. >>>>> And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: >>>>> leads to: >>>>> >>>>> collection copyFrom: readLimit-100 to: readLimit -> >>>>> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 >>>>> 19:38 >>>>> 50K >>>>> <hr></pre> >>>>> </body></html> >>>>> ' >>>>> >>>>> I don't want to learn anything about http protocol, but it sounds >>>>> like >>>>> the whole stream was correctly retrieved. >>>>> That means something has changed in the order things are >>>>> processed. >>>>> We should test if it is a matter of VM or in image change. >>>>> >>>>> Nicolas >>>>> >>>>> 2009/4/29 Michael Rueger <[email protected]>: >>>>>> Nicolas Cellier wrote: >>>>>>> I confirm it works on windows and fails on linux (exupery VM) >>>>>> >>>>>> as it also fails on Mac it seems it could be the Unix socket >>>>>> code? >>>>>> >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
