Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ? 2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>

El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

...

Hi all,

yesterday, in some of that "why did I do that today" I decided to add a partition to my ext3 fs over LUKS encrypted over LVM over disk partitions Debian install. Well, things went far from ok, and the result I lost all the information (it is really encrypted, :(). I had a backup so nothing important was lost. Or that I thought. Because after reinstalling and trying to install the squeakvm I noticed that the squeak vm .deb file from:

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb

is not more available. I'm sure there are good reasons to remove that file. But for me that was the squeak vm that I was using (and the one you reach if you follow the links from pharo-download page and the one you'll try to download if you use a Debian derived distro...).

The case is that isn't available. So I got the tar.gz for i386 (there isn't amd64 package, but I have ia32-libs installed):

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.gz

and by using this vm I have a problem that I hadn't before:

In a PharoCore 10508 image evaluate this:

NetNameResolver addressForName: 'www.yahoo.com'

I get:

Error: primitive has failed

in NetNameResolver class>>primGetNameInfo:flags

Also

NetNameResolver primGetNameInfoHostSize

gives the same error but in:

in NetNameResolver class>>primGetNameInfoHostSize.

First I though that was the change of vm but then, using the same vm I opened an old image:

Pharo1.0beta Latest update: #10454

and there all works correctly.

Can someone confirm this bug so that I can add an issue in the traker.

Or maybe point to something that I am doing wrong.

I repeat, the data:

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10508 result: failed

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10454 result: worked

Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Between 10454 and 10508 I switched to useOldNetwork => true. Probably that makes the difference. Fixes are welcome! Cheers, Adrian On Jan 27, 2010, at 15:10 , Schwab,Wilhelm K wrote:

Probably. We need to ensure that all of the IPv6 primitives are protected with #useOldNetwork, and they are not at present. I started to split NetNameResolver into absract base and 4/6-specific subclasses, but was distracted from it. Something like that would help a lot.

Bill

________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, January 27, 2010 9:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ?

2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com<mailto:miguel.coba@gmail.com>> El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

...

Hi all,

yesterday, in some of that "why did I do that today" I decided to add a partition to my ext3 fs over LUKS encrypted over LVM over disk partitions Debian install. Well, things went far from ok, and the result I lost all the information (it is really encrypted, :(). I had a backup so nothing important was lost. Or that I thought. Because after reinstalling and trying to install the squeakvm I noticed that the squeak vm .deb file from:

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb

is not more available. I'm sure there are good reasons to remove that file. But for me that was the squeak vm that I was using (and the one you reach if you follow the links from pharo-download page and the one you'll try to download if you use a Debian derived distro...).

The case is that isn't available. So I got the tar.gz for i386 (there isn't amd64 package, but I have ia32-libs installed):

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.gz

and by using this vm I have a problem that I hadn't before:

In a PharoCore 10508 image evaluate this:

NetNameResolver addressForName: 'www.yahoo.com<http://www.yahoo.com>'

I get:

Error: primitive has failed

in NetNameResolver class>>primGetNameInfo:flags

Also

NetNameResolver primGetNameInfoHostSize

gives the same error but in:

in NetNameResolver class>>primGetNameInfoHostSize.

First I though that was the change of vm but then, using the same vm I opened an old image:

Pharo1.0beta Latest update: #10454

and there all works correctly.

Can someone confirm this bug so that I can add an issue in the traker.

Or maybe point to something that I am doing wrong.

I repeat, the data:

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10508 result: failed

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10454 result: worked

Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Do you see a simple solution to work around the problem in 1.0? Adrian On Jan 27, 2010, at 16:05 , Schwab,Wilhelm K wrote:

That change reduces the problems, but it does not eliminate it because there are sill paths to IPv6-specific code that is "unprotected." The primitive(s) in question fail if IPv6 is not available, in fact, the need to use IPv4 is detected by watching a primitive fail. We then turn around later and call that same primitive w/o checking #useOldNetwork, hence the defect on non-IPv6 machines.

The code is very complicated and should be factored into separate classes to group the primitive with the protocols they serve.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Wednesday, January 27, 2010 9:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Between 10454 and 10508 I switched to useOldNetwork => true. Probably that makes the difference. Fixes are welcome!

