- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] 07c9a0: 50344

by Marcus Denker

There is some strange side effect that now the menus have a very odd reddish color. I guess this is caused somehow by 16648 or maybe even 16647? I added a new issue tracker entry for that: https://pharo.fogbugz.com/f/cases/16652/Menues-now-have-a-very-strange-redd… > Log Message: > ----------- > 50344 > 16647 Nautilus Variable Menu Improvement > https://pharo.fogbugz.com/f/cases/16647 > > 16648 ThemeSettings protocol cleanup > https://pharo.fogbugz.com/f/cases/16648 > > 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals > https://pharo.fogbugz.com/f/cases/16649 > > http://files.pharo.org/image/50/50344.zip > >

Sept. 28, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 28, 2015

[pharo-project/pharo-core] 07c9a0: 50344

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 07c9a04969c9a4afbe64c1eeeeca0dabfe5a1bee https://github.com/pharo-project/pharo-core/commit/07c9a04969c9a4afbe64c1ee… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-28 (Mon, 28 Sep 2015) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariableReferences.st A Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/buildVariableReferencesMenuFrom_withIcon_contentBy_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/autoMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/autoMenuColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpDelayTime.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpDelayTime_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpEnabled.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/balloonHelpEnabled_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/buttonColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/buttonColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/defaultButtonColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/derivedMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/fallbackMenuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/flatMenu.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/flatMenu_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/maxBalloonHelpLineLength.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/maxBalloonHelpLineLength_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuBorderColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuBorderWidth.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuKeyboardControl.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuKeyboardFocusColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionTextColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuSelectionTextColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuShadowColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleBorderColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/menuTitleColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarProgressColor.st R Polymorph-Widgets.package/ThemeSettings.class/instance/accessing/progressBarProgressColor_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/applySettingsFrom_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/fromConfiguration_.st R Polymorph-Widgets.package/ThemeSettings.class/instance/as yet unclassified/toConfiguration_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpDelayTime.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpDelayTime_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpEnabled.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/balloonHelpEnabled_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/maxBalloonHelpLineLength.st A Polymorph-Widgets.package/ThemeSettings.class/instance/balloon/maxBalloonHelpLineLength_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/buttonColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/buttonColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/button/defaultButtonColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/autoMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/autoMenuColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/derivedMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/fallbackMenuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/flatMenu.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/flatMenu_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuBorderColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuBorderWidth.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuKeyboardControl.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuKeyboardFocusColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionTextColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuSelectionTextColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuShadowColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleBorderColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/menu/menuTitleColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarProgressColor.st A Polymorph-Widgets.package/ThemeSettings.class/instance/progressbar/progressBarProgressColor_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/applySettingsFrom_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/fromConfiguration_.st A Polymorph-Widgets.package/ThemeSettings.class/instance/settings/toConfiguration_.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableClass.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableContext.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableLink.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableName.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableObject.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableValue.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyClassVariableVariable.st R Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalVariableName.st M Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalVariableValue.st M Reflectivity.package/RFClassReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFClassReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFLinkReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFLinkReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFNameReification.class/class/plugin interface/nodes.st M Reflectivity.package/RFObjectReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFObjectReification.class/instance/generate/genForLiteralVariable.st A Reflectivity.package/RFReification.class/instance/as yet unclassified/genForGlobalVariable.st M Reflectivity.package/RFThisContextReification.class/class/plugin interface/nodes.st A Reflectivity.package/RFThisContextReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFValueReification.class/class/plugin interface/nodes.st M Reflectivity.package/RFVariableReification.class/class/plugin interface/nodes.st R Reflectivity.package/RFVariableReification.class/instance/generate/genForGlobal.st A Reflectivity.package/RFVariableReification.class/instance/generate/genForLiteralVariable.st M Reflectivity.package/RFVariableReification.class/instance/generate/genForRBVariableNode.st R Reflectivity.package/RFVariableReification.class/instance/generate/genForSlot.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50343.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50344.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50343.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50344.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50344 16647 Nautilus Variable Menu Improvement https://pharo.fogbugz.com/f/cases/16647 16648 ThemeSettings protocol cleanup https://pharo.fogbugz.com/f/cases/16648 16649 Links of Globals and Class Vars: implement all reifications + extend for Globals https://pharo.fogbugz.com/f/cases/16649 http://files.pharo.org/image/50/50344.zip

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Max Leske

