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