Cheers, Adrian

On Jan 27, 2010, at 15:10 , Schwab,Wilhelm K wrote:

...

Probably. We need to ensure that all of the IPv6 primitives are protected with #useOldNetwork, and they are not at present. I started to split NetNameResolver into absract base and 4/6-specific subclasses, but was distracted from it. Something like that would help a lot.

Bill

________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, January 27, 2010 9:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ?

2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com<mailto:miguel.coba@gmail.com>> El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

...

Hi all,

yesterday, in some of that "why did I do that today" I decided to add a partition to my ext3 fs over LUKS encrypted over LVM over disk partitions Debian install. Well, things went far from ok, and the result I lost all the information (it is really encrypted, :(). I had a backup so nothing important was lost. Or that I thought. Because after reinstalling and trying to install the squeakvm I noticed that the squeak vm .deb file from:

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb

is not more available. I'm sure there are good reasons to remove that file. But for me that was the squeak vm that I was using (and the one you reach if you follow the links from pharo-download page and the one you'll try to download if you use a Debian derived distro...).

The case is that isn't available. So I got the tar.gz for i386 (there isn't amd64 package, but I have ia32-libs installed):

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.gz

and by using this vm I have a problem that I hadn't before:

In a PharoCore 10508 image evaluate this:

NetNameResolver addressForName: 'www.yahoo.com<http://www.yahoo.com>'

I get:

Error: primitive has failed

in NetNameResolver class>>primGetNameInfo:flags

Also

NetNameResolver primGetNameInfoHostSize

gives the same error but in:

in NetNameResolver class>>primGetNameInfoHostSize.

First I though that was the change of vm but then, using the same vm I opened an old image:

Pharo1.0beta Latest update: #10454

and there all works correctly.

Can someone confirm this bug so that I can add an issue in the traker.

Or maybe point to something that I am doing wrong.

I repeat, the data:

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10508 result: failed

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10454 result: worked

Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge. inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We more or less agree. Now this is a question of what do we do now to fix this problem You see I sent the proposal for having an engineer yesterday and I hope I will get one and netwrok will be on the list Stef On Jan 27, 2010, at 4:59 PM, Schwab,Wilhelm K wrote:

Adrian,

I don't know that it is simple, because it ends up touching the socket methods, and the (IMHO very poorly designed) addresses.

In the "somebody has to say it column," one of the things that I was taught separates good OO design from the work of beginners is the appropriate use (and at times avoidance) of inheritance. I found this to be *very* true in my growth as a programmer. When I look back at seriously old code of mine, it is easy to find uses of inheritance that pretty clearly arose because I did not know how to compose/delegate/forward, because it was too much trouble in C++, or because C++ prevented my adding needed methods to base classes.

For whatever reason, Squeak is littered with questionable uses of inheritance. Things that should use streams or use byte arrays are instead inherited from them. Whatever the reason for these problems, I think they should be fixed when we have time, and certainly when they get in our way. SocketAddress is in the way. It does too much (the port should be separate) and does not readily aid with lazy discovery of host name vs. address; one should be able specify a name and have the number resolved lazily, or specify the address directly. For convenience, the lookup should be attempted (on demand) if the name is not known but the address is. The fact that it is all derived from/encoded in a byte array makes it just that much harder to fix it.

One of my longer-term objectives is to provide access to OpenSSL sockets, and it might be that I will create a new sockets interface based on OS threads to cover both it and stream sockets at the same time. Since there are other ways to encrypt, it is not my highest priority at present; I also hope someone will beat me to it, as there are no doubt better ways to solve the problems that I have in mind.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Wednesday, January 27, 2010 10:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Do you see a simple solution to work around the problem in 1.0? Adrian

On Jan 27, 2010, at 16:05 , Schwab,Wilhelm K wrote:

...

That change reduces the problems, but it does not eliminate it because there are sill paths to IPv6-specific code that is "unprotected." The primitive(s) in question fail if IPv6 is not available, in fact, the need to use IPv4 is detected by watching a primitive fail. We then turn around later and call that same primitive w/o checking #useOldNetwork, hence the defect on non-IPv6 machines.

