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 leves@caesar.elte.hu 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, Tim
Chris Muller asqueaker@gmail.com schrieb am Mi., 31. Aug. 2016, 23:53:
I think Levente's question deserves more discussion.
What is the direction? What is the plan?
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; tim@rowledge.org; http://www.rowledge.org/tim Maybe Computer Science should be in the College of Theology
On 9/1/16, tim Rowledge tim@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@rowledge.org; 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 hannes.hirzel@gmail.com wrote:
On 9/1/16, tim Rowledge tim@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 .......
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.
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@rowledge.org; http://www.rowledge.org/tim Maybe Computer Science should be in the College of Theology
On 31-08-2016, at 3:33 PM, Tim Felgentreff timfelgentreff@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Totum dependeat. = Let it all hang out.
On Wed, Aug 31, 2016 at 11:28:06PM +0200, H. Hirzel wrote:
On 8/31/16, Levente Uzonyi leves@caesar.elte.hu 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 lecteur@zogotounga.net wrote:
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
+1
_,,,^..^,,,_ best, Eliot
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.
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.
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.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
David T. Lewis -
Eliot Miranda -
H. Hirzel -
Levente Uzonyi -
marcel.taeumel -
Stéphane Rollandin -
Tim Felgentreff -
tim Rowledge