<br><br><div class="gmail_quote">On Thu, Jul 2, 2009 at 4:29 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/7/3 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi Igor,<br>
><br>
> On Thu, Jul 2, 2009 at 1:26 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>> 2009/7/2 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>> ><br>
>> ><br>
>> > On Thu, Jul 2, 2009 at 1:43 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 2009/7/2 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <<a href="mailto:johnson@cs.uiuc.edu">johnson@cs.uiuc.edu</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> The tendency to fork is a product of all Smalltalks, not just<br>
>> >> >> Squeak.<br>
>> >> ><br>
>> >> > as others have observed in the current spate of discussion the need<br>
>> >> > to<br>
>> >> > fork<br>
>> >> > can be minimised or avoided altogether by providing a small kernel<br>
>> >> > image<br>
>> >> > that can load packages, and getting into the habit of writing one's<br>
>> >> > application as a set of packages and regularly building them up into<br>
>> >> > an<br>
>> >> > image (nightly, weekly) starting from the kernel.<br>
>> >> > This approach also allows the VM and image representation to evolve<br>
>> >> > (and<br>
>> >> > even fork!) because the kernel is amenable to transformation. So one<br>
>> >> > can<br>
>> >> > create different forms of the kernel image with exactly the same<br>
>> >> > apparent<br>
>> >> > image contents, but with object representations adapted for specific<br>
>> >> > uses,<br>
>> >> > such as an extremely compact representation for embedded applications<br>
>> >> > and a<br>
>> >> > simple one for performance and normal development, and one can have<br>
>> >> > purely<br>
>> >> > interpreted VMs for hostile or memory-limited machines (iPhone does<br>
>> >> > not<br>
>> >> > allow one to enable execution permission on mmap'ed memory) and JITs<br>
>> >> > for performance and normal development.<br>
>> >> > IMO it is also easier building up a kernel than carving it out of a<br>
>> >> > monolithic image to architect the necessary modularity support to<br>
>> >> > allow<br>
>> >> > packages to be loaded that make major transformations such as adding<br>
>> >> > a<br>
>> >> > GUI<br>
>> >> > and replacing a standard i/o stack dump with an interactive debugger.<br>
>> >> > I hope that if such a beast becomes available that the community will<br>
>> >> > make<br>
>> >> > the effort to port to it, which involves packaging their code, and we<br>
>> >> > can<br>
>> >> > branch to our heart's content because images will be constructed not<br>
>> >> > constricting.<br>
>> >><br>
>> >> Yes, and all Squeak forks could use such kernel as a base, except<br>
>> >> those who making own changes to VM.<br>
>> ><br>
>> > I'm actually working on a kernel image _so_ I can make changes to the<br>
>> > base<br>
>> > VM. If the kernel is expressed first as source from which an image is<br>
>> > generated then one can create a different image format from that source.<br>
>> > So<br>
>> > my route to a faster object format, and to a fast 64-bit format, is<br>
>> > through<br>
>> > the kernel. So I disagree. I think the kernel can also be used by<br>
>> > those<br>
>> > working on their own VMs, and it can be much easier than using e.g. a<br>
>> > SystemTracer-based approach.<br>
>> ><br>
>><br>
>> Ageed.<br>
>> Except cases, like changing the core primitives (don't ask me why one<br>
>> would do that),<br>
>> and other basic VM<->image interfaces.<br>
>> This is actually what i had in mind , saying about 'own changes to VM'.<br>
><br>
> OK, so let me expand a little and I think you'll see that there aren't many<br>
> exceptional cases.<br>
> This is all being derived from John Maloney's MicroSqueak, but my kernel<br>
> image will be much more of a MilliSqueak, because it'll include the<br>
> compiler, a command-line interface, etc. i.e. it'll resemble Gnu Smalltalk.<br>
> In the image is a "shadow" class hierarchy rooted in MObject or<br>
> MProtoObject. This code can be in the bytecode set of the host system or<br>
> not. If not, you can't run it directly but instead have to interpret it<br>
> with a special version of ContextPart. This interpreter can allow one to<br>
> test the code before producing a kernel; image form it, and the interpreter<br>
> can allow one to test new system primitives etc.<br>
<br>
</div></div>Exactly! I know exactly what you are talking about.<br>
Because i doing so in Moebuis. This is good way (keeping a core class<br>
hierarchy as a source in image)<br>
- enables you to use common smalltalk tools (browser & friends) to develop it.<br>
And of course, enables to maintain it as a package.<br>
<br>
The one, huge, difference between us in this regard, that i'm using a<br>
'CV' prefix, not 'M' :)</blockquote><div><br></div><div>:) :) What does CV stand for?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> An additional tool (the MilliSqueak image builder) reads this class<br>
> hierarchy and constructs an image in whatever format one defines. It<br>
> renames all the MFoo classes on generating the image so that in the new<br>
> image they're called Object, ProtoObject et al, and fixes up any special<br>
> methods such as compilerClass that have to be hacked to work as one desires<br>
> in the host system.<br>
<br>
</div>Right, and again, i have envision nearly the same things. :)<br>
<div class="im"><br>
> If one wants e.g. to be able to run MCompiler to produce methods in a<br>
> bytecode set then there are a couple of ways to approach it. One way is for<br>
> MBehavior to effectively provide two method dictionaries, one holding<br>
> methods in the host system's bytecode set, one in the new system's. One<br>
> wouldn't need to store the extra methodDictionary in the MBehavior<br>
> instances, instead it would be some global dictionary maintained by the<br>
> MilliSqueak building/maintennance code, and the MilliSqueak image builder<br>
> would substitute the new methodDictionary for the old when producing an<br>
> image. The compilerClass method would be special. It would invoke a<br>
> compiler that compiled two versions, one using MCompiler, and one using<br>
> Compiler, to populate the two dictionaries. The image builder would fixup<br>
> the compilerClass method when producing the image. Another way is simply to<br>
> have two copies of MCompiler, one the MCompiler from which the kernel image<br>
> with be generated, and one, say, HostMCompiler, and just keep the two in<br>
> sync. HostMCompiler's methods are in the host format but it generates<br>
> methods in the new format. MBehavior compilerClass answers HostMCompiler,<br>
> but the image generator fixes this up.<br>
<br>
</div>Nearly the same what i did. Yes there should be two compilers - one<br>
serves for host platform, as usual, while other is for producing new<br>
code & methods in different format. ( Btw i looking & developing<br>
towards a unified compiler model, which could serve for both<br>
environments, and depending on providing it a different 'environment'<br>
object - it could produce methods for one or another environment,<br>
without much hassle). I'd call it: a compiler module :)<br>
<br>
In order to minimize the coding which glueing the stuff (like things<br>
you describing - compilerClass, host format & other),<br>
a format of objects in a newly generated memory is extracted from<br>
behavior of special classes, which i called Species.<br>
So, by gathering stuff together:<br>
- class hierarchy<br>
- modular compiler<br>
- environment (aka 'image builder')<br>
- species<br>
<br>
you are know everything about object formats and can work<br>
transparently in both domains (host/target), because the code i put in<br>
Species is made ultimately invariant to environment it runs in, and<br>
depends only on arguments which you passing to them.<br>
<br>
In this way, i implemented things like #ivarAt: , #ivarAt:put: ,<br>
#header , and rest such stuff in species using functional(stateless)<br>
way - so all what you doing is compiling (and in case of VMMaker -<br>
translating) this code to VM , and voila , you have your own object<br>
format.<br>
<div class="im"><br>
> An additional VMMaker package allows one to develop a new VM for that<br>
> format, and at least check if it starts up. The VM simulator could actually<br>
> provide i/o if the image is headless. It would be easy to write a little<br>
> console for the VM simulator to do i/o with the simulated headless image.<br>
> Then the new VM would be the means by which one executed the new bytecode<br>
> and primitive set.<br>
> This is all half-baked but you get the idea. There's lots of ways to pull<br>
> this off. And I'm sure there are some tricky bits here (e.g. making<br>
> senders/implementors work in the host on the new format methods). But the<br>
> idea of having a source tree for the image one wants is a good one, and it<br>
> means that the kernel image is produced from source, not by transformation<br>
> of some existing image. One can choose precisely the base class library,<br>
> the bytecode set, etc and one can test it in image using either the VM<br>
> simulator and/or by constructing a special Context interpreter.<br>
> If one uses a special Context interpreter, which one needs to develop anyway<br>
> if one is developing a new bytecode set because in the new kernel<br>
> InstructionStream et al must interpret the new bytecode instruction set,<br>
> then it also needs either the two dictionary or the duplication approach. I<br>
> haven't decided which is best yet.<br>
><br>
> If this scheme can be made to work I think one will be able to experiment to<br>
> ones heart's content and have considerable freedom experimenting with<br>
> different kernel images, for example ones that implement a novel namespace<br>
> scheme, or a new language, or simply a well-defined ANSI subset, or a format<br>
> making good use of 64-bits, or...<br>
><br>
<br>
</div>Eliot, just say, if you wish any help on that. I see we have a lot of<br>
synergy about an idea, how things should be made.<br>
So, i'd like to offer my help to make this bright future a bit closer :)</blockquote><div><br></div><div>We should definitely work together. At the least we should exchange code. I have yet to commit mine/John's to any shared repository. I'm busy preparing an open source release of the Stack VM and then will be doing some FFI work so the MilliSqueak work will be in te background. But once I've got the STack VM ready I'll at least take some time to commit the code. </div>
<div><br></div><div>Great!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
>> >><br>
<br>
[snip]<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="h5">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>