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

Re: [Pharo-dev] RewriteTool

by Jean-Christophe Bach

* Sean P. DeNigris <sean(a)clipperadams.com> [06.05.2015. @12:23:09 -0700]: > There are two repos: > http://smalltalkhub.com/#!/~PharoExtras/RewriteTool , which seems to have > been forked some time ago > and > http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/ , which is now about 70 > commits ahead of the first! > > What should be done? > > ----- > Cheers, > Sean The right one should be the fork which was done to integrate Mark's work. But Mark is committing one its own repo, therefore the PharoExtras one should be updated. Mark, could you do it and then use the pharoextras repo? Thx, Jean-Christophe

May 7, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

> On 6 maj, 2015, at 21:27 , Sergio Fedi [via Smalltalk] <ml-node+s1294792n4824882h50(a)n4.nabble.com> wrote: > > Does this mean that we should focus on adding the comments on this ManifestXXX class? > (instead of other implementations)â Yes, that seems like the right approach to me. I believe we could add some methods to âTheManifestBuilderâ to get/set a package comment. If we put the methods in a special category in that builder, we should be ok. These methods are then what we call from the get/add comment in the AbstractNautilusUI class. (Then I have some reservations to the details of how ManifestXXX are done, but that is for some other time - package comments should live here, and it is easy to work with.) -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4824950.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 7, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

> On 6 maj, 2015, at 21:23 , stepharo [via Smalltalk] <ml-node+s1294792n4824878h26(a)n4.nabble.com> wrote: > > our idea is that each package should have meta-data: > - default code formatting > - false positive for rules > - and of course package comment. > > So for now the simplest thing we did was to add a class called > ManifestXXX for packageXXX. > This way it is versionned with the classes and we can browse it.... > > Stef Thanks for the clarification. Iâll work with Sergio Fedi on this one, it seems to be a very simple thing (very little, well isolated code). Best, Kasper -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4824949.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 7, 2015

[Review]: Issue 15503 Add RPackage>>#mcWorkingCopy for MCSliceInfo>>#makeSlice

by Sean P. DeNigris

It's really quick - 3 tiny methods changed and two tests added. The monkey passed it and it's holding up two more fixes I want to do... Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Issue-15503-Add-RPackage-mcWorkingCopy-for-MCS… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 6, 2015

Re: [Pharo-dev] Where to start contributing

by Sergio Fedi

âThanks for the advice. Seems a really safe and newbie-friendly task to: 1 - Review other people's fixes and comment on them 2 - Try to reproduce bugs, post them and maybe make a test case for it

May 6, 2015

Re: [Pharo-dev] Roadmaps

by Sergio Fedi

I suppose we can incorporate this documentation of the process in the comments of a bug fix (Editing the case) On Wed, May 6, 2015 at 6:57 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > Aha, ok. I understand them more now. > > Thanks for the explanation. > â >

May 6, 2015

Re: [Pharo-dev] Roadmaps

by Sergio Fedi

Aha, ok. I understand them more now. Thanks for the explanation. â

May 6, 2015

Re: [Pharo-dev] Roadmaps

by Sean P. DeNigris

stepharo wrote > There are notes for me. But I've been adding a few :) They are handy places to stash common understanding about the system (e.g. from mailing list posts or exploring the image) which are not quite ready to be proper documentation. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Roadmaps-tp4824459p4824930.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 6, 2015

Re: [Pharo-dev] external package handling ... a concrete case

by stepharo

Le 6/5/15 22:37, Esteban Lorenzano a Ã©crit : > but that happens because GTools guys made a mistake: > > spotterActDefault > ^ Smalltalk tools browser openOnPackage: self > > thatâs the correct implementation of that method. Ok but I do not care. This is just an example of the problem. I will **not** publish the GTSpotter code nor update the configuration because I do know the internal of GT. If I would be maintaining an external pharo tool I would hate that somebody publish random code to it. When we publish a change in Pharo for external tools this is like a pull request! Stef > > Esteban > >> On 06 May 2015, at 22:14, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> I'm cleaning nautilus model and Spotter is extended. >> Now I will not publish the fix in Spotter, I will not update a configuration of a tool I do not know. >> So what should I do, stop working? No this is not possible. So I will push this changes in the inbox and >> integrate it and GT people should merge the fix in their baseline when they want. >> Or I will really stop doing anything for Pharo 50 alpha. >> >> Stef >> >> spotterActDefault >> ^ Nautilus openOnPackage: self >> > >

May 6, 2015

Re: [Pharo-dev] Roadmaps

by stepharo

> Interesting. > > So, these roadmaps. > > I read some of them but I didn't get a clear picture of what are they, > so here I am asking: > > What are roadmaps? There are notes for me. Usually I spent time reading code to get an understanding about a part so that at least I remember. And I keep so log about the things I learned, found strange.... Have a look at menu for example. I want to improve them so now I continue to update this roadmap so that I can discuss with guille about solutions and we can pair program and improve the system. So they are a bit cryptic. :) > > Why should we use them? (what problem do they solve) > > How do we use them? > > I have a feeling that they are like a "roadmap to the final > implementation" > That is, an explanation of the different decisions you took as part of > solving a problem that led you to where you finally arrived. It is more a log of problems and steps that have been done. > > Feel free to correct me. >

May 6, 2015