Hi Torsten,
wow, what a great summary. Thanks. See below.
On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann astares@gmx.de wrote:
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.
+1000.
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.
So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reitierating this more abstractly?
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...
Please, I'd love to have you write a fuller list. We could add it to the list at Cog Projects http://www.mirandabanda.org/cogblog/cog-projects/ or add it to a "Directions" page or some such. But capturing these ideas is importasnt.
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.)
Well, mapping finished images a la VW's PermSpace is probably easier. The memory mapping in .Nt is extremely complex. But I get the requirement; ultra-fast start-up of small components.
This we'll leave to the web framework designers, but it seems eminently
doable no?
For sure.
Bye Torsten
thanks again. And give serious thought to carefully enunciating these requirements/this design sketch?
Hi Eliot!
Torsten writes:
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 and metaprogramming will be our future.
You respond:
So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reiterating this more abstractly?
Right, there's no need for anyone to use UUIDs when referring to classes in Smalltalk expressions. We can keep using class names as we always have. Instead, we can do the following:
- Add an ID field to each class.
- Make each class responsible for its own name literal. The "name" field of each class would hold the method literal used by methods that refer to that class, rather than just a name key into the traditional system dictionary.
This allows each class to have any name. When a developer attempts to compile source that refers to a particular class name, the system can present a list of all the classes with that name from which to choose. To aid in the decision, the system can present additional information, such as author, release date, module membership, etc. When displaying method source after compilation, the system can emphasize class names which correspond to multiple classes, and provide quick means for getting at that additional information.
We could keep that information in a live memory of objects describing edits made to the system, with which we can interact via remote messaging. Let's call it a history memory. Like the traditional changes/sources system, it could record the history of our development activity, but with all the reflective power of an object system for answering our queries (and synchronizing with other systems on our behalf).
This history memory could supplant the traditional system dictionary and changes/sources files. The key to making this practical is having a minimal object memory and a module system with which to grow it.
I've done all this. Will you collaborate with me?
thanks!
-C
[1] http://thiscontext.com/a-detailed-naiad-description
(I'm currently working on a GitHub-based installer. It interacts with GitHub's web services API, reminiscent of the WebDAV support I wrote for interacting with the live system from Your Favorite Text Editor.)
-- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
vm-dev@lists.squeakfoundation.org