[Vm-dev] Simulator Question

[Gabriel Hernán Barbuto]

Igor

Thanks for your reply. But my idea was not to call interpret. I am
aware of the infinite loop.

I would like to push the selector and the receiver onto the stack and
then call something like Interpreter>>#commonSend and then clean the
stack.

Maybe I cannot call Interpreter>>#commonSend because it fetches the
next byte code and I don't want to modify the execution state. But at
least perform the rest of the calls. I don't know if this makes any
sense.

>From what I have learned so far. Besides that this approach might not
work. The problem seems to be creating the selector. If I can create
the selector I will try it anyway.

Thanks again.

Gabriel


On Thu, Jan 6, 2011 at 5:00 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
> On 6 January 2011 16:41, Gabriel Hernán Barbuto <gbarbuto at gmail.com> wrote:
>>
>> Hi
>>
>> I am working with the InterpreterSimulator and I would like to send a
>> message to an object inside the simulated environment. For example, I
>> have the oop for true and I want to send it the message printString.
>>
>> My question is if this is possible. I don't know if there is a way to
>> send a message to an object inside the simulation. I have thought
>> about tinkering with the stack and calling an interpreter method. But
>> I am not sure if this will work.
>>
>
> Hi, Gabriel.
> The problem is, that even if you prepare a context and all arguments
> for message send,
> you should start interpreting the code and then leave the interpret
> loop once you received the answer.
> But if you look at #interpret method, there is an infinite loop,
> and no way how to escape it.
>
> I don't know if there is a way to tell simulator to leave the loop at
> certain point.
>
>
> P.S. In general, it would be cool to have something like:
>
> sqInt interpreter_call( sqInt receiver , sqInt selector , sqInt * arguments )
>
> means: send message to receiver and return the answer.
>
> Unfortunately, Squeak VM does not provides such things, in contrast to
> languages like Lua,
> which providing C interoperability layer by default from very
> beginning of it existence.
>
>> Any hint will be much appreciated. Thanks in advance.
>>
>> Gabriel
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>