[ruby-talk:27429] Re: thoughts for future Ruby with bytecode VM

"Phil Tomson" <[e-mail]> wrote in message
news:tDRO7.36967$[e-mail]...
> from the brainstorm department....
>
> I'm working on a task distribution system which distributes runnable
> objects (objects which respond to a 'run' method) to various clients.  One
> thing I've had to do was define a 'remote_require' method on the clients
> so that I can send new runnable class definitions to clients so that they
> are 'aware' of new classes which the user might create (basically, I
> 'stringify' the rb file which defines the class, send the string to the
> client and the client does an Object.class_eval(str) )
>
> In the future, when Ruby's backend is some kind of VM that executes
> bytecode, it would be nice to be able to access the bytecodes which a
> particular class was compiled to so that the bytecode could be sent around
> instead of the actual text (assuming the bytecode is more compact than the
> text description - maybe not true).  So we'd have some method defined in
> Module or Class which is called something like: bytecode, which returns
> the bytecode definition for the class or module.  Maybe we would even have
> a new object type: Bytecode


This "agent" capability was the basis for the 1991 design and implementation
of SmalltalkAgents (Smalltalk on the MacOS); which ultimately has evolved
into SmallScript today. Given the goal of that 91 design was agent centric
technology with capabilities for settop boxes, it should hardly be a
surprise. But, the Mac version provided green-threads and real-time object
package/agent extrusion and loading (10's of thousands to 100's of thousands
of objects per/second -- very fast for its day). Agent packages contained
arbitrary object clusters, databases, could be random accessed, and were
fully extensible for adding addition sections/directories.

You could grab a running UI components, threads, etc and drag them to the
desktop, store them in a DB, throw them to another machine, etc.  We called
the Agent technology packages "PIPOs" and they were written up in various
Agent books and magazines of the day. One of the major demonstrations of
this was given in 1994-1995 to show off the potential of OpenDoc. We built a
NetScape/Mozilla clone browser in Smalltalk. We then, while it was live
browsing and animating images, tore its pieces off and threw them across the
net (so to speak) to another computer where they came back alive still
running.

The point of all this is that it was do-able efficiently on 1991+ technology
which was basically 16-20MHz 68K cpu's with a risc-style byte-code
interpreter.

Bytecodes were, in the 1991 QKS Smalltalk version (and still are in
SmallScript) stored in the struct-portion of a <Method> object. Blocks
(closures/partial-continuations) hold state but otherwise point into some
subsection of byte-codes within the method that created them [even if that
method is unbound/anonymous].

Today there are a number of reason's not to use "green-object-threads"
within a host MP system. Green-object-threads (stack only holds OOP
references) can still be provided but it is not clear how valuable they
would be and their is a significant performance penalty over native threads
with mixed data stacks. However, smalltalk blocks are no problem to capture,
persist, restore etc.

What you are really talking about is classic "context" objects which have
been used in Lisp and Smalltalk systems for a long time 25 years plus.
Modern implementation techniques use a hybrid mix of real-stacks for
performance and context/frame and block objects to capture cross-thread
shareable (and persistable) continuation information.

I can't authoritatively speak for "all" Smalltalks, but QKS Smalltalk the
ancestor of SmallScript fully supports conversion of classes (modules),
methods, blocks (any object) to a binary blob for persistance and subsequent
revivication in some other context. The PIPO infrastructure from QKS
Smalltalk's final 1998 version was written in pure Smalltalk. I also expect
bring over my QKS Smalltalk PIPO implementation to SmallScript; but I've
been busy with other things.

In bootstrapping SmallScript, I used a variant of them to allow me to
autoload code changes into the system before it had the compiler fully up
and running natively. A variant of that same technique is also the mechanism
by which SmallScript modules are packaged and deployed as DLL's, etc.

====
So, it not only is possible to package up code (methods, closures,
partial-continuations, green-threads/fibers) but it is the basis for
modularizing most modern dynamic language systems. Source is a secondary
medium that may be provided for human-convenience and refactoring but is not
needed for just-in-time dynamic (binary) integration and deployment.

-- Dave S. [www.smallscript.org]

>
> #a.rb
> class A
>    def initialize
>    end
>    #...
>    def method
>      #blah
>      dosomething
>    end
> end
>
>
> #main.rb
> require 'a.rb'
> #now we 'know' about class A
>
> classAbytecode = A.bytecode
> #later, after a remote client is set up:
>
> client.remote_require(classAbytecode)
> #now the remote client will 'know' about class A
> ######end main.rb ########
>
> BTW: maybe it would be nice to be able to access the definition
> of a class (as a string, without comments) as well (could this be done in
> the current
> version of Ruby):
>
> #main2.rb
> require 'a.rb' #from above
>
> classStr = A.definition
>
> puts classStr
> =>
> "class A
>    def initialize
>    end
>    def method
>       dosomething
>    end
> end"
>
> Phil
>
>