On 16/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Sat, 16 Feb 2008 13:56:54 +0100, Igor Stasenko wrote:
>
> > On 16/02/2008, Klaus D. Witzel wrote:
> >>
> >> There's always some price to pay, when you want to maintain control over
> >> your asynchronous computations. Another possibility would be to base
> >> absence(dead), presence(alive), other state(busy,idle) of your
> >> interpreter
> >> instances on events. Have you considered using events for that, would
> >> that
> >> be easy to implement in Hydra?
> >>
> >
> > Well, i can add some code at the end of image startup phase
> > broadcasting to others that new image is ready for work. As well as,
> > at shutdown, a broadcast that it's going to vanish.
>
> Ahh, now we are talking events :)
>
> > This can be done using current set of features (channels), no need to
> > put this code into VM.
>
> Exactly, I thought about the same.
>
> > In same way, for a busy/idle state: you may put code in image to
> > declare by yourself, when it is busy or idle, and respond with
> > appropriate message on request, if needed.
>
> For dead/alive: an interval timed object which periodically (3-4 secs)
> sends "I'm alive" ;-)
>
> > Channels are implemented using events, e.g. when you putting something
> > in channel, in reality its an event posted to corresponding event
> > queue.
>
> Sure.
>
> >>
> >> > Okay, i think i have a solution which will suit both of us.
> >>
> >> For the records: in the previous I just tried to use *your* existing
> >> index
> >> into *your* existing collection :)
> >>
> >> > By adding a HydraInterpreter class, instances of which will be used in
> >> > primitives.
> >>
> >> That sounds good.
> >>
> >> > Class should have two fields: index and handle.
> >> > Primitives then checking:
> >> > - if given argument is of class HydraInterpreter,
> >> > then reads index and handle.
> >>
> >> How would you map one of these indexes to its corresponding instance of
> >> HydraInterpreter, how would your #doit:at: do that mapping?
> >>
> >
> > 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.

> >
> >> > then checks if by given index VM having same interpreter handle, as
> >> > specified in HydraInterpreter instance.
> >> > If not, then it tries to search its list of interpreters to find given
> >> > handle, and if found, updates index automatically.
> >> > If handle not found, then primitive fails.
> >> >
> >>
> >> Looks like a lot of work (if only for your index); did you compare
> >> against
> >> simple (HydraInterpreter allInstances) ? This (or something like this)
> >> needs only be done after a new HydraInterpreter was
> >> created(copied)/started, and, depending on needs, after one of the
> >> HydraInterpreter instances gone away.
> >>
> > ..erm.. do you mean by HydraInterpreter  as an interpreter at VM side,
> > or as an object?
>
> Cannot understand "as an interpreter at VM side": didn't you write that
> everything is an object on the Smalltalk side (even your handles, which
> seem to represent the magic)? To be sure, I didn't think about anything
> "behind" your handle.
>
> And by HydraInterpreter instance I meant the one from your discussion with
> Keith. Perhaps I associate your handle with an instance of
> HydraInterpreter, whereas you treat them as different objects. No problem,
> just put a "represents" symbol between them.
>
> 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.

> > Objects can contain a random values, nothing bad will happen if you
> > pass it to primitive.
>
> Thanks to the implementor of the primitive and to the writer of the
> corresponding test cases ;-)
>
> >
> > A primitive #interpreterInstanceAt: will be refactored to return a
> > freshly created HydraInterpreter instance.
>
> Ah, this is where you map elements of (1 to: n)? But didn't you write you
> are concerned that is slow, because you always have to enumerate your 100
> instances (example)?
>
> And, did you consider to implement #= and #hash which are now necessary
> for all your freshly created HydraInterpreter instances?
>
Yes, i did :)
By now, lets stop tempting peoples patience by discussing usage of
#at: patterns :)
I don't think this can be crucial for the system at the end :)


-- 
Best regards,
Igor Stasenko AKA sig.