Right now the "Future Directions" workspace says this:
<quote> - This image is ~15M. If you execute - Smalltalk unloadAllKnownPackages - it will become ~10M - A SqueakCore image is available at http://ftp.squeak.org/4.4 - A reasonable target is the creation of a smaller image, which may be a task before the community - A place to explore where to make reductions is likely the removal/replacement of GUIs - Once we have a smaller core image, we can employ Andreas Raab''s memo [1] on how to load code back into the image. This will be based on tests delineating the separate responsibilities of core and application developers [1]]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html </quote> I'm reasonably happy with the above, unless someone has something extra cool they'd like to mention? frank |
]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html
Seems like wrong link ? Karl On Wed, Dec 5, 2012 at 11:25 PM, Frank Shearar <[hidden email]> wrote: Right now the "Future Directions" workspace says this: |
On 5 December 2012 22:41, karl ramberg <[hidden email]> wrote:
> ]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html > > Seems like wrong link ? See, that's why QA is important! Thanks! frank > Karl > > > On Wed, Dec 5, 2012 at 11:25 PM, Frank Shearar <[hidden email]> > wrote: >> >> Right now the "Future Directions" workspace says this: >> >> <quote> >> - This image is ~15M. If you execute - Smalltalk >> unloadAllKnownPackages - it will become ~10M >> >> - A SqueakCore image is available at http://ftp.squeak.org/4.4 >> >> - A reasonable target is the creation of a smaller image, which may be >> a task before the community >> >> - A place to explore where to make reductions is likely the >> removal/replacement of GUIs >> >> - Once we have a smaller core image, we can employ Andreas Raab''s >> memo [1] on how to load code back into the image. This will be based >> on tests delineating the separate responsibilities of core and >> application developers >> >> >> [1]]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html >> </quote> >> >> I'm reasonably happy with the above, unless someone has something >> extra cool they'd like to mention? >> >> frank >> > > > > |
On 2012-12-05 5:42 PM, Frank Shearar wrote:
> On 5 December 2012 22:41, karl ramberg <[hidden email]> wrote: >> ]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html >> >> Seems like wrong link ? > See, that's why QA is important! Thanks! > > frank > >> Karl >> >> >> On Wed, Dec 5, 2012 at 11:25 PM, Frank Shearar <[hidden email]> >> wrote: >>> Right now the "Future Directions" workspace says this: >>> >>> <quote> >>> - This image is ~15M. If you execute - Smalltalk >>> unloadAllKnownPackages - it will become ~10M >>> >>> - A SqueakCore image is available at http://ftp.squeak.org/4.4 >>> >>> - A reasonable target is the creation of a smaller image, which may be >>> a task before the community >>> >>> - A place to explore where to make reductions is likely the >>> removal/replacement of GUIs >>> >>> - Once we have a smaller core image, we can employ Andreas Raab''s >>> memo [1] on how to load code back into the image. This will be based >>> on tests delineating the separate responsibilities of core and >>> application developers >>> >>> >>> [1]]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html >>> </quote> >>> >>> I'm reasonably happy with the above, unless someone has something >>> extra cool they'd like to mention? >>> >>> frank >>> >> >> >> Chris |
In reply to this post by Frank Shearar-3
On 2012-12-05 5:42 PM, Frank Shearar wrote:
> On 5 December 2012 22:41, karl ramberg <[hidden email]> wrote: >> ]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html >> >> Seems like wrong link ? > See, that's why QA is important! Thanks! > > frank > >> Karl >> >> >> On Wed, Dec 5, 2012 at 11:25 PM, Frank Shearar <[hidden email]> >> wrote: >>> Right now the "Future Directions" workspace says this: >>> >>> <quote> >>> - This image is ~15M. If you execute - Smalltalk >>> unloadAllKnownPackages - it will become ~10M >>> >>> - A SqueakCore image is available at http://ftp.squeak.org/4.4 >>> >>> - A reasonable target is the creation of a smaller image, which may be >>> a task before the community >>> >>> - A place to explore where to make reductions is likely the >>> removal/replacement of GUIs >>> >>> - Once we have a smaller core image, we can employ Andreas Raab''s >>> memo [1] on how to load code back into the image. This will be based >>> on tests delineating the separate responsibilities of core and >>> application developers >>> >>> >>> [1]]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html >>> </quote> >>> >>> I'm reasonably happy with the above, unless someone has something >>> extra cool they'd like to mention? >>> >>> frank >>> >> >> >> This is it: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150469.html Chris |
In reply to this post by Frank Shearar-3
On 12/5/12 8:25 PM, "Frank Shearar" <[hidden email]> wrote: > A SqueakCore image is available at http://ftp.squeak.org/4.4 No, such directory is empty. The last one is in http://ftp.squeak.org/4.3alpha/SqueakCore4.3alpha-11722.zip And could update to last trunk using the regular VM , not the CogVM. With this , many handicapped hardware as my own G4's and Pentium 3's could run it > - A reasonable target is the creation of a smaller image, which may be > a task before the community +1 > - Once we have a smaller core image, we can employ Andreas Raab''s > memo [1] on how to load code back into the image. This will be based > on tests delineating the separate responsibilities of core and > application developers +1 > I'm reasonably happy with the above, unless someone has something > extra cool they'd like to mention? > > frank Like to mention you made as astounding job. Very thanks ! Edgar |
On 06 Dec 2012, at 7:25, "Edgar J. De Cleene" <[hidden email]> wrote:
> > > > On 12/5/12 8:25 PM, "Frank Shearar" <[hidden email]> wrote: > >> A SqueakCore image is available at http://ftp.squeak.org/4.4 > > No, such directory is empty. > The last one is in > http://ftp.squeak.org/4.3alpha/SqueakCore4.3alpha-11722.zip Sure. But 4.4 _will_ be there when it's released :) frank > And could update to last trunk using the regular VM , not the CogVM. > With this , many handicapped hardware as my own G4's and Pentium 3's could > run it > >> - A reasonable target is the creation of a smaller image, which may be >> a task before the community > > +1 > >> - Once we have a smaller core image, we can employ Andreas Raab''s >> memo [1] on how to load code back into the image. This will be based >> on tests delineating the separate responsibilities of core and >> application developers > > +1 > >> I'm reasonably happy with the above, unless someone has something >> extra cool they'd like to mention? >> >> frank > > Like to mention you made as astounding job. > > Very thanks ! > > Edgar > > > > |
In reply to this post by Edgar De Cleene
On Thu, Dec 06, 2012 at 05:25:56AM -0200, Edgar J. De Cleene wrote:
> > On 12/5/12 8:25 PM, "Frank Shearar" <[hidden email]> wrote: > > > A SqueakCore image is available at http://ftp.squeak.org/4.4 > > No, such directory is empty. > The last one is in > http://ftp.squeak.org/4.3alpha/SqueakCore4.3alpha-11722.zip > > And could update to last trunk using the regular VM , not the CogVM. > With this , many handicapped hardware as my own G4's and Pentium 3's could > run it Edgar, thanks for the reminder. I think that we should do two things: 1) Save the final release image as image format 6504 prior to release. This is done by resaving the image from an interpreter VM, which makes it usable by a wider range of VMs including some very old interpreter VMs that may still be in service (e.g. Edgars old Mac that does not have an updated interpreter VM available). 2) In the image, get rid of the SmalltalkImage>>okayToSave warning. This was originally added to protect users with older interpreter VMs from saving their images with Cog, rendering them unreadable on the older VM. I think, but am not certain, that the okayToSave warning has outlived its usefulness. It also presents a serious problem because if we save the release image in 6504 format (as per above), then new users will see a confusing message the first time they save their image under Cog. The warning is factually incorrect, because it says 'Images saved under Cog cannot be opened on an interpreter again!' which is true if and only if the image had been saved from an obsolete interpreter VM. In other words, for most users today the warning message is incorrect, confusing, and wrong. Comments? Dave |
On 12/6/12 11:24 AM, "David T. Lewis" <[hidden email]> wrote:
> Images saved under Cog > cannot be opened on an interpreter again!' which is true if and only > if the image had been saved from an obsolete interpreter VM. In other > words, for most users today the warning message is incorrect, confusing, > and wrong. If understand well, what you say is the update could be done with CogVm's and with some preference saved as Cog or as Legacy (that is Legacy was older VM as Squeak 4.2.5beta1U John M McIntosh). Good news to me Edgar |
In reply to this post by David T. Lewis
On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote:
> On Thu, Dec 06, 2012 at 05:25:56AM -0200, Edgar J. De Cleene wrote: >> >> On 12/5/12 8:25 PM, "Frank Shearar" <[hidden email]> wrote: >> >> > A SqueakCore image is available at http://ftp.squeak.org/4.4 >> >> No, such directory is empty. >> The last one is in >> http://ftp.squeak.org/4.3alpha/SqueakCore4.3alpha-11722.zip >> >> And could update to last trunk using the regular VM , not the CogVM. >> With this , many handicapped hardware as my own G4's and Pentium 3's could >> run it > > Edgar, thanks for the reminder. > > I think that we should do two things: > > 1) Save the final release image as image format 6504 prior to release. > This is done by resaving the image from an interpreter VM, which makes > it usable by a wider range of VMs including some very old interpreter VMs > that may still be in service (e.g. Edgars old Mac that does not have > an updated interpreter VM available). Given that our CI runs on RHell, with its attendant library problems, is it possible to use the InterpreterVM build's output in the SqueakTrunkOnInterpreter job? If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly to do the above automatically, couldn't we? frank > 2) In the image, get rid of the SmalltalkImage>>okayToSave warning. This > was originally added to protect users with older interpreter VMs from > saving their images with Cog, rendering them unreadable on the older VM. > > I think, but am not certain, that the okayToSave warning has outlived > its usefulness. It also presents a serious problem because if we save the > release image in 6504 format (as per above), then new users will see a > confusing message the first time they save their image under Cog. The > warning is factually incorrect, because it says 'Images saved under Cog > cannot be opened on an interpreter again!' which is true if and only > if the image had been saved from an obsolete interpreter VM. In other > words, for most users today the warning message is incorrect, confusing, > and wrong. > > Comments? > > Dave > > |
In reply to this post by Edgar De Cleene
On Thu, Dec 06, 2012 at 10:40:20AM -0200, Edgar J. De Cleene wrote:
> On 12/6/12 11:24 AM, "David T. Lewis" <[hidden email]> wrote: > > > Images saved under Cog > > cannot be opened on an interpreter again!' which is true if and only > > if the image had been saved from an obsolete interpreter VM. In other > > words, for most users today the warning message is incorrect, confusing, > > and wrong. > > If understand well, what you say is the update could be done with CogVm's > and with some preference saved as Cog or as Legacy (that is Legacy was older > VM as Squeak 4.2.5beta1U John M McIntosh). Yes, that is right. Resaving the image from an interpreter VM is fast and easy, so it makes sense to use Cog for the updating and image building, and just resave the final result with an interpreter VM. Cog is a *lot* faster for doing anything related to Montecello :) Dave > > Good news to me > > Edgar > > |
In reply to this post by Frank Shearar-3
On Thu, Dec 06, 2012 at 01:51:19PM +0000, Frank Shearar wrote:
> On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote: > > > > 1) Save the final release image as image format 6504 prior to release. > > This is done by resaving the image from an interpreter VM, which makes > > it usable by a wider range of VMs including some very old interpreter VMs > > that may still be in service (e.g. Edgars old Mac that does not have > > an updated interpreter VM available). > > Given that our CI runs on RHell, with its attendant library problems, > is it possible to use the InterpreterVM build's output in the > SqueakTrunkOnInterpreter job? > > If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly > to do the above automatically, couldn't we? > Yes, this can be easily added as a step in either the SqueakTrunk or SqueakTrunkOnInterpreter job on box3. It's just a matter of running the final image once more using the interpreter VM and a start script consisting of "snapshot: true andExit: true". Dave |
In reply to this post by David T. Lewis
On 2012-12-06, at 14:24, "David T. Lewis" <[hidden email]> wrote: > On Thu, Dec 06, 2012 at 05:25:56AM -0200, Edgar J. De Cleene wrote: >> >> On 12/5/12 8:25 PM, "Frank Shearar" <[hidden email]> wrote: >> >>> A SqueakCore image is available at http://ftp.squeak.org/4.4 >> >> No, such directory is empty. >> The last one is in >> http://ftp.squeak.org/4.3alpha/SqueakCore4.3alpha-11722.zip >> >> And could update to last trunk using the regular VM , not the CogVM. >> With this , many handicapped hardware as my own G4's and Pentium 3's could >> run it > > Edgar, thanks for the reminder. > > I think that we should do two things: > > 1) Save the final release image as image format 6504 prior to release. > This is done by resaving the image from an interpreter VM, which makes > it usable by a wider range of VMs including some very old interpreter VMs > that may still be in service (e.g. Edgars old Mac that does not have > an updated interpreter VM available). +1 > 2) In the image, get rid of the SmalltalkImage>>okayToSave warning. This > was originally added to protect users with older interpreter VMs from > saving their images with Cog, rendering them unreadable on the older VM. Done. > I think, but am not certain, that the okayToSave warning has outlived > its usefulness. It also presents a serious problem because if we save the > release image in 6504 format (as per above), then new users will see a > confusing message the first time they save their image under Cog. The > warning is factually incorrect, because it says 'Images saved under Cog > cannot be opened on an interpreter again!' which is true if and only > if the image had been saved from an obsolete interpreter VM. In other > words, for most users today the warning message is incorrect, confusing, > and wrong. > > Comments? > > Dave - Bert - |
In reply to this post by David T. Lewis
On 6 December 2012 16:15, David T. Lewis <[hidden email]> wrote:
> On Thu, Dec 06, 2012 at 01:51:19PM +0000, Frank Shearar wrote: >> On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote: >> > >> > 1) Save the final release image as image format 6504 prior to release. >> > This is done by resaving the image from an interpreter VM, which makes >> > it usable by a wider range of VMs including some very old interpreter VMs >> > that may still be in service (e.g. Edgars old Mac that does not have >> > an updated interpreter VM available). >> >> Given that our CI runs on RHell, with its attendant library problems, >> is it possible to use the InterpreterVM build's output in the >> SqueakTrunkOnInterpreter job? >> >> If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly >> to do the above automatically, couldn't we? >> > > Yes, this can be easily added as a step in either the SqueakTrunk or > SqueakTrunkOnInterpreter job on box3. It's just a matter of running > the final image once more using the interpreter VM and a start script > consisting of "snapshot: true andExit: true". Right. The latest SqueakTrunk build _should_ do this, if you'd like to check it in about 8 minutes? frank > Dave > > |
On 6 December 2012 17:01, Frank Shearar <[hidden email]> wrote:
> On 6 December 2012 16:15, David T. Lewis <[hidden email]> wrote: >> On Thu, Dec 06, 2012 at 01:51:19PM +0000, Frank Shearar wrote: >>> On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote: >>> > >>> > 1) Save the final release image as image format 6504 prior to release. >>> > This is done by resaving the image from an interpreter VM, which makes >>> > it usable by a wider range of VMs including some very old interpreter VMs >>> > that may still be in service (e.g. Edgars old Mac that does not have >>> > an updated interpreter VM available). >>> >>> Given that our CI runs on RHell, with its attendant library problems, >>> is it possible to use the InterpreterVM build's output in the >>> SqueakTrunkOnInterpreter job? >>> >>> If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly >>> to do the above automatically, couldn't we? >>> >> >> Yes, this can be easily added as a step in either the SqueakTrunk or >> SqueakTrunkOnInterpreter job on box3. It's just a matter of running >> the final image once more using the interpreter VM and a start script >> consisting of "snapshot: true andExit: true". > > Right. The latest SqueakTrunk build _should_ do this, if you'd like to > check it in about 8 minutes? Well. It helps if I (a) use the right syntax for a conditional and (b) don't bork the script. The script will now, hopefully, * copy the base image into the target directory * update the image * open it with an interpreter VM and save it (to get the image format right) * copy the updated image * run the tests in the copy of the updated image * produce the updated image as a build artifact That will be build #49: http://squeakci.org/job/SqueakTrunk/49/. frank >> Dave >> >> |
On 6 December 2012 21:56, Frank Shearar <[hidden email]> wrote:
> On 6 December 2012 17:01, Frank Shearar <[hidden email]> wrote: >> On 6 December 2012 16:15, David T. Lewis <[hidden email]> wrote: >>> On Thu, Dec 06, 2012 at 01:51:19PM +0000, Frank Shearar wrote: >>>> On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote: >>>> > >>>> > 1) Save the final release image as image format 6504 prior to release. >>>> > This is done by resaving the image from an interpreter VM, which makes >>>> > it usable by a wider range of VMs including some very old interpreter VMs >>>> > that may still be in service (e.g. Edgars old Mac that does not have >>>> > an updated interpreter VM available). >>>> >>>> Given that our CI runs on RHell, with its attendant library problems, >>>> is it possible to use the InterpreterVM build's output in the >>>> SqueakTrunkOnInterpreter job? >>>> >>>> If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly >>>> to do the above automatically, couldn't we? >>>> >>> >>> Yes, this can be easily added as a step in either the SqueakTrunk or >>> SqueakTrunkOnInterpreter job on box3. It's just a matter of running >>> the final image once more using the interpreter VM and a start script >>> consisting of "snapshot: true andExit: true". >> >> Right. The latest SqueakTrunk build _should_ do this, if you'd like to >> check it in about 8 minutes? > > Well. It helps if I (a) use the right syntax for a conditional and (b) > don't bork the script. The script will now, hopefully, > * copy the base image into the target directory > * update the image > * open it with an interpreter VM and save it (to get the image format right) > * copy the updated image > * run the tests in the copy of the updated image > * produce the updated image as a build artifact > > That will be build #49: http://squeakci.org/job/SqueakTrunk/49/. Indeed, the build's back in happy land. frank >>> Dave >>> >>> |
On Thu, Dec 06, 2012 at 10:16:42PM +0000, Frank Shearar wrote:
> On 6 December 2012 21:56, Frank Shearar <[hidden email]> wrote: > > On 6 December 2012 17:01, Frank Shearar <[hidden email]> wrote: > >> On 6 December 2012 16:15, David T. Lewis <[hidden email]> wrote: > >>> On Thu, Dec 06, 2012 at 01:51:19PM +0000, Frank Shearar wrote: > >>>> On 6 December 2012 13:24, David T. Lewis <[hidden email]> wrote: > >>>> > > >>>> > 1) Save the final release image as image format 6504 prior to release. > >>>> > This is done by resaving the image from an interpreter VM, which makes > >>>> > it usable by a wider range of VMs including some very old interpreter VMs > >>>> > that may still be in service (e.g. Edgars old Mac that does not have > >>>> > an updated interpreter VM available). > >>>> > >>>> Given that our CI runs on RHell, with its attendant library problems, > >>>> is it possible to use the InterpreterVM build's output in the > >>>> SqueakTrunkOnInterpreter job? > >>>> > >>>> If so, we could adjust SqueakTrunkOnInterpreter's job/script slightly > >>>> to do the above automatically, couldn't we? > >>>> > >>> > >>> Yes, this can be easily added as a step in either the SqueakTrunk or > >>> SqueakTrunkOnInterpreter job on box3. It's just a matter of running > >>> the final image once more using the interpreter VM and a start script > >>> consisting of "snapshot: true andExit: true". > >> > >> Right. The latest SqueakTrunk build _should_ do this, if you'd like to > >> check it in about 8 minutes? > > > > Well. It helps if I (a) use the right syntax for a conditional and (b) > > don't bork the script. The script will now, hopefully, > > * copy the base image into the target directory > > * update the image > > * open it with an interpreter VM and save it (to get the image format right) > > * copy the updated image > > * run the tests in the copy of the updated image > > * produce the updated image as a build artifact > > > > That will be build #49: http://squeakci.org/job/SqueakTrunk/49/. > > Indeed, the build's back in happy land. > > frank > There is a glitch in the builtastic.sh script that is preventing the image format conversion step from running. Try the attached update. Dave p.s. Yes I know I should learn how to use github ;) builtastic.sh (2K) Download Attachment |
Free forum by Nabble | Edit this page |