On Mon, 18 Feb 2008 17:45:10 +0100, Igor Stasenko wrote:

> On 16/02/2008, Klaus D. Witzel wrote:
>> On Sat, 16 Feb 2008 18:09:27 +0100, Igor Stasenko wrote:
>>
>> > On 16/02/2008, Klaus D. Witzel wrote:
>> >> On Sat, 16 Feb 2008 13:56:54 +0100, Igor Stasenko wrote:
>> ...
>> >> > index and handle is the result of previous calls to primitives  
>> which
>> >> > should return a HydraInterpreter instance from now.
>> >>
>> >> Still unclear: your user (a developer) has an index, say an element  
>> from
>> >> (1 to: n), for which you want to return her/him a HydraInterpreter
>> >> instance from now on?
>> >>
>> >
>> > Right.
>>
>> </phew> and no further comment on index dilemma :)
>>
>
> Forgot to notice, that this would require registering HydraInterpreter
> in special objects array, to be able primitives to deal with it.

I see that I still cannot see what you aim for. Can't you let the user  
(developer) make her/his decisions and, when she/he implements it as an  
xyzCollection with cool speedy abcIndex, just let them do so?

We discussed the "a new Hydra .image started", "and now one went away"  
events (also the heartbeat event). If someone wants to maintain a  
collection with this happenings, they should be free to do so.

> If this is acceptable, then i will do the changes in VM and
> primitives. If not, then i'll keep primitives untouched, but refactor
> classes to use HydraInterpreter instances instead of handles.

Sounds good.

> Can't make a decision, if making HydraInterpreter a special object
> worth doing or not.

If your handle is representable by 31bit quantity then it could be the  
first instance variable, like in CompiledMethod the header field. Would  
let sophisticated user add more instance variables (as opposed to, say  
MethodDictionary which is hardcoded).

But that can wait, no doubts.

> Meanwhile i'll start implementing a HydraStream.

And the reliable, bidirectional communication, will that be part of your  
stream thing or come later? I just want to know when I can start my  
attempt with HydraSMS, no real hurry (other things must be tested+working  
before that).

>> ...
>> >> > ..erm.. do you mean by HydraInterpreter  as an interpreter at VM  
>> side,
>> >> > or as an object?
>> ...
>> >> BTW: isn't the HydraInterpreter name misleading (and causing  
>> confusion
>> >> in
>> >> the above). How about using another name, without "interpreter" in  
>> it,
>> >> because your "as an interpreter at VM side" is something else.
>> >>
>> > Hmm, i don't know.
>> > We have HydraVM , which runs multiple interpreters and
>> > HydraInterpreter "represents" one of them.
>> > If you having better naming suggestions, just say it.
>>
>> It doesn't interpret anything (it is as dead as a handle is dead), so  
>> I'd
>> say HydraImageReference (like MethodReference etc).
>>
>
> Image is quite dead too - it's just a bunch of bytes sitting in memory.
> See, when you do:
>
> Smalltalk garbageCollect
> Smalltalk version
>
> it seems more logical than:
>
> SmalltalkImage garbageCollect
> SmalltalkImage version

That depends from what the garbage disappears. Smalltalk is generally free  
of garbage and shame on those who claim the contrary ;-) But your running  
image has garbage, and that was created by you ! (you can't send your  
.image with garbage to someone else, no you can't ;-)

BTW someone (whether they saw the mess or had other reasons) already moved  
#version to SystemVersion anyways.

> so, i'd say that if you wanna do something with image/memory you
> should ask interpreter to do it for you, not image.
>
> In that way:
> interpreter doit: 'Foo bar'
> seem more logical than
> image doit: 'Foo bar'
>
> also consider that under the hood, it's actually an interpreter
> instance, which in own turn refers to it's image and make it running,
> but in addition it having own state and behavior not quite relevant to
> image (object memory).

Fell free to see it so, also when usually (all the users of something) ~~  
(the creator of something) and the former have their own ideas of what is  
what. No need to forsee *everything*, I mean by that.

>
>
>> /Klaus
>>
>> P.S. any time frame for the next step(s) ?
>>
>