hpi-swa-lab / babylonian-programming-smalltalk Goto Github PK

Saving a method with probes results in "nothing more expected"

Results in TheClass new

If a sample has a longer text than the containing code holder (so that you can scroll down), the first character you type in the sample text will automatically scroll up again.

Initial state: Empty method with a single example

Upon deleting the example and saving,

Debugger:

but allow for continued execution, maybe always allow for 5 more seconds to run?

Put in a temporary probe that records the results of the dispatch and displays a list of actual methods that are called to allow for simple navigation.

Currently, users see the unedited execution values for examples. When the executed message itself returns self, there is no telling by the button if the objects are the same or a new object of the receiving class is returned. Users have to inspect the object and manually check its object identity or check the return value of a message to ensure the object itself is returned. It's quicker to just display 'result: self' in these cases.
From:

to:

What to keep in mind:

• BPExampleMorph >> exectuionResultAsString edits the displayed text
• BPExampleMorph >> exectuionResultAsString may not execute the example method to eg. check if the receiver is the same after sending the message to the receiving class again

Currently the ExamplesMorph is indented with an extra tab which remains in place when code is stored. As this is unusual and an unnecessary character, we should layout the SOH with the TextIndent attribute.

More considerations:

• in loops
• maybe it is important to see that this is part of a failed trace

Multiple probes at the same location break the parsing / compiling.

Multiple probes in the same line break layouting.

Probing method arguments would provide immediate context for a method. Either this is enabled by default for every method that has at least one probe, or users should be able to explicitly probe arguments.

Instead it should check if a method with same name exists and rename its own method

e.g. when opening a method with an example in two browsers

If you click into the text of a sample to give it keyboard focus, and then move the surrounding TextMorph, it does not get the focus back despite #mouseOverToKeyboardFocus being enabled.

(reported by @LinqLover)

Instead of overwriting it should only append the method to the class

Or at any other point outside of a statement / expression.

Annotations can not be placed in the debugger because of it does not set #currentCompiledMethod. #determineIntervalToAnnotateFor:forNodes: should maybe not use internal state and use the #compiledMethod-Extension instead.

Also applies to ChangeList.

(reported by @LinqLover)

Currently, each line in a BPSwimlane consists of a morph for each called method in the stack.
However, if a line above any other line already defined a stack morph for a method, which is also called in that order for current line, the height of the previous morph should increase to cover the current line instead of making a new morph.
.

This will decrease the morph count noticeably.

Currently strings (for example in expectedResult) are written into the test without ''. This will result in an syntax error for most strings

The problem in a nutshell: When adding characters behind a probe, they are added to the probe, as attributes should propagate to successors.

Wenn man hinter dem letzten Zeichen des Ausdrucks, auf das sich eine Probe bezieht, weitertippt, landet die Addition beim Speichern innerhalb des annotierten Babylonian-Ausdrucks. In vielen Fällen eher wenig nützlich, beispielsweise, wenn man ein neues Statement eingetippt hat (z. B. hinter foo ein . bar). Ich hätte aber auch keine Idee, wie man das auf die Schnelle lösen könnte, ohne die Semantik von Attributen im normalen Editor auf den Kopf zu stellen

Should probably by activated by default.

When one opens a debugger by halting at a probe and one then restarts the method and hits the probe again, another debugger opens.

• Propagate set of active layers to other processes
• Propagate DynamicVariables to other processes
• Ensure tracing is thread-safe
• remember the newly created processes, as they also need to be stopped when anything goes wrong OR we want to terminate the example execution
• Track exceptions in the descendant processes

investigate!

These should probably be updated if possible. Maybe simple use allInstances and check for the old name?

BPExtractAnnotations fails for (AdditionalMethodState >> #keysAndValuesDo:) bpAnnotations with "MessageNotUnderstood: UndefinedObject>>ruleName", bc of comments such as "<Association|Pragma>". The grammar should be more strict and not try to parse these as babylonian annotations.
Reported by @LinqLover

This will simpilfy the whole compiler logic and speed up the process.

See PR #92

They should only style when a method is displayed.

They are very error-prone to implement, and do not add much value right now.

Getting an example through #bpExamples and then modifying its name, can break the parsing of the method that contains the example

This one is tricky when one works with a method in a superclass A but investigates an execution of this method on an object of subclass B and one is interested in an instance variable that is only defined in B. As the probe expression block is compiled in the context of A the resulting bytecode can not access the instance variable of B, also it is unclear how it might go about this.

One solution may be to convert the static instance variable access to a dynamic one aka self instVarNamed: #instVarName. As the expression probe block is only instantiated during the method execution self binds to the correct object.

When annotating the main loop in displayLine: textLine offset: offset leftInRun: leftInRun the method can not be saved implying a syntax error in the annotated source code.

Similar to what BPMethodExamples have. Otherwise BPScriptExample>>#runOn: throws UndeclaredVariableWarning which is unnecessary, as we have them set up. The RunConfiguration should also honor the setup scripts.

This will remove the example from the system, but the pragma is not removed when the change to the source code is cancelled. When trying to render the annotation for the pragma the example instance can not be found in the global collection.

Add a way to add examples from superclasses.

The symbols for example collapse / expand should be triangle right and triangle down.

Then we can use the elipse icon to implement a new menu that includes advanced actions on examples such as:

• open in printbugger
• directly start in debugger