[etoys-dev] binary loading (was: FreeCell: Etoys interaction with Journal via DBus on Sugar (OLPC))

Hilaire Fernandes hilaire at ofset.org
Fri Jul 31 13:06:16 EDT 2009


I am interested by binary loading. It can help to attract more
developer as it makes life more efficient for those like me willing to
write/extend etoys with additional application like Dr Geo[1]  without
the need to fork

Hilaire

[1] http://wiki.laptop.org/go/DrGeo

2009/7/30 Jecel Assumpcao Jr <jecel at merlintec.com>:
> Andreas Raab wrote:
>> Bert Freudenberg wrote:
>> > Basically we want to deploy a Squeak application, without shipping a
>> > custom image. I think that's a new problem, typically Smalltalk apps
>> > ship as customized images.
>>
>> Funny you should mention that. This is something I am actually working
>> on in my spare time. I do have the outline for a Squeak application
>> bundle that stores binary representations of code (so that the image
>> does not require a Compiler; in fact I want to be able to use that to
>> load one ;-) and optionally, source code. It's nicely small and fast so
>> far (the entirety of Morphic goes into 700k and takes less than a second
>> to load) but the work's only just started so there is a long ways to go
>> here. If someone is seriously interesting in this direction, drop me a note.
>
> This is my number one priority for the second half of 2009. I won't be
> able to start working on it until late August or September, but have a
> very brief explanation at http://wiki.squeak.org/squeak/5637
>
> Earlier this year I had proposed a much simpler version of this
> (http://wiki.squeak.org/squeak/584) which wouldn't have the complicated
> "swizzling" on load and save nor the multiple viewpoints and new
> concurrency model. The focus was exactly on fast binary loading and what
> I thought I could get the Squeak community to agree with as a next step.
>
> Since I was unable to get any interest in the "Squeak friendly"
> proposal, I decided I might as well go with the more radical design
> instead. This will involve a significant rewrite of ObjectMemory with an
> organization using segments (like Self) and fragmented object tables
> (like "handles" in early Mac software) which I hope will be equally
> useful for small and large (64 bit) memories.
>
> -- Jecel
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>



-- 
http://blog.ofset.org/hilaire


More information about the etoys-dev mailing list