Hi!
Jecel Assumpcao Jr wrote: [SNIP of stuff we agree on]
I really like eToys but I have not looked deeply at its implementation and what a "merge" entails. I think a majority of Squeak-dev would like a merge... *IF* it means keeping eToys a separate layer/entity that can load on top of the base.
Note that the official Squeak images already include Etoys. so a merge would not imply adding that. It would, instead, mean adding lots of little fixes and some new functionallity (like scaling the screen or the new navigation bar).
We all agree about how great it would be to have a tiny kernel image that could load an Etoys layer, but that is not going to happen soon. People have created scripts in the past that can rip out all the Etoys stuff but always in such a way that it is a one way street: the result can't be loaded back in. We know what needs to be done to go beyond that and have a reloadable layer, but none of us has the time to do it. So putting this on a roadmap for the near future is sure to lead to disappointment.
Well, still, it is a crucial point. Let me outline two different scenarios of which I would only support one:
Scenario 1:
- eToys and Squeak-dev merge by simply moving all changes made in the eToys-fork to the eToys code inside Squeak.
- Work continues on improving eToys inside Squeak based on the needs of the eToys project. The code is still intertangled with the rest of Squeak. There is no clear boundary and we will see eToys specific code in the "core classes" (especially Morphic I presume).
Scenario 2:
- eToys and Squeak-dev merge by moving all changes made in the eToys-fork to the eToys code inside Squeak BUT also clearly marks a boundary between eToys and Squeak. This can be done using method categories and whatever means necessary. While it can not easily be snapshotted separately we at least KNOW what it consists of.
- Work *begins* (I am not expecting a timetable, but I do expect an ambition and a plan) on turning eToys into a separate entity that is indeed "loadable" on top of Squeak. I would love to hear the technical details on why this is hard (I don't doubt it, I just wonder).
Now... scenario 2 is VASTLY different from scenario 1.
regards, Göran
Göran Krampe wrote:
Well, still, it is a crucial point. Let me outline two different scenarios of which I would only support one:
I think this discussion is premature. No plan exists, and these are not plausible scenarios since they describe two extremes. The reality will be somewhere in the middle.
Cheers, - Andres
Scenario 1:
- eToys and Squeak-dev merge by simply moving all changes made in the
eToys-fork to the eToys code inside Squeak.
- Work continues on improving eToys inside Squeak based on the needs of
the eToys project. The code is still intertangled with the rest of Squeak. There is no clear boundary and we will see eToys specific code in the "core classes" (especially Morphic I presume).
Scenario 2:
- eToys and Squeak-dev merge by moving all changes made in the
eToys-fork to the eToys code inside Squeak BUT also clearly marks a boundary between eToys and Squeak. This can be done using method categories and whatever means necessary. While it can not easily be snapshotted separately we at least KNOW what it consists of.
- Work *begins* (I am not expecting a timetable, but I do expect an
ambition and a plan) on turning eToys into a separate entity that is indeed "loadable" on top of Squeak. I would love to hear the technical details on why this is hard (I don't doubt it, I just wonder).
Now... scenario 2 is VASTLY different from scenario 1.
regards, Göran
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Andreas Raab wrote:
Göran Krampe wrote:
Well, still, it is a crucial point. Let me outline two different scenarios of which I would only support one:
I think this discussion is premature. No plan exists, and these are not plausible scenarios since they describe two extremes. The reality will be somewhere in the middle.
Cheers,
- Andres
I agree that it may be premature, but since the discussion was brought up I wanted to make it clear that some of us out here don't consider ourselves "eToys haters" *nor* do we want an intertangled base.
regards, Göran
Göran Krampe wrote:
I agree that it may be premature, but since the discussion was brought up I wanted to make it clear that some of us out here don't consider ourselves "eToys haters" *nor* do we want an intertangled base.
Indeed. I think it is good to have these discussions now. I will start by confessing that I have not looked at the Etoys code to see what the problem is, so am only repeating what other people have said. I can imagine some issues, though:
1) things hidden in obscure places
This would complicate removing more than reloading. It could lead to an image that is supposed to be Etoys free actually having methods or even whole classes left in. These would be missing from any generated Etoys package, but since they would still be in the main image any code in the package that depends on them would still work. And we can suppose that this would be relatively small compared to what was removed and so wouldn't bother people too much.
2) changing, rather than deleting, methods
It is often that case that some methods would still be needed without Etoys but only one or a few of its lines would have to be eliminated or rewritten. Reloading Etoys wouldn't work unless these methods were restored to their previous versions as part of the package loading. But any later changes to these methods would be lost this way and other things would break. Doing this right requires some careful programming.
3) circular dependencies
This is often cited as the most significant problem. Rather than having Etoys as a clean layer on top of Morphic you have parts of Morphic that do their job by using Etoys stuff. This is why Bert suggested making Etoys+Morphic one big reloadable package instead of trying to separate the two. I think enough people want Morphic without Etoys (Cuis, Pharo and others) that I feel we should at least try to evaluate what kind of an effort it would be to separate them. Obviously people have already been able to rip out Etoys in a way that satisfied them and that already involved dealing with circular dependencies. Perhaps these efforts leave pieces of Etoys in place?
There is another discussion which I would like to have: what will Etoys be like in the future? The current Squeakland Foundation roadmap indicates that it will be basically what we have now in a few years, which isn't what I would like. We have several programming environment in Squeak: Smalltalk-80, Etoys from Squeakland, Etoys from Squeak.org, Scratch, tiles (broken), alternative syntax (removed in recent Squeaks, right?) and a few others that are external packages. I would like to see a nicer path from Scratch-->Etoys-->Smalltalk-80 and if we go in that direction then Etoys would be even more integrated into the system rather than less.
-- Jecel
On Monday 05 Oct 2009 1:01:17 pm Andreas Raab wrote:
I think this discussion is premature. No plan exists, and these are not plausible scenarios since they describe two extremes. The reality will be somewhere in the middle.
Andreas,
I feel the critical question is not so much in separating Etoys out into a module but in the commitment for (reasonable) backward compatibility for all the projects out there. The former is a question of getting more hands into Squeak while the latter one is of policy.
Will Etoys be supported as an application module on Squeak or will it be spun off into an independent fork?
If the policy is to favor an integration as a module, what is the best way to collect ideas (and work item plans)? mantis? wiki?
Subbu
2009/10/5 Göran Krampe goran@krampe.se:
Hi!
Jecel Assumpcao Jr wrote: [SNIP of stuff we agree on]
I really like eToys but I have not looked deeply at its implementation and what a "merge" entails. I think a majority of Squeak-dev would like a merge... *IF* it means keeping eToys a separate layer/entity that can load on top of the base.
Note that the official Squeak images already include Etoys. so a merge would not imply adding that. It would, instead, mean adding lots of little fixes and some new functionallity (like scaling the screen or the new navigation bar).
We all agree about how great it would be to have a tiny kernel image that could load an Etoys layer, but that is not going to happen soon. People have created scripts in the past that can rip out all the Etoys stuff but always in such a way that it is a one way street: the result can't be loaded back in. We know what needs to be done to go beyond that and have a reloadable layer, but none of us has the time to do it. So putting this on a roadmap for the near future is sure to lead to disappointment.
Well, still, it is a crucial point. Let me outline two different scenarios of which I would only support one:
Scenario 1:
- eToys and Squeak-dev merge by simply moving all changes made in the
eToys-fork to the eToys code inside Squeak.
- Work continues on improving eToys inside Squeak based on the needs of the
eToys project. The code is still intertangled with the rest of Squeak. There is no clear boundary and we will see eToys specific code in the "core classes" (especially Morphic I presume).
Scenario 2:
- eToys and Squeak-dev merge by moving all changes made in the eToys-fork to
the eToys code inside Squeak BUT also clearly marks a boundary between eToys and Squeak. This can be done using method categories and whatever means necessary. While it can not easily be snapshotted separately we at least KNOW what it consists of.
IHMO this is a bad idea to continue to mix Squeak and eToys code. As you say, EToys should be a separate entity from Squeak or Pharo. For example, Seaside is not embedded in Squeak, this is a completely separate product.
This could be a win-win situation for both communities : Squeakers or Pharoers will be happy to move and clean their platform without the fear to break the entire Etoys stuff, EToyers will have access to a more secure and well-maintained core base. As the EToys removal experience of Pharo has shown, EToys code encrust every aspect of the Squeak platform and is not really good from of point of maintenance of the system in the long run.
Best regards,
On 05.10.2009, at 10:46, Serge Stinckwich wrote:
2009/10/5 Göran Krampe goran@krampe.se:
Hi!
Jecel Assumpcao Jr wrote: [SNIP of stuff we agree on]
I really like eToys but I have not looked deeply at its implementation and what a "merge" entails. I think a majority of Squeak-dev would like a merge... *IF* it means keeping eToys a separate layer/entity that can load on top of the base.
Note that the official Squeak images already include Etoys. so a merge would not imply adding that. It would, instead, mean adding lots of little fixes and some new functionallity (like scaling the screen or the new navigation bar).
We all agree about how great it would be to have a tiny kernel image that could load an Etoys layer, but that is not going to happen soon. People have created scripts in the past that can rip out all the Etoys stuff but always in such a way that it is a one way street: the result can't be loaded back in. We know what needs to be done to go beyond that and have a reloadable layer, but none of us has the time to do it. So putting this on a roadmap for the near future is sure to lead to disappointment.
Well, still, it is a crucial point. Let me outline two different scenarios of which I would only support one:
Scenario 1:
- eToys and Squeak-dev merge by simply moving all changes made in the
eToys-fork to the eToys code inside Squeak.
- Work continues on improving eToys inside Squeak based on the
needs of the eToys project. The code is still intertangled with the rest of Squeak. There is no clear boundary and we will see eToys specific code in the "core classes" (especially Morphic I presume).
Scenario 2:
- eToys and Squeak-dev merge by moving all changes made in the
eToys-fork to the eToys code inside Squeak BUT also clearly marks a boundary between eToys and Squeak. This can be done using method categories and whatever means necessary. While it can not easily be snapshotted separately we at least KNOW what it consists of.
IHMO this is a bad idea to continue to mix Squeak and eToys code. As you say, EToys should be a separate entity from Squeak or Pharo. For example, Seaside is not embedded in Squeak, this is a completely separate product.
This could be a win-win situation for both communities : Squeakers or Pharoers will be happy to move and clean their platform without the fear to break the entire Etoys stuff, EToyers will have access to a more secure and well-maintained core base. As the EToys removal experience of Pharo has shown, EToys code encrust every aspect of the Squeak platform and is not really good from of point of maintenance of the system in the long run.
IMHO the only viable way to do this is to declare Morphic as part of Etoys, and maintain the two together. There can be alternate UI frameworks - we still have MVC, and there are a couple of other contenders (and using ToolBuilder it is possible to have tools working under any of them). Etoys code does not stretch too far into the rest of the system I think, but is very closely related to Morphic.
- Bert -
etoys-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Göran Krampe -
Jecel Assumpcao Jr -
K. K. Subramaniam -
Serge Stinckwich