Further ideas to improve overall bytecode tools:


  *   We could reuse Marcel's recent #save*InspectorState approach to memorize which methods should be displayed as bytecode. It would be also great to extend the Debugger factory API to specify the desired contentsSymbol. CodeHolders (such as MessageSets or other debuggers) could pass their contentsSymbol if you open a new CodeHolder on them, for example by pressing Browse, Implementors, or also via debugIt. Maybe we could also make a preference for the preferred content symbol?
  *   It would be great if the bytecode (i. e. CompiledCode >> #symbolic) would show real evaluable Smalltalk messages. For example, 'returnTop' has no implementors, and if you want to find out what this bytecode does, you need to either debug the stepInto button, or browse your image via #methodStringsContainingit, so I would find it much more convenient to directly write 'methodReturnTop' into the bytecode.
A very simple approach could be the following:

InstructionPointer >> #subclassResponsibility
| sender |
sender := thisContext sender.
(self class whichCategoryIncludesSelector: sender selector) = #'instruction decoding'
ifFalse: [^ super subclassResponsibility].
self print: sender asMessage.
However, this would require a proper use of "^ self subclassResponsibility" in InstructionClient.

  *   We could also use a multi-column list instead of a text pane to display the bytecodes.
  *   Maybe also provide a side-by-side view of both source and bytecode with synchronized selection? This could help associating the bytecodes with the original source.
  *   ...

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph
Gesendet: Montag, 20. Januar 2020 15:39 Uhr
An: Squeak Dev
Betreff: [squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs


Hi all, time for some more context fun! :-)


Marcel recently mentioned to me that we could need some kind of "raw debugger" for a better experience when exploring the bytecode.

The current best work"flow" to do this was: In the open debugger, first evaluate [ThisContext method symbolic edit] in the CVI (ContextVariablesInspector) to see the bytecode. Then, while debugging, you need to evaluate [ThisContext pc] in the CVI repeatedly to check the current position and compare it with the bytecode to see what's going on. Furthermore, you could open the debug menu of the stepInto button and debug the button action to dive into the deeps of context simulation.


This changeset proposes an implementation for debugging the bytecode directly. It's still very alpha-WiP-tbd-y, but it might give you an impression of my approach.

Some screenshots (sorry, Dave!):

Comeback of the code provenance button:

[cid:d1d771ba-ba9b-41cb-b7ed-08c00b322fc5]

Take attention to the Simulate button!

[cid:d6ebdeed-824c-4cbb-8299-af44d771afdd]


Go ahead and give me feedback! It would be nice to have an early version of this feature in Trunk in not-so-far time; I am sure this could be helpful for investigating all the context bug I reported over the latest months.

I'm excited to hear from you!


Best,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200120/205b34c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 53722 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200120/205b34c6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 57006 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200120/205b34c6/attachment-0003.png>