I opened an issue http://code.google.com/p/pharo/issues/detail?id=3609
2011/1/20 Alexandre Bergel <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > > > > 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 < [email protected] > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >
