- Pharo-dev - lists.pharo.org

[Pharo-project] does anybody knows who is using StandardToolSet?

by StÃ©phane Ducasse

Because it would be good that it uses a registration mechanism. Hardcoding the classes of the tools is not optimal for example for the new Finder. Stef

Jan. 28, 2011

[Pharo-project] Issue 3614 in pharo: Fix finder with * expressions!

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3614 by stephane...(a)gmail.com: Fix finder with * expressions! http://code.google.com/p/pharo/issues/detail?id=3614 yes now Finder new computeWithMethodFinder: '''a*'' . ''ab'' . true ' works!

Jan. 28, 2011

[Pharo-project] Issue 3613 in pharo: Hudson 1.2 dev : testOBAutocategorizeCommandOverride

by pharo＠googlecode.com

Status: New Owner: jbaptist...(a)gmail.com CC: marianopeck Labels: Milestone-1.2-DevImage New issue 3613 by jbaptist...(a)gmail.com: Hudson 1.2 dev : testOBAutocategorizeCommandOverride http://code.google.com/p/pharo/issues/detail?id=3613 Pharo image: dev Pharo core version: 1.2 Virtual machine used: current Steps to reproduce: 1. run the test OBCmdAutoCategorizeWithAMCTest The test is Wrong i attach a file to correct the test. But i don't make it green Attachments: OBCmdAutoCategorizeWithAMCTest.st 602 bytes

Jan. 28, 2011

Re: [Pharo-project] Issue 3609 in pharo: Integrate RPackage

by pharo＠googlecode.com

Comment #1 on issue 3609 by cy.delau...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 Another point to look at: Monticello needs to know what are the sub-categories of a package before saving it to a repository. That work was concretly done by PackageOrganize,r which was looking for category-names matching with the packageInfo name. For now I just copied this code, but I guess at the end we should avoid this kind of behavior by storing properly in a RPackage what are its sub-categories ?

Jan. 28, 2011

Re: [Pharo-project] Issue 439 in pharo: Change autocompletion shortcut from cmd-q to ...?

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #15 on issue 439 by marcus.d...(a)gmail.com: Change autocompletion shortcut from cmd-q to ...? http://code.google.com/p/pharo/issues/detail?id=439 (No comment was entered for this change.)

Jan. 28, 2011

[Pharo-project] [update 1.3] #13024

by StÃ©phane Ducasse

13024 ----- - Repackaging a lot of classes and creating UI-Basic for Model and RealEstateAgent. Stef and Ben

Jan. 28, 2011

Re: [Pharo-project] RPackage

by Cyrille Delaunay

I opened an issue http://code.google.com/p/pharo/issues/detail?id=3609 2011/1/20 Alexandre Bergel <alexandre(a)bergel.eu> > Excellent project to work on. Include PackageInfo in your scope :-) > > Alexandre > > > On 20 Jan 2011, at 11:40, Cyrille Delaunay wrote: > > > By looking a bit more at Monticello, this is how I think it works (if not > tell me): > > > > => WorkingCopy is the first kind of objects we have. A workingCopy has > informations about version, ancestors, ... (surely a lot of other things) of > a package and has a reference to a MCPackage > > => a MCPackage does not know about the elements composing itself before > calling the method MCPackage >> snapshot. This method will return a fresh > MCSnapshot object. It is at this moment (I think), that monticello will use > PackageInfo to retrieve all necessary informations. > > => a MCSnapshot contains a kind of 'modelisation' of the system, which > basically is a collection composed by: > > => MCOrganizationDefinition, specifying what are > the subcategories of the package > > => MCMethodDefinition(s), one for each method > included in the package (both defined and extension methods). > > => MCClassDefinition(s), one for each class > included in the package. > > > > So I think the point to focus on is, MCPackage >> snapshot, using the > RPackage interface instead of PackageInfo interface to build the snapshot. > I'm looking to do that. > > > > > > > > 2011/1/19 Cyrille Delaunay <cy.delaunay(a)gmail.com> > > Hello, > > Currently I am working on integrate RPackage in pharo, and having it > working in parallel of PackageInfo. > > What RPackage is already able to do (or at least until you find something > wrong;)) is: > > - synchronize and initialize with the current MCPackages in the system > > - update itself when changes are made in the system (new category, new > class, new method, ... ). > > > > Now I was wondering if there would be something to pay attention to with > Monticello. Maybe when saving or importing packages to/from a repository? I > don't know how monticello work, but after looking quickly, that's some > thoughts I had: > > > > > > > > > > > > 1) => Saving from the image to a repository: How monticello know if the > package we want to saved is extended by other classes? is there currently a > link between Monticello and Package Info to do that? > > 2) => import from a repository into the image: How do we manage to > install the extension in the right package ? > > > > For the point 1) : > > > > MCPackageManager seems to directly listen to the system events (see > MCPackageManager class >> reregisterForNotificationsWith:), in a parallel > direction than RPackage (with its announcements system). So I guess > Monticello update itself all its packages and check itself when a protocol > is added to know if it's an extension. Therefore there would be nothing to > worry when replacing PackageInfo by RPackage > > > > For the point 2) : > > > > When monticello will import the code, it will create classes, create > methods in some protocols (that can be extensions or not), using the system > interface. Then, Normally each modification will raise the corresponding > event, for which RPackage is listening to (throught the announcement > system). Therefore RPackage will update itself and there would be still > nothing to worry. > > > > > > For now the only link to make I see, is when creating or deleting a > MCPackage: we have to do the same with the RPackages. This is currently done > in RPackage, by listening to MC changes (look at RPackageOrganizer >> > update:). PackageInfo is directly updated in the MC code instead of > listening to changes. > > > > So I wonder if there is some big parts I totally forgot ? and In general > if you have something in mind that should be done for RPackage? > > > > 2010/12/6 <csrabak(a)bol.com.br> > > > > I think this small thread is an excellent example of the need we have to > implement simpler practice: > > > > When we announce a package or project, it would nice if the first > paragraph[s] could be a short description of what it's all about! > > > > We could even open another thread and agree upon a format for it, and > look, we could even have the same text in some specific attribute in the > package which could be collected, selected, etc.!! > > > > -- > > Cesar Rabak > > > > > > Em 06/12/2010 07:08, Tudor Girba < tudor.girba(a)gmail.com > escreveu: > > Good work, Cyrille! > > > > For people that might not know what RPackage is, this project aims to > replace PackageInfo with a faster and cleaner implementation. At the moment, > all categories are mapped one-to-one and in the end, we would like to remove > class categories altogether. > > > > This infrastructure is also targeted to code browsers. > > > > Doru > > > > > > On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: > > > > > Hello, > > > > > > Recently I made some improvements about RPackage. What I mainly did, is > to implement the 'SystemAnnounncements listening', to update the organizer > when the system change. With that I implemented a set of tests that should > all be green now (in RPackageMCSynchronisationTest (I should change the > name)). > > > > > > You can load RPackage by evaluating: > > > > > > Gofer new > > > squeaksource: 'PharoInbox'; > > > package: 'ConfigurationOfRPackage'; > > > load. > > > (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. > > > > > > (I think it should work, but squeaksource is down for now, so I was not > able to test it). > > > > > > In those tests I started to write some about traits, but after few, I > realized that the events emitted when a trait change are the same that the > one used for classes ? > > > Then if you have some ideas about what is still missing in RPackage, > tell me, I can add it to my task list :) > > > > -- > > www.tudorgirba.com > > > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

Jan. 28, 2011

[Pharo-project] Issue 3612 in pharo: Full Image uses wrong Theme

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3612 by marcus.d...(a)gmail.com: Full Image uses wrong Theme http://code.google.com/p/pharo/issues/detail?id=3612 Full Image uses wrong Theme Should use Glamour Theme for 1.2

Jan. 28, 2011

Re: [Pharo-project] Issue 3611 in pharo: ParagraphEditor should be removed

by pharo＠googlecode.com

Updates: Summary: ParagraphEditor should be removed Cc: aplantec Comment #1 on issue 3611 by stephane...(a)gmail.com: ParagraphEditor should be removed http://code.google.com/p/pharo/issues/detail?id=3611 Am'I correct that we can soon get rid of paragraphEditor

Jan. 28, 2011

[Pharo-project] Issue 3610 in pharo: Should remove Morphic-Undo

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com CC: aplan...(a)gmail.com New issue 3610 by stephane...(a)gmail.com: Should remove Morphic-Undo http://code.google.com/p/pharo/issues/detail?id=3610 Alain is it correct that we could remove Command and CommandHistory now?

Jan. 28, 2011