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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
