<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 1, 2016 at 9:41 AM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/1/16, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
> I suspect that like a lot of us I’m conflicted about having something large<br>
> like EToys included.<br>
><br>
> In one sense it’s an important project that needs to be constantly kept up<br>
> to date and that is best done by having it always there so that anyone<br>
> refactoring code can’t help but find the EToys code that needs to be<br>
> updated. Of course, that’s the same argument one might make for Scratch,<br>
<br>
</span>Maybe Scratch could be included as well temporarily to benefit from<br>
the same refactoring treatment .......<br></blockquote><div><br></div><div>Agreed. Pharo experience shows how many packages get pout of date by not being included in everyday development. I think it would be nice if we can have a build process where we have a fat trunk (seems appropriate) but unload inessentials when prod ing the all-in-one. I'd happily carry some overhead doing trunk development provided unloading is easy and the all-in-one development artefact is readily available.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">> Magma, all the games, VMMaker and so on.<br>
><br>
> On the other hand, it ’s obviously ridiculous to have all this stuff in a<br>
> basic development image and anyone would mad to include so much waste of<br>
> space nonsense.<br>
><br>
> So obviously what we really need is a better system for dealing with this. I<br>
> don’t know what that might be. The 'least unlikely to screw us’ approach<br>
> would seem to be having a lot of this in the general development image and<br>
> make sure it is kept properly unload-able (autocorrect tried to make that<br>
> ‘unlovable’ which seems oddly appropriate) for any deployment usage (like<br>
> for example Scratch and indeed EToys).<br>
><br>
> A more complicated idea (and we all love complex cool tools, right?) might<br>
> be an extension of Chris’ history database that includes all the code of all<br>
> the packages (hey, slurp in all of squeaksource and so on! Stress Magma!)<br>
> and when changing code in your image it checks also in the Great Database Of<br>
> All Things. Must be a PhD or two in that , surely?<br>
><br>
> tim<br>
> --<br>
> tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
> Maybe Computer Science should be in the College of Theology<br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>