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


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

Reply via email to