Defects ======= As we all know, no software is bug-free, especially when it contains more than three line of code. Defects Fixed ------------- ``f49a8518-e49e-4235-821a-68b0d2e9ba38`` 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 DONE before 2022-04-29 ``ea672ea8-1eb6-4d9f-829e-5539d3fc406b`` 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 ``57400aef-d0ac-483a-a9ff-5b3d1b331921`` 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 DONE before 2022-04-29 ``030be14a-5be0-43e7-bd8b-630c3dc28b49`` 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. 2022-04-29: It is definitly the missing undeclared handling. I added a workaround that just recompiles everything in module. 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 | WORKAROUND before 2022-04-29 ``fdfb56ab-678f-4893-b242-3f26fd4b95c5`` 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 DONE 2022-04-29 .. image:: BrowserDuplicateGlobalClass.jpeg :scale: 50% ``31c6b8bb-13ea-4d67-ba86-d5f5904a8346`` Filling in a package with modules over an existing package leaves one with a debugger. OPEN 2020-12-09 | DONE 2021-03-23 ``f6795b8d-0e56-4cb5-b5ce-f7cd66b38d3c`` 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 ``ce53a2c6-e7d1-4d74-bef7-ff8ce7b771a4`` Using exactly a module `Always use ` does not work in a browser. The same is true for `Use category or `. 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 ``290b20af-7f6a-4503-af35-51e31689dafc`` File outs of interface components miss the package name. OPEN 2021-04-14 | DONE before 2021-04-28 ``970e8f95-82e7-427f-b47d-d570e4022847`` 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.* See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/3 OPEN 2020-12-09 | DONE 2022-01-20 ``0c6a4759-d736-4328-832d-2faee6d9bfce`` It was not possible to import packages, that depend on one or more integrated module. OPEN 2022-05-04 | DONE 2022-05-04 ``00c74c59-5710-41ad-baf5-d3dc8c74c6a6`` The default module browser was broken. Fixed by loading the pluggable button morph code into module and sub-classing it. OPEN 2022-05-04 | DONE 2022-05-04 Know Limitations ---------------- ``96007d90-9859-4176-9688-6d2a59ca188e`` 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. See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/1 *Fix: Recompile the class being referenced.* 2022-04-29: This workaround is now applied automatically. Undefined handling is still missing. OPEN 2021-04-28 ``6501e4a4-76b0-4104-a721-9ce895e6892c`` 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. See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/2 *Fix: None so far, keep backups :-]* OPEN 2021-04-28 ``7f2bf0b4-8442-4013-a147-fe229ac19608`` 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.* See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/4 OPEN 2021-04-28 ``d9dbfc51-c866-4ffc-bfd0-de3ff36a2352`` Haver's version of the plugable button morph does not rotate with the canvas used by vector graphics. I could not reproduce this behavior. See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/14 OPEN 2022-04-25 | CANCELED 2022-05-05 ``4f124b73-64c4-413e-b9fe-b8b14f4e556b`` Haver sometimes reorders categories during file-out. I had to use the old Cuis file-out code, that has a bug wrt. to category ordering, but handles some methods like #compilerClass correctly. See: https://todo.sr.ht/~cy-de-fect/HaverOnCuis/15 OPEN 2022-05-05 Bug Reporting ------------- An issue tracker can be found at `sourcehut`_: https://todo.sr.ht/~cy-de-fect/HaverOnCuis .. _sourcehut: https://sr.ht/