MC case sensitity and sub-packages

Brian and others have told me that I could expect to define packages such as

  DolphinCompatibility-ODBC
  DolphinCompatibility-Streams

and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC.  I was unable to make it work reliably, and I think I might have just figured out why.

Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving.

It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that.

Does that sound right?  Am I missing something that might cost me later?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote:

> Brian and others have told me that I could expect to define packages such as
>
>  DolphinCompatibility-ODBC
>  DolphinCompatibility-Streams
>
> and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC.  I was unable to make it work reliably, and I think I might have just figured out why.

I really encourage you to save them as separate packages
if you want to load and save them all build a metacelloConfig (not difficult and worth).
don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice).,
I hate this pattern matching behavior.

> Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving.
>
> It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that.

probably I do not like that part of the system

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

I am doing some housekeeping toward building a new image.  Changes such as below have allowed me to get Migrate into an almost-releasable state.  One of its jobs is to look for code that is at risk of being lost, and that feature is detecting a LOT of code that should be safe; it is probably due to the extra packages.  I had hoped that I could safely avoid the "double save" problem, but this is even worse than that :(

Absent a simple solution, the answer is to delete DolphinCompatibility and others.  The next question is then: will I have problems with dependencies between the sub-packages?  I am wondering whether there could be problems saving separate packages like

   DolphinCompatibility-Streams
   DolphinCompatibility-ODBC

when DolphinCompatibility would be perfectly happy.

Does that make sense?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Wednesday, January 13, 2010 2:40 AM
To: [hidden email]
Subject: Re: [Pharo-project] MC case sensitity and sub-packages


On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote:

> Brian and others have told me that I could expect to define packages
> such as
>
>  DolphinCompatibility-ODBC
>  DolphinCompatibility-Streams
>
> and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC.  I was unable to make it work reliably, and I think I might have just figured out why.

I really encourage you to save them as separate packages if you want to load and save them all build a metacelloConfig (not difficult and worth).
don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice)., I hate this pattern matching behavior.

> Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving.
>
> It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that.

probably I do not like that part of the system

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

It looks as though this might work as I had hoped, though I am giving careful consideration to your concern.  I had both DolphCompatibility and Dolphincompatibility in package names; there were a few of the later form.  I used PackageOrganizer to enumerate the package names, selected the incorrect ones, then unregistered them.

After the above and fixing a couple of things in my Migrate pacakge names list, my suspect methods report is down to five methods that are expected to appear.  The save of the enumerated top-level packages *appears* to have worked.  I will need to try building an image from them before getting too full of myself.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Friday, January 15, 2010 9:17 AM
To: [hidden email]
Subject: Re: [Pharo-project] MC case sensitity and sub-packages

Stef,

I am doing some housekeeping toward building a new image.  Changes such as below have allowed me to get Migrate into an almost-releasable state.  One of its jobs is to look for code that is at risk of being lost, and that feature is detecting a LOT of code that should be safe; it is probably due to the extra packages.  I had hoped that I could safely avoid the "double save" problem, but this is even worse than that :(

Absent a simple solution, the answer is to delete DolphinCompatibility and others.  The next question is then: will I have problems with dependencies between the sub-packages?  I am wondering whether there could be problems saving separate packages like

   DolphinCompatibility-Streams
   DolphinCompatibility-ODBC

when DolphinCompatibility would be perfectly happy.

Does that make sense?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Wednesday, January 13, 2010 2:40 AM
To: [hidden email]
Subject: Re: [Pharo-project] MC case sensitity and sub-packages


On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote:

> Brian and others have told me that I could expect to define packages
> such as
>
>  DolphinCompatibility-ODBC
>  DolphinCompatibility-Streams
>
> and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC.  I was unable to make it work reliably, and I think I might have just figured out why.

I really encourage you to save them as separate packages if you want to load and save them all build a metacelloConfig (not difficult and worth).
don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice)., I hate this pattern matching behavior.

> Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving.
>
> It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that.

probably I do not like that part of the system

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Bill

your english is too rich for us poor non native speakers so we may miss what you imply :)


> Stef,
>
> I am doing some housekeeping toward building a new image.  Changes such as below have allowed me to get Migrate into an almost-releasable state.  One of its jobs is to look for code that is at risk of being lost, and that feature is detecting a LOT of code that should be safe; it is probably due to the extra packages.  I had hoped that I could safely avoid the "double save" problem, but this is even worse than that :(

what happen?

> Absent a simple solution, the answer is to delete DolphinCompatibility and others.  The next question is then: will I have problems with dependencies between the sub-packages?  

which subpackages?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jan 15, 2010, at 4:09 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> It looks as though this might work as I had hoped, though I am giving careful consideration to your concern.  I had both DolphCompatibility and Dolphincompatibility in package names; there were a few of the later form.  I used PackageOrganizer to enumerate the package names, selected the incorrect ones, then unregistered them.

pay attention PackageOrganizer was full of dust

> After the above and fixing a couple of things in my Migrate pacakge names list, my suspect methods report is down to five methods that are expected to appear.  The save of the enumerated top-level packages *appears* to have worked.  I will need to try building an image from them before getting too full of myself.

:)


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project