On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniam subbukk@gmail.com wrote:
On Friday 19 February 2010 12:36:25 pm Bert Freudenberg wrote:
3.8 was the last common release. That's why Etoys doesn't even have MC. I think the very first step would be to repackage Etoys, just like Andreas did with 3.8. Since 3.9 the main line uses MC.
Repackage which Etoys? Etoys from Etoys trunk or the Etoys in Squeak trunk?
I have 422 patches from 1900htmlColor-bf.cs till 2340*.cs (so far) that I can try to manually merge into Etoys/Squeak. For some time we will have to deal with two Etoys - Etoys/Etoys and the emerging Etoys/Squeak.
So the Todo list will look like: A. Excise Etoys/Squeak into a loadable package and unload it from the current Squeak trunk. B. foreach Etoys changeset from Etoys/Etoys updates.list apply it to this new package load it in Squeak and make it pass a smoke test. C. Rebase Etoys/Etoys to this new package.
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
BTW, I do like the Karl's proposal to have two images - etoys-dev and etoys (runtime). Runtime image should not be burdened with scaffolding code.
Subbu
Loading the change sets into trunk and resolving all conflicts is also a way of doing it.
Etoys is a seperate package in trunk image that can be unloaded, btw
Karl
On 19.02.2010, at 14:00, karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniam subbukk@gmail.com wrote:
On Friday 19 February 2010 12:36:25 pm Bert Freudenberg wrote:
3.8 was the last common release. That's why Etoys doesn't even have MC. I think the very first step would be to repackage Etoys, just like Andreas did with 3.8. Since 3.9 the main line uses MC.
Repackage which Etoys? Etoys from Etoys trunk or the Etoys in Squeak trunk?
I meant classify all code in the Etoys image into packages, same names as in trunk.
Then we have two sets of packages - the ones in trunk and the ones in the Etoys image, so we can easily compare them. Then we can gradually modify the Etoys-image packages so they become more like those in the trunk. At the same time, fixes done in Etoys would be applied to the trunk. In the end, the packages will be the same, and we're done.
- Bert -
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniam subbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Subbu
K. K. Subramaniam skrev 2010-02-20 08:36:
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniamsubbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Subbu
I suggest making one at source.squeak.org and it's easy to move over if we want it on an other location later
Karl
On 20.02.2010, at 08:36, K. K. Subramaniam wrote:
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniam subbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
You are confusing two things. One is the Etoys image which is what you download from squeakland. The other is the Etoys package in trunk. Those have almost nothing to do with each other as I tried to explain previously.
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Not laptop.org for sure. Somewhere on squeak.org would be best IMHO. Previously we wanted to host it on squeakland but I spoke to Tim and he agreed that squeak.org might be a good idea.
If we go the Monticello route instead of continuing with changesets in an update stream then I think making an Etoys project at source.squeak.org is our best option. Is that what we want?
- Bert -
On 20.02.2010, at 12:17, Bert Freudenberg wrote:
On 20.02.2010, at 08:36, K. K. Subramaniam wrote:
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniam subbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
You are confusing two things. One is the Etoys image which is what you download from squeakland. The other is the Etoys package in trunk. Those have almost nothing to do with each other as I tried to explain previously.
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Not laptop.org for sure. Somewhere on squeak.org would be best IMHO. Previously we wanted to host it on squeakland but I spoke to Tim and he agreed that squeak.org might be a good idea.
If we go the Monticello route instead of continuing with changesets in an update stream then I think making an Etoys project at source.squeak.org is our best option. Is that what we want?
Sent to soon.
What I meant to add is that this Etoys repo would hold *all* code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
- Bert -
Bert Freudenberg skrev 2010-02-20 12:26:
On 20.02.2010, at 12:17, Bert Freudenberg wrote:
On 20.02.2010, at 08:36, K. K. Subramaniam wrote:
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniamsubbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
You are confusing two things. One is the Etoys image which is what you download from squeakland. The other is the Etoys package in trunk. Those have almost nothing to do with each other as I tried to explain previously.
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Not laptop.org for sure. Somewhere on squeak.org would be best IMHO. Previously we wanted to host it on squeakland but I spoke to Tim and he agreed that squeak.org might be a good idea.
If we go the Monticello route instead of continuing with changesets in an update stream then I think making an Etoys project at source.squeak.org is our best option. Is that what we want?
Sent to soon.
What I meant to add is that this Etoys repo would hold *all* code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Yes, this sounds nice to me. But we have some old school Squeakers here ;-) How are Scott and Ted feeling about using Monticello ?
Karl
On 20.02.2010, at 13:45, Karl Ramberg wrote:
Bert Freudenberg skrev 2010-02-20 12:26:
On 20.02.2010, at 12:17, Bert Freudenberg wrote:
On 20.02.2010, at 08:36, K. K. Subramaniam wrote:
On Friday 19 February 2010 06:30:07 pm karl ramberg wrote:
On Fri, Feb 19, 2010 at 1:37 PM, K. K. Subramaniamsubbukk@gmail.com
wrote:
I get stuck in Step A. Where does one draw the boundary between Morphic and Etoys? Does one have to start from scratch or is there a partially excised version somewhere?
..
Etoys is a seperate package in trunk image that can be unloaded, btw
I can unload Etoys from the trunk image, but is there a reference repository for Etoys for loading it all back?
You are confusing two things. One is the Etoys image which is what you download from squeakland. The other is the Etoys package in trunk. Those have almost nothing to do with each other as I tried to explain previously.
Will the loadable Etoys be hosted in source.squeak.org or in etoys.laptop.org?
Not laptop.org for sure. Somewhere on squeak.org would be best IMHO. Previously we wanted to host it on squeakland but I spoke to Tim and he agreed that squeak.org might be a good idea.
If we go the Monticello route instead of continuing with changesets in an update stream then I think making an Etoys project at source.squeak.org is our best option. Is that what we want?
Sent to soon.
What I meant to add is that this Etoys repo would hold *all* code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Yes, this sounds nice to me. But we have some old school Squeakers here ;-) How are Scott and Ted feeling about using Monticello ?
Karl
We could continue accepting changesets posted on the tracker. Someone familiar with MC would have to commit them though.
- Bert -
On Saturday 20 February 2010 04:56:30 pm Bert Freudenberg wrote:
What I meant to add is that this Etoys repo would hold all code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
The source code in Etoys packages are less than 8% of overall source code (35k out of 527k). Why not keep only the Etoys packages in the repo and compose an image on demand from the current trunk? Patches for trunk could go into Inbox while those for Etoys could go into tracker.
Is it possible to automatically harvest changesets in updates.list into mcz? Then we don't have to decide between cs or mcz right away. I don't know the history behind cs vs. mcz and don't intend to reawaken a flame war ;-).
Subbu
On 20.02.2010, at 16:46, K. K. Subramaniam wrote:
On Saturday 20 February 2010 04:56:30 pm Bert Freudenberg wrote:
What I meant to add is that this Etoys repo would hold all code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
The source code in Etoys packages are less than 8% of overall source code (35k out of 527k). Why not keep only the Etoys packages in the repo and compose an image on demand from the current trunk? Patches for trunk could go into Inbox while those for Etoys could go into tracker.
Is it possible to automatically harvest changesets in updates.list into mcz? Then we don't have to decide between cs or mcz right away. I don't know the history behind cs vs. mcz and don't intend to reawaken a flame war ;-).
Subbu
Sigh. Etoys is *not* just what is called the Etoys package in the trunk. At least not *yet*. As I wrote earlier:
"Then we have two sets of packages - the ones in trunk and the ones in the Etoys image, so we can easily compare them. Then we can gradually modify the Etoys-image packages so they become more like those in the trunk. At the same time, fixes done in Etoys would be applied to the trunk. In the end, the packages will be the same, and we're done."
So that's why we need a repository for *all* the packages in Etoys - to work on making them more similar to the trunk.
- Bert -
Is there a way to check all the Etoys change sets for changes to classes not in the trunk Etoys package ? That way we could locate the places that need special work.
Karl
Bert Freudenberg skrev 2010-02-20 17:31:
On 20.02.2010, at 16:46, K. K. Subramaniam wrote:
On Saturday 20 February 2010 04:56:30 pm Bert Freudenberg wrote:
What I meant to add is that this Etoys repo would hold all code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
The source code in Etoys packages are less than 8% of overall source code (35k out of 527k). Why not keep only the Etoys packages in the repo and compose an image on demand from the current trunk? Patches for trunk could go into Inbox while those for Etoys could go into tracker.
Is it possible to automatically harvest changesets in updates.list into mcz? Then we don't have to decide between cs or mcz right away. I don't know the history behind cs vs. mcz and don't intend to reawaken a flame war ;-).
Subbu
Sigh. Etoys is *not* just what is called the Etoys package in the trunk. At least not *yet*. As I wrote earlier:
"Then we have two sets of packages - the ones in trunk and the ones in the Etoys image, so we can easily compare them. Then we can gradually modify the Etoys-image packages so they become more like those in the trunk. At the same time, fixes done in Etoys would be applied to the trunk. In the end, the packages will be the same, and we're done."
So that's why we need a repository for *all* the packages in Etoys - to work on making them more similar to the trunk.
- Bert -
Nitpick: I see that the package is called EToys in trunk, while the official name is Etoys
Karl
On Sat, Feb 20, 2010 at 09:16:36PM +0530, K. K. Subramaniam wrote:
On Saturday 20 February 2010 04:56:30 pm Bert Freudenberg wrote:
What I meant to add is that this Etoys repo would hold all code currently in the Etoys image, just as the trunk repo holds all code in the trunk image. Ideally we'd add a configuration-based update mechanism just as in trunk so that we can easily load updates by pushing a button. Does that make the idea more clear?
The source code in Etoys packages are less than 8% of overall source code (35k out of 527k). Why not keep only the Etoys packages in the repo and compose an image on demand from the current trunk? Patches for trunk could go into Inbox while those for Etoys could go into tracker.
Is it possible to automatically harvest changesets in updates.list into mcz? Then we don't have to decide between cs or mcz right away. I don't know the history behind cs vs. mcz and don't intend to reawaken a flame war ;-).
Subbu,
It's not matter of one versus the other. Monticello is the right way to commit updates and compare differences between packages, as Bert described.
In addition to this (not instead of), a list of change sets from an update stream may be very useful for identifying when changes were made, who made them, and for what reason.
From my recent experience working on making MVC reloadable in trunk, I
can say that there were several times when I wished that I could find an original change set to help me understand why something was done. I suspect we will have similar situations as we work on Etoys in trunk, so from my POV it would be ideal if we could use the Monticello configuration that Bert described, and also have all of the change sets available.
Dave
I there a preferred version of Monticello to use, or is it just to grab the latest one from SqueakMap ?
Karl
Bert Freudenberg skrev 2010-02-21 15:04:
On 21.02.2010, at 14:37, Karl Ramberg wrote:
I there a preferred version of Monticello to use, or is it just to grab the latest one from SqueakMap ?
Karl
Since our goal is to move closer to Squeak trunk I'd use that version if possible.
- Bert -
Hi I got all exited about this :-) Do you have access to set up the project at source.squeak.org , Bert ?
Karl
On 21.02.2010, at 19:06, Karl Ramberg wrote:
Bert Freudenberg skrev 2010-02-21 15:04:
On 21.02.2010, at 14:37, Karl Ramberg wrote:
I there a preferred version of Monticello to use, or is it just to grab the latest one from SqueakMap ?
Karl
Since our goal is to move closer to Squeak trunk I'd use that version if possible.
- Bert -
Hi I got all exited about this :-) Do you have access to set up the project at source.squeak.org , Bert ?
Karl
You need to make a member account, then I can add you to the Etoys Dev group there:
http://source.squeak.org/etoys.html
In any case we need to packetize the whole image first, there must not be any methods left. Which is not exactly easy, just look at all the star categories in Morph for example ... Maybe someone can find Andreas' code that did this for 3.8.
- Bert -
On Sun, Feb 21, 2010 at 8:38 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 21.02.2010, at 19:06, Karl Ramberg wrote:
Bert Freudenberg skrev 2010-02-21 15:04:
On 21.02.2010, at 14:37, Karl Ramberg wrote:
I there a preferred version of Monticello to use, or is it just to grab the latest one from SqueakMap ?
Karl
Since our goal is to move closer to Squeak trunk I'd use that version if possible.
- Bert -
Hi I got all exited about this :-) Do you have access to set up the project at source.squeak.org , Bert ?
Karl
You need to make a member account, then I can add you to the Etoys Dev group there:
http://source.squeak.org/etoys.html
In any case we need to packetize the whole image first, there must not be any methods left. Which is not exactly easy, just look at all the star categories in Morph for example ... Maybe someone can find Andreas' code that did this for 3.8.
this ?
http://ftp.squeak.org/updates/6671Reorganize39-6665-ar.cs
karl
On 21.02.2010, at 22:39, karl ramberg wrote:
On Sun, Feb 21, 2010 at 8:38 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 21.02.2010, at 19:06, Karl Ramberg wrote:
Bert Freudenberg skrev 2010-02-21 15:04:
On 21.02.2010, at 14:37, Karl Ramberg wrote:
I there a preferred version of Monticello to use, or is it just to grab the latest one from SqueakMap ?
Karl
Since our goal is to move closer to Squeak trunk I'd use that version if possible.
- Bert -
Hi I got all exited about this :-) Do you have access to set up the project at source.squeak.org , Bert ?
Karl
You need to make a member account, then I can add you to the Etoys Dev group there:
http://source.squeak.org/etoys.htmlIn any case we need to packetize the whole image first, there must not be any methods left. Which is not exactly easy, just look at all the star categories in Morph for example ... Maybe someone can find Andreas' code that did this for 3.8.
this ?
http://ftp.squeak.org/updates/6671Reorganize39-6665-ar.cs
karl
Yes. I think that might be a good start.
- Bert -
Bert Freudenberg wrote:
In any case we need to packetize the whole image first, there must not be any methods left. Which is not exactly easy, just look at all the star categories in Morph for example ... Maybe someone can find Andreas' code that did this for 3.8.
I'd recommend something slightly different namely to file out a list of classes and categories from Squeak and move all the classes in the Etoys image into the same categories. Then, define the set of packages as we have in the trunk right now and see what's left. Having the same package structure will make it a lot easier to diff and merge them.
Cheers, - Andreas
On 22.02.2010, at 00:13, Andreas Raab wrote:
Bert Freudenberg wrote:
In any case we need to packetize the whole image first, there must not be any methods left. Which is not exactly easy, just look at all the star categories in Morph for example ... Maybe someone can find Andreas' code that did this for 3.8.
I'd recommend something slightly different namely to file out a list of classes and categories from Squeak and move all the classes in the Etoys image into the same categories. Then, define the set of packages as we have in the trunk right now and see what's left. Having the same package structure will make it a lot easier to diff and merge them.
Cheers,
- Andreas
Sounds right - I did not mean to literally use this old change set but to take it as a reference point. And matching the trunk structure is important.
For the various non-trunk categories I think moving them to the "Etoys" package would be a good first-order guideline. Here is an example:
MessageSet openMessageList: (PackageInfo named: 'FlexibleVocabularies') extensionMethods name: 'ext methods'
We currently have about 30 packages more than Trunk (try the script below) but many of them are accidental and would have a natural home in the "Etoys" package (e.g. Connectors - unless someone would step up to maintain it as a separate package).
And we should fix the spelling of the "Etoys" package to not have a capital "T", both in the Etoys image and Trunk.
- Bert -
packages := PluggableSet new. packages equalBlock: [:a :b | a sameAs: b]. packages hashBlock: [:a | a asLowercase hash]. SystemOrganization categories do: [:category | packages add: (category copyUpTo: $-) asString]. Smalltalk allClassesDo: [:cls | cls organization categories do: [:protocol | protocol first = $* ifTrue: [ packages add: (protocol allButFirst copyUpTo: $-)]]]. packages asSortedArray
On Monday 22 February 2010 03:13:55 pm Bert Freudenberg wrote:
And we should fix the spelling of the "Etoys" package to not have a capital "T", both in the Etoys image and Trunk.
I have seen EToys Etoy (see Etoy-UserObjects in etoys image) eToys (see basicType)
and then Etoys. Do I take it that Etoys is the correct spelling?
Subbu
On 22.02.2010, at 12:39, K. K. Subramaniam wrote:
On Monday 22 February 2010 03:13:55 pm Bert Freudenberg wrote:
And we should fix the spelling of the "Etoys" package to not have a capital "T", both in the Etoys image and Trunk.
I have seen EToys Etoy (see Etoy-UserObjects in etoys image) eToys (see basicType)
and then Etoys. Do I take it that Etoys is the correct spelling?
Yes. Where ever you see a different spelling, please fix it :)
- Bert -
Bert Freudenberg wrote:
Sounds right - I did not mean to literally use this old change set but to take it as a reference point. And matching the trunk structure is important.
For the various non-trunk categories I think moving them to the "Etoys" package would be a good first-order guideline. Here is an example:
MessageSet openMessageList: (PackageInfo named: 'FlexibleVocabularies') extensionMethods name: 'ext methods'
We currently have about 30 packages more than Trunk (try the script below) but many of them are accidental and would have a natural home in the "Etoys" package (e.g. Connectors - unless someone would step up to maintain it as a separate package).
Sounds reasonable. One of the things that might be helpful is to set up a wiki with "porting notes and status" for each package (like noting that we should discuss folding Connectors into Etoys).
We should then spend some time to go over the differences and just take notes about the portions that require work. I'd like to get an idea first about the scope of what needs to be done and then about how to address the issues.
And we should fix the spelling of the "Etoys" package to not have a capital "T", both in the Etoys image and Trunk.
Fine by me. You've got all the commit rights you need :-)
Cheers, - Andreas
- Bert -
packages := PluggableSet new. packages equalBlock: [:a :b | a sameAs: b]. packages hashBlock: [:a | a asLowercase hash]. SystemOrganization categories do: [:category | packages add: (category copyUpTo: $-) asString]. Smalltalk allClassesDo: [:cls | cls organization categories do: [:protocol | protocol first = $* ifTrue: [ packages add: (protocol allButFirst copyUpTo: $-)]]]. packages asSortedArray
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
K. K. Subramaniam -
karl ramberg -
Karl Ramberg