[squeak-dev] Fork Proposal: Cuis & Killer Apps.
eliot.miranda at gmail.com
Mon Sep 12 20:18:52 UTC 2011
On Mon, Sep 12, 2011 at 9:27 AM, Ben Coman <btc at openinworld.com> wrote:
> Casey Ransberger wrote:
> On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <leves at elte.hu> wrote:
>> On Wed, 7 Sep 2011, Overcomer Man wrote:
>> I suggest a new fork or possibly a new orientation for the next Squeak
>> I guess we have too many forks already (compared to the number of active
> Adopt Cuis as the core image and focus on killer applications to attract
>>> Smalltalk users.
>> Cuis is nice, but lacks features that are important for those killer apps
>> (e.g. internationalization). Also throwing aways years of work (3.8, 3.9,
>> 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from
>> Cuis (and Pharo) instead.
>> To make the image smaller we should do two things (in parallel):
>> - craving (make packages unloadable, remove dependencies, split packages)
>> - building (use Spoon to rebuild the current image)
> Yes, we should merge the best things from Squeak into Cuis, We should
> merge the best things from Cuis into Squeak. Until all are one.
> WRT internationalization, though, I do feel that most end users don't
> need 20 languages they don't speak in the core system. Most users will want
> to use the system in a primary language. This stuff should all be available
> as rock-solid external packages. Not saying it isn't important, not saying
> that at all. If we hope to rebase Etoys on Squeak, internationalization is
>> To make this happen we have to start with writing tests, which "document"
>> the expected behavior of the system. So when we change it, we can be sure
>> that we didn't lose anything important.
> A living system needs a living specification, and the closest thing I
> know how to do to a living specification is a great suite of tests.
> Let's start by merging the tests.
> An interesting future scenario would be a shared test repository between
> the various forks of Squeak, with their respective continuous integration
> servers outputting results to a common database. Differences in "good
> results " between forks should be catered for, but would highlight
> differences in the "specification" of each fork, which might help it to
> converge over time while allowing the implementations to differ.
An excellent idea!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev