<div dir="ltr">Hi Torsten,<div><br></div><div>    wow, what a great summary.  Thanks.  See below.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <span dir="ltr">&lt;<a href="mailto:astares@gmx.de" target="_blank">astares@gmx.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Eliot wrote:<br>
&gt;We&#39;re getting there with fast.  Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI &gt;code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is &gt;453k, 386k code, 68k data.  That includes the interpreter, JIT, core primitives and memory manager/GC. Add on &gt;several k for the FFI, C library et al and a VM in a megabyte is realistic.  Is that in the right ball park?<br>
<br>
</span>Yes, wet&#39;s my appetite :)<br>
<br>
Tiny means easy to download and use for scripting, no other dependencies<br>
for the out of the box REPL experience. But still powerfull to built one on another<br>
and scale up to large programs.<br>
<br>
Initially you provide just a simple VM executable for a &quot;tiny smalltalk&quot; (ts), for simple<br>
things like:<br>
<br>
   c:\myscripts\ts.exe -e 3+4<br>
   7<br>
<br>
where ts.exe is the VM in a few kB including a small initial kernel image (as part of<br>
the PE DATA section). It should be able to run scripts:<br>
<br>
   c:\myscripst\ts.exe <a href="http://automate.st" target="_blank">automate.st</a><br>
<br>
It should be possible to easily build components (either with or without the sources):<br>
<br>
   ts.exe <a href="http://sunit.st" target="_blank">sunit.st</a> -o sunit.sll<br>
   ts.exe <a href="http://sunit.st" target="_blank">sunit.st</a> -noSource -o sunit.sll<br>
<br>
So you can either include other scripts<br>
<br>
   ts.exe -i <a href="http://sunit.st" target="_blank">sunit.st</a>  <a href="http://mytests.st" target="_blank">mytests.st</a><br>
<br>
or link the previously built binary components to form something new.<br>
<br>
   ts.exe -l junit.sll <a href="http://mytests.st" target="_blank">mytests.st</a><br>
<br>
But it should be possible to build another vm+image easily:<br>
<br>
      ts.exe -i <a href="http://mykillerapp.st" target="_blank">mykillerapp.st</a>  -o killerapp.exe<br>
 or   ts.exe -l mykillerapp.sll -o killerapp.exe<br>
<br>
by writing a new PE file for Windows either including a new kernel image or a combined<br>
one based on the already built-in initial kernel of the previous one.<br>
So I can deploy a killerapp or reassemble it to form the next language version.<br>
<br>
SmallScript was very close to that and it was a nice thing to work with.<br>
Especially since usually Smalltalk usually throws things out at the end - but<br>
one never builds a house by carving it out of a rock. We need bricks to assemble.<br></blockquote><div><br></div><div>+1000.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With the above scheme you could build components, some of them portable, others<br>
explicitly non-portable as the code includes native calls. The later have to<br>
be rebuilt on the other platform - so if you have good design abstractions you<br>
can implement a UI lib on Windows and one on Mac.<br>
<br>
Some of the components are with the source code packaged in for debugging<br>
(but not changeable), for closed source components you leave it out.<br>
<br>
And still it should support pinnable objects (not moved by GC for callouts),<br>
sandboxing, Classes with UUIDs to allow for side by side loading/migration<br>
and an extensible meta-scheme as this is where Smalltalk is still the hero of all<br>
und metaprogramming will be our future.<br></blockquote><div><br></div><div>So so far I have pinning.  But I&#39;d love to hear more detail on sandboxing.  I&#39;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?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also the VM should be available as a shared component - so it can run in-process<br>
in other programs like a web browser. Always wished to write:<br>
<br>
   &lt;script type=&quot;text/tinyscript&quot;&gt;<br>
         BrowserLog write: &#39;HelloWorld&#39;.<br>
   &lt;/script&gt;<br>
<br>
directly in HTML.<br>
<br>
And this is only the beginning of the wish list...<br></blockquote><div><br></div><div>Please, I&#39;d love to have you write a fuller list.  We could add it to the list at <a href="http://www.mirandabanda.org/cogblog/cog-projects/">Cog Projects</a> or add it to a &quot;Directions&quot; page or some such.  But capturing these ideas is importasnt.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt;Yep.  But personally I think Fuel is better and just as fast.  Certainly that&#39;s the parcels experience.<br>
&gt;  - but still with the ability to bootstrap up to a full saveable image<br>
<br>
</span>Yes, Fuel would be an option. At least it would be platform independent. Not sure<br>
about other options (quick loading by mapping component using memory mapped files etc.)<br></blockquote><div><br></div><div>Well, mapping finished images a la VW&#39;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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt;This we&#39;ll leave to the web framework designers, but it seems eminently doable no?<br>
<br>
</span>For sure.<br>
<br>
Bye<br>
<span class="HOEnZb"><font color="#888888">Torsten<br></font></span></blockquote><div><br></div><div>thanks again.  And give serious thought to carefully enunciating these requirements/this design sketch? </div></div><br>-- <br>best,<div>Eliot</div>
</div></div>