Eliot wrote:
>We're getting there with fast.  Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data.  That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic.  Is that in the right ball park?

Yes, wet's my appetite :)

Tiny means easy to download and use for scripting, no other dependencies
for the out of the box REPL experience. But still powerfull to built one on another
and scale up to large programs.

Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple
things like:

   c:\myscripts\ts.exe -e 3+4
   7

where ts.exe is the VM in a few kB including a small initial kernel image (as part of
the PE DATA section). It should be able to run scripts:

   c:\myscripst\ts.exe automate.st

It should be possible to easily build components (either with or without the sources):

   ts.exe sunit.st -o sunit.sll
   ts.exe sunit.st -noSource -o sunit.sll

So you can either include other scripts

   ts.exe -i sunit.st  mytests.st

or link the previously built binary components to form something new.

   ts.exe -l junit.sll mytests.st

But it should be possible to build another vm+image easily:

      ts.exe -i mykillerapp.st  -o killerapp.exe
 or   ts.exe -l mykillerapp.sll -o killerapp.exe

by writing a new PE file for Windows either including a new kernel image or a combined
one based on the already built-in initial kernel of the previous one.
So I can deploy a killerapp or reassemble it to form the next language version.

SmallScript was very close to that and it was a nice thing to work with.
Especially since usually Smalltalk usually throws things out at the end - but
one never builds a house by carving it out of a rock. We need bricks to assemble.

With the above scheme you could build components, some of them portable, others
explicitly non-portable as the code includes native calls. The later have to
be rebuilt on the other platform - so if you have good design abstractions you
can implement a UI lib on Windows and one on Mac.

Some of the components are with the source code packaged in for debugging
(but not changeable), for closed source components you leave it out.

And still it should support pinnable objects (not moved by GC for callouts),
sandboxing, Classes with UUIDs to allow for side by side loading/migration
and an extensible meta-scheme as this is where Smalltalk is still the hero of all
und metaprogramming will be our future.

Also the VM should be available as a shared component - so it can run in-process
in other programs like a web browser. Always wished to write:

   <script type="text/tinyscript">
         BrowserLog write: 'HelloWorld'.
   </script>

directly in HTML.

And this is only the beginning of the wish list...

>Yep.  But personally I think Fuel is better and just as fast.  Certainly that's the parcels experience.
>  - but still with the ability to bootstrap up to a full saveable image

Yes, Fuel would be an option. At least it would be platform independent. Not sure
about other options (quick loading by mapping component using memory mapped files etc.)

>This we'll leave to the web framework designers, but it seems eminently doable no?

For sure.

Bye
Torsten