[squeak-dev] My own Squeak direction

Juan Vuletich juan at jvuletich.org
Mon Nov 16 13:09:37 UTC 2009


Jecel Assumpcao Jr wrote:
> Juan Vuletich wrote:
>   
>> My own Squeak direction is described in 
>> http://www.jvuletich.org/Cuis/Index.html . As it seems to be 
>> incompatible with that of many in the community, it requires a fork.
>>
>> Aside from that, I fully support your direction, and I'll try to keep 
>> helping. Of course, I'd be delighted if at least some of my objectives 
>> were adopted for Squeak too.
>>     
>
> While it is good to avoid forking as much as possible, I always like to
> remind people that Squeak 3.8 was a merge of four forks (squeak.org 3.7,
> Squeakland, SmallLand and OpenCroquet) and that merges might also happen
> in the future. My own vision, described below, requires a radical
> rewrite of ObjectMemory and a significant patch of message sending in
> Interpreter. So this will probably require a fork as well (we shall see
> - I had hoped to be able to work on this starting in August, but now
> next January seems more likely).
>
> I would like for there to be a single, world-wide image for Squeak. This
> would be split up into many relatively small, immutable files for
> storage. A given machine probably wouldn't have access to the whole set
> of files at any one time. This image would support multiple simultaneous
> viewpoints such that if you have a pointer to an object and I have a
> pointer to the same object we might get different results when sending
> the exact same message. The viewpoints are managed mostly manually with
> a reasonable visual representation.
>   

I wonder what do you have in mind as typical uses for this 
functionality. While I applaud efforts on modernizing Smalltalk, I'm a 
bit reluctant of changes to the language semantics.

> Each node only loads into RAM as much of the global image as it needs to
> run its current code. Several nodes might collaborate by loading
> different parts of the image and sending messages to each other.
> Alternatively, several nodes might load the same parts of the image and
> keep in sync with the TeaTime scheme. Machines with 16 thousand
> SiliconSqueak cores are in the early planning stage, which gives you an
> idea of how far I think we can scale this.
>   

Wow! Experimenting with such a system would be fantastic!

> At the other extreme, a headless application running on a single core
> with only the barest parts of the image that it needs to support it
> should fit easily in just 128KB of memory. Other applications might have
> fancy multimedia features and I would like the option to have as much of
> this in Squeak so that bare hardware is a practical platform, even as
> Squeak makes better and better use of native features in other OSes. I
> would like SqueakNOS to be safer and more robust than current OSes.
>
> -- Jecel
>   


Great.

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list