March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Thierry Goubier

2015-03-03 17:00 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-03-03 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean(a)clipperadams.com >>> > wrote: >>> >>>> Ben Coman wrote >>>> > Would it be feasible to have a community maintained >>>> > PharoForwardCompatability package available in the >>>> ConfigurationBrowser >>>> > that is generally available for everyone to use >>>> >>>> Great idea! If we're just talking about renames, it could just be >>>> pre-loaded, no? >>>> >>>> >>> Ideally these sort of renames would be pushed back to all previous >>> Releases, but that seems not feasible resource-wise. Its a question of ALL >>> actions required do a point-release of those older versions, and how often >>> you are able to do that. There is also the temptation that with a >>> point-Release, people will pressure to add "just one more" thing that might >>> not be a "simple rename" . >>> >>> An additional benefit of it being a Configuration loaded external onto >>> the older Releases is that people can see the changes, which is a big tip >>> for which parts of their code the should update for it to work in a later >>> version. >>> >> >> Ben, I like your idea. >> >> It would allow stable-based additional packages to include the . >> configuration as a pre-requisite (and as such make the manager of that >> package aware that it has a version working on the .1 or the .2 version). >> >> For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 >> requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for >> example) any time after ConfigurationOfPharo3.1 became available. >> > > My idea might have merit to do point releases of PharoX.x, but I think the > semantics of that are broader and likely a bigger effort than what I was > considering, which was having a ConfigurationOfPharoForwardCompatability. > But my ConfigurationOfPharo3.X are your ConfigurationOfPharoForwardCompatability. They are just numbered so that they can be relied on for deployment of large packages (and they manipulate a bit the platform so that everything works properly, that's all). Point releases of Pharo are optional. Thierry

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Ben Coman

On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-03-03 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> >> On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> Ben Coman wrote >>> > Would it be feasible to have a community maintained >>> > PharoForwardCompatability package available in the ConfigurationBrowser >>> > that is generally available for everyone to use >>> >>> Great idea! If we're just talking about renames, it could just be >>> pre-loaded, no? >>> >>> >> Ideally these sort of renames would be pushed back to all previous >> Releases, but that seems not feasible resource-wise. Its a question of ALL >> actions required do a point-release of those older versions, and how often >> you are able to do that. There is also the temptation that with a >> point-Release, people will pressure to add "just one more" thing that might >> not be a "simple rename" . >> >> An additional benefit of it being a Configuration loaded external onto >> the older Releases is that people can see the changes, which is a big tip >> for which parts of their code the should update for it to work in a later >> version. >> > > Ben, I like your idea. > > It would allow stable-based additional packages to include the . > configuration as a pre-requisite (and as such make the manager of that > package aware that it has a version working on the .1 or the .2 version). > > For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 > requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for > example) any time after ConfigurationOfPharo3.1 became available. > My idea might have merit to do point releases of PharoX.x, but I think the semantics of that are broader and likely a bigger effort than what I was considering, which was having a ConfigurationOfPharoForwardCompatability. cheers -ben

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Thierry Goubier

2015-03-03 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Ben Coman wrote >> > Would it be feasible to have a community maintained >> > PharoForwardCompatability package available in the ConfigurationBrowser >> > that is generally available for everyone to use >> >> Great idea! If we're just talking about renames, it could just be >> pre-loaded, no? >> >> > Ideally these sort of renames would be pushed back to all previous > Releases, but that seems not feasible resource-wise. Its a question of ALL > actions required do a point-release of those older versions, and how often > you are able to do that. There is also the temptation that with a > point-Release, people will pressure to add "just one more" thing that might > not be a "simple rename" . > > An additional benefit of it being a Configuration loaded external onto the > older Releases is that people can see the changes, which is a big tip for > which parts of their code the should update for it to work in a later > version. > Ben, I like your idea. It would allow stable-based additional packages to include the . configuration as a pre-requisite (and as such make the manager of that package aware that it has a version working on the .1 or the .2 version). For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for example) any time after ConfigurationOfPharo3.1 became available. The strong point is: if I don't see the need, then my SmaCC will stay at v2.0.3 for Pharo3, and will keep working even if ConfigurationOfPharo3.1 makes obsolete a key API I do use, since, by default, pharo users will download the 3.0 image. ConfigurationOfPharo3.1 should change the platform tag to #pharo3.1. To avoid that someone updates his image to 3.1, load my SmaCC planned for 3.0, and encounter errors that I don't want to handle (yet). > Also because people using the package can see the "simple" changes, there > doesn't need to be as much rigor adding stuff to it - so it can be more > community driven. Also its more dynamic - for example if this change is > made early in Pharo 5, the Pharo 4 projects can already include it and be > already adapting. Because you want to minimise the point releases of the > older versions, you would otherwise need to wait a whole year for the Pharo > 5 Release to lock down all required "renames" to back propagate. > Also, one of the points of that scheme is that those additional packages are entirely optionals: by default, there is no point release. Or, if we need the possibility to have a point release of Pharo in the stable cycle, we can call the point release .0.X (and have the platform naming follow suit). Example: Pharo3.0 released. (#pharo3.0.0) ConfigurationOfPharo3.1 released (#pharo3.1.0) ConfigurationOfPharo3.2 released (#pharo3.2.0) ConfigurationOfPharo3.3 released Pharo3.0.1 released with bugfixes (say it is judged necessary) but no API change. (#pharo3.0.1) ConfigurationOfPharo3.4 released etc... Approach being: 3.0.x is supposed to maintain a stable api (no change needed for external packages) 3.X is optional and mark/prepare changes for 4.0 How hard it would be to keep the Monkey checking on past versions of Pharo? Can I provide a SLICE for Pharo3 now and the monkey is able to say if it passes or not? I haven't tried. Thierry

