Smalltalk › Pharo › Pharo Smalltalk Developers

Category Renaming under Monticello

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Sven Van Caekenberghe

Category Renaming under Monticello

Hi,

When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition.

I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one.

I also wanted to rename a category, but that would give the same issue I guess.

I am sure this is worth a FAQ entry, but I could find anything.

Anyone any idea ?

Thx,

Sven

Henrik Sperre Johansen

Re: Category Renaming under Monticello

On Dec 6, 2010, at 3:38 22PM, Sven Van Caekenberghe wrote:

> Hi,
>
> When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition.
>
> I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one.
>
> I also wanted to rename a category, but that would give the same issue I guess.
>
> I am sure this is worth a FAQ entry, but I could find anything.
>
> Anyone any idea ?
>
> Thx,
>
> Sven

IIRC, Monticello does not automatically create new packages (or delete empty ones) based on recategorization.
If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.

Cheers,
Henry

Sven Van Caekenberghe

Re: Category Renaming under Monticello

On 06 Dec 2010, at 15:42, Henrik Johansen wrote:

> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.

OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ?

And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ?

Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ?

Anyway, thanks for the reply.

Sven

Henrik Sperre Johansen

Re: Category Renaming under Monticello

On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote:

>
> On 06 Dec 2010, at 15:42, Henrik Johansen wrote:
>
>> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.
>
> OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ?
>
> And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ?
>
> Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ?
>
> Anyway, thanks for the reply.
>
> Sven

IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty.
So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically.
New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either.

If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename)

TLDR;
The packages will contain the correct code, if you publish them.
Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition.

Cheers,
Henry

Sven Van Caekenberghe

Re: Category Renaming under Monticello

Hendrik,

Thanks for all the help.

It seems that changing the category programmatically like this works:

((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server')
collect: [ :className | Smalltalk globals at: className ])
do: [ :each | each category: 'Zinc-HTTP-Client-Server' ]

Now MC did pick up the changes.

Sven

On 06 Dec 2010, at 16:07, Henrik Johansen wrote:

>
> On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote:
>
>>
>> On 06 Dec 2010, at 15:42, Henrik Johansen wrote:
>>
>>> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.
>>
>> OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ?
>>
>> And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ?
>>
>> Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ?
>>
>> Anyway, thanks for the reply.
>>
>> Sven
>
> IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty.
> So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically.
> New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either.
>
> If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename)
>
> TLDR;
> The packages will contain the correct code, if you publish them.
> Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition.
>
> Cheers,
> Henry

Noury Bouraqadi-2

Re: Category Renaming under Monticello

Hi,

A while ago (2-3 years) I submitted the a change to MC and MC Browser to support package renaming and also changing the initials of all classes in the package. It was rejected because it is possible to have a cleaner alternative implementation that makes use of RB. Unfortunately, I didn't manage to do the change.

Attached my code.
A right click on a package name is supposed to
Note however that I didn't test it with recent Pharo images.

Noury

On 7 déc. 2010, at 00:05, Sven Van Caekenberghe wrote:

> Hendrik,
>
> Thanks for all the help.
>
> It seems that changing the category programmatically like this works:
>
> ((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server')
> collect: [ :className | Smalltalk globals at: className ])
> do: [ :each | each category: 'Zinc-HTTP-Client-Server' ]
>
> Now MC did pick up the changes.
>
> Sven
>
> On 06 Dec 2010, at 16:07, Henrik Johansen wrote:
>
>>
>> On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote:
>>
>>>
>>> On 06 Dec 2010, at 15:42, Henrik Johansen wrote:
>>>
>>>> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.
>>>
>>> OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ?
>>>
>>> And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ?
>>>
>>> Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ?
>>>
>>> Anyway, thanks for the reply.
>>>
>>> Sven
>>
>> IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty.
>> So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically.
>> New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either.
>>
>> If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename)
>>
>> TLDR;
>> The packages will contain the correct code, if you publish them.
>> Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition.
>>
>> Cheers,
>> Henry
>
>

MonticelloRename-Noury Bouraqadi.1.mcz (4K) Download Attachment