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

[pharo-project/pharo-core]

by GitHub

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

April 28, 2015

[pharo-project/pharo-core]

by GitHub

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

April 28, 2015

[pharo-project/pharo-core] 24aa0d: 50013

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 24aa0d177ba39fa8631a44b922a2c3e788f9a856 https://github.com/pharo-project/pharo-core/commit/24aa0d177ba39fa8631a44b9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-28 (Tue, 28 Apr 2015) Changed paths: M Refactoring-Environment.package/RBAndEnvironment.class/README.md M Refactoring-Environment.package/RBBrowserEnvironment.class/README.md M Refactoring-Environment.package/RBBrowserEnvironmentWrapper.class/README.md M Refactoring-Environment.package/RBCategoryEnvironment.class/README.md M Refactoring-Environment.package/RBClassEnvironment.class/README.md M Refactoring-Environment.package/RBNotEnvironment.class/README.md M Refactoring-Environment.package/RBOrEnvironment.class/README.md M Refactoring-Environment.package/RBPackageEnvironment.class/README.md M Refactoring-Environment.package/RBPragmaEnvironment.class/README.md M Refactoring-Environment.package/RBProtocolEnvironment.class/README.md M Refactoring-Environment.package/RBSelectorEnvironment.class/README.md M Refactoring-Environment.package/RBVariableEnvironment.class/README.md R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script621.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script622.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50012.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50013.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Shout.package/SHParserST80.class/class/instance creation/new.st A Shout.package/SHRBTextStyler.class/instance/formatting/addStyle_attribute_from_to_.st M Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitMessageNode_.st M Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitMethodNode_.st M Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitPragmaNode_.st Log Message: ----------- 50013 15249 Comment RBEnvironment classes https://pharo.fogbugz.com/f/cases/15249 15412 SHParserST80 class>#new not needed https://pharo.fogbugz.com/f/cases/15412 15413 fix AST based syntax colouring https://pharo.fogbugz.com/f/cases/15413 http://files.pharo.org/image/50/50013.zip

April 28, 2015

Re: [Pharo-dev] Are these changes good enough

by Marcus Denker

Another thing is that Pharo4 is now stableâ¦ we try to only fix real show stoppers. And in all cases, we do it first in the current development version (Pharo5 now). > On 28 Apr 2015, at 02:57, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > Uploaded and marked as solved. > > âLet's see how it goes. >

April 28, 2015

Re: [Pharo-dev] "Gentle" Deprecation

by Marcus Denker

> On 28 Apr 2015, at 04:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > In String>>#subStrings: there is: > "This method is planned for future deprecation in favour of #substrings: > (Issue 7592), > but we do it gently, first via Critic Browser > Design Flaws > Future > Deprecation Warning" > > Is that now preferred over #deprecated:on:in:? > Noâ¦ the idea was to experiment how to change methods that are used a lot. In this case we did it very very late in Pharo4 and a real deprecation looked too intrusive. It could be an idea to use staged deprecation for some cases.. i Marcus

April 28, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Ben Coman

On Tue, Apr 28, 2015 at 4:19 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I will soon release a âversioner commit toolâ who will help with this. > The process will remain as now: > > you do your changes > you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ > (and in the hopefully not far future even âNautilusâ or, why not > âPharo-IDEâ or even âPharoâ) > tools will collect packages and configurations and generate new ones, > using semver nomenclature. > finally, you will copy your âmainâ configuration (the root of your change) > to the inbox (same as now). > > this is the beginning of the end of SLICEd based development. > and this is the beginning of a modular era :) > > This is almost ready and is a good example of incremental changes that > produces a fundamental lap (remember ânomads do not build cathedralsâ talk > from Marcus): > > - gofer allows the scripting of commit and load packages > - metacello allows us to declare and manage dependences > - versionner does a very good job maintaining metacello configurations > - version commit tool will allow the automation release pacthes for nested > configurations > > Esteban > > ps: and when I said almost ready, it is for real: I hope to release an > alpha version for testing tomorrow :) > pps: sounds bad to put this last tool in the list to the big > contributionsâ¦ at the end, is just a small tool on top of really important > projects :)) > Thanks Esteban. This sounds a good initiative to pull these parts together. I look forward to give it a try. I still maintain there is a need for a tool to merge two Configuration's resultant-set-of-packages (similar to what is done a Slice's dependants) to facilitate parallel paths of development. For context, when reviewing resolved issues, I use Monticello's merge tool to review the individual changes of a Slice before loading it. I also find that list a great reference after loading the Slice. My issue review workflow simultaneously starts two merges and completes one, leaving the other open as a reference. Then I can Browse direct to the affected methods and drop halts in them to get into the debugger to understand what is going on. There is also a broader issue here. Unless I'm missing something, when loading a Configuration we are blind to what the changes will be. This has some small security implications. I envisage merging a Configuration's resultant-set-of-packages *somehow* plugs into the existing merge tool. A Slice's resultant-set-of-packages is directly specified by its dependants list, so where that list is passed for further merge processing of individual packages, at that point I thought we might be able to pass in a Configuration's resultant-set-of-packages -- but I haven't looked into this yet. cheers -ben > > > On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > stepharo wrote > >> - we do a fix we publish it in Pharo and yes this touches Rubric and > >> - we integrate it in Pharo head > > > > I'm not clear what the best process is, but I wanted to relate an > experience > > I just had updating TxText... > > Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its > ancestor, > > which I wanted to copy to the TxText repo, is > > Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I > checked > > the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking > > others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, > copied it > > over, and updated the config. > > > > So, for external projects, simply taking changes from the inbox and > > integrating seems to be a little lacking. Maybe at least copy the > packages > > back to the canonical repos to preserve the ancestry... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Integration-process-in-presence-of-external-project-t… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

April 28, 2015

"Gentle" Deprecation

by Sean P. DeNigris

In String>>#subStrings: there is: "This method is planned for future deprecation in favour of #substrings: (Issue 7592), but we do it gently, first via Critic Browser > Design Flaws > Future Deprecation Warning" Is that now preferred over #deprecated:on:in:? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Gentle-Deprecation-tp4822336.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 28, 2015

Re: [Pharo-dev] Are these changes good enough

by Sergio Fedi

Uploaded and marked as solved. âLet's see how it goes.

April 28, 2015

Re: [Pharo-dev] Are these changes good enough

by Sergio Fedi

Oh, great, I misunderstood. Glad you clarified that. I'm gonna do it now. â

April 28, 2015

Re: [Pharo-dev] Are these changes good enough

by Bernardo Ezequiel Contreras

Sergio, there's a misunderstanding, i explained what i usually do, im not going to do it for you. you should try it, first On Mon, Apr 27, 2015 at 9:18 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > Great!â > > I suppose the bug system will inform me when you finally resolve the case, > right? > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 28, 2015