November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How I can add my projects to configuration browser ?

by phil＠highoctane.be

Mmh, looks like I looked into an older Pharo30 image I had around in Windows. On OSX where I am now, there is indeed no such thing in the title. BTW, the "about" in the down pointing arrow of the configuration browser says: A MetacelloConfigurationBrowser is simple tool to browse Metacello configurations published at http://www.squeaksource.com/MetaRepoForPharoXXwhere XX denotes different pharo versions. MetaRepoForPharo1.0 acts as a distribution of all the packages/projects that can be loaded in Pharo1.0. We are sorry for the name but the source limits the length of the project name: The full name is MetacelloRepositoriesForPharoXX. Metacello is a configuration language for packages. It allows one to define dependencies between packages as well as between complete projects. A little dated... Issue created: https://pharo.fogbugz.com/default.asp?12063 Phil

Nov. 3, 2013

Re: [Pharo-dev] moving moose to pharo 3.0

by Tudor Girba

Thanks, Camillo. Doru On Sun, Nov 3, 2013 at 9:21 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2013-11-03, at 21:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > We essentially finished moving Moose to Pharo 3.0 (we still have 6 > yellow tests but they needed attention anyway). It took about 4 people > looking into issues for a total probably around 2 man-days of effort. The > largest impediment was actually SmalltalkHub being down for one day :). > > > > What posed problems: > > - RB visitor now has correct visit* methods instead of accept* methods. > The deprecation messages helped quite a bit. This meant (1) that we had to > rename in our visitors the methods, and (2) that we had to change the old > accept* messages. > > - RB nodes do not answer to #isLiteral anymore. Instead, they answer > correctly to #isLiteralNode so that to avoid confusion with > Object>>#isLiteral. This is good, and this meant that we had to hunt all > #isLiteral usages in Moose. > > - Categories are no longer mapped on RPackages through 1-to-1. This is > also good because it is an important step in Pharo. Although originally we > said we want to keep 1-to-1, this is probably a better solution now. For > Moose, this meant that some of our older tests setup had to be modified a > bit to rely on RPackage only. > > - Some Morphs rely now on Announcements, and this had a little impact on > the assumptions we make when we suspend announcements (to avoid infinite > loops) that are being sent between Morphic and Glamour. We fixed this in > Glamour. > > - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory > without a deprecation. For this one, we should add a deprecation for the > old method. > > opened an issue for that: > https://pharo.fogbugz.com/f/cases/12062/ensureDirectory-and-ensureFile-shou… > > > - flatCollect had a conflicting behavior in Pharo. We are now > integrating the Moose version so that it returns the same species. > > - The new SpecDebugger expects the registered Inspector to be based on > Spec, and this causes problems with the GTInspector. This problem still has > to be fixed in Pharo. > > > > All in all, we encountered no significant problems and the problems we > faced came from deep into Pharo. So, if your code is not relying directly > on RB, RPackage or the Debugger, you are likely to have a smooth transition. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 3, 2013

Re: [Pharo-dev] moving moose to pharo 3.0

by Max Leske

Good to know. Thanks Doru! On 03.11.2013, at 21:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). > > What posed problems: > - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. > - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. > - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. > - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. > - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. > - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. > - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. > > All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 3, 2013

Re: [Pharo-dev] moving moose to pharo 3.0

by Camillo Bruni

On 2013-11-03, at 21:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). > > What posed problems: > - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. > - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. > - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. > - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. > - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. opened an issue for that: https://pharo.fogbugz.com/f/cases/12062/ensureDirectory-and-ensureFile-shou… > - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. > - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. > > All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 3, 2013

moving moose to pharo 3.0

by Tudor Girba

Hi, We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). What posed problems: - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 3, 2013

Re: [Pharo-dev] How I can add my projects to configuration browser ?

by kilon alios

thanks so only thing it takes is to be a contributor , or ask to be added as contributor to that project ? what do you mean by "ConfigurationBrowse window title" ? the only thing I see in the title is "Configuration browser" this link you provided http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo30/ says its for Pharo 3 On Sun, Nov 3, 2013 at 6:25 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Check for Pharo 30 (the name is in the ConfigurationBrowse window title): > > STH Project: http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo30 > Repo: http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main > > > Phil > > > On Sun, Nov 3, 2013 at 5:17 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I have seen some interesting projects (well pretty much everyone of them) >> in configuration browser and I was curious how exactly they are added , is >> there a specific process that needs to be followed ? >> > >

Nov. 3, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 3, 2013

[pharo-project/pharo-core] a5bce4: 30544

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: a5bce43720062026ab415167af4db194d3958d62 https://github.com/pharo-project/pharo-core/commit/a5bce43720062026ab415167… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-03 (Sun, 03 Nov 2013) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script199.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30544.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TextModel.class/definition.st M Spec-Core.package/TextModel.class/instance/initialization/initialize.st A Spec-Core.package/TextModel.class/instance/protocol-events/whenMenuHolderChanged_.st M Spec-Core.package/TextModel.class/instance/protocol/codePaneMenu_shifted_.st A Spec-Core.package/TextModel.class/instance/protocol/menuHolder.st A Spec-Core.package/TextModel.class/instance/protocol/menuHolder_.st A StartupPreferences.package/extension/SettingBrowser/instance/exportAllSettings_by_withBasename_.st M StartupPreferences.package/extension/SettingBrowser/instance/exportSettings.st A StartupPreferences.package/extension/SettingBrowser/instance/exportSettings_toFileNamed_.st Log Message: ----------- 30544 12061 SettingBrowser>>exportSettings need refactoring https://pharo.fogbugz.com/f/cases/12061 11920 NewValueHolder should use value instead of contents https://pharo.fogbugz.com/f/cases/11920 11819 TextModel>>#codePaneMenu:shifted: should work with a value holder https://pharo.fogbugz.com/f/cases/11819 http://files.pharo.org/image/30/30544.zip

Nov. 3, 2013

Re: [Pharo-dev] Quit is not asking for a confirmation anymore?

by StÃ©phane Ducasse

On Nov 3, 2013, at 5:32 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I opened a bug entry: > > https://pharo.fogbugz.com/f/cases/12060/The-Quit-menu-entry-is-not-asking-f… > > Would be great to discuss about this. We should get warned. There is no discussion :) > > Alexandre > > On Nov 3, 2013, at 1:19 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Better not miss the menu option... >> >> >> >> >> >> >> On Sun, Nov 3, 2013 at 3:36 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Really a bug? And I was liking it :) >> >> Doru >> >> On Sun, Nov 3, 2013 at 2:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> no, is a bug. >> I already reported also, but maybe a bug report would help :) >> >> >> On Sun, Nov 3, 2013 at 10:09 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> When I quit Pharo 3.0, no confirmation is asked anymore? Is this really intended? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Nov. 3, 2013

Re: [Pharo-dev] Quit is not asking for a confirmation anymore?

by Alexandre Bergel

I opened a bug entry: https://pharo.fogbugz.com/f/cases/12060/The-Quit-menu-entry-is-not-asking-f… Would be great to discuss about this. Alexandre On Nov 3, 2013, at 1:19 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Better not miss the menu option... > > > > > > > On Sun, Nov 3, 2013 at 3:36 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Really a bug? And I was liking it :) > > Doru > > On Sun, Nov 3, 2013 at 2:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > no, is a bug. > I already reported also, but maybe a bug report would help :) > > > On Sun, Nov 3, 2013 at 10:09 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > When I quit Pharo 3.0, no confirmation is asked anymore? Is this really intended? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 3, 2013