respondsTo: bug/Hydra

Igor Stasenko siguctua at gmail.com
Mon Dec 24 23:03:23 UTC 2007


On 25/12/2007, Chris Cunnington <cunnington at 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
>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list