March 3, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40531 Home: https://github.com/pharo-project/pharo-core

March 3, 2015

[pharo-project/pharo-core] 58e3ee: 40531

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 58e3ee9f15c9cb6cd0db4791534739939ca983e9 https://github.com/pharo-project/pharo-core/commit/58e3ee9f15c9cb6cd0db4791… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-03 (Tue, 03 Mar 2015) Changed paths: M Nautilus.package/CodeRewritingAcceptor.class/instance/protocol/accept_notifying_.st M NautilusRefactoring.package/ChangesBrowser.class/class/specs/defaultSpec.st R NautilusRefactoring.package/ChangesBrowser.class/instance/accessing/acceptButton.st R NautilusRefactoring.package/ChangesBrowser.class/instance/accessing/cancelButton.st R NautilusRefactoring.package/ChangesBrowser.class/instance/initialization/initializeAcceptButton.st R NautilusRefactoring.package/ChangesBrowser.class/instance/initialization/initializeCancelButton.st M NautilusRefactoring.package/ChangesBrowser.class/instance/initialization/initializeWidgets.st A NautilusRefactoring.package/ChangesBrowser.class/instance/opening/open.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/performing/internalPerformRefactorings_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script530.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script531.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40530.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40531.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40531 15030 ChangesBrowser should not roll own dialog https://pharo.fogbugz.com/f/cases/15030 http://files.pharo.org/image/40/40531.zip

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Ben Coman

On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > Would it be feasible to have a community maintained > > PharoForwardCompatability package available in the ConfigurationBrowser > > that is generally available for everyone to use > > Great idea! If we're just talking about renames, it could just be > pre-loaded, no? > > Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" . An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version. Also because people using the package can see the "simple" changes, there doesn't need to be as much rigor adding stuff to it - so it can be more community driven. Also its more dynamic - for example if this change is made early in Pharo 5, the Pharo 4 projects can already include it and be already adapting. Because you want to minimise the point releases of the older versions, you would otherwise need to wait a whole year for the Pharo 5 Release to lock down all required "renames" to back propagate. cheers -ben

March 3, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Marcus Denker

> On 03 Mar 2015, at 15:30, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-03-03 15:14 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> On 03 Mar 2015, at 08:06, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>>> >>>> >>>> Other things TODO to make it even smaller: >>>> >>>> - Hunt down that one GTPlayground instance that is hanging around >> >> This is *strange*. I was able to get it down to 1 >> >> Smalltalk garbageCollect. >> Smalltalk garbageCollect. >> Smalltalk garbageCollect. >> GTPlayground allInstances size. >> >> and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. >> Yet, when I download the last build, open *one* GTPlayground: >> >> GTPlayground allInstances size ==> 2. >> There is something happening that I donât understand. > > I think we found it: > > https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs… <https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs…> > Marcus > > > Maybe there is another cause: > > "A fresh image that only uses old Workspace" > > Smalltalk garbageCollect. > GTPlayground allInstances size. -> 1 > > > (RubFindReplaceService classVarNamed:#Singleton) whenDialogDeleted. > RubFindReplaceService classVarNamed:#Singleton put:nil > > Smalltalk garbageCollect. > GTPlayground allInstances size. -> 0 > > RubFindReplaceService may nead a cleanUp, too. Yes, all Singletons should be cleared on #cleanUp > The whenDialogDeleted is called on a MorphDeleted announcement, but > somehow this does not work, the method is never called, maybe the MorphDeleted is never > announced? > > Could be, yes. Marcus

March 3, 2015

Re: [Pharo-dev] Seaside on Pharo 4 CI Job ?

by Johan Brichau

no, what do you mean? > On 03 Mar 2015, at 15:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I think you mean Pharo 3.0, right? > > Doru > > On Tue, Mar 3, 2015 at 3:30 PM, Johan Brichau <johan(a)inceptive.be <mailto:johan@inceptive.be>> wrote: > Well, there is a Pharo4Seaside job (created by Stephan). > > I think it makes sense to add Pharo4 to the main build now because we should start taking care of it. > > So, itâs in now. > > btw: has anyone used the combination filter? We do not intend to keep building Seaside3.0 for Pharo4 and would like to exclude that from the build. > > Johan > > > > On 03 Mar 2015, at 10:09, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > Is there a reason we are not building Seaside on Pharo 4 with a CI job ? > > > > https://ci.inria.fr/pharo-contribution/job/Seaside/ <https://ci.inria.fr/pharo-contribution/job/Seaside/> > > > > This seems especially important as we are moving closer to a release. > > > > Sven > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

March 3, 2015

Re: [Pharo-dev] Seaside on Pharo 4 CI Job ?

by Tudor Girba

I think you mean Pharo 3.0, right? Doru On Tue, Mar 3, 2015 at 3:30 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Well, there is a Pharo4Seaside job (created by Stephan). > > I think it makes sense to add Pharo4 to the main build now because we > should start taking care of it. > > So, itâs in now. > > btw: has anyone used the combination filter? We do not intend to keep > building Seaside3.0 for Pharo4 and would like to exclude that from the > build. > > Johan > > > > On 03 Mar 2015, at 10:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Is there a reason we are not building Seaside on Pharo 4 with a CI job ? > > > > https://ci.inria.fr/pharo-contribution/job/Seaside/ > > > > This seems especially important as we are moving closer to a release. > > > > Sven > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 3, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by Sean P. DeNigris

Ben Coman wrote > Would it be feasible to have a community maintained > PharoForwardCompatability package available in the ConfigurationBrowser > that is generally available for everyone to use Great idea! If we're just talking about renames, it could just be pre-loaded, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/milliseconds-versus-milliSeconds-tp4809142p4809198.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 3, 2015