On 14/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
>
> 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).
>
>

What can i say? Only that you are real guru in metaprogramming, and
i'm lacking in expertise to deal with this task.
I never got so deep under the hood to have need in creating a block
contexts, or using #ifCurtailed: methods.

>  >
>  > 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
>  >>
>  >
>

Maybe it would be less confusing for me, from a start, if methods
names would be #remotelyDo: , #locallyDo:..
I'm working at home, about a 2 years till now, so there is no real
difference for me between #atHomeDo: and #atWorkDo: :)

In general, i finally understood your idea. But due to my lack of
practice (and knowledge) in uber-metaprogramming i don't think i will
be capable do that without help :)

What i can currently do, is provide an implementation of reliable
bidirectional communication. The rest, i hope you can do yourself.
Orr.. if you prototype most of meta-crunching stuff and point me out
what places i should add to make it live.

-- 
Best regards,
Igor Stasenko AKA sig.