Bug in NetNameResolver on PharoCore 10508?

> 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

> 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

>
> 2010/1/27 Miguel Enrique Cobá Martinez <[hidden email]>
>         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
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
> Sent: Wednesday, January 27, 2010 9:00 AM
> To: [hidden email]
> 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 <[hidden email]<mailto:[hidden email]>>
> 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
> [hidden email]<mailto:[hidden email]>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 2010/1/27 Miguel Enrique Cobá Martinez <[hidden email]>
>         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
>         [hidden email]
>        
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Mariano Martinez Peck
> Sent: Wednesday, January 27, 2010 9:00 AM
> To: [hidden email]
> 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
> <[hidden email]<mailto:[hidden email]>>
> 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
> [hidden email]<mailto:[hidden email].
> inria.fr>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Adrian Lienhard
> Sent: Wednesday, January 27, 2010 9:31 AM
> To: [hidden email]
> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Mariano Martinez Peck
>> Sent: Wednesday, January 27, 2010 9:00 AM
>> To: [hidden email]
>> 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
>> <[hidden email]<mailto:[hidden email]>>
>> 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
>> [hidden email]<mailto:[hidden email].
>> inria.fr>
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Adrian Lienhard
> Sent: Wednesday, January 27, 2010 9:31 AM
> To: [hidden email]
> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Mariano Martinez Peck
>> Sent: Wednesday, January 27, 2010 9:00 AM
>> To: [hidden email]
>> 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
>> <[hidden email]<mailto:[hidden email]>>
>> 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
>> [hidden email]<mailto:[hidden email].
>> inria.fr>
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Adrian Lienhard
> Sent: Wednesday, January 27, 2010 10:25 AM
> To: [hidden email]
> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Adrian Lienhard
>> Sent: Wednesday, January 27, 2010 9:31 AM
>> To: [hidden email]
>> 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: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>>> Mariano Martinez Peck
>>> Sent: Wednesday, January 27, 2010 9:00 AM
>>> To: [hidden email]
>>> 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
>>> <[hidden email]<mailto:[hidden email]>>
>>> 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
>>> [hidden email]<mailto:[hidden email].
>>> inria.fr>
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Adrian Lienhard
> Sent: Wednesday, January 27, 2010 10:25 AM
> To: [hidden email]
> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Adrian Lienhard
>> Sent: Wednesday, January 27, 2010 9:31 AM
>> To: [hidden email]
>> 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: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>>> Mariano Martinez Peck
>>> Sent: Wednesday, January 27, 2010 9:00 AM
>>> To: [hidden email]
>>> 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
>>> <[hidden email]<mailto:[hidden email]>>
>>> 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
>>> [hidden email]<mailto:[hidden email].
>>> inria.fr>
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
> > Sent: Wednesday, January 27, 2010 9:00 AM
> > To: [hidden email]
> > 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 <[hidden email]<mailto:[hidden email]>>
> > 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
> > [hidden email]<mailto:[hidden email]>
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>
>

> 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
>
>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project