The code is very complicated and should be factored into separate classes to group the primitive with the protocols they serve.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Wednesday, January 27, 2010 9:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Between 10454 and 10508 I switched to useOldNetwork => true. Probably that makes the difference. Fixes are welcome!

Cheers, Adrian

On Jan 27, 2010, at 15:10 , Schwab,Wilhelm K wrote:

...

Probably. We need to ensure that all of the IPv6 primitives are protected with #useOldNetwork, and they are not at present. I started to split NetNameResolver into absract base and 4/6-specific subclasses, but was distracted from it. Something like that would help a lot.

Bill

________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, January 27, 2010 9:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ?

2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com<mailto:miguel.coba@gmail.com>> El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

...

Hi all,

yesterday, in some of that "why did I do that today" I decided to add a partition to my ext3 fs over LUKS encrypted over LVM over disk partitions Debian install. Well, things went far from ok, and the result I lost all the information (it is really encrypted, :(). I had a backup so nothing important was lost. Or that I thought. Because after reinstalling and trying to install the squeakvm I noticed that the squeak vm .deb file from:

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb

is not more available. I'm sure there are good reasons to remove that file. But for me that was the squeak vm that I was using (and the one you reach if you follow the links from pharo-download page and the one you'll try to download if you use a Debian derived distro...).

The case is that isn't available. So I got the tar.gz for i386 (there isn't amd64 package, but I have ia32-libs installed):

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.g z

and by using this vm I have a problem that I hadn't before:

In a PharoCore 10508 image evaluate this:

NetNameResolver addressForName: 'www.yahoo.com<http://www.yahoo.com>'

I get:

Error: primitive has failed

in NetNameResolver class>>primGetNameInfo:flags

Also

NetNameResolver primGetNameInfoHostSize

gives the same error but in:

in NetNameResolver class>>primGetNameInfoHostSize.

First I though that was the change of vm but then, using the same vm I opened an old image:

Pharo1.0beta Latest update: #10454

and there all works correctly.

Can someone confirm this bug so that I can add an issue in the traker.

Or maybe point to something that I am doing wrong.

I repeat, the data:

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10508 result: failed

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10454 result: worked

Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge. inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El mié, 27-01-2010 a las 15:31 +0100, Adrian Lienhard escribió:

Between 10454 and 10508 I switched to useOldNetwork => true. Probably that makes the difference. Fixes are welcome!

Yes I saw that UseOldNetwork is true now. I tried to change it to false save it, ran: NetNameResolver initializeNetwork but the NetNameResolver useOldNetwork keeps giving true and not false. What can I do to change the useOldNetwork value?

Cheers, Adrian

On Jan 27, 2010, at 15:10 , Schwab,Wilhelm K wrote:

...

Probably. We need to ensure that all of the IPv6 primitives are protected with #useOldNetwork, and they are not at present. I started to split NetNameResolver into absract base and 4/6-specific subclasses, but was distracted from it. Something like that would help a lot.

Bill

________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, January 27, 2010 9:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ?

2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com<mailto:miguel.coba@gmail.com>> El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

...

Hi all,

yesterday, in some of that "why did I do that today" I decided to add a partition to my ext3 fs over LUKS encrypted over LVM over disk partitions Debian install. Well, things went far from ok, and the result I lost all the information (it is really encrypted, :(). I had a backup so nothing important was lost. Or that I thought. Because after reinstalling and trying to install the squeakvm I noticed that the squeak vm .deb file from:

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb

is not more available. I'm sure there are good reasons to remove that file. But for me that was the squeak vm that I was using (and the one you reach if you follow the links from pharo-download page and the one you'll try to download if you use a Debian derived distro...).

The case is that isn't available. So I got the tar.gz for i386 (there isn't amd64 package, but I have ia32-libs installed):

http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.gz

and by using this vm I have a problem that I hadn't before:

In a PharoCore 10508 image evaluate this:

NetNameResolver addressForName: 'www.yahoo.com<http://www.yahoo.com>'

I get:

Error: primitive has failed

in NetNameResolver class>>primGetNameInfo:flags

Also

NetNameResolver primGetNameInfoHostSize

gives the same error but in:

in NetNameResolver class>>primGetNameInfoHostSize.

