Hi,
With 3.9 we now can not use the update number as a sub-numbering (e.g. 3.9updateXYZ). So it might be interesting to come up with a different way of numbering at least some snap-shots along the way to 3.9 final...
1) For putting out pre-loaded images. I think this is a god thing to have, as it makes testing easiert for people, thus growing the number of testers 2) As tags for "stable" points, so people can say "it worked in 3.9.15".
The question is if we adopt the Linux Way of numbering: 3.8 is stable, 3.9 is unstable, both have minor revisions (3.8.1, 3.9.1), with 3.9 then be renamed 3.10 as soon as we decide to do a stabler release.
What do you think? I would like to release a 3.9alpha image soon, so that people can test the changes that we added over the last week. There was a huge bag-log of small fixes on mantis.
Marcus
Hi -
IIRC, then the idea was not to use the implicit upgrade-the-last-version-of-each-package scheme that we're currently using in Tweak. In which case all new configurations would have to be posted explicitly. In which case the X.Y-update number scheme still applies since it basically identifies the configuration map and therefore implicitly the versions of the packages being used.
Cheers, - Andreas
Marcus Denker wrote:
Hi,
With 3.9 we now can not use the update number as a sub-numbering (e.g. 3.9updateXYZ). So it might be interesting to come up with a different way of numbering at least some snap-shots along the way to 3.9 final...
- For putting out pre-loaded images. I think this is a god thing to
have, as it makes testing easiert for people, thus growing the number of testers 2) As tags for "stable" points, so people can say "it worked in 3.9.15".
The question is if we adopt the Linux Way of numbering: 3.8 is stable, 3.9 is unstable, both have minor revisions (3.8.1, 3.9.1), with 3.9 then be renamed 3.10 as soon as we decide to do a stabler release.
What do you think? I would like to release a 3.9alpha image soon, so that people can test the changes that we added over the last week. There was a huge bag-log of small fixes on mantis.
Marcus
Am 02.08.2005 um 06:01 schrieb Andreas Raab:
Hi -
IIRC, then the idea was not to use the implicit upgrade-the-last- version-of-each-package scheme that we're currently using in Tweak. In which case all new configurations would have to be posted explicitly. In which case the X.Y-update number scheme still applies since it basically identifies the configuration map and therefore implicitly the versions of the packages being used.
Ok, yes, that will work too... I really need to re-read all the mails of the package list. The only problem is that the new setup is not working, but we need to have some 3.9a image out there for testing soon.
I think we could just put out a 3.9aTesting or something like that for now... or fix the setup. Can I help there somehow?
Marcus
The new setup is not working? What appears to be the problem?
- A.
Marcus Denker wrote:
Am 02.08.2005 um 06:01 schrieb Andreas Raab:
Hi -
IIRC, then the idea was not to use the implicit upgrade-the-last- version-of-each-package scheme that we're currently using in Tweak. In which case all new configurations would have to be posted explicitly. In which case the X.Y-update number scheme still applies since it basically identifies the configuration map and therefore implicitly the versions of the packages being used.
Ok, yes, that will work too... I really need to re-read all the mails of the package list. The only problem is that the new setup is not working, but we need to have some 3.9a image out there for testing soon.
I think we could just put out a 3.9aTesting or something like that for now... or fix the setup. Can I help there somehow?
Marcus
On Tue, 02 Aug 2005 05:24:42 -0700, "Andreas Raab" andreas.raab@gmx.de said:
The new setup is not working? What appears to be the problem?
The diff-file generation is not working on the SqueakSource server that we are currently using at http://source.squeakfoundation.org.
I'm working on the problem now, trying to set up a new SqueakSource image with Bert's diff generation capability included. (Avi originally set up the SS image, but he's offline for awhile so I'm taking that over for now.) In theory we could just not use the diff generation and have everyone load the full .mcz for every update, but IMO that might hammer the squeaksource server a bit hard and we might as well just get the diff generation working, since it's already working at Impara.
Bert helpfully sent out the list of a dozen or so installed packages in the Impara SqueakSource image, but installing these packages in a fresh 3.7 image is turning out to be not as trivial as it should be, although it should be doable. (E.g. I had to first track down all the packages; some of them need to be loaded in a certain order; some (KomHttpServer) seem to require being installed via SqueakMap and not MC; I ran across a bug in SimpleServiceEntry (which I fixed) which prevented some packages from being installed; etc.)
Hey Bert, what is in your SystemFixes-bf package? I didn't see that one anywhere online... that may save me some trouble.
Anyway, I'm getting a bit more busy again lately, so my time spent working on this is limited. Marcus, if you (or anyone else) have a decent amount of free time and want to work on this, that would be great... you'd just have to start with a 3.7 basic image and install the packages Bert listed in his post, then start up the SS server locally and test it via http://localhost:9090 and make sure the diff (mcd) file generation and everything else is working. On the other hand, I think I could probably get it working in the next 2-3 days.
- Doug
- A.
Marcus Denker wrote:
Am 02.08.2005 um 06:01 schrieb Andreas Raab:
Hi -
IIRC, then the idea was not to use the implicit upgrade-the-last- version-of-each-package scheme that we're currently using in Tweak. In which case all new configurations would have to be posted explicitly. In which case the X.Y-update number scheme still applies since it basically identifies the configuration map and therefore implicitly the versions of the packages being used.
Ok, yes, that will work too... I really need to re-read all the mails of the package list. The only problem is that the new setup is not working, but we need to have some 3.9a image out there for testing soon.
I think we could just put out a 3.9aTesting or something like that for now... or fix the setup. Can I help there somehow?
Marcus
Hi Doug -
The new setup is not working? What appears to be the problem?
The diff-file generation is not working on the SqueakSource server that we are currently using at http://source.squeakfoundation.org.
I see.
I'm working on the problem now, trying to set up a new SqueakSource image with Bert's diff generation capability included. (Avi originally set up the SS image, but he's offline for awhile so I'm taking that over for now.) In theory we could just not use the diff generation and have everyone load the full .mcz for every update, but IMO that might hammer the squeaksource server a bit hard and we might as well just get the diff generation working, since it's already working at Impara.
True. On the other hand we might as well serve the packages via Apache or so - there will be *plenty* of situations where we'll be able to fetch those packages and it might be worthwhile to get this going so that we're not killing squeaksource with the requests. After which it's only a question of bandwidth and I think we've got plenty.
Bert helpfully sent out the list of a dozen or so installed packages in the Impara SqueakSource image, but installing these packages in a fresh 3.7 image is turning out to be not as trivial as it should be, although it should be doable. (E.g. I had to first track down all the packages; some of them need to be loaded in a certain order; some (KomHttpServer) seem to require being installed via SqueakMap and not MC; I ran across a bug in SimpleServiceEntry (which I fixed) which prevented some packages from being installed; etc.)
Hey Bert, what is in your SystemFixes-bf package? I didn't see that one anywhere online... that may save me some trouble.
Unfortunately, Bert is off for vacation - don't expect a response right now.
Cheers, - Andreas
Am 03.08.2005 um 05:55 schrieb Andreas Raab:
Bert helpfully sent out the list of a dozen or so installed packages in the Impara SqueakSource image, but installing these packages in a fresh 3.7 image is turning out to be not as trivial as it should be, although it should be doable. (E.g. I had to first track down all the packages; some of them need to be loaded in a certain order; some (KomHttpServer) seem to require being installed via SqueakMap and not MC; I ran across a bug in SimpleServiceEntry (which I fixed) which prevented some packages from being installed; etc.)
Yes, unfortunately I didn't take notes when I installed our server image - but I remember I had to do the same hunting for packages etc.
Hey Bert, what is in your SystemFixes-bf package? I didn't see that one anywhere online... that may save me some trouble.
Unfortunately, Bert is off for vacation - don't expect a response right now.
I'm back now. SystemFixes-bf.1 only contains one method, a tiny improvement to ChangeSet class>>uniqueNameLike: to answer the original string when no such changeset exists. IMHO this is completely unrelated.
- Bert -
Ok, here's my current progress, I've only been working on this sporadically.
I'm able to get a SqueakSource image loaded with Bert's packages (with tweaks), and mostly working, but the diff-file generation doesn't work in this image, either. Basically pretty similar to what we have running now, I guess. :|
There's two main problems I'm running into:
1. This SqueakSource (SS) setup is based on Squeak 3.7, but the version of Monticello (bf.254) in Bert's package list is not compatible with 3.7. (avi.231 is not compatible with 3.7 either.) If you load either of these versions in 3.7, loading .mcz files no longer works. I came up with a quick hack which seems to fix it (see attached changeset), but it causes other problems with loading regular changesets.
2. The diff-file (.mcd) generation hangs in the SS image. Well, it doesn't hang the SS image, it just doesn't send back a http response. Requesting any file ending in .mcd seems to do this, other files are either found or return a "not found" error. I haven't really dug into this yet. I don't think this is related to problem #1 but who knows...
I think the missing link here may be the "SystemFixes-bf.1" package from Bert's list, which is not available anywhere that I can find... I think it may be a few key fixes in a private package. :)
Anyway, if anyone wants to set up a mostly-working SqueakSource image to get to the exact same point that I'm at now, here are the steps you can follow: (I will post these to the swiki once it's all working, since there seems to be a lack of SqueakSource how-tos out there)
- Start with a fresh 3.7-5989-basic image. - Load these packages in roughly this order. (These are from Bert's working configuration... they are available on SqueakMap or on source.impara.de.) - DynamicBindings-gk.1.mcz - KomServices-gk.2.mcz - PackageInfo-Base-bf.22.mcz - Monticello-bf.254.mcz - Install my SimpleServicesHack-dew changeset (attached to this email), to allow additional .mcz files to load - KomHttpServer-gk.6.mcz - Seaside2-avi.86.mcz - Mewa-al.13.mcz - TinyWiki-lr.10.mcz - SqueakSource-bf.146.mcz - MonticelloConfigurations-bf.26.mcz - TweakMC-bf.11.mcz (not needed? seems to be only Tweak-related) - run the first few lines of code in SSRepository class>>initialize - change SSRepository class>>startUp to include 'http://localhost:9090/' as the RootUrl. - execute "SSRepository startUp" in a workspace - open any web browser on http://localhost:9090. SqueakSource works... hooray!
To continue with more serious testing: - add a new Member for yourself via squeaksource web browser ui - open an inspector on "SSRepository current" in the image, drill down to members/(your id) and set your superuser flag to true. - create a new project via the squeaksource web ui, and try saving new versions of a package to the project, seems to work. - getting files directly e.g. http://localhost:9090/dougsproj/Kernel-dew.1.mcz works. - getting a diff file e.g. http://localhost:9090/dougsproj/Kernel-md.5%28dew.1%29.mcd doesn't respond, though.
- Doug
Some good news, it looks like I figured out the diff-file generation problem. (problem #2 below)
I managed to put a halt in the diff generating code that was being executed, and found it was in an infinite loop trying to create an error stack caused by a different problem. The infinite loop was because SocketStream>>printString is broken (in 3.7/3.8/3.9, I'll post a fix). After fixing that, I got a different infinite loop because it was trying to email the error stack somewhere (maybe configured to Bert's address), which caused a connection error, which then tried to email another error stack for that, etc. I might be tempted to just dump error stacks into a log directory on the server rather than emailing them, hm.
Anyway, after fixing that, the root cause of the error was because I did actually have the wrong version of Monticello loaded, which I was trying to get around the SimpleServiceEntry problem earlier. Loading the version specified by Bert fixed that.
So, .mcd file generation is working nicely, and using #updateFromRepositories and #upgrade on the MCConfiguration map from a client image appears to work, which is how the automatic updating will work.
I'd still like to fix problem #1, though, since the SS image will be a bit crippled with my hack in there. Then I will try replacing the SS image at http://source.squeakfoundation.org and see how it goes...
- Doug
On Aug 10, 2005, at 12:48 AM, Doug Way wrote:
Ok, here's my current progress, I've only been working on this sporadically.
I'm able to get a SqueakSource image loaded with Bert's packages (with tweaks), and mostly working, but the diff-file generation doesn't work in this image, either. Basically pretty similar to what we have running now, I guess. :|
There's two main problems I'm running into:
- This SqueakSource (SS) setup is based on Squeak 3.7, but the
version of Monticello (bf.254) in Bert's package list is not compatible with 3.7. (avi.231 is not compatible with 3.7 either.) If you load either of these versions in 3.7, loading .mcz files no longer works. I came up with a quick hack which seems to fix it (see attached changeset), but it causes other problems with loading regular changesets.
- The diff-file (.mcd) generation hangs in the SS image. Well, it
doesn't hang the SS image, it just doesn't send back a http response. Requesting any file ending in .mcd seems to do this, other files are either found or return a "not found" error. I haven't really dug into this yet. I don't think this is related to problem #1 but who knows...
I think the missing link here may be the "SystemFixes-bf.1" package from Bert's list, which is not available anywhere that I can find... I think it may be a few key fixes in a private package. :)
Anyway, if anyone wants to set up a mostly-working SqueakSource image to get to the exact same point that I'm at now, here are the steps you can follow: (I will post these to the swiki once it's all working, since there seems to be a lack of SqueakSource how-tos out there)
- Start with a fresh 3.7-5989-basic image.
- Load these packages in roughly this order. (These are from Bert's
working configuration... they are available on SqueakMap or on source.impara.de.)
- DynamicBindings-gk.1.mcz
- KomServices-gk.2.mcz
- PackageInfo-Base-bf.22.mcz
- Monticello-bf.254.mcz
- Install my SimpleServicesHack-dew changeset (attached to this
email), to allow additional .mcz files to load
- KomHttpServer-gk.6.mcz
- Seaside2-avi.86.mcz
- Mewa-al.13.mcz
- TinyWiki-lr.10.mcz
- SqueakSource-bf.146.mcz
- MonticelloConfigurations-bf.26.mcz
- TweakMC-bf.11.mcz (not needed? seems to be only Tweak-related)
- run the first few lines of code in SSRepository class>>initialize
- change SSRepository class>>startUp to include
'http://localhost:9090/' as the RootUrl.
- execute "SSRepository startUp" in a workspace
- open any web browser on http://localhost:9090. SqueakSource
works... hooray!
To continue with more serious testing:
- add a new Member for yourself via squeaksource web browser ui
- open an inspector on "SSRepository current" in the image, drill down
to members/(your id) and set your superuser flag to true.
- create a new project via the squeaksource web ui, and try saving new
versions of a package to the project, seems to work.
- getting files directly e.g.
http://localhost:9090/dougsproj/Kernel-dew.1.mcz works.
- getting a diff file e.g.
http://localhost:9090/dougsproj/Kernel-md.5%28dew.1%29.mcd doesn't respond, though.
- Doug
<SimpleServiceHack-dew.1.cs>
packages@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Doug Way -
Marcus Denker