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).

  1. Will remove the imported symbols from the list of bound symbols. (DONE 2021-02-18 13:10:08)

  2. 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

_images/BrowserDuplicateGlobalClass.jpeg
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 <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

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