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: [email protected] [mailto:[email protected]] On Behalf Of Schwab,Wilhelm K Sent: Friday, January 15, 2010 9:17 AM To: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Wednesday, January 13, 2010 2:40 AM To: [email protected] 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 > > Does that sound right? Am I missing something that might cost me later? > > Bill > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
