respondsTo: bug

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 <[hidden email]> 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

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

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email]
[mailto:squeak-dev- when

On 12/18/07 2:16 PM, "Andreas Raab" <[hidden email]> 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 <[hidden email]> 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.

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
>
>


--
Best regards,
Igor Stasenko AKA sig.

> 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

Ah, I meant to say Igor. EEEEeeeeee... Sorry...


Chris

On 25/12/2007, Chris Cunnington <[hidden email]> 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 :)
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
>

--
Best regards,
Igor Stasenko AKA sig.

Thanks, Vlad.

Just kidding. Thanks, Igor!

Chris

On Dec 24, 2007 4:24 PM, Chris Cunnington <[hidden email]> 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

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" <[hidden email]> 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