[squeak-dev] Forks, forks, forks

Eliot Miranda eliot.miranda at gmail.com
Thu Jul 2 16:09:09 UTC 2009


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.


>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090702/16345c8d/attachment.htm


More information about the Squeak-dev mailing list