Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
* Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run * get halo for world, choose "preferences..." from halo menu * disable "eToyFriendly" in the "scripting category" * click the gray World background, choose "previous project" from the World menu * you'll be taken to the hidden top-level project, light-blue background * now is a good time to save the image
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
* running Etoys-To-Go creates a folder called "Etoys" next to it. Unzip the attached files into that "Etoys" folder. * open a file list. You should see the files now (loadmc.st, compatFixes-bf.cs, MonadicIfNotNil-eem.cs, Pragmas-eem.cs, FakeUIManager-bf.cs) * select the contents of loadmc.st and "do it". If the files are in the default folder, it should work. * this will churn for a long while, but finally, it should have installed Monticello and MonticelloConfigurations and PackageInfo from trunk.
Starting with this it should be really simple to get MC-based updates going, we just need to add some more utility methods from the trunk.
Comments and help welcome :)
- Bert -
On Mon, Apr 19, 2010 at 01:52:14PM +0200, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
- running Etoys-To-Go creates a folder called "Etoys" next to it. Unzip the attached files into that "Etoys" folder.
- open a file list. You should see the files now (loadmc.st, compatFixes-bf.cs, MonadicIfNotNil-eem.cs, Pragmas-eem.cs, FakeUIManager-bf.cs)
- select the contents of loadmc.st and "do it". If the files are in the default folder, it should work.
- this will churn for a long while, but finally, it should have installed Monticello and MonticelloConfigurations and PackageInfo from trunk.
Hi Bert,
I followed your instructions and everything loaded as expected. I now have an Etoys image with Monticello.
Once I got this far, I did world -> open... -> Monticello Browser to open the Monticello browser. The available repositories (right hand browser pane) were Squeak trunk and the local package-cache, so I added the Etoys repository by clicking the "+Repository" button, selecting type "HTTP", then enter the repository location:
MCHttpRepository location: 'http://source.squeak.org/etoys' user: 'dtl' password: 'mypassword'
So now I can browse both the Etoys repository and the Squeak trunk repository, and everything looks fine. I can see that a number of "FixUnderscores" have already been done on Etoys packages, so I see those differences relative to the base Etoys-to-go image, and everything else looks pretty much in sync as expected.
Starting with this it should be really simple to get MC-based updates going, we just need to add some more utility methods from the trunk.
Most likely adding the Monticello-based update stream would be a good next step.
[Off topic: I assume that the idea is to switch over to MC for development, although I have to say that I personally like Edgar's idea of *also* providing a changeset based stream generated from the MC changes. However, I don't know that we have a fully usable implementation of this.]
Comments and help welcome :)
It looks good so far :)
Dave
On 20.04.2010, at 03:32, David T. Lewis wrote:
So now I can browse both the Etoys repository and the Squeak trunk repository, and everything looks fine. I can see that a number of "FixUnderscores" have already been done on Etoys packages, so I see those differences relative to the base Etoys-to-go image, and everything else looks pretty much in sync as expected.
Hmm, don't we need to do a full re-categorization first before creating the real packages?
We need to account for every last method. Damn, I had code to check for that but didn't save it apparently ... oh well.
Karl, I filed out the reorg you did in your dev image (the one linked on the wiki) and added it to my "loadmc" script. It's included in the new zip below. So applying this should reflect the current state of re-categorizing.
The zip also has some more compiler changes from Eliot (literal byte-arrays), which was necessary for Installer to load.
Most likely adding the Monticello-based update stream would be a good next step.
Almost, yes.
We still need to refine the categorization. I had a crazy idea: in the trunk image, generate a list of which class is in which category, same for all methods. Then recategorize everything in the Etoys image to match that (provided the class/method exists). Since this only recategorizes, it should do no harm. Could that possibly work?
Also, we need to add some code that creates actual MC working copies for all the packages. That would be the initial set of "real" packages which will need to be committed to the repo.
[Off topic: I assume that the idea is to switch over to MC for development, although I have to say that I personally like Edgar's idea of *also* providing a changeset based stream generated from the MC changes. However, I don't know that we have a fully usable implementation of this.]
I have been playing with the idea to keep a traditional update stream in place as fall-back ... in case some surgery is needed that would be infeasible with MC updates.
Where would you see the need for a full changeset-based update stream? Seems cumbersome to me having to maintain both, with little benefit.
Comments and help welcome :)
It looks good so far :)
Dave
Thanks for testing!
- Bert -
On 4/20/2010 4:35 PM, Bert Freudenberg wrote:
We still need to refine the categorization. I had a crazy idea: in the trunk image, generate a list of which class is in which category, same for all methods. Then recategorize everything in the Etoys image to match that (provided the class/method exists). Since this only recategorizes, it should do no harm. Could that possibly work?
Yes. I was thinking about the same thing.
I have been playing with the idea to keep a traditional update stream in place as fall-back ... in case some surgery is needed that would be infeasible with MC updates.
I think that's wise, in particular in the early stages. In fact, you might consider using the update stream until the dust settles and post updated MC packages after installing each update. This could be automated and while you're trying to catch up all you'd need to do is to load updates first, then merge MC packages and the diffs should be empty, no?
Cheers, - Andreas
On Tue, Apr 20, 2010 at 04:52:02PM -0700, Andreas Raab wrote:
On 4/20/2010 4:35 PM, Bert Freudenberg wrote:
We still need to refine the categorization. I had a crazy idea: in the trunk image, generate a list of which class is in which category, same for all methods. Then recategorize everything in the Etoys image to match that (provided the class/method exists). Since this only recategorizes, it should do no harm. Could that possibly work?
Yes. I was thinking about the same thing.
Yes it should work. The only caution is that when you recategorize a class, it ends up looking like a big batch of deletions from one package, and a batch of additions to some other package. This will look rather alarming to someone accustomed to tidy change set updates, so it will be good get these changes done as soon as possible.
I have been playing with the idea to keep a traditional update stream in place as fall-back ... in case some surgery is needed that would be infeasible with MC updates.
I think that's wise, in particular in the early stages. In fact, you might consider using the update stream until the dust settles and post updated MC packages after installing each update. This could be automated and while you're trying to catch up all you'd need to do is to load updates first, then merge MC packages and the diffs should be empty, no?
And even if it cannot be automated, it is still quite easy to manually apply the MC updates after change sets are committed. Use the preamble of the change set as the update comment for the MC update(s), so all of the comments will be aligned and there is a way to trace the MC package updates back to the change sets. Typically a single change set will require updates to more the one MC package, so just paste the same change set preamble text into each of the affected MC package commits. It's not perfect, but it's good enough to get started.
Dave
On 21.04.2010, at 05:17, David T. Lewis wrote:
On Tue, Apr 20, 2010 at 04:52:02PM -0700, Andreas Raab wrote:
On 4/20/2010 4:35 PM, Bert Freudenberg wrote:
We still need to refine the categorization. I had a crazy idea: in the trunk image, generate a list of which class is in which category, same for all methods. Then recategorize everything in the Etoys image to match that (provided the class/method exists). Since this only recategorizes, it should do no harm. Could that possibly work?
Yes. I was thinking about the same thing.
Yes it should work. The only caution is that when you recategorize a class, it ends up looking like a big batch of deletions from one package, and a batch of additions to some other package. This will look rather alarming to someone accustomed to tidy change set updates, so it will be good get these changes done as soon as possible.
That is exactly why I want the recategorization done *before* creating the actual packages :)
I have been playing with the idea to keep a traditional update stream in place as fall-back ... in case some surgery is needed that would be infeasible with MC updates.
I think that's wise, in particular in the early stages. In fact, you might consider using the update stream until the dust settles and post updated MC packages after installing each update. This could be automated and while you're trying to catch up all you'd need to do is to load updates first, then merge MC packages and the diffs should be empty, no?
And even if it cannot be automated, it is still quite easy to manually apply the MC updates after change sets are committed. Use the preamble of the change set as the update comment for the MC update(s), so all of the comments will be aligned and there is a way to trace the MC package updates back to the change sets. Typically a single change set will require updates to more the one MC package, so just paste the same change set preamble text into each of the affected MC package commits. It's not perfect, but it's good enough to get started.
Dave
Well if it can't be automated it's cumbersome. I want to make contributing as simple as possible. Manually maintaining the changeset update stream should be left to emergency surgery only, IMHO.
- Bert -
On Monday 19 April 2010 05:22:14 pm Bert Freudenberg wrote:
Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World
menu
- you'll be taken to the hidden top-level project, light-blue
background now is a good time to save the image
Linux users will get an error about missing sources file when trying to save the image under a new name. It looks for sources file in Contents/Linux-i686 while the sources file is in Contents/Resources. Workaround is to link the file into the vmPath.
FYI .. Subbu
On 21.04.2010, at 05:20, K. K. Subramaniam wrote:
On Monday 19 April 2010 05:22:14 pm Bert Freudenberg wrote:
Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World
menu
- you'll be taken to the hidden top-level project, light-blue
background now is a good time to save the image
Linux users will get an error about missing sources file when trying to save the image under a new name.
Well, my instructions said "save" not "save as" ;)
Etoys hard-codes the image name anyway, working with several images is not supported without fiddling. The error is not even Linux-specific, you get the same error on the Mac.
Save replaces the image where it was. Save-as stores into the default directory, even if you do not change the image name. In Etoys, the default directory usually differs from the image directory, unlike regular Squeak. The image directory usually is read-only (that's why I recommended Etoys-To-Go where it is writable).
Because of this, save-as will not store the image where it was originally (inside Etoys-To-Go.app in this case), but into the "user directory". That is the "Etoys" folder next to "Etoys-To-Go.app". But running Etoys-To-Go again will not use that saved image but still the original one. Running a copy of the image outside the Resources folder will not work either, as translations and examples etc. are looked up relative to the image.
It looks for sources file in Contents/Linux-i686 while the sources file is in Contents/Resources. Workaround is to link the file into the vmPath.
Well, that makes the error go away, but as I explained above, will not result in a fully functional Etoys.
If you really wanted to support out-of-place images, you would have to change the logic for both the source file lookup and resources lookup. There has been no need for that so far, but we'd happily take (reasonable) patches :)
- Bert -
Great news. It will be really useful to load DrGeo for Etoys. I am doing a lot of refactoring in DrGeo for cleaning and optimization.
So I will split DrGeo in different complementary Monticello packages to ease its loading in Etoys.
Hilaire
Bert Freudenberg a écrit :
Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
- running Etoys-To-Go creates a folder called "Etoys" next to it. Unzip the attached files into that "Etoys" folder.
- open a file list. You should see the files now (loadmc.st, compatFixes-bf.cs, MonadicIfNotNil-eem.cs, Pragmas-eem.cs, FakeUIManager-bf.cs)
- select the contents of loadmc.st and "do it". If the files are in the default folder, it should work.
- this will churn for a long while, but finally, it should have installed Monticello and MonticelloConfigurations and PackageInfo from trunk.
Starting with this it should be really simple to get MC-based updates going, we just need to add some more utility methods from the trunk.
Comments and help welcome :)
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 19.04.2010, at 13:52, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
... which I just pushed to the new 4.1 update stream at etoys.squeak.org
* Evaluate this in a workspace to set the new update server (you need at least a 4.0.2336 image): HTTPSocket httpFileInNewChangeSet: 'etoys.squeak.org/updates/newUpdateStream-bf.cs' * Then load updates. This will ask if you want to advance to 4.1, say yes. Load updates again * This will take quite a while ... * ... but eventually you should have an image with Monticello loaded :)
Heres a log of the changes: http://squeakland.org/updates/
This includes the recategorization from trunk (huge 1 MB changeset) and an edited version of Karl's recategorization, ending up in a quite reasonable number of packages IMHO. Also, thanks to Eliot for porting the compiler changes!
The next step should be to create proper packages and commit them to the etoys repo. The will differ a bit from your initial ones, Karl. Do we want to try to merge yours or would it be simpler to start clean and just fix the underscores again?
- Bert -
Hi Bert -
Thanks for the instructions, I followed them and they work well. For looking at the Flash issues this has been the first time that I've been using an Etoys image in a while and I noticed some highly annoying things that I thought I'd point out:
* Keyboard shortcuts. Some keyboard shortcuts seem completely broken on Windows. At first I thought this is a VM issue but they don't work with the the VM in the Etoys app either. Is there a way to fix that? Having shortcuts like "implementors" not work makes working somewhere between hard and impossible. Any ideas how to fix that?
* Scaling. As much as I understand the desire, is there a way to turn off display scaling and the uber-large cursors? The fonts are simply too hard on my eyes for continuous work.
* Image saving. At first I tried a "save as" but this complained about not finding the sources/changes file afterwards. How come? Second, saving the image produces a visible flashing which is for some reason completely discomforting - it looks as if there was an error that the system tried to inform me about by the flash.
Cheers, - Andreas
On 4/25/2010 7:56 PM, Bert Freudenberg wrote:
On 19.04.2010, at 13:52, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
... which I just pushed to the new 4.1 update stream at etoys.squeak.org
- Evaluate this in a workspace to set the new update server (you need at least a 4.0.2336 image): HTTPSocket httpFileInNewChangeSet: 'etoys.squeak.org/updates/newUpdateStream-bf.cs'
- Then load updates. This will ask if you want to advance to 4.1, say yes. Load updates again
- This will take quite a while ...
- ... but eventually you should have an image with Monticello loaded :)
Heres a log of the changes: http://squeakland.org/updates/
This includes the recategorization from trunk (huge 1 MB changeset) and an edited version of Karl's recategorization, ending up in a quite reasonable number of packages IMHO. Also, thanks to Eliot for porting the compiler changes!
The next step should be to create proper packages and commit them to the etoys repo. The will differ a bit from your initial ones, Karl. Do we want to try to merge yours or would it be simpler to start clean and just fix the underscores again?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
At Mon, 26 Apr 2010 20:57:56 -0700, Andreas Raab wrote:
- Keyboard shortcuts. Some keyboard shortcuts seem completely broken on
Windows. At first I thought this is a VM issue but they don't work with the the VM in the Etoys app either. Is there a way to fix that? Having shortcuts like "implementors" not work makes working somewhere between hard and impossible. Any ideas how to fix that?
I thought this is a VM issue. Is there any other short cut other than Ctrl-m that doesn't work? It must be translated to return somewhere in the VM.
- Scaling. As much as I understand the desire, is there a way to turn
off display scaling and the uber-large cursors? The fonts are simply too hard on my eyes for continuous work.
If you have the gray bar, hold the button on the screen resize icon and say 'No Scaling'. (Or something like:
SugarNavigatorBar basicNew toggleScreenSetting: #physical).
-- Yoshiki
On 4/26/2010 9:21 PM, Yoshiki Ohshima wrote:
At Mon, 26 Apr 2010 20:57:56 -0700, Andreas Raab wrote:
- Keyboard shortcuts. Some keyboard shortcuts seem completely broken on
Windows. At first I thought this is a VM issue but they don't work with the the VM in the Etoys app either. Is there a way to fix that? Having shortcuts like "implementors" not work makes working somewhere between hard and impossible. Any ideas how to fix that?
I thought this is a VM issue. Is there any other short cut other than Ctrl-m that doesn't work? It must be translated to return somewhere in the VM.
Yes, it seems that Ctrl-m is the only one that doesn't work. Weird.
- Scaling. As much as I understand the desire, is there a way to turn
off display scaling and the uber-large cursors? The fonts are simply too hard on my eyes for continuous work.
If you have the gray bar, hold the button on the screen resize icon and say 'No Scaling'.
Ah, great, that does the trick. Is there also a way of turning off the overly big mouse cursor?
Cheers, - Andreas
On 27.04.2010, at 09:16, Andreas Raab wrote:
On 4/26/2010 9:21 PM, Yoshiki Ohshima wrote:
At Mon, 26 Apr 2010 20:57:56 -0700, Andreas Raab wrote:
- Keyboard shortcuts. Some keyboard shortcuts seem completely broken on
Windows. At first I thought this is a VM issue but they don't work with the the VM in the Etoys app either. Is there a way to fix that? Having shortcuts like "implementors" not work makes working somewhere between hard and impossible. Any ideas how to fix that?
I thought this is a VM issue. Is there any other short cut other than Ctrl-m that doesn't work? It must be translated to return somewhere in the VM.
Yes, it seems that Ctrl-m is the only one that doesn't work. Weird.
^M is ASCII 13, Carriage Return. Might be hard-coded somewhere.
- Bert -
On 27.04.2010, at 05:57, Andreas Raab wrote:
- Scaling. As much as I understand the desire, is there a way to turn off display scaling and the uber-large cursors? The fonts are simply too hard on my eyes for continuous work.
That's exactly why I would like developers to use the same settings as users. If it's unbearable for us, how can we expect our users to tolerate it?
- Image saving. At first I tried a "save as" but this complained about not finding the sources/changes file afterwards. How come? Second, saving the image produces a visible flashing which is for some reason completely discomforting - it looks as if there was an error that the system tried to inform me about by the flash.
The flashing comes from using the virtual screen. The display is black at first, then the virtual screen is drawn. It is distracting, yes. Yoshiki tried to reduce it before, but it's still not fully gone, just less pronounced.
The save-as issue I explained before:
Begin forwarded message:
From: Bert Freudenberg bert@freudenbergs.de Date: 21. April 2010 11:09:28 MESZ To: etoys-dev dev etoys-dev@squeakland.org Subject: Re: [etoys-dev] Preparing for Monticello-based updates
On 21.04.2010, at 05:20, K. K. Subramaniam wrote:
On Monday 19 April 2010 05:22:14 pm Bert Freudenberg wrote:
Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World
menu
- you'll be taken to the hidden top-level project, light-blue
background now is a good time to save the image
Linux users will get an error about missing sources file when trying to save the image under a new name.
Well, my instructions said "save" not "save as" ;)
Etoys hard-codes the image name anyway, working with several images is not supported without fiddling. The error is not even Linux-specific, you get the same error on the Mac.
Save replaces the image where it was. Save-as stores into the default directory, even if you do not change the image name. In Etoys, the default directory usually differs from the image directory, unlike regular Squeak. The image directory usually is read-only (that's why I recommended Etoys-To-Go where it is writable).
Because of this, save-as will not store the image where it was originally (inside Etoys-To-Go.app in this case), but into the "user directory". That is the "Etoys" folder next to "Etoys-To-Go.app". But running Etoys-To-Go again will not use that saved image but still the original one. Running a copy of the image outside the Resources folder will not work either, as translations and examples etc. are looked up relative to the image.
It looks for sources file in Contents/Linux-i686 while the sources file is in Contents/Resources. Workaround is to link the file into the vmPath.
Well, that makes the error go away, but as I explained above, will not result in a fully functional Etoys.
If you really wanted to support out-of-place images, you would have to change the logic for both the source file lookup and resources lookup. There has been no need for that so far, but we'd happily take (reasonable) patches :)
- Bert -
At Tue, 27 Apr 2010 13:30:51 +0200, Bert Freudenberg wrote:
On 27.04.2010, at 05:57, Andreas Raab wrote:
- Scaling. As much as I understand the desire, is there a way to turn off display scaling and the uber-large cursors? The fonts are simply too hard on my eyes for continuous work.
That's exactly why I would like developers to use the same settings as users. If it's unbearable for us, how can we expect our users to tolerate it?
- Image saving. At first I tried a "save as" but this complained about not finding the sources/changes file afterwards. How come? Second, saving the image produces a visible flashing which is for some reason completely discomforting - it looks as if there was an error that the system tried to inform me about by the flash.
The flashing comes from using the virtual screen. The display is black at first, then the virtual screen is drawn. It is distracting, yes. Yoshiki tried to reduce it before, but it's still not fully gone, just less pronounced.
I wonder what did I do? Ah, yes... What I did was for the transition between projects, when "from" and "to" are in the same size. Upon saving, obviously the class side startUp must be the problem. Prob'ly providing a right #startUp: for DisplayScreen would do it...
-- Yoshiki
On 26.04.2010, at 04:56, Bert Freudenberg wrote:
On 19.04.2010, at 13:52, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image (not save-as)
This will result in an image ready for development work. I'm suggesting to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
... which I just pushed to the new 4.1 update stream at etoys.squeak.org
- Evaluate this in a workspace to set the new update server (you need at least a 4.0.2336 image): HTTPSocket httpFileInNewChangeSet: 'etoys.squeak.org/updates/newUpdateStream-bf.cs'
- Then load updates. This will ask if you want to advance to 4.1, say yes. Load updates again
- This will take quite a while ...
- ... but eventually you should have an image with Monticello loaded :)
Heres a log of the changes: http://squeakland.org/updates/
This includes the recategorization from trunk (huge 1 MB changeset) and an edited version of Karl's recategorization, ending up in a quite reasonable number of packages IMHO. Also, thanks to Eliot for porting the compiler changes!
The next step should be to create proper packages and commit them to the etoys repo.
- Bert -
We did it :)
There is an initial version of all Monticello packages that now constitute the Etoys image in our main repository at
http://source.squeak.org/etoys.html
If you load updates, it will first fetch changesets from the update stream, and then proceed to update packages from the repository. We will mostly just post new packages from now on. But if needed, we still have the update stream.
To get an Etoys image for development, either follow the procedure I outlined above (takes about 10 minutes here), or download an all-in-one zip (based on Etoys-To-Go) from here:
http://etoys.squeak.org/download/
It's easier if you do not use save-as in this setup, only regular image save. The image name is mentioned explicitly in the VM settings.
New versions can be submitted to the "Etoys Inbox" by *anyone*, no registration required:
http://source.squeak.org/etoysinbox.html
Of course, Etoys developers can commit to the main repository directly. If you want to have access, register on that server, and ping me so I add you to the right group.
We'll look at all contributions, though we need to be somewhat conservative. Remember this is used by kids worldwide, it's deployed on about a million machines, and more are to come [1]. Features are cool, but don't make the kids cry, mkay? ;)
Btw, if someone feels more comfortable using changesets, don't worry, you can still attach them to a ticket on our tracker at
http://tracker.squeakland.org/
Some other developer will then build Monticello packages and commit them.
So, the gates are open, let the contributions flow :)
- Bert -
[1] http://www.earthtimes.org/articles/show/one-laptop-per-child-and,1271519.sht...
On Thu, Apr 29, 2010 at 11:05 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 26.04.2010, at 04:56, Bert Freudenberg wrote:
On 19.04.2010, at 13:52, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following
a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the
World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image (not save-as)
This will result in an image ready for development work. I'm suggesting
to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
... which I just pushed to the new 4.1 update stream at etoys.squeak.org
- Evaluate this in a workspace to set the new update server (you need at
least a 4.0.2336 image):
HTTPSocket httpFileInNewChangeSet: 'etoys.squeak.org/updates/newUpdateStream-bf.cs'
- Then load updates. This will ask if you want to advance to 4.1, say
yes. Load updates again
- This will take quite a while ...
- ... but eventually you should have an image with Monticello loaded :)
Heres a log of the changes: http://squeakland.org/updates/
This includes the recategorization from trunk (huge 1 MB changeset) and
an edited version of Karl's recategorization, ending up in a quite reasonable number of packages IMHO. Also, thanks to Eliot for porting the compiler changes!
The next step should be to create proper packages and commit them to the
etoys repo.
- Bert -
We did it :)
There is an initial version of all Monticello packages that now constitute the Etoys image in our main repository at
http://source.squeak.org/etoys.htmlIf you load updates, it will first fetch changesets from the update stream, and then proceed to update packages from the repository. We will mostly just post new packages from now on. But if needed, we still have the update stream.
To get an Etoys image for development, either follow the procedure I outlined above (takes about 10 minutes here), or download an all-in-one zip (based on Etoys-To-Go) from here:
http://etoys.squeak.org/download/It's easier if you do not use save-as in this setup, only regular image save. The image name is mentioned explicitly in the VM settings.
New versions can be submitted to the "Etoys Inbox" by *anyone*, no registration required:
http://source.squeak.org/etoysinbox.htmlOf course, Etoys developers can commit to the main repository directly. If you want to have access, register on that server, and ping me so I add you to the right group.
We'll look at all contributions, though we need to be somewhat conservative. Remember this is used by kids worldwide, it's deployed on about a million machines, and more are to come [1]. Features are cool, but don't make the kids cry, mkay? ;)
Btw, if someone feels more comfortable using changesets, don't worry, you can still attach them to a ticket on our tracker at
http://tracker.squeakland.org/Some other developer will then build Monticello packages and commit them.
So, the gates are open, let the contributions flow :)
- Bert -
[1] http://www.earthtimes.org/articles/show/one-laptop-per-child-and,1271519.sht...
Great !
Karl
This great news.
I am try to extract the Etoys Gettext facilities to produce a compatible layer for Pharo (can be used for squeak) so I can have both DrGeo translation running in both Etoys and Pharo (Polymorph version of DrGeo). I will create compatibilitz mcz package for DrGeo to integrate the specific Etoys viewer and Tiles methods to make DrGeo tiles aware.
Did someone try to load drgeo Monticello package in Etoys?
Hilaire
2010/4/29 Bert Freudenberg bert@freudenbergs.de
On 26.04.2010, at 04:56, Bert Freudenberg wrote:
On 19.04.2010, at 13:52, Bert Freudenberg wrote:
Hi folks,
as we discussed lately we want to enable easier contributions, following
a model similar to Squeak's "trunk". I spent the weekend making the latest tools from Squeak work in the Etoys image. I did not push it to the update stream yet, but it is attached. Let's discuss in the developer meeting on IRC later today.
Here is how to test it:
- Download Etoys-To-Go4-Final.zip from squeakland.org and unzip and run
- get halo for world, choose "preferences..." from halo menu
- disable "eToyFriendly" in the "scripting category"
- click the gray World background, choose "previous project" from the
World menu
- you'll be taken to the hidden top-level project, light-blue background
- now is a good time to save the image (not save-as)
This will result in an image ready for development work. I'm suggesting
to use Etoys-To-Go because it is self-contained and allows to save the image easily. The regular install is read-only.
Now for my stuff ...
... which I just pushed to the new 4.1 update stream at etoys.squeak.org
- Evaluate this in a workspace to set the new update server (you need at
least a 4.0.2336 image):
HTTPSocket httpFileInNewChangeSet: 'etoys.squeak.org/updates/newUpdateStream-bf.cs'
- Then load updates. This will ask if you want to advance to 4.1, say
yes. Load updates again
- This will take quite a while ...
- ... but eventually you should have an image with Monticello loaded :)
Heres a log of the changes: http://squeakland.org/updates/
This includes the recategorization from trunk (huge 1 MB changeset) and
an edited version of Karl's recategorization, ending up in a quite reasonable number of packages IMHO. Also, thanks to Eliot for porting the compiler changes!
The next step should be to create proper packages and commit them to the
etoys repo.
- Bert -
We did it :)
There is an initial version of all Monticello packages that now constitute the Etoys image in our main repository at
http://source.squeak.org/etoys.htmlIf you load updates, it will first fetch changesets from the update stream, and then proceed to update packages from the repository. We will mostly just post new packages from now on. But if needed, we still have the update stream.
To get an Etoys image for development, either follow the procedure I outlined above (takes about 10 minutes here), or download an all-in-one zip (based on Etoys-To-Go) from here:
http://etoys.squeak.org/download/It's easier if you do not use save-as in this setup, only regular image save. The image name is mentioned explicitly in the VM settings.
New versions can be submitted to the "Etoys Inbox" by *anyone*, no registration required:
http://source.squeak.org/etoysinbox.htmlOf course, Etoys developers can commit to the main repository directly. If you want to have access, register on that server, and ping me so I add you to the right group.
We'll look at all contributions, though we need to be somewhat conservative. Remember this is used by kids worldwide, it's deployed on about a million machines, and more are to come [1]. Features are cool, but don't make the kids cry, mkay? ;)
Btw, if someone feels more comfortable using changesets, don't worry, you can still attach them to a ticket on our tracker at
http://tracker.squeakland.org/Some other developer will then build Monticello packages and commit them.
So, the gates are open, let the contributions flow :)
- Bert -
[1] http://www.earthtimes.org/articles/show/one-laptop-per-child-and,1271519.sht...
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 -
Hilaire Fernandes -
K. K. Subramaniam -
karl ramberg -
Scott Wallace -
Yoshiki Ohshima