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