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