aglynn42 / charismetabase

Charismeta Windows Pharo 6.1

These are changed library packages for Charismeta for Pharo 6.1 on Windows. Charismeta is a Smalltalk version of Meta, taking advantage of the tools in Pharo. A sample use case is below.

Charismeta sample use case:

Problem: a unit test started failing with an undefined object exception after a recent update from GIT, however the unit tests on the changed and directly related classes pass. Procedure: When the exception occurs, and Pharo brings up the debugger, rather than spending time stepping back to see where the object that is not defined (i.e. not set to anything – like a null pointer exception) originated, the developer asks Charismeta via the chat window in Pharo “is this exception related to changes that came in the latest update from GIT?” Charismeta parses the question using topic word clustering, and from the parsed sentence looks at the classes changed in the latest update, gets the current virtual stack from the debugger, and compares the current code, the running code in memory, the current code model, and the diff from the changes to the code model created by the latest code changes.
Although the changes didn’t trigger this unit test automatically, since the class under test wasn’t directly affected, Charismeta can see that one of the changes did directly affect a class that is part of a pattern which includes the failing class. By looking up the pattern from the code model (all the GoF design patterns along with quite a few more are built in to Smalltalk) Charismeta can see that it is a Chain of Responsibility pattern. Although the pattern appears to be intact in the code models, querying the running code shows two elements in the message flow that depart from the pattern. By calling the message flow browser and backtracking programmatically, Charismeta finds a message being passed which has an accompanying object not part of the design pattern, and looking at the sender can see that while its code hasn’t changed, the methods it called to respond to the message it received are the second element that departs from the design pattern. Stepping back one more message, the sender of that message is one of the classes where code was altered. Charismeta responds “one of the classes changed is part of a Chain of Responsibility which also includes the class under test when the failure occurred, and one of the messages in the chain is sending a different object with the message, here is the class that changed.” Charismeta invokes the system code browser with that class in focus, and sets it to “scoped”, so that only other classes in the running scope are displayed in the class list area of the browser.
Charismeta then asks, “would you like me to try to fix the problem?” The developer responds “sure”.
Charismeta queries the code critics module (Renraku) with all critics enabled to look for any direct problems with the way the code is written, Renraku suggests that a method has a bunch of conditionals that would be better done as a cascade. Charismeta then calls the code rewrite module on that method and it rearranges the messy conditionals into a clean cascade.
It then calls the refactoring tools and tells the tool to apply the Chain of Responsibility pattern from the class where the original pattern began to the class with the failing test. The refactoring tools attempt do so, but it results in no further changes, since the code still constitutes a valid CoR pattern. Charismeta then calls the unit tests related to its changes to be run in a second test runner. Those tests all pass. Lastly, it calls the unit test that failed and any unit tests on classes directly related to it in that second test runner, and those all pass. Since the failing test and related tests are now passing, and tests on the changes it had the rewrite tool make and related classes are now passing. Charismeta says, “it appears to be fixed, but you should run all the tests for this module, at least, and make sure that it hasn’t introduced any new problems”. The developer, prior to running a larger set of tests, clicks ‘restart’ in the still open debugger showing the exception. This time the tests he was running all pass. He decides to look at what Charismeta had done. Bringing up a generic system code browser (i.e. unscoped) he can find what classes were changed, since they’re at the top of the left navigation pane under “Recently Changed”. He selects the most recently changed class and compares it to the previous version, and sees the messy conditionals section has been changed to a clean cascade. He looks at the logic of the cascade and it seems correct, although with the original conditionals section it’s difficult to tell what it was doing in every possible system state. Since what it’s doing in different states is clearer now. He goes back to the test runner and selects all tests for all the packages in the module, and clicks “run profiled”, so that he can check for any other bugs and make sure the changed classes and all of those around them don’t have any new performance problems. All the tests pass, and the profiler results show no particularly long running methods, prior to returning to the work he was doing that triggered the failing test to be run initially, he puts a note in Grafoscopio that includes links to the class whose unit test failed and the class Charismeta changed, to the effect that using clean cascades is important in terms of understanding the logic clearly enough to prevent introducing problems. Since the changed class was changed in the last commit, when he saves the note, Charismeta also links the note to the git change record.