[squeak-dev] Burn the Squeak Image! (Why I am running for board)

I was trying to guide the discussion back to Matthews proposal which I agree with. I'm not suggesting they should adopt any image.

You misunderstand, I was agreeing with you, the comment about what was absurd wasn't in reply to you but to the previous suggestion that all these different forks could be convinced to come back to a core image; just isn't going to happen.
 

I think getting the various communities to buy in and commit to a vision of shared core packages should be the responsibility of the board. It should be in each communities interest to work on such an activity. This is where the real work will need to be done.

Again, I was agreeing with that position.

Andreas is the only person I've seen proposing anything at all pragmatic for the board to do.  SNIP

What isn't pragmatic about Matthew's proposal? I don't think he suggests  that the board does this themselves - maybe I misunderstood.

I like his proposal, that doesn't make it pragmatic, at least, not as pragmatic as what Andreas is always saying, harvest what's done, rather than making big plans for doing stuff that the past has shown rarely works out.

One of Squeaks big problems, IMHO, is that every version is planned and realised by someone grand idea of features that should be in the next version.  More often than not, this is vaporware, work someone wants to do, or thinks can be done, but isn't done, so everyone waits and waits and waits for a new version.

I'd much rather see releases done by specific dates, like a release every 6 months, each release harvesting the latest fixes and patches of accomplished work.  Make it easier to get new stuff integrated into the core by releasing regularly and often rather than these pie in the sky visions of what might be.  Guaranteed steady gradual evolution and continual progress beats the hell out of revolutionary grand changes that might or might not actually happen.
 

I don't think the board should be following and picking. I don't think that works. The sub communities should be playing an active role in this and I think it should be the boards responsibility to:

 - Convince each community that it's worth doing
 - Find out and agree what needs to be done
 - Enable each community to work
     - Remove barriers
     - Define processes
     - Resources: tools, email lists, servers, etc
 - Manage the overall progress and lend support where necessary

- Zulq

Which is what they've been doing, it's not been working so well.  The Squeak community wouldn't be splintered into so many fragments otherwise.  The Pharo guys forked because it's the only way to get anything done, it takes too long to try and get anything real done in the core Squeak, progress is glacial, so everyone forks.

Keith and Matthew are right, focus on packages and tools for sharing code, Andreas is right, focus on what's done, integrate it, make progress, stop the pie in the sky dreams of the ultimate system, or core kernel image, or whatever other pipe dream people keep chasing that clearly isn't being used by all the sub communities anyway. 

I don't care what image I use, I care what packages I use.  I care that my Collections package is the latest and greatest, or that my Seaside package is up to date, or that I'm using the newest FFI, or the right Polymorph.  I don't care about eToys or Graphics or 3D or anything to do with educating kids.  Packages are more important than images.  The only thing I want from an image is that it isn't bloated with a bunch of unloadable code like eToys that infects everything and breaks everything when you try and remove it.

Elliot is right about building images from scripts as well, I want to automate the builds of the images I use with a script to load onto a base image just the packages I want.  Damien does this now with his dev images, a good starting point for me, then I use a script and Keiths installer to further load and customize it to my liking.

Anyway, now I'm just rambling, so I'll leave it at that.  +1 for tools, Packages, and integrate what's done and get it out.

Ramon Leon
http://onsmalltalk.com

I'm not sure that's true.  Say it becomes yet another fork, separate
(necessarily, at first, because it's a different image format) from
all of the other forks.  As long as most packages can be loaded into
it, it'll get used.  Maybe not by the people doing the forking (by
Scratch, say, or Squeakland), but by the majority of us who have a few
pet packages (in my case, Seaside, OmniBrowser, DabbleDB, etc) that we
can load into nearly any Squeak image and feel at home.  I'm pretty
happy to load those into a MinimalMorphic image this month, a Pharo
image next month, and a Cog image the month after, if there's some
compelling reason to do so - and 10x performance would certainly be
compelling.

A shared microkernel would be nice, but I don't think it's essential
in the short term to drive adoption of a new technology.

Eliot Miranda a écrit :

I need to point out that unless the various communities can start building
their disparate and diverging images form a micro-kernel image I don't see
how improved execution technology is going to be adopted by the community.
 I'm working hard on a VM that will be potentially 10x the current Squeak VM
for Smalltalk intensive benchmarks.  This VM will be source code compatible
and bytecode compatible but likely it will not be image compatible as it
will use a streamlined object representation that doesn't use compact
classes.  The only way I can see this being adopted by the community at
large is if the community starts building images form microkernels.

maybe a silly question (I have no idea of what is involved): would converting an image from the current format to the one your VM will require be an option ?

Stef

2009/3/1 Andreas Raab <[hidden email]>:

> Igor Stasenko wrote:
>>
>> Changing the object formats alone does not gives any benefits. What is
>> the point in having new format when you keep using old semantic model
>> as before?
>
> Speed. That is the only point of the exercise to begin with.
>
>> This is like swapping instance variables order in your class.. Apart
>> from a better aestetical view it gives you nothing :)
>
> If swapping ivars in a class would give me a 3x in performance I'd be doing
> this all day long...
>

but we both know that this is too good to be true.  :)
unless you change the way how things working, you can't achieve
significant performance boost. And often this means rewriting
interfaces, which inevitably leads to changing a lot of code on
language side etc.

> Cheers,
>  - Andreas

>
--
Best regards,
Igor Stasenko AKA sig.