Squeak 4.4 Question
Locked
12
12
 
|
Where is the sources file for 4.4? Ican get the VM, the image, and changes file - but where is the 4.4 sources file hiding?
James Robertson http://www.jarober.com [hidden email] |
|
|
On 7 January 2013 14:48, James Robertson <[hidden email]> wrote:
> Where is the sources file for 4.4? Ican get the VM, the image, and changes file - but where is the 4.4 sources file hiding? We don't yet have an All-in-One that would ship with everything you'd need. You can use any SqueakV41.sources, for instance from here: https://github.com/frankshearar/squeak-ci/blob/master/SqueakV41.sources frank > James Robertson > http://www.jarober.com > [hidden email] > > > > |
|
|
In reply to this post by jarober
On 07.01.2013, at 15:48, James Robertson <[hidden email]> wrote:
> Where is the sources file for 4.4? Ican get the VM, the image, and changes file - but where is the 4.4 sources file hiding? We have been sloppy with making source files. All releases since 4.1 have shipped with the same sources and growing changes. The plan was to condense sources for every point release, but nondestructively: the changes are supposed to be compacted and appended to the previous release's sources. That way, all point releases can share a single sources file. Maybe we should finally follow through with this plan for 4.5? Or even for the full 4.4 release? TL;DR: use 4.1 sources for 4.4 - Bert - |
|
|
As a small suggestion, having even a symlink labeled 4.4 would make it a lot more obvious for people trying to download :)
On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: > On 07.01.2013, at 15:48, James Robertson <[hidden email]> wrote: > >> Where is the sources file for 4.4? Ican get the VM, the image, and changes file - but where is the 4.4 sources file hiding? > > > We have been sloppy with making source files. All releases since 4.1 have shipped with the same sources and growing changes. > > The plan was to condense sources for every point release, but nondestructively: the changes are supposed to be compacted and appended to the previous release's sources. That way, all point releases can share a single sources file. > > Maybe we should finally follow through with this plan for 4.5? Or even for the full 4.4 release? > > TL;DR: use 4.1 sources for 4.4 > > - Bert - James Robertson http://www.jarober.com [hidden email] |
|
|
I've just done that, James, and also put up the Cog VMs we tested with
4.4 (version r2640). I haven't yet uploaded Interpreter VMs. And I've update the release checklist to make sure 4.5 doesn't have this issue :) frank On 7 January 2013 15:03, James Robertson <[hidden email]> wrote: > As a small suggestion, having even a symlink labeled 4.4 would make it a lot more obvious for people trying to download :) > > On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: > >> On 07.01.2013, at 15:48, James Robertson <[hidden email]> wrote: >> >>> Where is the sources file for 4.4? Ican get the VM, the image, and changes file - but where is the 4.4 sources file hiding? >> >> >> We have been sloppy with making source files. All releases since 4.1 have shipped with the same sources and growing changes. >> >> The plan was to condense sources for every point release, but nondestructively: the changes are supposed to be compacted and appended to the previous release's sources. That way, all point releases can share a single sources file. >> >> Maybe we should finally follow through with this plan for 4.5? Or even for the full 4.4 release? >> >> TL;DR: use 4.1 sources for 4.4 >> >> - Bert - > > James Robertson > http://www.jarober.com > [hidden email] > > > > |
|
|
On 1/11/13, Frank Shearar <[hidden email]> wrote:
> I've just done that, James, and also put up the Cog VMs we tested with > 4.4 (version r2640). Thank you Frank, having the Cog VMs plus image and sources file for 4.4. which were tested together is very useful. May I ask you to put a http://ftp.squeak.org/4.4/SqueakV41.sources.zip file in addition to http://ftp.squeak.org/4.4/SqueakV41.sources.gz for convenience of MS Windows users who do not have something like 7-zip (http://www.7-zip.org/) installed? --Hannes I haven't yet uploaded Interpreter VMs. > > And I've update the release checklist to make sure 4.5 doesn't have > this issue :) > > frank > > On 7 January 2013 15:03, James Robertson <[hidden email]> wrote: >> As a small suggestion, having even a symlink labeled 4.4 would make it a >> lot more obvious for people trying to download :) >> >> On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: >> >>> On 07.01.2013, at 15:48, James Robertson <[hidden email]> wrote: >>> >>>> Where is the sources file for 4.4? Ican get the VM, the image, and >>>> changes file - but where is the 4.4 sources file hiding? >>> >>> >>> We have been sloppy with making source files. All releases since 4.1 have >>> shipped with the same sources and growing changes. >>> >>> The plan was to condense sources for every point release, but >>> nondestructively: the changes are supposed to be compacted and appended >>> to the previous release's sources. That way, all point releases can share >>> a single sources file. >>> >>> Maybe we should finally follow through with this plan for 4.5? Or even >>> for the full 4.4 release? >>> >>> TL;DR: use 4.1 sources for 4.4 >>> >>> - Bert - >> >> James Robertson >> http://www.jarober.com >> [hidden email] >> >> >> >> > > |
|
|
On 12 January 2013 02:28, H. Hirzel <[hidden email]> wrote:
> On 1/11/13, Frank Shearar <[hidden email]> wrote: >> I've just done that, James, and also put up the Cog VMs we tested with >> 4.4 (version r2640). > > Thank you Frank, having the Cog VMs plus image and sources file for > 4.4. which were tested together is very useful. > > May I ask you to put a > http://ftp.squeak.org/4.4/SqueakV41.sources.zip > file in addition to > http://ftp.squeak.org/4.4/SqueakV41.sources.gz > for convenience of MS Windows users who do not have something like > 7-zip (http://www.7-zip.org/) installed? > > --Hannes Hi Hannes, A bit slow, but you'll find a zip. (I'm a bit surprised that Windows can't gunzip a file - doesn't Windows 7's built in unzipper support it?) I have _also_ put files called SqueakV44.sources(.gz|zip). These are identical to the V41 sources, but I've realised that for automating things you REALLY REALLY want to have the sources file name derivable from the Squeak version. At some point I will need to make Squeak 4.4 look for a SqueakV44.sources file, and I've added an item to the todo list to have Squeak 4.5 do this automatically as part of the release cycle. frank > I haven't yet uploaded Interpreter VMs. >> >> And I've update the release checklist to make sure 4.5 doesn't have >> this issue :) >> >> frank >> >> On 7 January 2013 15:03, James Robertson <[hidden email]> wrote: >>> As a small suggestion, having even a symlink labeled 4.4 would make it a >>> lot more obvious for people trying to download :) >>> >>> On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: >>> >>>> On 07.01.2013, at 15:48, James Robertson <[hidden email]> wrote: >>>> >>>>> Where is the sources file for 4.4? Ican get the VM, the image, and >>>>> changes file - but where is the 4.4 sources file hiding? >>>> >>>> >>>> We have been sloppy with making source files. All releases since 4.1 have >>>> shipped with the same sources and growing changes. >>>> >>>> The plan was to condense sources for every point release, but >>>> nondestructively: the changes are supposed to be compacted and appended >>>> to the previous release's sources. That way, all point releases can share >>>> a single sources file. >>>> >>>> Maybe we should finally follow through with this plan for 4.5? Or even >>>> for the full 4.4 release? >>>> >>>> TL;DR: use 4.1 sources for 4.4 >>>> >>>> - Bert - >>> >>> James Robertson >>> http://www.jarober.com >>> [hidden email] >>> >>> >>> >>> >> >> > |
|
|
On 16/01/13 4:40 AM, Frank Shearar wrote:
> > I have _also_ put files called SqueakV44.sources(.gz|zip). These are > identical to the V41 sources, but I've realised that for automating > things you REALLY REALLY want to have the sources file name derivable > from the Squeak version. At some point I will need to make Squeak 4.4 > look for a SqueakV44.sources file, and I've added an item to the todo > list to have Squeak 4.5 do this automatically as part of the release > cycle. Won't that cause further confusion - the same file named differently. I don't understand how a file name that never changes, can be a problem for automating a build. IMHO, it should be left alone, unless the plan described by Bert is implemented. A "temporary" solution, often becomes permanent. >>>> On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: >>>>> The plan was to condense sources for every point release, but >>>>> nondestructively: the changes are supposed to be compacted and appended >>>>> to the previous release's sources. That way, all point releases can share >>>>> a single sources file. >>>>> >>>>> Maybe we should finally follow through with this plan for 4.5? Or even >>>>> for the full 4.4 release? |
|
|
On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote:
> On 16/01/13 4:40 AM, Frank Shearar wrote: >> >> >> I have _also_ put files called SqueakV44.sources(.gz|zip). These are >> identical to the V41 sources, but I've realised that for automating >> things you REALLY REALLY want to have the sources file name derivable >> from the Squeak version. At some point I will need to make Squeak 4.4 >> look for a SqueakV44.sources file, and I've added an item to the todo >> list to have Squeak 4.5 do this automatically as part of the release >> cycle. > > > Won't that cause further confusion - the same file named differently. I > don't understand how a file name that never changes, can be a problem for > automating a build. How can I derive "SqueakV41.sources" from "4.4"? If I can't derive it, how can a script? It was an error (on my part) to not produce a SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due course, but I need to leave the SqueakV41.sources there for the moment because the current 4.4 looks for such a file. James Robertson correctly pointed out that one usually has a .sources file, so we should have such a thing. > IMHO, it should be left alone, unless the plan described by Bert is > implemented. A "temporary" solution, often becomes permanent. The "temporary" part is keeping the SqueakV41.sources there until we can be sure that 4.4 images won't look for that file, but for SqueakV44.sources instead. frank >>>>> On Jan 7, 2013, at 9:57 AM, Bert Freudenberg wrote: >>>>>> >>>>>> The plan was to condense sources for every point release, but >>>>>> nondestructively: the changes are supposed to be compacted and >>>>>> appended >>>>>> to the previous release's sources. That way, all point releases can >>>>>> share >>>>>> a single sources file. >>>>>> >>>>>> Maybe we should finally follow through with this plan for 4.5? Or even >>>>>> for the full 4.4 release? > > > |
|
|
On 16/01/13 9:24 AM, Frank Shearar wrote:
> > How can I derive "SqueakV41.sources" from "4.4"? If I can't derive it, > how can a script? You don't derive it. It never changes. > It was an error (on my part) to not produce a > SqueakV44.sources. No, it was not an error. AFAIK, the sources file should not change names, unless you do a condense sources. IIRC, prior to the appearance of SqueakV41.sources, the sources file was only condensed on a full release (i.e. SqueakV5.sources should have been next), not on a point release. Somehow, a decision was made to do the condense on the 4.1 release, probably because the changes file got too big (and there used to be (still is?), a limit on the size of the changes file). > James Robertson > correctly pointed out that one usually has a .sources file, so we > should have such a thing. The .sources files was packaged with the all in one release, and sometimes with the VM. IIRC, the releases only ever included the .image/.changes. You either already had the .sources file installed from before, or you were able to download it by itself. James is correct that there's usually a .sources file. But that does not mean there is supposed to be a SqueakV44.sources file. |
|
|
On 16 January 2013 16:04, Yanni Chiu <[hidden email]> wrote:
> On 16/01/13 9:24 AM, Frank Shearar wrote: >> >> >> How can I derive "SqueakV41.sources" from "4.4"? If I can't derive it, >> how can a script? > > > You don't derive it. It never changes. How do you know what sources file goes with what version? We're _supposed_ to have a distinct sources file for every release (see Bert's recent mail on the matter), and we don't. Yet. Because this _will_ be the case going forward. >> It was an error (on my part) to not produce a >> >> SqueakV44.sources. > > > No, it was not an error. AFAIK, the sources file should not change names, > unless you do a condense sources. Fine, you're right, SqueakV44.sources being a copy of SqueakV41.sources is a bit lame. If you like, the error is that we didn't condense sources, and we should for every release. Nevertheless, my point still stands: you cannot build reliable automated scripts, and if you don't have a sources file, you can't automate things, because your image will bring up a nice warning dialog that you can never see because it's headless. > IIRC, prior to the appearance of SqueakV41.sources, the sources file was > only condensed on a full release (i.e. SqueakV5.sources should have been > next), not on a point release. Somehow, a decision was made to do the > condense on the 4.1 release, probably because the changes file got too big > (and there used to be (still is?), a limit on the size of the changes file). Well. I would be fine with either a condense on a major release or a minor release, if it was ALWAYS true. Consistency is the mother of automation. But that's not where we are. frank >> James Robertson >> >> correctly pointed out that one usually has a .sources file, so we >> should have such a thing. > > > The .sources files was packaged with the all in one release, and sometimes > with the VM. IIRC, the releases only ever included the .image/.changes. You > either already had the .sources file installed from before, or you were able > to download it by itself. > > James is correct that there's usually a .sources file. But that does not > mean there is supposed to be a SqueakV44.sources file. > > |
|
|
On 16/01/13 11:12 AM, Frank Shearar wrote:
> > Fine, you're right, SqueakV44.sources being a copy of > SqueakV41.sources is a bit lame. If you like, the error is that we > didn't condense sources, and we should for every release. It's not clear that any error was made. The "plan" apparently was to condense sources "non-destructively". But, condense sources is destructive, at the moment. So, without doing the work to make it a non-destructive condense, then the only option was to do the same as before - which is to use SqueakV41.sources. > > Well. I would be fine with either a condense on a major release or a > minor release, if it was ALWAYS true. Consistency is the mother of > automation. But that's not where we are. SqueakV41.sources is an anomaly. That's where we're at. My original point was that introducing SqueakV44.sources as an "alias" name for SqueakV41.sources does not improve the current situation, IMHO. |
|
|
On Wed, Jan 16, 2013 at 12:02:48PM -0500, Yanni Chiu wrote:
> On 16/01/13 11:12 AM, Frank Shearar wrote: > > > >Fine, you're right, SqueakV44.sources being a copy of > >SqueakV41.sources is a bit lame. If you like, the error is that we > >didn't condense sources, and we should for every release. > > It's not clear that any error was made. The "plan" apparently was to > condense sources "non-destructively". But, condense sources is > destructive, at the moment. So, without doing the work to make it a > non-destructive condense, then the only option was to do the same as > before - which is to use SqueakV41.sources. > > > > >Well. I would be fine with either a condense on a major release or a > >minor release, if it was ALWAYS true. Consistency is the mother of > >automation. But that's not where we are. > > SqueakV41.sources is an anomaly. That's where we're at. My original > point was that introducing SqueakV44.sources as an "alias" name for > SqueakV41.sources does not improve the current situation, IMHO. +1 Dave |
|
|
In reply to this post by Yanni Chiu
On 16 January 2013 17:02, Yanni Chiu <[hidden email]> wrote:
> On 16/01/13 11:12 AM, Frank Shearar wrote: >> >> >> Fine, you're right, SqueakV44.sources being a copy of >> SqueakV41.sources is a bit lame. If you like, the error is that we >> didn't condense sources, and we should for every release. > > > It's not clear that any error was made. The "plan" apparently was to > condense sources "non-destructively". But, condense sources is destructive, > at the moment. So, without doing the work to make it a non-destructive > condense, then the only option was to do the same as before - which is to > use SqueakV41.sources. It's clear to me that I made an error :). There's no obvious link between Squeak4.4-12327.zip and SqueakV41.sources. There could be if there was a SqueakV4.sources, there could be if there was (as there is now) a SqueakV44.sources. In general: I want a clear, obvious, trivial mapping between a zipball and the sources file that goes with it. I've worked around the issue in the CI builds by putting the SqueakV1.sources in the repository with the image. Now's the time for me to fix this, and make sure that the release process makes a zipball called SqueakM.N-KKKK and a sources file called SqueakVMN.sources.gz. This allows for the automated deployment of a bunch of stuff: to CI environments today, and to Heroku tomorrow. (It's supposed to be possible to deploy images without sources files. I haven't been able to get this to work for me. That, too, would satisfy me.) >> Well. I would be fine with either a condense on a major release or a >> minor release, if it was ALWAYS true. Consistency is the mother of >> automation. But that's not where we are. > > > SqueakV41.sources is an anomaly. That's where we're at. My original point > was that introducing SqueakV44.sources as an "alias" name for > SqueakV41.sources does not improve the current situation, IMHO. It's an alias for 12327, sure. I don't want it to be an alias going forward. I want it to be the actual proper sources file for the 4.4 releases. And when the next release comes out, and I delete Squeak4.4-12327.zip, I'll delete the SqueakV41.sources and the alias problem will disappear! frank |
|
|
On 16/01/13 1:38 PM, Frank Shearar wrote:
> > (It's supposed to be possible to deploy images without sources files. > I haven't been able to get this to work for me. That, too, would > satisfy me.) I keep the .sources files with the VM, and never have to download a .sources file for new releases. If I didn't want to save the space, I would have all the previous squeak .sources there too. Right now, there's just PharoV10.sources and SqueakV41.sources. Assuming condense sources is done in the future, when would the SqueakV4x.sources start to appear? Once the first release candidate is declared? Or, just after the final release candidate? > > It's an alias for 12327, sure. I don't want it to be an alias going > forward. I want it to be the actual proper sources file for the 4.4 > releases. It's premature to introduce SqueakV44.sources, on the faint hope that in the near future, the non-destructive condense sources will appear. In my experience, I've seen lots of baggage get introduced, in preparation for when the rewrite, improved, etc. thing appears - and then it doesn't. But, we get stuck with the "prep" stuff (i.e. multiple copies of SqueakV41.sources, with different names). > And when the next release comes out, and I delete > Squeak4.4-12327.zip, I'll delete the SqueakV41.sources and the alias > problem will disappear! "delete" a release! That sounds like a completely wrong process. IIUC, 4.4 is now released. It uses SqueakV41.sources. Now you want to release another 4.4 that uses SqueakV44.sources - that is exactly the same as SqueakV41.sources. Doesn't that create further confusion? I don't see why this can't be addressed in 4.5. |
|
|
On 16 January 2013 21:44, Yanni Chiu <[hidden email]> wrote:
> On 16/01/13 1:38 PM, Frank Shearar wrote: >> >> >> (It's supposed to be possible to deploy images without sources files. >> I haven't been able to get this to work for me. That, too, would >> satisfy me.) > > > I keep the .sources files with the VM, and never have to download a > .sources file for new releases. If I didn't want to save the space, I > would have all the previous squeak .sources there too. Right now, > there's just PharoV10.sources and SqueakV41.sources. > > Assuming condense sources is done in the future, when would the > SqueakV4x.sources start to appear? Once the first release candidate is > declared? Or, just after the final release candidate? > > >> >> It's an alias for 12327, sure. I don't want it to be an alias going >> forward. I want it to be the actual proper sources file for the 4.4 >> releases. > > > It's premature to introduce SqueakV44.sources, on the faint hope that in > the near future, the non-destructive condense sources will appear. In my > experience, I've seen lots of baggage get introduced, in preparation for > when the rewrite, improved, etc. thing appears - and then it doesn't. > But, we get stuck with the "prep" stuff (i.e. multiple copies of > SqueakV41.sources, with different names). I don't care about condensed sources, destructive or otherwise. I care about scriptability, and hooking Squeak up to everything in the world. >> And when the next release comes out, and I delete >> Squeak4.4-12327.zip, I'll delete the SqueakV41.sources and the alias >> problem will disappear! > > > "delete" a release! That sounds like a completely wrong process. >> IIUC, 4.4 is now released. It uses SqueakV41.sources. Now you want to > release another 4.4 that uses SqueakV44.sources - that is exactly the > same as SqueakV41.sources. Doesn't that create further confusion? I > don't see why this can't be addressed in 4.5. They might have the same content, but they are semantically different. But I'm tired of arguing. Please propose a means that I can, with an absolute minimum of effort find the sources file corresponding to a given Squeak version, both for 4.4 and for arbitrary versions in the future. I repeat: _all I want_ is a _simple_ correspondence between a released Squeak and the source file that it needs. One that a shell script can calculate. One that doesn't involve scraping links off a web page. Deploying without sources might also work, but then you lose debuggability. frank |
|
|
In reply to this post by Frank Shearar-3
On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote: > On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote: >> On 16/01/13 4:40 AM, Frank Shearar wrote: >>> >>> >>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are >>> identical to the V41 sources, but I've realised that for automating >>> things you REALLY REALLY want to have the sources file name derivable >>> from the Squeak version. At some point I will need to make Squeak 4.4 >>> look for a SqueakV44.sources file, and I've added an item to the todo >>> list to have Squeak 4.5 do this automatically as part of the release >>> cycle. >> >> >> Won't that cause further confusion - the same file named differently. I >> don't understand how a file name that never changes, can be a problem for >> automating a build. > > How can I derive "SqueakV41.sources" from "4.4"? If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking? - Bert - > If I can't derive it, > how can a script? It was an error (on my part) to not produce a > SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due > course, but I need to leave the SqueakV41.sources there for the moment > because the current 4.4 looks for such a file. James Robertson > correctly pointed out that one usually has a .sources file, so we > should have such a thing. > >> IMHO, it should be left alone, unless the plan described by Bert is >> implemented. A "temporary" solution, often becomes permanent. > > The "temporary" part is keeping the SqueakV41.sources there until we > can be sure that 4.4 images won't look for that file, but for > SqueakV44.sources instead. > > frank |
|
|
On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote:
> > On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote: > >> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote: >>> On 16/01/13 4:40 AM, Frank Shearar wrote: >>>> >>>> >>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are >>>> identical to the V41 sources, but I've realised that for automating >>>> things you REALLY REALLY want to have the sources file name derivable >>>> from the Squeak version. At some point I will need to make Squeak 4.4 >>>> look for a SqueakV44.sources file, and I've added an item to the todo >>>> list to have Squeak 4.5 do this automatically as part of the release >>>> cycle. >>> >>> >>> Won't that cause further confusion - the same file named differently. I >>> don't understand how a file name that never changes, can be a problem for >>> automating a build. >> >> How can I derive "SqueakV41.sources" from "4.4"? > > If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking? Maybe I'm getting misunderstood because it's not clear that I'm talking about the _names_ of files, not the contents. If I want to write a buildpack to deploy a Smalltalk application to Heroku, I'll have an environment variable called SQUEAK_VERSION and another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string "4.4-12327". With that I can find out where exactly to find an image tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a simple string manipulation. But there is no easy, simple, reliable way for me to say "oh, and the sources that corresponds to that is of course called "SqueakV44.sources.gz" because my release process had a bug in it. I really don't care whether the sources file for 4.4 is condensed. I care that it _has_ a sources file, and I care that its _name_ is trivially derivable/calculable from the version _name_. This isn't a hypothetical question about a maybe thing. I have the buildpack right now. I just can't finish it because I can't write a script to find the sources file. (Scraping http://ftp.squeak.org/4.4/ for URLs is so made of fail that I'm not going to contemplate it.) frank > - Bert - > >> If I can't derive it, >> how can a script? It was an error (on my part) to not produce a >> SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due >> course, but I need to leave the SqueakV41.sources there for the moment >> because the current 4.4 looks for such a file. James Robertson >> correctly pointed out that one usually has a .sources file, so we >> should have such a thing. >> >>> IMHO, it should be left alone, unless the plan described by Bert is >>> implemented. A "temporary" solution, often becomes permanent. >> >> The "temporary" part is keeping the SqueakV41.sources there until we >> can be sure that 4.4 images won't look for that file, but for >> SqueakV44.sources instead. >> >> frank > > > > > |
|
|
On 16.01.2013, at 14:50, Frank Shearar <[hidden email]> wrote: > On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote: >> >> On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote: >> >>> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote: >>>> On 16/01/13 4:40 AM, Frank Shearar wrote: >>>>> >>>>> >>>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are >>>>> identical to the V41 sources, but I've realised that for automating >>>>> things you REALLY REALLY want to have the sources file name derivable >>>>> from the Squeak version. At some point I will need to make Squeak 4.4 >>>>> look for a SqueakV44.sources file, and I've added an item to the todo >>>>> list to have Squeak 4.5 do this automatically as part of the release >>>>> cycle. >>>> >>>> >>>> Won't that cause further confusion - the same file named differently. I >>>> don't understand how a file name that never changes, can be a problem for >>>> automating a build. >>> >>> How can I derive "SqueakV41.sources" from "4.4"? >> >> If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking? > > Maybe I'm getting misunderstood because it's not clear that I'm > talking about the _names_ of files, not the contents. > > If I want to write a buildpack to deploy a Smalltalk application to > Heroku, I'll have an environment variable called SQUEAK_VERSION and > another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string > "4.4-12327". With that I can find out where exactly to find an image > tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a > simple string manipulation. But there is no easy, simple, reliable way > for me to say "oh, and the sources that corresponds to that is of > course called "SqueakV44.sources.gz" because my release process had a > bug in it. I really don't care whether the sources file for 4.4 is > condensed. I care that it _has_ a sources file, and I care that its > _name_ is trivially derivable/calculable from the version _name_. > > This isn't a hypothetical question about a maybe thing. I have the > buildpack right now. I just can't finish it because I can't write a > script to find the sources file. (Scraping http://ftp.squeak.org/4.4/ > for URLs is so made of fail that I'm not going to contemplate it.) > > frank How about producing a Squeak4.5-12345.sources, and making Squeak look for that first, and SqueakV45.sources secondly? Or maybe the other way around would make more sense, as there only would be a SqueakV45.sources when the release goes golden, so the release would not unnecessarily try to open a non-existing file. The problem we had with condensing sources in the past is that we had files with different contents but the same name produced at different stages of the release. Putting the build number into the file name fro pre-releases would solve that. - Bert - |
|
|
On 16.01.2013, at 15:03, Bert Freudenberg <[hidden email]> wrote: > > On 16.01.2013, at 14:50, Frank Shearar <[hidden email]> wrote: > >> On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote: >>> >>>> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote: >>>>> On 16/01/13 4:40 AM, Frank Shearar wrote: >>>>>> >>>>>> >>>>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are >>>>>> identical to the V41 sources, but I've realised that for automating >>>>>> things you REALLY REALLY want to have the sources file name derivable >>>>>> from the Squeak version. At some point I will need to make Squeak 4.4 >>>>>> look for a SqueakV44.sources file, and I've added an item to the todo >>>>>> list to have Squeak 4.5 do this automatically as part of the release >>>>>> cycle. >>>>> >>>>> >>>>> Won't that cause further confusion - the same file named differently. I >>>>> don't understand how a file name that never changes, can be a problem for >>>>> automating a build. >>>> >>>> How can I derive "SqueakV41.sources" from "4.4"? >>> >>> If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking? >> >> Maybe I'm getting misunderstood because it's not clear that I'm >> talking about the _names_ of files, not the contents. >> >> If I want to write a buildpack to deploy a Smalltalk application to >> Heroku, I'll have an environment variable called SQUEAK_VERSION and >> another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string >> "4.4-12327". With that I can find out where exactly to find an image >> tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a >> simple string manipulation. But there is no easy, simple, reliable way >> for me to say "oh, and the sources that corresponds to that is of >> course called "SqueakV44.sources.gz" because my release process had a >> bug in it. I really don't care whether the sources file for 4.4 is >> condensed. I care that it _has_ a sources file, and I care that its >> _name_ is trivially derivable/calculable from the version _name_. >> >> This isn't a hypothetical question about a maybe thing. I have the >> buildpack right now. I just can't finish it because I can't write a >> script to find the sources file. (Scraping http://ftp.squeak.org/4.4/ >> for URLs is so made of fail that I'm not going to contemplate it.) >> >> frank > > > How about producing a Squeak4.5-12345.sources, and making Squeak look for that first, and SqueakV45.sources secondly? Or maybe the other way around would make more sense, as there only would be a SqueakV45.sources when the release goes golden, so the release would not unnecessarily try to open a non-existing file. > > The problem we had with condensing sources in the past is that we had files with different contents but the same name produced at different stages of the release. Putting the build number into the file name fro pre-releases would solve that. > > - Bert - And in case this hasn't been mentioned yet, the non-desctructive condense sources is this: Smalltalk appendChangesTo: 'test123.sources' - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |