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."
>>
>>
>>
>>
>>
>>
>>
>>
>
