Hi Guys,
I just ran into a very unfortunate situation: I have an image which has been built on top of 3.6 basic but some later code (written against 3.6 too) requires (a variety of) the full packages. My problem: I have no idea which versions of the packages at SM have been used when 3.6-full was built, neither do I know if their latest version will work with 3.6 (highly unlikely if they have been touched at all in the mean time) nor do I know where I would find those packages, nor do I know how to "extract" them (which may not be possible for all of them) from a 3.6 full image.
Help! If you happen to know which versions went into 3.6 and if you happen to have a copy of said package please let me know.
Cheers, - Andreas
PS. God, how I wish I had a cached version of all of the packages that went into 3.6 full ... I wonder if we shouldn't ship the packages which have been loaded in full as "loadable" (e.g., cached) with the basic versions?!
Am 29.09.2004 um 22:31 schrieb Andreas Raab:
Hi Guys,
I just ran into a very unfortunate situation: I have an image which has been built on top of 3.6 basic but some later code (written against 3.6 too) requires (a variety of) the full packages. My problem: I have no idea which versions of the packages at SM have been used when 3.6-full was built, neither do I know if their latest version will work with 3.6 (highly unlikely if they have been touched at all in the mean time) nor do I know where I would find those packages, nor do I know how to "extract" them (which may not be possible for all of them) from a 3.6 full image.
Help! If you happen to know which versions went into 3.6 and if you happen to have a copy of said package please let me know.
The Package Loader can at least show the installed versions:
Balloon3D (1.0.3) Benchmarks (2) Celeste (1.07) Games (07-06-2003) PackageInfo (1.30) SARInstaller for 3.6 (19) SM Package Loader (1.02) SUnit (3.1) Scamper (1.02) SqueakMap Base (1.07) Upgrade to 3.6 Full Image (1.2) VMMaker (3.6g2)
- Bert -
Hi!
Bert Freudenberg bert@impara.de wrote:
Am 29.09.2004 um 22:31 schrieb Andreas Raab:
Hi Guys,
I just ran into a very unfortunate situation: I have an image which has been built on top of 3.6 basic but some later code (written against 3.6 too) requires (a variety of) the full packages. My problem: I have no idea which versions of the packages at SM have been used when 3.6-full was built, neither do I know if their latest version will work with 3.6 (highly unlikely if they have been touched at all in the mean time) nor do I know where I would find those packages, nor do I know how to "extract" them (which may not be possible for all of them) from a 3.6 full image.
Help! If you happen to know which versions went into 3.6 and if you happen to have a copy of said package please let me know.
The Package Loader can at least show the installed versions:
Balloon3D (1.0.3) Benchmarks (2) Celeste (1.07) Games (07-06-2003) PackageInfo (1.30) SARInstaller for 3.6 (19) SM Package Loader (1.02) SUnit (3.1) Scamper (1.02) SqueakMap Base (1.07) Upgrade to 3.6 Full Image (1.2) VMMaker (3.6g2)
- Bert -
Yes, and that should be correct - or am I missing something?
regards, Göran
The Package Loader can at least show the installed versions:
Balloon3D (1.0.3) Benchmarks (2) Celeste (1.07) Games (07-06-2003) PackageInfo (1.30) SARInstaller for 3.6 (19) SM Package Loader (1.02) SUnit (3.1) Scamper (1.02) SqueakMap Base (1.07) Upgrade to 3.6 Full Image (1.2) VMMaker (3.6g2)
- Bert -
Yes, and that should be correct - or am I missing something?
Only that knowing the versions don't help much unless you have the packages itself. I have been able to find all but the VMMaker package (this doesn't seem to exist any longer) though there were some very strange oddities: If you take a 3.6 and open the package loader it tries to update SqueakMap (and miserably fails if you say yes) but if you don't it gives you a series of releases which don't even show if you go to SM in the browser. Very, very odd.
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
itself. I have been able to find all but the VMMaker package (this doesn't seem to exist any longer)
Hmm, it should be there on my site... yup, in the usual place http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-6g2...
Interestingly google finds vmmaker3-6g2 but not vmmaker3-6 - odd.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim It said, "Insert disk #3," but only two will fit!
Hmm, it should be there on my site... yup, in the usual place http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-6g2...
Interestingly google finds vmmaker3-6g2 but not vmmaker3-6 - odd.
Phew! Thanks a lot - for some reason I couldn't load it via SM. At last I got all the packages back together.
Cheers, - Andreas
Hi!
"Andreas Raab" andreas.raab@gmx.de wrote:
The Package Loader can at least show the installed versions:
Balloon3D (1.0.3) Benchmarks (2) Celeste (1.07) Games (07-06-2003) PackageInfo (1.30) SARInstaller for 3.6 (19) SM Package Loader (1.02) SUnit (3.1) Scamper (1.02) SqueakMap Base (1.07) Upgrade to 3.6 Full Image (1.2) VMMaker (3.6g2)
- Bert -
Yes, and that should be correct - or am I missing something?
Only that knowing the versions don't help much unless you have the packages itself. I have been able to find all but the VMMaker package (this doesn't seem to exist any longer)
Ehum, well - the releases (the URLs of them) are available in SM - and with the upcoming SM which includes a server cache - the files would be available too... unless of course the maintainer has decided to DELETE the release.
Now... you may recall a discussion we had in Stockholm over a beer regarding immutability etc? ;) Anyway - I hope people DO NOT DELETE old releases (nor the files those URLs point to), because it gives us headaches, but as you are aware of there is no mechanism in SM that prevents the account holder from doing it. I could add more warnings of course... :)
though there were some very strange oddities: If you take a 3.6 and open the package loader it tries to update SqueakMap (and miserably fails if you say yes)
It does? (checking...) Hmmm, just tried a 3.6-basic 5424 - worked for me.
but if you don't it gives you a series of releases which don't even show if you go to SM in the browser. Very, very odd.
Not odd to me :) - if you say no... it can't update the map. So you are looking at an old map. Perhaps it should warn though.
Cheers,
- Andreas
regards, Göran
Hi Goran,
Now... you may recall a discussion we had in Stockholm over a beer regarding immutability etc? ;)
I do, but I think it'd be more worthwhile to have the packages in full be redistributed alongside the basic image so that if people want to they can easily upgrade their basic to full image (incidentally I wouldn't mind a full snapshot of SM either - just something so that it's very clear which version has been used and where to get it).
though there were some very strange oddities: If you take a 3.6 and open the package loader it tries to update SqueakMap (and miserably fails if you say yes)
It does? (checking...) Hmmm, just tried a 3.6-basic 5424 - worked for me.
I just tried it again and now it worked. Odd indeed. Could this be related to some sm cache not being deleted?
but if you don't it gives you a series of releases which don't even show if you go to SM in the browser. Very, very odd.
Not odd to me :) - if you say no... it can't update the map. So you are looking at an old map. Perhaps it should warn though.
But then, why are the versions in the old map no longer present in the new map? Say, if I look at the old map I see VMMaker as version 3.6g (with a URL which later results in a 404) whereas in a "new" map I see versions 3.7b4 and 3.7b5 but *not* 3.6g. And please note that this map comes from the same server so I would expect some amount of consistency here.
Cheers, - Andreas
On Sun, Oct 03, 2004 at 05:46:13PM -0700, Andreas Raab wrote:
.... have the packages in full be redistributed alongside the basic image so that if people want to they can easily upgrade their basic to full image (incidentally I wouldn't mind a full snapshot of SM either - just something so that it's very clear which version has been used and where to get it).
Isn't this what Lex is proposing with his "Universes" idea? A "snapshot" of some subset of SM at some known configuration, from which you can select packages and be reasonably confident that you have grabbed the right ones.
Dave
"David T. Lewis" lewis@mail.msen.com wrote:
Isn't this what Lex is proposing with his "Universes" idea? A "snapshot" of some subset of SM at some known configuration, from which you can select packages and be reasonably confident that you have grabbed the right ones.
Yes, it is. The 3.7 stable universe is now closed to updates (and will be posted within a couple of weeks I hope). Thus, if you download a 3.7universes image a year from now, you'll get almost the same packages as you'd get if you downolad it a month from now. To contrast, if you download a 3.7final image a year from now and then start loading "3.7 releases" from SqueakMap, you will get a different set of packages, because various packages will have been updated and tested for compatibility with 3.7final. That's great and desirable behavior, but it is different from a stable release of an entire set of packages.
Philosophically, please notice that the universes design has a place to put these policies: universe servers consult a Policy object before allowing any changes to be made. SqueakMap does not. This is a good example of the different priorities of SqueakMap and Universes: SqueakMap after years of development has gotten along fine without policies, but Universes got policies within it's first 2-day implementation.
All this said, the "release packages" that Goran mentioned he is thinking about, may well support policies. If nothing else, they will probably support informal policies simply due to there only being one person (or one committee) who knows the password of thhe account that owns the release package. We will see how it goes!
-Lex
"Andreas Raab" andreas.raab@gmx.de wrote:
But then, why are the versions in the old map no longer present in the new map? Say, if I look at the old map I see VMMaker as version 3.6g (with a URL which later results in a 404) whereas in a "new" map I see versions 3.7b4 and 3.7b5 but *not* 3.6g.
That's probably my fault - I had some weird trouble trying to add releases, set which was default etc some time ago. Can't remember details anymore. It probably shouldn't have been possible for me to delete old records.
Given that you found the 3.6g2 package at the 'right' place on my site, can you tell me the faulty URL? I might be able to patch it up.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim There can never be a computer language in which you cannot write a bad program.
Hi!
"Andreas Raab" andreas.raab@gmx.de wrote:
Hi Goran,
Now... you may recall a discussion we had in Stockholm over a beer regarding immutability etc? ;)
I do, but I think it'd be more worthwhile to have the packages in full be redistributed alongside the basic image so that if people want to they can easily upgrade their basic to full image (incidentally I wouldn't mind a full snapshot of SM either - just something so that it's very clear which version has been used and where to get it).
Today we *can* do this - but we haven't done it yet. We can distribute a preloaded client cache in the zip etc. This has been the intention *all along*. I have even posted a snippet earlier how to preload the cache etc. It is just 10 lines of code or such. I have always argued for a zip with the smallest image in it and then a map + a preloaded cache so that you can easily "fatten" that image to a Full or other.
though there were some very strange oddities: If you take a 3.6 and open the package loader it tries to update SqueakMap (and miserably fails if you say yes)
It does? (checking...) Hmmm, just tried a 3.6-basic 5424 - worked for me.
I just tried it again and now it worked. Odd indeed. Could this be related to some sm cache not being deleted?
Hmmm, well - SqueakMap takes a look in the "sm" dir for the map file. If it is there and it is newer than the instance in the image it is loaded into the image etc. It is the file called map.xxx.sgz (gzipped export imagesegment, xxx being the highest number).
but if you don't it gives you a series of releases which don't even show if you go to SM in the browser. Very, very odd.
Not odd to me :) - if you say no... it can't update the map. So you are looking at an old map. Perhaps it should warn though.
But then, why are the versions in the old map no longer present in the new map? Say, if I look at the old map I see VMMaker as version 3.6g (with a URL which later results in a 404) whereas in a "new" map I see versions 3.7b4 and 3.7b5 but *not* 3.6g. And please note that this map comes from the same server so I would expect some amount of consistency here.
Eh... well, before I added releases to SM there was only a "current" version in there. My memory is week, but if versions were altered after the 3.6 release and before the new SM - then the versions in 3.6 would not be in the current map. When I migrated I could (obviously) only remember the version current as of that day.
Cheers,
- Andreas
cheers, Göran
Andreas
normally there was a script (do ont remember the name) on SqueakMap to build the fullImage. We did a new version for 3.7 so you should find the 3.6 version and compare with what you have in the image.
Stef
On 29 sept. 04, at 22:31, Andreas Raab wrote:
Hi Guys,
I just ran into a very unfortunate situation: I have an image which has been built on top of 3.6 basic but some later code (written against 3.6 too) requires (a variety of) the full packages. My problem: I have no idea which versions of the packages at SM have been used when 3.6-full was built, neither do I know if their latest version will work with 3.6 (highly unlikely if they have been touched at all in the mean time) nor do I know where I would find those packages, nor do I know how to "extract" them (which may not be possible for all of them) from a 3.6 full image.
Help! If you happen to know which versions went into 3.6 and if you happen to have a copy of said package please let me know.
Cheers,
- Andreas
PS. God, how I wish I had a cached version of all of the packages that went into 3.6 full ... I wonder if we shouldn't ship the packages which have been loaded in full as "loadable" (e.g., cached) with the basic versions?!
normally there was a script (do ont remember the name) on SqueakMap to build the fullImage. We did a new version for 3.7 so you should find the 3.6 version and compare with what you have in the image.
That is not the point - I do not need a load script which tries to fetch the latest version of packages (and fails for three out of six, with two of the three it loads successfully being _different_ and _non-functioninng_ compared to the code being in 3.6) I need the packages that were actually loaded to build 3.6.
Cheers, - Andreas
On 30 sept. 04, at 15:10, Andreas Raab wrote:
normally there was a script (do ont remember the name) on SqueakMap to build the fullImage. We did a new version for 3.7 so you should find the 3.6 version and compare with what you have in the image.
That is not the point - I do not need a load script which tries to fetch the latest version of packages (and fails for three out of six, with two of the three it loads successfully being _different_ and _non-functioninng_ compared to the code being in 3.6) I need the packages that were actually loaded to build 3.6.
This was not the latest version of package but the versions used to build 3.6.!
At least the version we built based on that can be used to rebuild 3.7 in the future so I do not see why the version 3.6 of this script would not work. You have all the id and the version inside the method packagedo or something like that.
I did not try the version 3.6 of the script but I always thought it was there for that. This script should not take the latest version else I would not have written the email.
Stef
Cheers,
- Andreas
Am 30.09.2004 um 15:34 schrieb stéphane ducasse:
On 30 sept. 04, at 15:10, Andreas Raab wrote:
normally there was a script (do ont remember the name) on SqueakMap to build the fullImage. We did a new version for 3.7 so you should find the 3.6 version and compare with what you have in the image.
That is not the point - I do not need a load script which tries to fetch the latest version of packages (and fails for three out of six, with two of the three it loads successfully being _different_ and _non-functioninng_ compared to the code being in 3.6) I need the packages that were actually loaded to build 3.6.
This was not the latest version of package but the versions used to build 3.6.!
At least the version we built based on that can be used to rebuild 3.7 in the future so I do not see why the version 3.6 of this script would not work. You have all the id and the version inside the method packagedo or something like that.
I did not try the version 3.6 of the script but I always thought it was there for that. This script should not take the latest version else I would not have written the email.
The problem is that SqueakMap back then did not have the concept of releases: There were only one enry for each project, releasing a new version did make the old one unavailable.
Marcus
Hi all!
Marcus Denker denker@iam.unibe.ch wrote: [SNIP]
The problem is that SqueakMap back then did not have the concept of releases: There were only one enry for each project, releasing a new version did make the old one unavailable.
Marcus
Ahhh.... sorry. I knew that - but actually somehow got brainwashed and thought we got releases added before that. Well, that explains the conundrum at least.
regards, Göran
Ok I checked and this was 3.7 full assembler and if I would have remember its name this morning I would not have send my email. I was sure that the same script existed for 3.6. but not. so we should really learn from this story.
Sorry andreas. I was dreaming.
Stef
On 30 sept. 04, at 15:10, Andreas Raab wrote:
normally there was a script (do ont remember the name) on SqueakMap to build the fullImage. We did a new version for 3.7 so you should find the 3.6 version and compare with what you have in the image.
That is not the point - I do not need a load script which tries to fetch the latest version of packages (and fails for three out of six, with two of the three it loads successfully being _different_ and _non-functioninng_ compared to the code being in 3.6) I need the packages that were actually loaded to build 3.6.
Cheers,
- Andreas
Am 29.09.2004 um 22:31 schrieb Andreas Raab:
Hi Guys,
I just ran into a very unfortunate situation: I have an image which has been built on top of 3.6 basic but some later code (written against 3.6 too) requires (a variety of) the full packages. My problem: I have no idea which versions of the packages at SM have been used when 3.6-full was built, neither do I know if their latest version will work with 3.6 (highly unlikely if they have been touched at all in the mean time) nor do I know where I would find those packages, nor do I know how to "extract" them (which may not be possible for all of them) from a 3.6 full image.
Help! If you happen to know which versions went into 3.6 and if you happen to have a copy of said package please let me know.
The Squeak 3.6 CD has a complete snapshot of SqueakMap from (I think) a week or two after the 3.6 release.
http://www.squeak.de/SqueakCD.html
Marcus
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
goran.krampe＠bluefish.se -
lex＠cc.gatech.edu -
Marcus Denker -
stéphane ducasse -
Tim Rowledge