EToys in the Trunk
Locked
 
|
Hi All,
With the recent updates, we have the full EToys package in the Trunk, which has more than 78k LoC. That's almost 1.5x what Morphic has, and it's more than Kernel, System and Collections together. Do we want to keep it in the Trunk? Levente |
|
|
Hello Levente
I suggest yes, for the time being. Later on it should be made unload-able. --Hannes On 8/31/16, Levente Uzonyi <[hidden email]> wrote: > Hi All, > > With the recent updates, we have the full EToys package in the Trunk, > which has more than 78k LoC. That's almost 1.5x what Morphic has, and > it's more than Kernel, System and Collections together. > > Do we want to keep it in the Trunk? > > Levente > > |
|
|
I think Levente's question deserves more discussion.
What is the direction? What is the plan? |
|
|
The plan was to get this in early to have the instability now rather than later in the release cycle. My main interest was in getting the Squeakland Etoys version running, including all the new graphics, Kedama2, and the Sugar stuff. But I also merged (for now) most of the support code for Dbus, Pango, Siss, Connectors, BroomMorphs, Skeleton, ScratchConnect, Flash, Gstreamer, DrGeo, ... everything from the last Squeakland release I could get in. Since a lot of that stuff won't be needed anymore, my plan now is to fix bugs in the things I definitely would want to keep, and strip out those things that are obsolete. I expect the Etoys package size will be reduced again. Please allow us some time for this. We will do our best to make sure the rest of the system doesn't break while we're working on Etoys. Most of the time the only negative effect should be the large download and image sizes. Cheers, Chris Muller <[hidden email]> schrieb am Mi., 31. Aug. 2016, 23:53: I think Levente's question deserves more discussion. |
|
|
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, 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; [hidden email]; http://www.rowledge.org/tim Maybe Computer Science should be in the College of Theology |
|
In reply to this post by Levente Uzonyi
Hi Levente, the Etoys package has been in the Trunk for quite some time. We should keep around until we factored out the last bit of Etoys code from the base system into the Etoys package. Having it in the Trunk, simplifies this refactoring process a lot. In general, I am not a fan of "argument-by-LoC". :-) Those 78k LoC have their own package, so that's fine. Best, Marcel |
|
|
In reply to this post by timrowledge
On 9/1/16, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Maybe Computer Science should be in the College of Theology > > > > |
|
|
On Thu, Sep 1, 2016 at 9:41 AM, H. Hirzel <[hidden email]> wrote: On 9/1/16, tim Rowledge <[hidden email]> wrote: 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.
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by marcel.taeumel
On Thu, 1 Sep 2016, marcel.taeumel wrote:
> Levente Uzonyi wrote >> Hi All, >> >> With the recent updates, we have the full EToys package in the Trunk, >> which has more than 78k LoC. That's almost 1.5x what Morphic has, and >> it's more than Kernel, System and Collections together. >> >> Do we want to keep it in the Trunk? >> >> Levente > > Hi Levente, > > the Etoys package has been in the Trunk for quite some time. We should keep > around until we factored out the last bit of Etoys code from the base system > into the Etoys package. Having it in the Trunk, simplifies this refactoring > process a lot. > > In general, I am not a fan of "argument-by-LoC". :-) Those 78k LoC have > their own package, so that's fine. You seem to ignore the fact that the difference between what was in the Trunk and what is in there now is 50k LoC (comparable to Morphic). If I update my images, they'll grow significantly. If I were to do such a significant change, I'd at least let the community know about it beforehand. Levente > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/EToys-in-the-Trunk-tp4913502p4913540.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > |
|
|
> You seem to ignore the fact that the difference between what was in the
> Trunk and what is in there now is 50k LoC (comparable to Morphic). > > If I update my images, they'll grow significantly. > > If I were to do such a significant change, I'd at least let the community > know about it beforehand. +1. |
|
|
In reply to this post by timfelgentreff
> On 31-08-2016, at 3:33 PM, Tim Felgentreff <[hidden email]> wrote: > > ScratchConnect What? Why on earth didn’t anyone ever mention this to me? I mean, this has to be a good way to get Scratchers interested in eToys, right? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Totum dependeat. = Let it all hang out. |
|
|
In reply to this post by Hannes Hirzel
On Wed, Aug 31, 2016 at 11:28:06PM +0200, H. Hirzel wrote:
> > On 8/31/16, Levente Uzonyi <[hidden email]> wrote: > > Hi All, > > > > With the recent updates, we have the full EToys package in the Trunk, > > which has more than 78k LoC. That's almost 1.5x what Morphic has, and > > it's more than Kernel, System and Collections together. > > > > Do we want to keep it in the Trunk? > > > > Levente > > > > Hello Levente > > I suggest yes, for the time being. Later on it should be made unload-able. > > --Hannes I missed most of this discussion, but I would like to say that I think that Hannes has it exactly right. The work can and should be done in trunk, and it is important that the result should ultimately be unloadable and reloadable. The timing also seems right to me. The work is being done in trunk early in the release cycle. This should provide the opportunity to achieve a reloadable Etoys in time for a next Squeak release. As long as the package is fully reloadable, the decision as to whether to include Etoys in our next release can be made later, as part of the release planning process. Near term, the trunk image will be larger, but if we elect to unload Etoys for a next release then the resulting image should be smaller than before. I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk. Scratch is already being successfully developed as an external package compatible with trunk, which suggests that we should ultimately be able to do the same with Etoys. Others have mentioned that we need better tools to support this, and I agree. Dave |
|
|
> I missed most of this discussion, but I would like to say that I think
> that Hannes has it exactly right. The work can and should be done in trunk, > and it is important that the result should ultimately be unloadable and > reloadable. > > The timing also seems right to me. The work is being done in trunk early > in the release cycle. This should provide the opportunity to achieve a > reloadable Etoys in time for a next Squeak release. > > As long as the package is fully reloadable, the decision as to whether to > include Etoys in our next release can be made later, as part of the release > planning process. Near term, the trunk image will be larger, but if we > elect to unload Etoys for a next release then the resulting image should > be smaller than before. > > I think it would be great if both Etoys and Scratch were easily loadable > and unloadable in trunk. Scratch is already being successfully developed > as an external package compatible with trunk, which suggests that we should > ultimately be able to do the same with Etoys. Others have mentioned that > we need better tools to support this, and I agree. > > Dave > +1 to all of the above Stef --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus |
|
|
On Sun, Sep 4, 2016 at 7:05 PM, Stéphane Rollandin <[hidden email]> wrote: I missed most of this discussion, but I would like to say that I think +1 _,,,^..^,,,_ best, Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |