- Pharo-dev - lists.pharo.org

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

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

by Bernardo Ezequiel Contreras

sergio, if you submit a slice to the inbox and change the status to Resolved (Fix Review Needed), the monkey (CI) will test your slice and inform you the result. 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

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

by Sergio Fedi

Great!â I suppose the bug system will inform me when you finally resolve the case, right?

April 28, 2015

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

by Bernardo Ezequiel Contreras

yes, i have done that. :) But now, i save the slice in a local repository (a simple directory) and test that slice in a fresh image, i try to merge it (see the changes and merge them) and then i copy the slice(that also will copy the related packages) from my local repository to the inbox. On Mon, Apr 27, 2015 at 8:31 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > I was following that video. > > And now I'm pretty sure my blunder was caused because I kept the package > selected after revieweing the Changes. > > So instead of aving the Slice, I saved only the package. > > âThanks for the patience :) > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 28, 2015

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

by Sergio Fedi

I was following that video. And now I'm pretty sure my blunder was caused because I kept the package selected after revieweing the Changes. So instead of aving the Slice, I saved only the package. âThanks for the patience :)

April 27, 2015

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

by Bernardo Ezequiel Contreras

Sergio This video explains in step 4 how to create a slice. https://www.youtube.com/watch?v=iFomI-7h4qQ hth On Mon, Apr 27, 2015 at 7:32 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > One thing I previously missed: marking it as resolved (and in need for a > peer review) > > Already done that at: > > > https://pharo.fogbugz.com/f/cases/resolve/15417/TestRunner-does-not-offer-t… > > â > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 27, 2015