Bug in NetNameResolver on PharoCore 10508?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
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
--
Miguel Cobá
http://miguel.leugim.com.mx



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Mariano Martinez Peck
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]>
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Miguel Cobá
NetNameResolver definitely containts at least one bug related to IPv6 code being called when it should not be.  I am trying to adapt to the imaging building changes, so I can't easily confirm your details at this point, but there are problems with the code.  I have encountered it on both Linux and Windows, the latter being more machine-specific, perhaps due to the particular version of the OS, presence of vm software, and other confounding factors unrelated to Pharo.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Wednesday, January 27, 2010 8:50 AM
To: pharo
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Mariano Martinez Peck
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]>
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
In reply to this post by Mariano Martinez Peck
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 <[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

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Adrian Lienhard
In reply to this post by Schwab,Wilhelm K
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]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Miguel Cobá
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: [hidden email] [mailto:[hidden email]] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Wednesday, January 27, 2010 9:30 AM
To: [hidden email]
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 <[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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
In reply to this post by Adrian Lienhard
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Adrian Lienhard
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.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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Stéphane Ducasse
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: [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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
Stef,

I missed your propoal[*] but I will look for it later today.

[*] lots of traffic here, some progress on only loosely related data mining fronts, and I've been focused on how to use metacello configurations in my build process.

Bill

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Wednesday, January 27, 2010 11:56 AM
To: [hidden email]
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Mariano Martinez Peck
In reply to this post by Miguel Cobá


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


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

 
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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
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


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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
In reply to this post by Adrian Lienhard
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: [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

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
In reply to this post by Miguel Cobá
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Bug in NetNameResolver on PharoCore 10508?

Schwab,Wilhelm K
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


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Thursday, January 28, 2010 5:00 AM
To: [hidden email]
Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in NetNameResolver on PharoCore 10508?

Miguel Cobá
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in NetNameResolver on PharoCore 10508?

Adrian Lienhard
+1

On Jan 28, 2010, at 16:39 , Miguel Enrique Cobá Martinez wrote:

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
123