First I though that was the change of vm but then, using the same vm I opened an old image:

Pharo1.0beta Latest update: #10454

and there all works correctly.

Can someone confirm this bug so that I can add an issue in the traker.

Or maybe point to something that I am doing wrong.

I repeat, the data:

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10508 result: failed

vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 image: PharoCore 10454 result: worked

Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Miguel Cobá http://miguel.leugim.com.mx

The best I can figure out: you have the error because IPv6 primitives are called despite #useOldNetwork being rigged to answer true. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez Sent: Wednesday, January 27, 2010 9:30 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? El mié, 27-01-2010 a las 14:59 +0100, Mariano Martinez Peck escribió:

Yes, I can reproduce it in my Mac Os box...however, wasn't it the same problem of the network that we already have ? NetNameResolver useOldNetwork etc .. ?

I have useOldNetwork true in NetNameResolver but I have the same error. :( Thanks anyway

2010/1/27 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> El mar, 26-01-2010 a las 17:14 -0600, Miguel Enrique Cobá Martinez escribió:

> Hi all, > > yesterday, in some of that "why did I do that today" I decided to add a > partition to my ext3 fs over LUKS encrypted over LVM over disk > partitions Debian install. Well, things went far from ok, and the result > I lost all the information (it is really encrypted, :(). I had a backup > so nothing important was lost. Or that I thought. Because after > reinstalling and trying to install the squeakvm I noticed that the > squeak vm .deb file from: > > http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb > > is not more available. I'm sure there are good reasons to remove that > file. But for me that was the squeak vm that I was using (and the one > you reach if you follow the links from pharo-download page and the one > you'll try to download if you use a Debian derived distro...). > > The case is that isn't available. So I got the tar.gz for i386 (there > isn't amd64 package, but I have ia32-libs installed): > > http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.tar.gz > > and by using this vm I have a problem that I hadn't before: > > In a PharoCore 10508 image evaluate this: > > NetNameResolver addressForName: 'www.yahoo.com' > > I get: > > Error: primitive has failed > > in NetNameResolver class>>primGetNameInfo:flags > > Also > > NetNameResolver primGetNameInfoHostSize > > gives the same error but in: > > in NetNameResolver class>>primGetNameInfoHostSize. > > First I though that was the change of vm but then, using the same vm I > opened an old image: > > Pharo1.0beta > Latest update: #10454 > > and there all works correctly. > > Can someone confirm this bug so that I can add an issue in the traker. > > Or maybe point to something that I am doing wrong. > > I repeat, the data: > > vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 > image: PharoCore 10508 > result: failed > > vm: 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 > image: PharoCore 10454 > result: worked > > Thanks

Anybody can confirm? or is only me?

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr

http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El mié, 27-01-2010 a las 16:01 -0600, Miguel Enrique Cobá Martinez escribió:

El mié, 27-01-2010 a las 21:07 +0100, Mariano Martinez Peck escribió:

...

Add it. So that not to forget. If it is not a bug, we just close it and that's all.

http://code.google.com/p/pharo/issues/detail?id=1884

