Squeak 3.9 #7067
I happened to be comparing Squeak to Dolphin CE, and ran across this bug in Squeak relating to respondsTo:
(3 @ 4) respondsTo: #<=. "Squeak reports this as false"
However:
(3 @ 4) <= (10 @ 15). "true"
(3 @ 4) <= (1 @ 15). "false"
Trying other methods for Point, I get many similar 'false' results when sending 'respondsTo:' to Point (but I also get many correct results).
ie.
Point respondsTo: #abs. "false" however, Point respondsTo: #hash. "true" Point respondsTo: #storeOn:. true
Point respondsTo: #x. false but (3 @ 4) x. "3"
Point respondsTo: #y. false but (3 @ 4) y. "4"
There does not seem to be any pattern to when respondsTo: works correctly and when it doesn't.
-- dae
On 12/18/07, Doug Edmunds dae@douglasedmunds.com wrote:
(3 @ 4) respondsTo: #<=. "Squeak reports this as false"
Could you double-check that, please? Maybe it's different in your release of Squeak, but I get a true value.
Trying other methods for Point, I get many similar 'false' results when sending 'respondsTo:' to Point (but I also get many correct results).
ie.
Point respondsTo: #abs. "false"
You're sending that message to Point, a class, rather than to an instance of Point. The class doesn't respond to abs, but an instance should.
(3@2.5) respondsTo: #abs. "true" (3@2.5) respondsTo: #basicNew. "false"
Hope this helps!
--Tom Phoenix
Doug Edmunds wrote:
Squeak 3.9 #7067
I happened to be comparing Squeak to Dolphin CE, and ran across this bug in Squeak relating to respondsTo:
(3 @ 4) respondsTo: #<=. "Squeak reports this as false"
I tried this exactly as written here and Squeak 3.9 7067 reports this correctly as true. I think you might have tried, e.g.,
Point respondsTo: #<=.
(since you are using this below for other supposedly wrong results). Basically, what you are missing is the distinction between instances and classes - if you ask an *instance* of Point, like "3@4" whether it responds to #<= it will say yes, but if you ask the *class* Point it will answer no, because in fact, *class* Point does not respond to #x.
Trying other methods for Point, I get many similar 'false' results when sending 'respondsTo:' to Point (but I also get many correct results).
ie.
Point respondsTo: #abs. "false" however, Point respondsTo: #hash. "true" Point respondsTo: #storeOn:. true
The reason these answer true is that all objects (incl. class Point) respond to these messages - even nil, the UndefinedObject.
Point respondsTo: #x. false but (3 @ 4) x. "3"
Absolutely. The Point *class* does not respondTo: the message but the Point *instance* does. If you want to know whether a class can understand a particular message then you should ask for that, e.g.,
(3@4) respondsTo: #x. "=> true" Point respondsTo: #x. "=> false"
However,
Point canUnderstand: #x. "=> true"
The duality of #respondsTo: and #canUnderstand: exists because classes are objects, too, and therefore answering true to "Point respondsTo: #x" would be plain wrong since class Point does indeed not respond to #x.
Point respondsTo: #y. false but (3 @ 4) y. "4"
There does not seem to be any pattern to when respondsTo: works correctly and when it doesn't.
Oh, yes, there is. If you ask an *instance* use #respondsTo:. If you ask the *class* use #canUnderstand:.
Cheers, - Andreas
On 12/18/07 2:16 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
Basically, what you are missing is the distinction between instances and classes
The map is not the terrain. The classes are just templates, but people from the C world think that this is what's real. The instances are what's real. The classes are not the objects. (The classes are objects but, frankly, who cares. Metaclasses are somebody else's problem.) The instances are the objects. In Smalltalk you are dealing with a visible world of classes, which is false. And the real world of instances, which you can only see through the windows of the Inspector and the Explorer. You need to learn to see into two worlds, and not rely on the one, the System Browser, staring you in the face. The problem is added to, because classes are written to be as general as possible for maximum reuse. While the instances are as specific as possible. Unique, in fact. The leap to the dynamicly bound, loose typing world is weirder than you think... Not for nothing are we associated with Lisp.
Chris
On 18/12/2007, Chris Cunnington cunnington@sympatico.ca wrote:
On 12/18/07 2:16 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
Basically, what you are missing is the distinction between instances and classes
The map is not the terrain. The classes are just templates, but people from the C world think that this is what's real. The instances are what's real. The classes are not the objects. (The classes are objects but, frankly, who cares. Metaclasses are somebody else's problem.) The instances are the objects. In Smalltalk you are dealing with a visible world of classes, which is false. And the real world of instances, which you can only see through the windows of the Inspector and the Explorer. You need to learn to see into two worlds, and not rely on the one, the System Browser, staring you in the face. The problem is added to, because classes are written to be as general as possible for maximum reuse. While the instances are as specific as possible. Unique, in fact. The leap to the dynamicly bound, loose typing world is weirder than you think... Not for nothing are we associated with Lisp.
I can't agree with you on this. Classes are just objects, instances of own metaclass. Any object (including classes) refers to it's class. And to learn what object can do or can't, you may send #respondsTo: to any object in system.
But, for classes, there is a special methods which can describe a properties of it's instances, like: -methods of instance -it's variables e.t.c.
In this way, you can explore many of instance properties without creating them.
Chris
I can't agree with you on this. Classes are just objects, instances of own metaclass. Any object (including classes) refers to it's class. And to learn what object can do or can't, you may send #respondsTo: to any object in system.
Hi Ivan,
Thank you for correcting me. I wrote that post hoping somebody would show me where I'm wrong. I guess I'm close on some things and not so close on others.
I've never used #respondsTo:. I tried this:
Object respondsTo: asMorph
I print it, and get:
Object respondsTo: asMorph false
I thought this was a way of asking any object in the system if it has a certain method. How should I use respondsTo:? It's probably a beginner question, but, hey. That's me.
I read the Hydra posting, and if I understand it correctly, it's very exciting. If I download a standard Squeak package (VM, Sources, and image) and put that on a server and server it to the Internet, then that's probably fine.
If I add ten other images, then I guess they're all being served by the same VM, and problems will happen. What can go wrong? They freeze? I've always wondered how many Seaside images a person could put on a server, if they have installed the standard Squeak VM in a Linux server, like say RHES.
If I understand you are saying Hydra address the problems of such a configuration. Many images on one Squeak VM, but specially modified for the job, and all serving to the Internet. That's Hydra.
It's only available for Windows at the moment, I guess. I see that I can download the HydraVM-sig.1.mcz. But what do I do with it? Do I file it into an image, does that make sense? Doesn't it need to stand alone from images? How do you un-zip an mcz file, so that it stands alone from an image? Are all mcz files just for filing in?
Oh, one last question. When you say "threads" do you meaning anything different from the word "process"? I can, and have, run several Squeak images on the same server. Each has its own process number for starting and stopping it. Is that what you mean by threads, or is it something else? Do threads have a process number?
Any help you can give me understanding this would be great. Sorry if these questions are so rudimentary.
Chris
On 25/12/2007, Chris Cunnington cunnington@sympatico.ca wrote:
I can't agree with you on this. Classes are just objects, instances of own metaclass. Any object (including classes) refers to it's class. And to learn what object can do or can't, you may send #respondsTo: to any object in system.
Hi Ivan,
Err.. i'm Igor :)
Thank you for correcting me. I wrote that post hoping somebody would show me where I'm wrong. I guess I'm close on some things and not so close on others.
I've never used #respondsTo:. I tried this:
Object respondsTo: asMorph
I print it, and get:
Object respondsTo: asMorph false
I thought this was a way of asking any object in the system if it has a certain method. How should I use respondsTo:? It's probably a beginner question, but, hey. That's me.
No, not like that. see, if you sending #respondsTo: to some object (in your case you sending to Object class), it will tell you that given, particular object can respond to given message. But it will not tell you that all instances of Object class can respond to given message.
and btw, rather than asking about difference, you'd better simply look at implementation of #respondsTo: , there is nothing magical in it :)
I read the Hydra posting, and if I understand it correctly, it's very exciting. If I download a standard Squeak package (VM, Sources, and image) and put that on a server and server it to the Internet, then that's probably fine.
Currently Hydra available only in sources, so , to use it you need to build it first.
If I add ten other images, then I guess they're all being served by the same VM, and problems will happen. What can go wrong? They freeze? I've always wondered how many Seaside images a person could put on a server, if they have installed the standard Squeak VM in a Linux server, like say RHES.
What can go wrong mostly depends on what are you doing, and what images loading :) Currently, the number of safe primitives are short (all VM primitives , except GUI) and File/Socket/FFI plugins. And some minor plugins like FloatMath e.t.c (can't remember). So, i hope, that any image, with stripped down Morphic code, have a real chances to run without much problems.
Also, VM designed in a way to be backwards compatible with old plugins. But, you need to make sure that given plugins are used only by single Interpreter instance (main interpreter).
If I understand you are saying Hydra address the problems of such a configuration. Many images on one Squeak VM, but specially modified for the job, and all serving to the Internet. That's Hydra.
Yes, this could be an option. But Hydra VM is designed for generic purpose, there is no special accents on networking e.t.c.
It's only available for Windows at the moment, I guess. I see that I can download the HydraVM-sig.1.mcz. But what do I do with it? Do I file it into an image, does that make sense? Doesn't it need to stand alone from images? How do you un-zip an mcz file, so that it stands alone from an image? Are all mcz files just for filing in?
As i mentioned before, you need to build new VM. Then pick any image , you like and load HydraVM package in it using Monticello. Then you can try: HydraVM loadAndRunNewImage: 'yourimage.image'
and have fun.
But, honestly, it will crash in a moment, because you need to prepare an image which will be running in parallel. Currently, in my testing image i'm changed SmalltalkImage >> snapshot: save andQuit: quit embedded: embeddedFlag to run only my code if image served by non-main interpreter instance.
Oh, one last question. When you say "threads" do you meaning anything different from the word "process"? I can, and have, run several Squeak images on the same server. Each has its own process number for starting and stopping it. Is that what you mean by threads, or is it something else? Do threads have a process number?
Processes are ST objects. They have nothing to do with native threads. Everything which working currently in squeak will stay the same in Hydra VM. Hydra VM runs different interpreters in separate threads. Each interpreter is serving own squeak image which can use as many Processes as you want.
Any help you can give me understanding this would be great. Sorry if these questions are so rudimentary.
No, they're not. :)
Chris
On Dec 24, 2007 4:24 PM, Chris Cunnington cunnington@sympatico.ca wrote:
I've never used #respondsTo:.
I tried this:
Object respondsTo: asMorph
I print it, and get:
Object respondsTo: asMorph false
I thought this was a way of asking any object in the system if it has a certain method. How should I use respondsTo:? It's probably a beginner question, but, hey. That's me.
It should be "Object respondsTo: #asMorph". But in fact, you can say "3 respondsTo: #asMorph". The reason that the first works is that Object is an instance of a subclass of Object. #asMorph is a message you send to instances, not classes.
-Ralph Johnson
Thank you for that. I read it over a few times. Tried it in Workspace. That¹s a really useful wrinkle, because I haven't had the hang of the #/symbol character.
Chris
On 12/26/07 4:21 PM, "Ralph Johnson" johnson@cs.uiuc.edu wrote:
It should be "Object respondsTo: #asMorph". But in fact, you can say "3 respondsTo: #asMorph". The reason that the first works is that Object is an instance of a subclass of Object. #asMorph is a message you send to instances, not classes.
-Ralph Johnson
Doug,
((3 @ 4) respondsTo: #<=) answers true here, the rest are confusing because you are sending #respondsTo: to a class, whereas you really want to know if its instances respond to certain messages, try
Array with: ((3 @ 4) respondsTo: #<=) with: ((3 @ 4) respondsTo: #abs) with: ((3 @ 4) respondsTo: #hash) with: ((3 @ 4) respondsTo: #storeOn:)
Cheers,
-Boris
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Boris Popov -
Chris Cunnington -
Doug Edmunds -
Igor Stasenko -
Ralph Johnson -
Tom Phoenix