On 9/1/16, tim Rowledge <tim at rowledge.org> wrote:
> I suspect that like a lot of us I’m conflicted about having something large
> like EToys included.
>
> In one sense it’s an important project that needs to be constantly kept up
> to date and that is best done by having it always there so that anyone
> refactoring code can’t help but find the EToys code that needs to be
> updated. Of course, that’s the same argument one might make for Scratch,

Maybe Scratch could be included  as well temporarily to benefit from
the same refactoring treatment .......

> Magma, all the games, VMMaker and so on.
>
> On the other hand, it ’s obviously ridiculous to have all this stuff in a
> basic development image and anyone would mad to include so much waste of
> space nonsense.
>
> So obviously what we really need is a better system for dealing with this. I
> don’t know what that might be. The 'least unlikely to screw us’ approach
> would seem to be having a lot of this in the general development image and
> make sure it is kept properly unload-able (autocorrect tried to make that
> ‘unlovable’ which seems oddly appropriate) for any deployment usage (like
> for example Scratch and indeed EToys).
>
> A more complicated idea (and we all love complex cool tools, right?) might
> be an extension of Chris’ history database that includes all the code of all
> the packages (hey, slurp in all of squeaksource and so on! Stress Magma!)
> and when changing code in your image it checks also in the Great Database Of
> All Things. Must be a PhD or two in that , surely?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Maybe Computer Science should be in the College of Theology
>
>
>
>