I think that get to the source of the problem. Is the change of UseOldNetwork from false to true in the last images. I added a comment (http://code.google.com/p/pharo/issues/detail?id=1884#c4) to the issue with a procedure to reproduce the problem in old images (that worked ok) and to correct the problem in the last image (that doesn't work). Can you please test it and decide if it is right to revert to the old version of NetNameRelease class>>initializeNetwork? Any comment welcome Thanks -- Miguel Cobá http://miguel.leugim.com.mx

El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió:

I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize.

Bill

Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel Cobá http://miguel.leugim.com.mx

+1

...

Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers.

The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper.

Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required.

As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes.

So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this.

Regards

Miguel Coba

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives. Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well? Cheers, Adrian On Jan 28, 2010, at 22:52 , John M McIntosh wrote:

Some of this is all related to

http://bugs.squeak.org/view.php?id=7392

However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next?

On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote:

...

+1

-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I for one never said we should throw out the new network code. But, we've been living in collective denial trying to reduce it to one defect when it is actually more complicated than that. Having cited the over-use of inheritance of the Squeak image as a source of various problems, I will add that inheritance *should* be used in NetNameResolver - specifically, we should group the ipv4 and ipv6 primitive sends into protocol-specific subclasses. Errors that are now weird-looking primitive failures will suddenly become DNU errors with an obvious cause. We should further send SocketAddress to its reward and make any required changes to use an aspect-based address that can lazily help with name resolution, and does not drag the port number into the address. The socket primitives will have to change at the same time (I think). IMHO, the only quick fix is to go back to known working network code, at which point we can plan for IPv6 in a future milestone. I urge the next attempt be based on an improved design, hopefully one that will allow OpenSSL sockets along with the usual suspects. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Friday, January 29, 2010 7:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? On 1/29/2010 1:08 PM, Adrian Lienhard wrote:

Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives.

Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well?

Apologies for coming in a bit late into the discussion. The new network plugin/code was orignally done by Ian and mangled by myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys as OLPC is IPv6 only. So would be worthwhile checking the etoys network code. Idea behind getting the code into Pharo was to enable more than the really outdated and bare bones network access available through the old network code. That the new stuff still doesn't work is a shame, but IMHO we should fix it rather than throwing it out. Patching the current code to allow use of the old network stuff would buy us time to fix the new code. Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mike do you have some cycles to help here? Stef On Jan 29, 2010, at 1:23 PM, Michael Rueger wrote:

On 1/29/2010 1:08 PM, Adrian Lienhard wrote:

...

Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives.

Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well?

Apologies for coming in a bit late into the discussion.

The new network plugin/code was orignally done by Ian and mangled by myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys as OLPC is IPv6 only. So would be worthwhile checking the etoys network code.

Idea behind getting the code into Pharo was to enable more than the really outdated and bare bones network access available through the old network code. That the new stuff still doesn't work is a shame, but IMHO we should fix it rather than throwing it out.

Patching the current code to allow use of the old network stuff would buy us time to fix the new code.

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

thanks I need to hack something simple to destress from proposal writing. But I have no clue about network Stef On Jan 29, 2010, at 6:48 PM, Michael Rueger wrote:

On 1/29/2010 6:28 PM, Stéphane Ducasse wrote:

...

Mike

do you have some cycles to help here?

let me see what I can come up with :-)

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

From Socket class >> initializeNetwork:

"Initialize the network drivers and the NetNameResolver. Do nothing if the network is already initialized." "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. " NetNameResolver initializeNetwork This explains why the initializeNetwork must be called *before* every network transaction. Between image restarts the network isn't guaranteed to remain. I propose to create a new preference (I know that they are banned but we need a workaround for 1.0 release) and then each user can, without modify the NetNameResolver class >>initializeNetwork, change the setting to the value that works for him/her. First evaluate: Preferences addPreference: #useOldNetwork categories: #(general network) default: false balloonHelp: 'Enable/disable the use of the old network code in making network connections. You need to save and restart the image to this preference to take effect' projectLocal: false changeInformee: nil changeSelector: nil. to create the preference in a PharoCore 10508 image. Then load Network-Kernel-MiguelCoba.22 from PharoInbox. Pay attention that when you change the preference, it is not refected immediately. You need to: 1. Open the image with the wrong value of the Preference 2. Change the preference Preferences enable: #useOldNetwork or Preferences disable: #useOldNetwork 3. Save the image 4. Restart the saved image 5. Evaluate: NetNameResolver initializeNetwork or some way use the network (open a monticello browser for example, so that initializeNetwork is called) 6. Test that the preference is being used: NetNameResolver useOldNetwork -> value of preference 7. Test that resolves correctly an address: NetNameResolver addressForName: 'www.yahoo.com' -> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0) 8. Save the new image, now with the new preference. I added this workaround as a fix to issue 1884 and changed status to fixed. Can you give it a try please and if so, generate a new image for PharoCore? Cheers -- Miguel Cobá http://miguel.leugim.com.mx

Thanks Miguel. I tried but here in the residence I have a proxy to with user and password. To use Monticello or whatever, I always need to evaluate this: HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090 proxyUser: 'XXX' password: 'YYY' or HTTPSocket proxyUser: 'XXX' password: 'YYY'. The problem is that with NetNameResolver I cannot get trough the proxy. Do someone know how can I set the username and password so that to use NetNameResolver? Sorry, I tried to test it ;) Mariano On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

