[squeak-dev] Monticello doesn't create new packages

Hello,

I derive all my images from a (3.8.2) start_dev image.

I have that one messed up in a way that Monticello doesn't create any
new packages.

Actually the package is created but it has no contents. And it isn't
marked as changed in MC Browser if I change a class of the package.

If I change a class in an existing package the change is seen in MC
Browser.

I attach two of those empty mcz.

I'm totally confused and don't even know where to start searching. The
dev image has started as 3.8 and then subsequently been updated to
3.8.2


Thanks,

Herbert

On 02.06.2008, at 10:10, Herbert König wrote:

> Actually the package is created but it has no contents. And it isn't
> marked as changed in MC Browser if I change a class of the package.
>
> <hk-zzz-hk.1.mcz><zzhk-aster-hk.4.mcz>


Well, do you actually have a class category exactly named "hk-zzz"? Or  
"zzhk-aster"?

- Bert -

Hello Bert,



BF> Well, do you actually have a class category exactly named "hk-zzz"? Or
BF> "zzhk-aster"?

yes I have.

hk-zzz was just a test with a single class zzz created and zzzhk-aster
is actually hk-aster and only after saving I renamed the files to
zzzhk-aster.


--
Cheers,

Herbert                                        

Hello,

BF>> Well, do you actually have a class category exactly named "hk-zzz"? Or
BF>> "zzhk-aster"?

HK> yes I have.

to be more precise with hk-aster I have categories "hk-aster game"
"hk-aster moving objects" and so on.

Actually I use MC regularly and the zzz example worked in another
image.



--
Cheers,

Herbert                                        

On 02.06.2008, at 10:32, Herbert König wrote:


A-ha! You would need to call your MC package 'hk-aster game' then. The  
default PI implementation does not do substring matching, but breaks  
at hyphens ("-").

Simplest would be renaming your categories "hk-aster-game" and "hk-
aster-moving objects".

Or implement a custom PackageInfo class - package names and class  
categories do not necessarily need to match, that is just the default.

To see how classes are found, debug this:

        (PackageInfo named: 'hk-aster') classes

Have fun,

- Bert -

Hello Bert,

BF> A-ha! You would need to call your MC package 'hk-aster game' then. The
BF> default PI implementation does not do substring matching, but breaks
BF> at hyphens ("-").

though I don't understand that (will look into the implementation you
mention later) ...

BF> Simplest would be renaming your categories "hk-aster-game" and "hk-
BF> aster-moving objects".

this one helped! So a class category must *not* start with a package
name followed immediately by a blank if the category shall belong to
the package.

Consequence seems to be I have to go through all my images if I have
broken this naming scheme somewhere and only part of my categories are
saved. Same is valid for method category names extending base classes
I guess.

Really ugly.

BF> Or implement a custom PackageInfo class - package names and class
BF> categories do not necessarily need to match, that is just the default.

I'll look here too.

BF> Have fun,

A smiley would have been ok here, the fun will consist of quite a lot
of digging where I disobeyed the naming scheme in some class
extension.

I think this is a serious issue (a trap) and I put investigating this
on my todo list for July. Or I misunderstood something.


Thanks a lot!

Herbert                                        

Hello Bert,

BF> A-ha! You would need to call your MC package 'hk-aster game' then. The
BF> default PI implementation does not do substring matching, but breaks
BF> at hyphens ("-").

though I don't understand that (will look into the implementation you
mention later) ...

BF> Simplest would be renaming your categories "hk-aster-game" and "hk-
BF> aster-moving objects".

this one helped! So a class category must *not* start with a package
name followed immediately by a blank if the category shall belong to
the package. Same is valid for method category names extending base
classes I guess.


Consequence seems to be I have to go through all my images if I have
broken this naming scheme somewhere and only part of my categories are
saved.

Really ugly.

BF> Or implement a custom PackageInfo class - package names and class
BF> categories do not necessarily need to match, that is just the default.

I'll look here too.

BF> Have fun,

A smiley would have been ok here, the fun will consist of quite a lot
of digging where I disobeyed the naming scheme in some class
extension.

I think this is a serious issue (a trap) and I put investigating this
on my todo list for July. Or I misunderstood something.


Thanks a lot!

Herbert                                        

On 02.06.2008, at 11:06, Herbert König wrote:

> BF> Simplest would be renaming your categories "hk-aster-game" and  
> "hk-
> BF> aster-moving objects".
>
> this one helped! So a class category must *not* start with a package
> name followed immediately by a blank if the category shall belong to
> the package.

This has nothing to do with blanks at all. The only significant  
characters are the hyphens. The category name is split into tokens by  
the hyphens, and only tokens are compared. Tokens are compared in  
whole, not by substrings.

> Consequence seems to be I have to go through all my images if I have
> broken this naming scheme somewhere and only part of my categories are
> saved.


Or, if you like substring matching better than token matching, include  
your own PackageInfo subclass with your package. It is really simple.  
Here is the default matching:

category: categoryName matches: prefix
        ^ categoryName notNil and: [categoryName = prefix or: [categoryName  
beginsWith: prefix, '-']]

Make a PI subclass, override the method as

category: categoryName matches: prefix
        ^ categoryName notNil and: [categoryName beginsWith: prefix]

and then in its class-side initialize method, do

        (self new packageName: 'hk-aster') register

- Bert -