As we all know, no saftware is bug-free, especially when it contains more than three line of code.
Patch the SystemDictionary>>#renameClass: Did it in another way, perhaps this method must be patched, too.
OPEN 2020-12-05 12:13:50 | BUSY 2020-12-05 18:06:41 | TESTING 2020-12-05 18:47:29
The versions browser does not diff, reverting versions does not work.
OPEN 2020-12-06 14:20:21 | TESTING 2020-12-06 15:09:06 | WATCHING 2020-12-09 17:09:58 | DONE 2020-12-21 18:31:50
Reexporting imported symbols will not work. This statement is subject to testing, it was derived solely on theoretical considerations.
The current implementation is untested and crappy, it will not work (2021-01-05).
Will remove the imported symbols from the list of bound symbols. (DONE 2021-02-18 13:10:08)
Will enable drag and drop for imported symbols. (DONE 2021-02-18 20:31:56)
OPEN 2020-12-06 15:07:50 | BUSY 2021-01-03 14:53:26 | TESTING 2021-01-03 17:27:26 | BUSY 2021-02-18 12:56:57 | TESTING 2021-02-18 20:32:15
Investigate why using a newly created class in a modules or environment in existing classes’ code requires recompiling that class. (Might be our missing undeclared handling). Maybe creating new associations messing up #declare:using: is root of this evil. #declare:using: sends #add: which copies the association it adds. Redefining global classes does not work. It should trigger a recompilation.
OPEN 2020-12-07 12:35:51 | DIAGNOSIS 2020-12-10 14:22:07 BUSY 2020-12-13 17:41:33 | DIAGNOSIS 2020-12-21 18:31:00
Defining a class in an environment with the same name as a global class defined in Smalltalk leads class organizer instance-variables in the browser being nil. See the screenshot below for details.
Browser>>#selectedClassName: answers nil for the global class. Using the environment-aware class list for filtering does not work. Obviously we have one case (Action) that is not part of the system organisation. If we have two classes in the same category; one global, another one in an environment, only one defined last is stored in the system organisation.
Categorizer>>#classify:under:suppressIfDefault: uses #>= to find the insertion point. This string comparison is by no means environment aware.
Now even Environments are messed up. Of course they are: The environment-awareness test-case resets the symbol-manager.
SystemDictionary>>#classNamed: contained dubious code.
OPEN 2020-12-07 16:35:29 | DIAGNOSIS 2020-12-07 22:16:43 STILL OPEN 2020-12-09 11:03:32 | WATCHING 2020-12-09 17:01:11
Filling in a package with modules over an existing package leaves one with a debugger.
OPEN 2020-12-09 | DONE 2021-03-23
Removing a module does not remove it’s classes from the system. Keeping the environments in computations leeds to spurious references. (WRONG 2021-02-27 19:03:14). Sometimes the class building stuff picks the wrong module. Got the reason: Classes created by the prameterized class builder are bound in Smalltalk instead of their proper environment (2021-02-27 19:44:08).
OPEN 2021-02-27 | BUSY 2021-02-27 16:15:13 | DIAGNOSIS 2021-02-27 19:44:08 | TESTING 2021-02-27 19:53:36
Using exactly a module Always use <Module> does not work in a browser. The same is true for Use category or <Module>. The global default module setting has no influence. The use category stuff does not even create a class, but works for the global setting. In general the global looks OK.
OPEN 2021-03-09 | WATCHING 2021-03-23
File outs of interface components miss the package name.
OPEN 2021-04-14 | DONE before 2021-04-28
Sometimes imports of class or classes bound in a module become undefined; there name is bound to nil. Usually this can be solved be recompiling the class referenced. For the time being I don’t know the exact reason.
Best theory so far: The class builder does not handle renaming classes correctly wrt. environments.
Fix: Recompile the class being referenced.
On rare occasions import specifications do not point to the export specification they import. Instead they point to the module name symbol. Usually this means, that your image is broken and needs to be recreated.
No valid theory so far.
Fix: None so far, keep backups :-]
Inspecting the contents of a code file creates the modules contained in that file. Probably this true for opening a code browser on the package. Yup it does!
Fix: Delete the spurious module.
Change set management is only half implemented. Filing out change-sets with module code may not work, because the author found that issue not too important.
Fix: Safe your module in package.