Really thanks for all your energy on that. I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:

...

...

From Socket class >> initializeNetwork:

"Initialize the network drivers and the NetNameResolver. Do nothing

if

...

the network is already initialized." "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. "

NetNameResolver initializeNetwork

This explains why the initializeNetwork must be called *before* every network transaction. Between image restarts the network isn't guaranteed to remain.

I propose to create a new preference (I know that they are banned but we need a workaround for 1.0 release) and then each user can, without modify the NetNameResolver class >>initializeNetwork, change the setting to the value that works for him/her.

First evaluate:

Preferences addPreference: #useOldNetwork categories: #(general network) default: false balloonHelp: 'Enable/disable the use of the old network code in making network connections. You need to save and restart the image to this preference to take effect' projectLocal: false changeInformee: nil changeSelector: nil.

to create the preference in a PharoCore 10508 image.

Then load

Network-Kernel-MiguelCoba.22

from PharoInbox.

Pay attention that when you change the preference, it is not refected immediately. You need to:

1. Open the image with the wrong value of the Preference 2. Change the preference Preferences enable: #useOldNetwork

or

Preferences disable: #useOldNetwork 3. Save the image 4. Restart the saved image 5. Evaluate: NetNameResolver initializeNetwork

or some way use the network (open a monticello browser for example, so that initializeNetwork is called)

6. Test that the preference is being used:

NetNameResolver useOldNetwork -> value of preference

7. Test that resolves correctly an address:

NetNameResolver addressForName: 'www.yahoo.com' -> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)

8. Save the new image, now with the new preference.

I added this workaround as a fix to issue 1884 and changed status to fixed.

Can you give it a try please and if so, generate a new image for PharoCore?

Cheers -- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Thu, 28 Jan 2010, Mariano Martinez Peck wrote:

Thanks Miguel. I tried but here in the residence I have a proxy to with user and password. To use Monticello or whatever, I always need to evaluate this:

HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090 proxyUser: 'XXX' password: 'YYY'

or

HTTPSocket proxyUser: 'XXX' password: 'YYY'.

The problem is that with NetNameResolver I cannot get trough the proxy. Do

If you only have an HTTP proxy, DNS won't work (but you don't really need that, because the proxy will resolve the domain names). So that's normal. Levente

someone know how can I set the username and password so that to use NetNameResolver?

Sorry, I tried to test it ;)

Mariano

On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote:

...

Really thanks for all your energy on that. I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:

...

...

From Socket class >> initializeNetwork:

"Initialize the network drivers and the NetNameResolver. Do nothing

if

...

the network is already initialized." "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. "

NetNameResolver initializeNetwork

This explains why the initializeNetwork must be called *before* every network transaction. Between image restarts the network isn't guaranteed to remain.

I propose to create a new preference (I know that they are banned but we need a workaround for 1.0 release) and then each user can, without modify the NetNameResolver class >>initializeNetwork, change the setting to the value that works for him/her.

First evaluate:

Preferences addPreference: #useOldNetwork categories: #(general network) default: false balloonHelp: 'Enable/disable the use of the old network code in making network connections. You need to save and restart the image to this preference to take effect' projectLocal: false changeInformee: nil changeSelector: nil.

to create the preference in a PharoCore 10508 image.

Then load

Network-Kernel-MiguelCoba.22

from PharoInbox.

Pay attention that when you change the preference, it is not refected immediately. You need to:

1. Open the image with the wrong value of the Preference 2. Change the preference Preferences enable: #useOldNetwork

or

Preferences disable: #useOldNetwork 3. Save the image 4. Restart the saved image 5. Evaluate: NetNameResolver initializeNetwork

or some way use the network (open a monticello browser for example, so that initializeNetwork is called)

6. Test that the preference is being used:

NetNameResolver useOldNetwork -> value of preference

7. Test that resolves correctly an address:

NetNameResolver addressForName: 'www.yahoo.com' -> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)

8. Save the new image, now with the new preference.

I added this workaround as a fix to issue 1884 and changed status to fixed.

