On May 3, 2009, at 1:46 AM, John M McIntosh wrote:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be
fixed or as Igor suggested refactored to oblivion.
(b) The deeper issue is that we affected how finalization works so
that this
2009/5/3 John M McIntosh john...@smalltalkconsulting.com:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be
fixed or as Igor suggested refactored to oblivion.
(b) The deeper issue is that we affected how finalization works so
that
Yes but why don't we close them with an ensure or something like that.
I mean is the logic of the connection making it that we cannot use
ensure or this is just a legacy?
On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote:
Well somewhere someone needs to close the socket before it is
Apparnetly after 10296 I can load moose without problem.
So the fixes of nicolas closing remoteString solved the problem.
Now this is only partially solved since I would really like to
understand
why it broke in the first place since we did not touch this code.
Stef
Oh, remoteString!!! I LOVE IT :)))
Stephane, remember this mail ?
I didn't sent it to list. Sending now, just as a reminder.
9 December 2008 05:20
subject One big mess :)
Here is an IRC log me chatting with Keith.
I just hope that Pharo guys will address this issue somewhere in
2009/5/3 John M McIntosh john...@smalltalkconsulting.com:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be
fixed or as Igor suggested refactored to oblivion.
IMO this should be done sooner or later. Its a pain to see it.
Oh well,
The Unix ipv6 logic translates the lookup error number into a string
and prints to the console.
If the name is an empty string, then yes it's EAI_NONAME
see
man 3 gai_strerror
GAI_STRERROR(3) BSD Library Functions Manual
GAI_STRERROR(3)
NAME
gai_strerror -- get
Thanks Johan for such a deep insight.
You're probably very close to the truth. I modified the priority of
the finalization process to 61. The socket problem just vanished.
It is hard to see whether this is a hack or this process should be at
a higher priority by design. I googled a bit about
Alexandre Bergel wrote:
Thanks Johan for such a deep insight.
You're probably very close to the truth. I modified the priority of
the finalization process to 61. The socket problem just vanished.
Great news!
And a big thanks to John for the in depth analysis!
So, should we just change the
I would like to know why does the system rely on finalisation to
release socket
Apparently david mentioned that this is the source of huge problems.
So what would be the alternative?
Stef
On Apr 30, 2009, at 12:00 PM, Michael Rueger wrote:
Alexandre Bergel wrote:
Thanks Johan for such a
Maybe it is still a bit early in the morning, but I am not sure to
understand what you mean with MC/FTP feature. What am I not testing?
Alexandre
On 29 Apr 2009, at 03:39, Cameron Sanders wrote:
So you want to use the MC/FTP feature. You are not testing it to make
certain that the MC/FTP
Alexandre,
I assume you are also following the threads on squeak-dev regarding
[squeak-dev] Re: Socket clock rollover issues -- is the problem you
are investigating related to that issue (e.g. failure due to a time-
out)?
Are you connecting to a public repository? If so, give me the info
Very good -- i have not followed it closely. Thank you.
-Cam
On Apr 29, 2009, at 11:38 AM, Nicolas Cellier wrote:
This is very unlikelya rollover: rollover happens once every 12 days
or so.
Nicolas
2009/4/29 Cameron Sanders camsander...@roadrunner.com:
Alexandre,
I assume you are also
Open a Pharo image, and execute ScriptLoader loadOBAlpha
If you have a Mac, this will surely fail.
Alexandre
On 29 Apr 2009, at 17:32, Cameron Sanders wrote:
Alexandre,
I assume you are also following the threads on squeak-dev regarding
[squeak-dev] Re: Socket clock rollover issues -- is
I confirm it works on windows and fails on linux (exupery VM)
Nicolas
2009/4/29 Alexandre Bergel alexan...@bergel.eu:
Open a Pharo image, and execute ScriptLoader loadOBAlpha
If you have a Mac, this will surely fail.
Alexandre
On 29 Apr 2009, at 17:32, Cameron Sanders wrote:
Alexandre,
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
Don't worry, I get it from the logical view. I just wondered if it
was related to 'Socket status must Unconnected before opening a new
connection'.
-cam
On Apr 29, 2009, at 10:27 PM, Cameron Sanders wrote:
Maybe I'm just sleep deprived... but, the method isUnconnected looks
odd. Perhaps
Er maybe someone doing the testing can stick a
Socket allInstances size inspect
in at the pointer where the exception is signaled. I think it would be
enlightening what the value is.
On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote:
Socket status must Unconnected before opening a new
Further to this Im wondering if there is something else clever
going on.
Should the finalization process run at priority 61? See
WeakArrayrestartFinalizationProcess
Perhaps someone can check that?
Let me ramble on...
In the past you had the event polling going on at prioirty 40 in the
Alexandre, you did mention having #port: sent to a ByteArray. It looks
like the last line of
FTPClientopenPassiveDataConnection should be:
self openDataSocket: remoteHostAddress asSocketAddress port: dataPort
instead of (current code):
self openDataSocket: remoteHostAddress
Where do I reduce that priority?
-cam
On Apr 29, 2009, at 11:40 PM, John M McIntosh wrote:
But let's consider what's NEW here is the 'input events fetching
process' is now running at 2x the speed of the older UI process and
consuming 10-30% of the cpu?
I'm not sure why before it was
On Wed, Apr 29, 2009 at 08:40:37PM -0700, John M McIntosh wrote:
In this problem area, if we consider the socket creation fails because
the number of sockets allocated has reached the limit (aka unix limit)
not seen in windows.
then this is because either (a) we are actualy holding onto
The Socket allInstances size inspect
should go in the exception handler block before it throws the
execption you don't want to see.
On 29-Apr-09, at 8:58 PM, Cameron Sanders wrote:
Alexandre, you did mention having #port: sent to a ByteArray. It looks
like the last line of
This is the first time it has failed for me. I have been using MCs FTP
in a variety of different images VMs over the last four months.
Suddenly...
MessageNotUnderstood: ByteArrayport:
in SocketconnectTo:port:.
Previously, hostAddress (in the aforementioned method) had been a
I have a different error.
Regarding updates, you can have a look at the package-cache, but
printIt 'ScriptLoader new logStream' should do what you want
Cheers,
Alexandre
On 28 Apr 2009, at 16:16, Cameron Sanders wrote:
This is the first time it has failed for me. I have been using MCs FTP
Alexandre,
Is your interest in getting the unit-test to pass, or o be able to use
it?
-Cam
On Apr 28, 2009, at 1:35 PM, Alexandre Bergel wrote:
Hum... ScriptLoader loadOBAlpha still does not pass...
Alexandre
___
Pharo-project mailing list
I am not sure to understand. I would like to be able to load OBAlpha
in Pharo and to not have this the socket problem.
Cheers,
Alexandre
On 28 Apr 2009, at 21:30, Cameron Sanders wrote:
Alexandre,
Is your interest in getting the unit-test to pass, or o be able to use
it?
-Cam
On Apr
So you want to use the MC/FTP feature. You are not testing it to make
certain that the MC/FTP works.
What is is your server string?
-Cam
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
28 matches
Mail list logo
