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