Hi Igor,<br><br><div class="gmail_quote">On Thu, Jul 2, 2009 at 1:26 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;">
<div><div></div><div class="h5">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>> 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 Squeak.<br>
>> ><br>
>> > as others have observed in the current spate of discussion the need to<br>
>> > fork<br>
>> > can be minimised or avoided altogether by providing a small kernel 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 an<br>
>> > image (nightly, weekly) starting from the kernel.<br>
>> > This approach also allows the VM and image representation to evolve (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 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 allow<br>
>> > packages to be loaded that make major transformations such as adding 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 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. So<br>
> my route to a faster object format, and to a fast 64-bit format, is through<br>
> the kernel. So I disagree. I think the kernel can also be used by 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>
</div></div>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'.</blockquote><div><br></div><div>OK, so let me expand a little and I think you'll see that there aren't many exceptional cases.</div>
<div>This is all being derived from John Maloney's MicroSqueak, but my kernel image will be much more of a MilliSqueak, because it'll include the compiler, a command-line interface, etc. i.e. it'll resemble Gnu Smalltalk.</div>
<div><br></div><div>In the image is a "shadow" class hierarchy rooted in MObject or MProtoObject. This code can be in the bytecode set of the host system or not. If not, you can't run it directly but instead have to interpret it with a special version of ContextPart. This interpreter can allow one to test the code before producing a kernel; image form it, and the interpreter can allow one to test new system primitives etc. </div>
<div><br></div><div>An additional tool (the MilliSqueak image builder) reads this class hierarchy and constructs an image in whatever format one defines. It renames all the MFoo classes on generating the image so that in the new image they're called Object, ProtoObject et al, and fixes up any special methods such as compilerClass that have to be hacked to work as one desires in the host system.</div>
<div><br></div><div>If one wants e.g. to be able to run MCompiler to produce methods in a bytecode set then there are a couple of ways to approach it. One way is for MBehavior to effectively provide two method dictionaries, one holding methods in the host system's bytecode set, one in the new system's. One wouldn't need to store the extra methodDictionary in the MBehavior instances, instead it would be some global dictionary maintained by the MilliSqueak building/maintennance code, and the MilliSqueak image builder would substitute the new methodDictionary for the old when producing an image. The compilerClass method would be special. It would invoke a compiler that compiled two versions, one using MCompiler, and one using Compiler, to populate the two dictionaries. The image builder would fixup the compilerClass method when producing the image. Another way is simply to have two copies of MCompiler, one the MCompiler from which the kernel image with be generated, and one, say, HostMCompiler, and just keep the two in sync. HostMCompiler's methods are in the host format but it generates methods in the new format. MBehavior compilerClass answers HostMCompiler, but the image generator fixes this up.</div>
<div><br></div><div>An additional VMMaker package allows one to develop a new VM for that format, and at least check if it starts up. The VM simulator could actually provide i/o if the image is headless. It would be easy to write a little console for the VM simulator to do i/o with the simulated headless image. Then the new VM would be the means by which one executed the new bytecode and primitive set.</div>
<div><br></div><div>This is all half-baked but you get the idea. There's lots of ways to pull this off. And I'm sure there are some tricky bits here (e.g. making senders/implementors work in the host on the new format methods). But the idea of having a source tree for the image one wants is a good one, and it means that the kernel image is produced from source, not by transformation of some existing image. One can choose precisely the base class library, the bytecode set, etc and one can test it in image using either the VM simulator and/or by constructing a special Context interpreter.</div>
<div><br></div><div>If one uses a special Context interpreter, which one needs to develop anyway if one is developing a new bytecode set because in the new kernel InstructionStream et al must interpret the new bytecode instruction set, then it also needs either the two dictionary or the duplication approach. I haven't decided which is best yet.</div>
<div><br></div><div><br></div><div>If this scheme can be made to work I think one will be able to experiment to ones heart's content and have considerable freedom experimenting with different kernel images, for example ones that implement a novel namespace scheme, or a new language, or simply a well-defined ANSI subset, or a format making good use of 64-bits, or...</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;"><div><div class="h5">>><br>
>> This is another reason for having a package-based development model.<br>
>> I remember we have discussed this before, but this idea & especially<br>
>> benefits which it could bring to us,<br>
>> were leaked from my mind :)<br>
>><br>
>> P.S. can't resist CC-ing this to Pharo list. :)<br>
>><br>
>> >><br>
>> >> There is a company in town that developed a commercial product on<br>
>> >> VisualWorks 2.0. They customized it heavily. It is a sound<br>
>> >> generater, in fact the world's fastest synthesizer in which you can<br>
>> >> specify each waveform. It is used by musicians and for sound effects<br>
>> >> in movies. All the programming is done by two people. It provide a<br>
>> >> very nice UI in which you drag and drop sound objects to create your<br>
>> >> piece. When you say "play", the sound objects are converted into code<br>
>> >> for an array of DSPs, which execute the code to play the sounds. The<br>
>> >> process is nearly instantaneous.<br>
>> >><br>
>> >> This company made a fork over ten years ago, and last I heard, had not<br>
>> >> caught up. They would like to run their software on Unix. It only<br>
>> >> runs on PC and Macs, and I think they have hacked the VM themselves to<br>
>> >> run on newer OSs. The binary, that is. But it was just too much<br>
>> >> trouble to convert their image, and didn't seem like it provided<br>
>> >> enough benefits.<br>
>> >><br>
>> >> There are still a lot of companies running VSE applications in spite<br>
>> >> of the fact that it hasn't been supported for a decade.<br>
>> >><br>
>> >> One of the great things about Smalltalk is that it is so open. You<br>
>> >> can change everything about it; the way the compiler works, the UI,<br>
>> >> the programming environment tools, what it means to send a message to<br>
>> >> an object that is not understood. You can change arrays, strings,<br>
>> >> booleans. Of course, if you do this then you are not longer<br>
>> >> compatible. If you hack Behavior and ClassDescription then the odds<br>
>> >> are that your hacks will not be compatible with other people's hacks.<br>
>> >> Every time a new version of the platform comes out, you'll have to go<br>
>> >> back and make sure none of your hacks are broken. Often they will be.<br>
>> >><br>
>> >> Sometimes it is worth the pain. But often people just fork. They<br>
>> >> will lose all the nifty new features that come out, but it just isn't<br>
>> >> worth the trouble to keep up.<br>
>> >><br>
>> >> I think the reason there is so much forking with Smalltalk is that<br>
>> >> application programmers don't have to depend on vendors. They can<br>
>> >> craft the environment to suit their own needs, and don't need to<br>
>> >> depend on someone who doesn't really understand their needs. There<br>
>> >> are disadvantages to forking, but it is easy and there are enough<br>
>> >> advantages that people will continue to do it.<br>
>> >><br>
>> >> So, we need to learn to live in a world of forks. Seaside shows how<br>
>> >> it can be done. Squeak and VisualWorks, after all, are different<br>
>> >> forks from the original Xerox Smalltalk-80.<br>
>> >><br>
>> >> -Ralph Johnson<br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best regards,<br>
>> Igor Stasenko AKA sig.<br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>