2009/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Thu, Jul 2, 2009 at 1:43 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 2009/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> >
>> > On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <johnson at cs.uiuc.edu>
>> > wrote:
>> >>
>> >> The tendency to fork is a product of all Smalltalks, not just Squeak.
>> >
>> > as others have observed in the current spate of discussion the need to
>> > fork
>> > can be minimised or avoided altogether by providing a small kernel image
>> > that can load packages, and getting into the habit of writing one's
>> > application as a set of packages and regularly building them up into an
>> > image (nightly, weekly) starting from the kernel.
>> > This approach also allows the VM and image representation to evolve (and
>> > even fork!) because the kernel is amenable to transformation.  So one
>> > can
>> > create different forms of the kernel image with exactly the same
>> > apparent
>> > image contents, but with object representations adapted for specific
>> > uses,
>> > such as an extremely compact representation for embedded applications
>> > and a
>> > simple one for performance and normal development, and one can have
>> > purely
>> > interpreted VMs for hostile or memory-limited machines (iPhone does not
>> > allow one to enable execution permission on mmap'ed memory) and JITs
>> > for performance and normal development.
>> > IMO it is also easier building up a kernel than carving it out of a
>> > monolithic image to architect the necessary modularity support to allow
>> > packages to be loaded that make major transformations such as adding a
>> > GUI
>> > and replacing a standard i/o stack dump with an interactive debugger.
>> > I hope that if such a beast becomes available that the community will
>> > make
>> > the effort to port to it, which involves packaging their code, and we
>> > can
>> > branch to our heart's content because images will be constructed not
>> > constricting.
>>
>> Yes, and all Squeak forks could use such kernel as a base, except
>> those who making own changes to VM.
>
> I'm actually working on a kernel image _so_ I can make changes to the base
> VM.  If the kernel is expressed first as source from which an image is
> generated then one can create a different image format from that source.  So
> my route to a faster object format, and to a fast 64-bit format, is through
> the kernel.  So I disagree.  I think the kernel can also be used by those
> working on their own VMs, and it can be much easier than using e.g. a
> SystemTracer-based approach.
>

Ageed.
Except cases, like changing the core primitives (don't ask me why one
would do that),
and other basic VM<->image interfaces.
This is actually what i had in mind , saying about 'own changes to VM'.

>>
>> This is another reason for having a package-based development model.
>> I remember we have discussed this before, but this idea & especially
>> benefits which it could bring to us,
>> were leaked from my mind :)
>>
>> P.S. can't resist CC-ing this to Pharo list.  :)
>>
>> >>
>> >> There is a company in town that developed a commercial product on
>> >> VisualWorks 2.0.   They customized it heavily.  It is a sound
>> >> generater, in fact the world's fastest synthesizer in which you can
>> >> specify each waveform.  It is used by musicians and for sound effects
>> >> in movies.  All the programming is done by two people.  It provide a
>> >> very nice UI in which you drag and drop sound objects to create your
>> >> piece.  When you say "play", the sound objects are converted into code
>> >> for an array of DSPs, which execute the code to play the sounds.  The
>> >> process is nearly instantaneous.
>> >>
>> >> This company made a fork over ten years ago, and last I heard, had not
>> >> caught up.  They would like to run their software on Unix.  It only
>> >> runs on PC and Macs, and I think they have hacked the VM themselves to
>> >> run on newer OSs.  The binary, that is.  But it was just too much
>> >> trouble to convert their image, and didn't seem like it provided
>> >> enough benefits.
>> >>
>> >> There are still a lot of companies running VSE applications in spite
>> >> of the fact that it hasn't been supported for a decade.
>> >>
>> >> One of the great things about Smalltalk is that it is so open.  You
>> >> can change everything about it; the way the compiler works, the UI,
>> >> the programming environment tools, what it means to send a message to
>> >> an object that is not understood.  You can change arrays, strings,
>> >> booleans.  Of course, if you do this then you are not longer
>> >> compatible.  If you hack Behavior and ClassDescription then the odds
>> >> are that your hacks will not be compatible with other people's hacks.
>> >> Every time a new version of the platform comes out, you'll have to go
>> >> back and make sure none of your hacks are broken.  Often they will be.
>> >>
>> >> Sometimes it is worth the pain.  But often people just fork.  They
>> >> will lose all the nifty new features that come out, but it just isn't
>> >> worth the trouble to keep up.
>> >>
>> >> I think the reason there is so much forking with Smalltalk is that
>> >> application programmers don't have to depend on vendors.  They can
>> >> craft the environment to suit their own needs, and don't need to
>> >> depend on someone who doesn't really understand their needs.  There
>> >> are disadvantages to forking, but it is easy and there are enough
>> >> advantages that people will continue to do it.
>> >>
>> >> So, we need to learn to live in a world of forks.  Seaside shows how
>> >> it can be done.  Squeak and VisualWorks, after all, are different
>> >> forks from the original Xerox Smalltalk-80.
>> >>
>> >> -Ralph Johnson
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.