I loaded Seaside in an updated Squeak image [1] and I've made it
available for download [2]. 1502/1504 tests pass. I started the server and looked at the demo pages and they look alright. Perhaps this could be added to the Jenkins server? Chris [1] hand loaded ConfigurationOfGofer from MonticelloRepository (Smalltalk at: #ConfigurationOfGofer) load. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) load. [2] http://osrcon.ca/downloads/Seaside3.0.7.zip |
On 4 June 2013 21:58, Chris Cunnington <[hidden email]> wrote:
> I loaded Seaside in an updated Squeak image [1] and I've made it available > for download [2]. 1502/1504 tests pass. I started the server and looked at > the demo pages and they look alright. Perhaps this could be added to the > Jenkins server? Thanks, Chris! I took a stab a while back at adding Seaside to the build scripts through the usual fashion - take a blank 4.5 and load it up. The process took far too long to be useful. But we could add a special-case build that took some vintage image with Seaside loaded in, and update that and run the Seaside tests. I don't understand the version string though - even in 4.5 the update number's only #12637. frank > Chris > > > [1] hand loaded ConfigurationOfGofer from MonticelloRepository > > (Smalltalk at: #ConfigurationOfGofer) load. > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside30'; > load. > (Smalltalk at: #ConfigurationOfSeaside30) load. > > [2] http://osrcon.ca/downloads/Seaside3.0.7.zip > |
Please note that a squeak 4.4/Seaside 3.0.8
Image and all-in-one bundle is readily availabe from the ftp :) Frank also should have the respective install script.. Best Tobias Am 04.06.2013 um 23:08 schrieb Frank Shearar <[hidden email]>: > On 4 June 2013 21:58, Chris Cunnington <[hidden email]> wrote: >> I loaded Seaside in an updated Squeak image [1] and I've made it available >> for download [2]. 1502/1504 tests pass. I started the server and looked at >> the demo pages and they look alright. Perhaps this could be added to the >> Jenkins server? > > Thanks, Chris! > > I took a stab a while back at adding Seaside to the build scripts > through the usual fashion - take a blank 4.5 and load it up. The > process took far too long to be useful. But we could add a > special-case build that took some vintage image with Seaside loaded > in, and update that and run the Seaside tests. > > I don't understand the version string though - even in 4.5 the update > number's only #12637. > > frank > >> Chris >> >> >> [1] hand loaded ConfigurationOfGofer from MonticelloRepository >> >> (Smalltalk at: #ConfigurationOfGofer) load. >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSeaside30'; >> load. >> (Smalltalk at: #ConfigurationOfSeaside30) load. >> >> [2] http://osrcon.ca/downloads/Seaside3.0.7.zip > |
On 4 June 2013 22:39, Tobias Pape <[hidden email]> wrote:
> Please note that a squeak 4.4/Seaside 3.0.8 > Image and all-in-one bundle is readily availabe from the ftp :) > > Frank also should have the respective install script.. Yep: https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scripts/Seaside.st I don't yet have a separate script to build one of these from scratch, but I'll add it to the todo list. frank > Best > Tobias > > Am 04.06.2013 um 23:08 schrieb Frank Shearar <[hidden email]>: > >> On 4 June 2013 21:58, Chris Cunnington <[hidden email]> wrote: >>> I loaded Seaside in an updated Squeak image [1] and I've made it available >>> for download [2]. 1502/1504 tests pass. I started the server and looked at >>> the demo pages and they look alright. Perhaps this could be added to the >>> Jenkins server? >> >> Thanks, Chris! >> >> I took a stab a while back at adding Seaside to the build scripts >> through the usual fashion - take a blank 4.5 and load it up. The >> process took far too long to be useful. But we could add a >> special-case build that took some vintage image with Seaside loaded >> in, and update that and run the Seaside tests. >> >> I don't understand the version string though - even in 4.5 the update >> number's only #12637. >> >> frank >> >>> Chris >>> >>> >>> [1] hand loaded ConfigurationOfGofer from MonticelloRepository >>> >>> (Smalltalk at: #ConfigurationOfGofer) load. >>> >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfSeaside30'; >>> load. >>> (Smalltalk at: #ConfigurationOfSeaside30) load. >>> >>> [2] http://osrcon.ca/downloads/Seaside3.0.7.zip |
You might want to shorten the scripts trailer, it contains fairly random cleanup code
and condenses the changes file, which might not be desirable. Or “Someone” should make a ReleaseBuilderSeaside... Best Tobias Am 05.06.2013 um 10:43 schrieb Frank Shearar <[hidden email]>: > On 4 June 2013 22:39, Tobias Pape <[hidden email]> wrote: >> Please note that a squeak 4.4/Seaside 3.0.8 >> Image and all-in-one bundle is readily availabe from the ftp :) >> >> Frank also should have the respective install script.. > > Yep: https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scripts/Seaside.st > > I don't yet have a separate script to build one of these from scratch, > but I'll add it to the todo list. > > frank > >> Best >> Tobias >> >> Am 04.06.2013 um 23:08 schrieb Frank Shearar <[hidden email]>: >> >>> On 4 June 2013 21:58, Chris Cunnington <[hidden email]> wrote: >>>> I loaded Seaside in an updated Squeak image [1] and I've made it available >>>> for download [2]. 1502/1504 tests pass. I started the server and looked at >>>> the demo pages and they look alright. Perhaps this could be added to the >>>> Jenkins server? >>> >>> Thanks, Chris! >>> >>> I took a stab a while back at adding Seaside to the build scripts >>> through the usual fashion - take a blank 4.5 and load it up. The >>> process took far too long to be useful. But we could add a >>> special-case build that took some vintage image with Seaside loaded >>> in, and update that and run the Seaside tests. >>> >>> I don't understand the version string though - even in 4.5 the update >>> number's only #12637. >>> >>> frank >>> >>>> Chris >>>> >>>> >>>> [1] hand loaded ConfigurationOfGofer from MonticelloRepository >>>> >>>> (Smalltalk at: #ConfigurationOfGofer) load. >>>> >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfSeaside30'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfSeaside30) load. >>>> >>>> [2] http://osrcon.ca/downloads/Seaside3.0.7.zip > |
In reply to this post by Frank Shearar-3
On Tue, 4 Jun 2013, Frank Shearar wrote:
> I don't understand the version string though - even in 4.5 the update > number's only #12637. The cause of the problem is that you removed some packages from the image used by Jenkins (without bumping the version of the VersionNumber package, which is used for ensuring monotonity of the Trunk's version number). People who are updating older images have those packages, so the version number is higher. I think there's no easy solution for this issue, because the original idea was to make packages unloadable, instead of unloading them and make them loadable. Levente > > frank > |
On 5 June 2013 12:06, Levente Uzonyi <[hidden email]> wrote:
> On Tue, 4 Jun 2013, Frank Shearar wrote: > >> I don't understand the version string though - even in 4.5 the update >> number's only #12637. > > > The cause of the problem is that you removed some packages from the image > used by Jenkins (without bumping the version of the VersionNumber package, > which is used for ensuring monotonity of the Trunk's version number). > People who are updating older images have those packages, so the version > number is higher. I'm trying, and failing, to find any documentation so that I don't repeat this messup. I certainly removed packages, but I removed them from a 4.5 image, hence off http://source.squeak.org/trunk and not http://source/squeak.org/4.4. frank > I think there's no easy solution for this issue, because the original idea > was to make packages unloadable, instead of unloading them and make them > loadable. > > Levente > >> >> frank |
On 5 June 2013 12:25, Frank Shearar <[hidden email]> wrote:
> On 5 June 2013 12:06, Levente Uzonyi <[hidden email]> wrote: >> On Tue, 4 Jun 2013, Frank Shearar wrote: >> >>> I don't understand the version string though - even in 4.5 the update >>> number's only #12637. >> >> >> The cause of the problem is that you removed some packages from the image >> used by Jenkins (without bumping the version of the VersionNumber package, >> which is used for ensuring monotonity of the Trunk's version number). >> People who are updating older images have those packages, so the version >> number is higher. > > I'm trying, and failing, to find any documentation so that I don't > repeat this messup. I certainly removed packages, but I removed them > from a 4.5 image, hence off http://source.squeak.org/trunk and not > http://source/squeak.org/4.4. OK, I think I understand. Utilities class >> #setSystemVersionFromConfig: sets the update number to the sum of the version numbers in the latest config. Which explains why Tony's update number is around 100 past what I think it should be; he has XML-Parser (35), Universes (45) and Nebraska (33) loaded, adding 35 + 45 + 33 = 113 to his total. So perhaps the thing I should have done is that when I removed these packages, I should have incremented SqueakVersion's version number by 114? frank > frank > >> I think there's no easy solution for this issue, because the original idea >> was to make packages unloadable, instead of unloading them and make them >> loadable. >> >> Levente >> >>> >>> frank |
yes 2013/6/14 Frank Shearar <[hidden email]> On 5 June 2013 12:25, Frank Shearar <[hidden email]> wrote: |
Is it too late to change this? And can we _document_ this somewhere?
frank On 14 June 2013 22:31, Nicolas Cellier <[hidden email]> wrote: > yes > > > 2013/6/14 Frank Shearar <[hidden email]> >> >> On 5 June 2013 12:25, Frank Shearar <[hidden email]> wrote: >> > On 5 June 2013 12:06, Levente Uzonyi <[hidden email]> wrote: >> >> On Tue, 4 Jun 2013, Frank Shearar wrote: >> >> >> >>> I don't understand the version string though - even in 4.5 the update >> >>> number's only #12637. >> >> >> >> >> >> The cause of the problem is that you removed some packages from the >> >> image >> >> used by Jenkins (without bumping the version of the VersionNumber >> >> package, >> >> which is used for ensuring monotonity of the Trunk's version number). >> >> People who are updating older images have those packages, so the >> >> version >> >> number is higher. >> > >> > I'm trying, and failing, to find any documentation so that I don't >> > repeat this messup. I certainly removed packages, but I removed them >> > from a 4.5 image, hence off http://source.squeak.org/trunk and not >> > http://source/squeak.org/4.4. >> >> OK, I think I understand. Utilities class >> >> #setSystemVersionFromConfig: sets the update number to the sum of the >> version numbers in the latest config. >> >> Which explains why Tony's update number is around 100 past what I >> think it should be; he has XML-Parser (35), Universes (45) and >> Nebraska (33) loaded, adding 35 + 45 + 33 = 113 to his total. >> >> So perhaps the thing I should have done is that when I removed these >> packages, I should have incremented SqueakVersion's version number by >> 114? >> >> frank >> >> > frank >> > >> >> I think there's no easy solution for this issue, because the original >> >> idea >> >> was to make packages unloadable, instead of unloading them and make >> >> them >> >> loadable. >> >> >> >> Levente >> >> >> >>> >> >>> frank >> > > > > |
It is not too late, it is too *early*.
You bump the VersionNumber package at the same moment you remove a package from the configuration. I'm not exactly sure how the stripped image is updated. I thought you simply have updateMissingPackages set to false and you skip the unloaded packages by using MCMcmUpdater's skipPackages? In that case, shouldn't the sum of the config map versions still be the same? The number should only differ if you actually remove packages from the config. - Bert - On 2013-06-14, at 23:36, Frank Shearar <[hidden email]> wrote: > Is it too late to change this? And can we _document_ this somewhere? > > frank > > On 14 June 2013 22:31, Nicolas Cellier > <[hidden email]> wrote: >> yes >> >> >> 2013/6/14 Frank Shearar <[hidden email]> >>> >>> On 5 June 2013 12:25, Frank Shearar <[hidden email]> wrote: >>>> On 5 June 2013 12:06, Levente Uzonyi <[hidden email]> wrote: >>>>> On Tue, 4 Jun 2013, Frank Shearar wrote: >>>>> >>>>>> I don't understand the version string though - even in 4.5 the update >>>>>> number's only #12637. >>>>> >>>>> >>>>> The cause of the problem is that you removed some packages from the >>>>> image >>>>> used by Jenkins (without bumping the version of the VersionNumber >>>>> package, >>>>> which is used for ensuring monotonity of the Trunk's version number). >>>>> People who are updating older images have those packages, so the >>>>> version >>>>> number is higher. >>>> >>>> I'm trying, and failing, to find any documentation so that I don't >>>> repeat this messup. I certainly removed packages, but I removed them >>>> from a 4.5 image, hence off http://source.squeak.org/trunk and not >>>> http://source/squeak.org/4.4. >>> >>> OK, I think I understand. Utilities class >> >>> #setSystemVersionFromConfig: sets the update number to the sum of the >>> version numbers in the latest config. >>> >>> Which explains why Tony's update number is around 100 past what I >>> think it should be; he has XML-Parser (35), Universes (45) and >>> Nebraska (33) loaded, adding 35 + 45 + 33 = 113 to his total. >>> >>> So perhaps the thing I should have done is that when I removed these >>> packages, I should have incremented SqueakVersion's version number by >>> 114? >>> >>> frank >>> >>>> frank >>>> >>>>> I think there's no easy solution for this issue, because the original >>>>> idea >>>>> was to make packages unloadable, instead of unloading them and make >>>>> them >>>>> loadable. >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> frank >>> >> >> >> >> > |
Free forum by Nabble | Edit this page |