On Thu, 14 Feb 2008 15:02:57 +0100, Igor Stasenko wrote:

> On 14/02/2008, Klaus D. Witzel wrote:
>> On Thu, 14 Feb 2008 13:26:55 +0100, Igor Stasenko wrote:
...
>>  > ... what i tried is to understand what you putting in
>>  > 'passing control' and in 'synchronous'.
>>  > Is this means, that you want do following:
>>
>> First we need to add this:
>>
>>  0] if any operation on either side fails, then the other side fails as
>>  well, with proper notification *whatsoever*.
>>
>
> Of course.
>
>>
>>  > - initiator image sends message to another one (a message payload is
>>  > not really relevant)
>>
>> 1] this part has more: initiator asks the other .image to establish a
>>  response channel. If handshaking fails, then 0]
>>
>>  > - then waits during another image performs requested operation
>>
>> No, no RPC. This is Smalltalk land, we want no stinkin' RPC :) instead,
>>
> Thanks GOD! :)

:)

>>  2] then the other .image sends back sufficient payload so that the
>>  initiator side has the "next" block evaluated, and so on with roles
>>  swapped, back and forth. If something fails, then 0]
>>
>>  No other part of the method is "resumed-to", on neither side. This is
>>  meant when I write, unit of transfer is Smalltalk's block. Apologies  
>>  if I didn't make *block* clearer.
>>
>>  May I repeat it? it's *blocks* :) Each block is evaluated on "its" side
>>  (#atHomeDo: #atWorkDo:), same with a block's blocks.
>
> Still is little bit confusing. Especially when you saying 'block's  
> blocks' :)

A block's block is created from bytecodes for which (thisContext  
isMemberOf: BlockContext) holds; let's call them nested blocks.
In the same sense is a non-block's block created from bytecodes for which  
(thisContext isMemberOf: MethodContext) holds.

Both, #atHomeDo:'s and #atWorkDo:'s, blocks can have nested blocks :)

> Can you elaborate little more (by suggesting how #atHomeDo: #atWorkDo:
> should look like)?

Worth to note: instances of HydraSMS (aka NetworkContext) know in which  
context they had been created. At creation time they insert a context for  
#ifCurtailed* and another for fall-through-return into their process'  
stack. But they can also be detached from their initiating process; I have  
subinstances of Model (Browser*) for which that is important and whose  
HydraSMS (aka NetworkContext) instance lives longer than the instance  
creating process.

> HydraSMS>>atHomeDo: aBlock
>  "Nothing sophisticated, just evaluate a block"

This is indeed a *very* sophisticated method; #atHomeDo: can be sent by  
either side, from a nested block or from the method initiated at the other  
side. Recall that we provide support for the-same-method-in-both-images;  
this might incur obstacles at HydraSMS development-time but they are  
offset by very-easy-to-use at library-use-time (only less burden-as-user  
can be more fun ;-)

>  homeBlock := aBlock.
>  ^ aBlock value

Yes, something like this is done on the (respective) other side, "just"  
after gathering+transfering sufficient payload data such that

  ((BlockContext newForMethod: imaginaryContext method)
   home: imaginaryContext
   startpc: startPC
   nargs: 0) value

can be performed (after the corresponding imaginaryContext has been  
determined by the respective side).

>
> HydraSMS>>atWorkDo: aBlock
>   "Send message to other side to evaluate it's Home block"
>   channel reliablySend: (self encodeEvaluateAtHomeDoPacket)
>  "what to do with aBlock here?"

Do the same with it as #atHomeDo: does, except that roles are swapped and  
other out-of-sequence-errors are possible.

> HydraSMS>>nextStringPut: aString
>  "Send string to be used by #nextString at remote side"
>   channel reliablySend: (self encodeNextStringPutPacket: aString)

Precisely, except that because of your Hydra channels implementation (no  
offense), you have two instance variables in HydraSMS instances which  
cannot both be named 'channel' ;-)

>
> HydraSMS>>decodePacket: aPacket
> "this method executed when you receiving data from channel"
>  aPacket isEvaluateAtHomeDo ifTrue: [ self atHomeDo: homeBlock ].
>  aPacket isNextStringPut ifTrue: [ nextString := aPacket extractString ].

Precisely, except that Smalltalk developers believe that we provide them a  
stream (they see #next*) and so you have to have a FIFO mechanism like the  
one you mentioned in a previous message.

>
> HydraSMS>>nextString
> "simple and stupid :)"
>  ^ nextString
  "still simple but not *that* stupid"
  ^ receivedDataBlocks removeFirst

>>
>>  > - then resuming operations (by receiving notification or return  
>> value).
>>
>> If you would have meant RPC by that: no. All that is transferred, is  
>> which
>>  Smalltalk block on which side is to be evaluated next (recalling that  
>> both
>>  sides are in the same compiled method and let's forget about
>>  parameter/argument passing for a moment). And Smalltalkers can put
>>  *everything* inside their blocks :)
>>
>>  -------------
>>
>>  Both sides intentionally return self (but of course they can persist
>>  parameters/arguments and do with them whatever they please).
>>
>>
>>  /Klaus
>>
>