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

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

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