Can you give it a try please and if so, generate a new image for PharoCore?

Cheers -- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El jue, 28-01-2010 a las 21:28 +0100, Mariano Martinez Peck escribió:

2010/1/28 Levente Uzonyi <leves@elte.hu> On Thu, 28 Jan 2010, Mariano Martinez Peck wrote:

Thanks Miguel. I tried but here in the residence I have a proxy to with user and password. To use Monticello or whatever, I always need to evaluate this:

HTTPSocket useProxyServerNamed: '10.100.1.4' port: 9090 proxyUser: 'XXX' password: 'YYY'

or

HTTPSocket proxyUser: 'XXX' password: 'YYY'.

The problem is that with NetNameResolver I cannot get trough the proxy. Do

If you only have an HTTP proxy, DNS won't work (but you don't really need that, because the proxy will resolve the domain names). So that's normal.

Thanks Levente. As you can see, I am a totally newbie with this stuff :(

Ok, this time I cannot be tester.

No hay problema. :) Saludos

Levente

someone know how can I set the username and password so that to use NetNameResolver?

Sorry, I tried to test it ;)

Mariano

On Thu, Jan 28, 2010 at 6:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr wrote:

Really thanks for all your energy on that. I have some administrative taks to do now but I will give a try just after.

On Jan 28, 2010, at 6:06 PM, Miguel Enrique Cobá Martinez wrote:

>From Socket class >> initializeNetwork:

"Initialize the network drivers and the NetNameResolver. Do nothing if the network is already initialized." "Note: The network must be re-initialized every time Squeak starts up, so applications that persist across snapshots should be prepared to re-initialize the network as needed. Such applications should call 'Socket initializeNetwork' before every network transaction. "

NetNameResolver initializeNetwork

This explains why the initializeNetwork must be called *before* every network transaction. Between image restarts the network isn't guaranteed to remain.

I propose to create a new preference (I know that they are banned but we need a workaround for 1.0 release) and then each user can, without modify the NetNameResolver class >>initializeNetwork, change the setting to the value that works for him/her.

First evaluate:

Preferences addPreference: #useOldNetwork categories: #(general network) default: false balloonHelp: 'Enable/disable the use of the old network code in making network connections. You need to save and restart the image to this preference to take effect' projectLocal: false changeInformee: nil changeSelector: nil.

to create the preference in a PharoCore 10508 image.

Then load

Network-Kernel-MiguelCoba.22

from PharoInbox.

Pay attention that when you change the preference, it is not refected immediately. You need to:

1. Open the image with the wrong value of the Preference 2. Change the preference Preferences enable: #useOldNetwork

or

Preferences disable: #useOldNetwork 3. Save the image 4. Restart the saved image 5. Evaluate: NetNameResolver initializeNetwork

or some way use the network (open a monticello browser for example, so that initializeNetwork is called)

6. Test that the preference is being used:

NetNameResolver useOldNetwork -> value of preference

7. Test that resolves correctly an address:

NetNameResolver addressForName: 'www.yahoo.com' -> 209.131.36.158(f1.www.vip.sp1.yahoo.com),0(0)

8. Save the new image, now with the new preference.

I added this workaround as a fix to issue 1884 and changed status to fixed.

Can you give it a try please and if so, generate a new image for PharoCore?

Cheers -- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Miguel Cobá http://miguel.leugim.com.mx

The OS/vm is part of it; behavior also depends on whether the network is configured for ipv6, and perhaps whether or not it is done correctly. It gets complicated in a hurry. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hernan Wilkinson [hernan.wilkinson@gmail.com] Sent: Friday, January 29, 2010 5:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? The changed you suggested worked on my machine, mac os X and also on a Debian. Hernan. 2010/1/28 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com<mailto:miguel.coba@gmail.com>> El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió:

I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize.

Bill

Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks for the feedback. Stef On Jan 29, 2010, at 11:27 PM, Hernan Wilkinson wrote:

The changed you suggested worked on my machine, mac os X and also on a Debian.

Hernan.

2010/1/28 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió:

...

I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize.

Bill

Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers.

The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper.

Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required.

As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes.

So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this.

Regards

Miguel Coba

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project