> On 28 Sep 2015, at 13:57, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? Yes it could. Iâve been thinking about that too. There are some nice properties, e.g. 1 commit <-> one note (where a note can be tree). That way you donât get merge conflicts on changing metadata. However, youâd need to find an equivalent mechanism for each new SCM. Also, using such a mechanism is a bit obscure. But the idea definitely deserves some attention. Cheers, Max > > [1] http://git-scm.com/docs/git-notes > > cheers -ben >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> >> >> >> I have a vague recollection that the problem was a particular file >> >> where data changed each commit and having the idea that this might be >> >> solved by: each commit writing metadata to a different file e.g. >> >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> >> metadata. >> > >> > >> > Hum, I thought that as well, but in fact write the merge driver turned >> > out >> > as far better and simpler. Moreover, all type of data oriented files >> > (ston, json, version) do not merge properly in git. So even Esteban >> > saying >> > he will use STON does not seems to solve the merge issue, unless he is >> > planning something else. I do take in account we will have more metadata >> > in >> > the future, thanks to EPICEA, so we need a way to handle it. >> > >> > Merging is easy, you just need to hook into it. >> > >> > I believed also that we could do the merge ourselves and force git to >> > commit >> > the result, but discovered this was a bad idea. Imagine having to fire >> > Pharo >> > to merge a 250k OCaml project with 2k of st code in it :( >> >> btw, would "notes" [1] be useful for attaching metadata? >> "A typical use of notes is to supplement a commit message without >> changing the commit itself." >> Or is the metadata better inside the commit? > > > I don't know. What happens to notes when you merge? Do you need to fetch > down all the ancestors (some of them without notes, because it was a merge > of whatever external stuff was in the repository, so you need to recurse[2]) > and merge them yourself everytime? What happens if a guy do a by hand edit > of a st file and commits outside of Pharo? Can it work outside git (Fossil, > Mercury, bazaar)? Does it scale to a lot of metadata? > > Thierry > > [2] gitfiletree has that code, and it gives unintuitive, but correct, > results at time. > > >> >> [1] http://git-scm.com/docs/git-notes >> All good questions I don't have answers for. Its something I only came across last week and I'm still understanding its general usage pattern. cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Christophe Demarey

Le 28 sept. 2015 Ã 13:57, Ben Coman a Ã©crit : > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> Le 28/09/2015 04:27, Ben Coman a Ã©crit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > > [1] http://git-scm.com/docs/git-notes I would not use that to store data useful to Pharo. Packages meta-data should be versioned at the same place that the code itself. Git is the trendy SCM but there are others. I prefer to not rely on a specific feature of a SCM to let door opened to others

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-28 13:57 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > Le 28/09/2015 04:27, Ben Coman a Ã©crit : > >> > >> > >> I have a vague recollection that the problem was a particular file > >> where data changed each commit and having the idea that this might be > >> solved by: each commit writing metadata to a different file e.g. > >> NNNN.metadata, and Monticello knows to pick up the highest numbered > >> metadata. > > > > > > Hum, I thought that as well, but in fact write the merge driver turned > out > > as far better and simpler. Moreover, all type of data oriented files > > (ston, json, version) do not merge properly in git. So even Esteban > saying > > he will use STON does not seems to solve the merge issue, unless he is > > planning something else. I do take in account we will have more metadata > in > > the future, thanks to EPICEA, so we need a way to handle it. > > > > Merging is easy, you just need to hook into it. > > > > I believed also that we could do the merge ourselves and force git to > commit > > the result, but discovered this was a bad idea. Imagine having to fire > Pharo > > to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit? > I don't know. What happens to notes when you merge? Do you need to fetch down all the ancestors (some of them without notes, because it was a merge of whatever external stuff was in the repository, so you need to recurse[2]) and merge them yourself everytime? What happens if a guy do a by hand edit of a st file and commits outside of Pharo? Can it work outside git (Fossil, Mercury, bazaar)? Does it scale to a lot of metadata? Thierry [2] gitfiletree has that code, and it gives unintuitive, but correct, results at time. > [1] http://git-scm.com/docs/git-notes > > cheers -ben > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 28/09/2015 04:27, Ben Coman a Ã©crit : >> >> >> I have a vague recollection that the problem was a particular file >> where data changed each commit and having the idea that this might be >> solved by: each commit writing metadata to a different file e.g. >> NNNN.metadata, and Monticello knows to pick up the highest numbered >> metadata. > > > Hum, I thought that as well, but in fact write the merge driver turned out > as far better and simpler. Moreover, all type of data oriented files > (ston, json, version) do not merge properly in git. So even Esteban saying > he will use STON does not seems to solve the merge issue, unless he is > planning something else. I do take in account we will have more metadata in > the future, thanks to EPICEA, so we need a way to handle it. > > Merging is easy, you just need to hook into it. > > I believed also that we could do the merge ourselves and force git to commit > the result, but discovered this was a bad idea. Imagine having to fire Pharo > to merge a 250k OCaml project with 2k of st code in it :( btw, would "notes" [1] be useful for attaching metadata? "A typical use of notes is to supplement a commit message without changing the commit itself." Or is the metadata better inside the commit? [1] http://git-scm.com/docs/git-notes cheers -ben

Sept. 28, 2015

Re: [Pharo-dev] [Pharo-users] Changing method icons priorities in nautilus

by Damien Cassou

Peter UhnÃ¡k <i.uhnak(a)gmail.com> writes: > So would it make sense to swap the priority? I agree with you. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Changing method icons priorities in nautilus

by Peter UhnÃ¡k

Hi, is it a good idea to have the test icon have higher priority than overrides (is overriding parent method/the method is overriden by a child) â Because the state of the test is also available from: 1) the test class itself 2) TestRunner (and one of the two I will have open regardless) And often a method affects more than one test so the icon is not representative of the state anyway. On the other hand if I want to reach the overriden method it's much harder because I have to open new browser, click on the class, find the method. So would it make sense to swap the priority? There's long standing issue in the tracker with having multiple icons per method, but resolving that from UI perspective is perhaps not as easy... (The remaining priorities seem ok... higher number = more important) â Peter

Sept. 28, 2015