Hi All,
Clément and I were talking earlier today (about issues around the solving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM. _,,,^..^,,,_ best, Eliot
Hmph, I often hit send too soon...
On Sat, Nov 30, 2019 at 1:03 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
Clément and I were talking earlier today (about issues around thesolving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
One obvious idea is to have a special menu constructed for the selected item, so that in the text pane, when something is selected, instead of the default "set font.../set style.../...copy (c)/cut (x)..." text menu one gets a menu populated from pragmas in the Vm classes, which might include printOop:. shortPrintOop:, printFrame:, etc, (and of course copy, but not cut/paste), and that these would output to the sub-inspector in the column to the right, which ideally would cascade.
With the right pragma design we could render tis both in Squeak and in GT, and (as I'm doing in my prototyping) the Squeak-specific UI goes in its own package (VMMakerUI-Squeak) so that while the pragmas are common to both Squeak and Pharo, a Pharo VMMaker isn't polluted with Squeak UI gizmos.
[yes, this effort at cross-platform portability is probably moot given Pharo's forking of the VM, but we can always hope that good sense prevails and we are able to work together once again]
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM. _,,,^..^,,,_ best, Eliot
One of the few things I've noticed in current VW images that I actually prefer is the tracing inspector approach. I don't imagine it would be terribly hard to implement in Squeak and in fact have a faint tickling in the back of my mind (but it could be termites) that I've seen such a thing.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: REP: Randomly Execute Programmers
Hi Eliot,
it reads like you are looking for an easier way to explore the tree (or graph) structure behind the oops-object combinations. This seems to be similar to unfolding an object graph by navigating an object's instance variables. Squeak's Object Explorer ([cmd]+[shift]+[i]) can do that in a basic fashion, the Inspector ([cmd]+[i]) cannot.
Here are some thoughts on how to approach this challenge:
- A specialized #explorerContents implementation on your VM objects can help customizing the appearance of Squeak's Object Explorer. For simple filters, the default ObjectExplorerWrapper might be sufficient. See Dictionary >> #explorerContents or CompiledCode >> #explorerContents. If oops would be kind of a custom class, that class could provide #explorerContents to look up that oops.
- Squeak has only one kind of tree widget at the moment, the PluggableTreeMorph. As you suggested, a column-based version with infinite columns would be a worthwhile addition to provide a different exploration experience to users. Once available, a preference could then toggle the kind of tree widget in Squeak's Object Inspector.
- In Squeak's Inspector, the value pane is able to show text with clickable links to, for example, spawn more inspectors. See CompiledMethod >> #inspectorClass and CompiledMethodInspector >> #selection for the mechanism. Now, that #selection can return a formatted text. So your custom inspector could "style" all those oops in the printString with PluggableTextAttribute.
- In Squeak's text morphs, the double-click action cannot easily be changed. Single click, however, works through text actions (e.g., PluggableTextAttribute). See Squeak's help topics (and help browser) for examples.
~~
So, which domain objects are you talking about? Do they all have custom classes? Or is it numbers, associations, symbols, ...?
Best, Marcel Am 30.11.2019 22:10:28 schrieb Eliot Miranda eliot.miranda@gmail.com: Hmph, I often hit send too soon...
On Sat, Nov 30, 2019 at 1:03 PM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:
Hi All,
Clément and I were talking earlier today (about issues around the solving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
One obvious idea is to have a special menu constructed for the selected item, so that in the text pane, when something is selected, instead of the default "set font.../set style.../...copy (c)/cut (x)..." text menu one gets a menu populated from pragmas in the Vm classes, which might include printOop:. shortPrintOop:, printFrame:, etc, (and of course copy, but not cut/paste), and that these would output to the sub-inspector in the column to the right, which ideally would cascade.
With the right pragma design we could render tis both in Squeak and in GT, and (as I'm doing in my prototyping) the Squeak-specific UI goes in its own package (VMMakerUI-Squeak) so that while the pragmas are common to both Squeak and Pharo, a Pharo VMMaker isn't polluted with Squeak UI gizmos.
[yes, this effort at cross-platform portability is probably moot given Pharo's forking of the VM, but we can always hope that good sense prevails and we are able to work together once again]
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM.
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Hi,
Experimenting for half an hour yesterday, I think the first step is to move the simulator printOop: logic to an explorer or inspector tool. printOop: requires an address and the simulator objects. It then figures out what the address is (stack frame, heap object and which kind, native code zone item and what kind, etc) and print the relevant information of the different items.
I want to have that information in an inspector/explorer and that on each field I can click inspect/explore to get a new inspector/explorer window on that. Then I want to expand the tool a bit to have previous and next item in memory (like inspector on a heap object should allow me to quickly inspect previous and next object. And lastly I want a tool resistant to errors, because when debugging a bug memory is corrupted, and I don't want the tool to fail in that case but just to show me a message such as "That address is suspicious".
A long time ago I extended the original inspector framework [1]. I could do it again in a similar way. It's just not as convenient as in GT.
[1] https://clementbera.wordpress.com/2012/11/15/how-to-create-a-pharo-inspector...
On Mon, Dec 2, 2019 at 10:25 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
it reads like you are looking for an easier way to explore the tree (or graph) structure behind the oops-object combinations. This seems to be similar to unfolding an object graph by navigating an object's instance variables. Squeak's Object Explorer ([cmd]+[shift]+[i]) can do that in a basic fashion, the Inspector ([cmd]+[i]) cannot.
Here are some thoughts on how to approach this challenge:
- A specialized #explorerContents implementation on your VM objects can
help customizing the appearance of Squeak's Object Explorer. For simple filters, the default ObjectExplorerWrapper might be sufficient. See Dictionary >> #explorerContents or CompiledCode >> #explorerContents. If oops would be kind of a custom class, that class could provide #explorerContents to look up that oops.
- Squeak has only one kind of tree widget at the moment, the
PluggableTreeMorph. As you suggested, a column-based version with infinite columns would be a worthwhile addition to provide a different exploration experience to users. Once available, a preference could then toggle the kind of tree widget in Squeak's Object Inspector.
- In Squeak's Inspector, the value pane is able to show text with
clickable links to, for example, spawn more inspectors. See CompiledMethod
#inspectorClass and CompiledMethodInspector >> #selection for the
mechanism. Now, that #selection can return a formatted text. So your custom inspector could "style" all those oops in the printString with PluggableTextAttribute.
- In Squeak's text morphs, the double-click action cannot easily be
changed. Single click, however, works through text actions (e.g., PluggableTextAttribute). See Squeak's help topics (and help browser) for examples.
~~
So, which domain objects are you talking about? Do they all have custom classes? Or is it numbers, associations, symbols, ...?
Best, Marcel
Am 30.11.2019 22:10:28 schrieb Eliot Miranda eliot.miranda@gmail.com: Hmph, I often hit send too soon...
On Sat, Nov 30, 2019 at 1:03 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
Clément and I were talking earlier today (about issues around thesolving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
One obvious idea is to have a special menu constructed for the selected item, so that in the text pane, when something is selected, instead of the default "set font.../set style.../...copy (c)/cut (x)..." text menu one gets a menu populated from pragmas in the Vm classes, which might include printOop:. shortPrintOop:, printFrame:, etc, (and of course copy, but not cut/paste), and that these would output to the sub-inspector in the column to the right, which ideally would cascade.
With the right pragma design we could render tis both in Squeak and in GT, and (as I'm doing in my prototyping) the Squeak-specific UI goes in its own package (VMMakerUI-Squeak) so that while the pragmas are common to both Squeak and Pharo, a Pharo VMMaker isn't polluted with Squeak UI gizmos.
[yes, this effort at cross-platform portability is probably moot given Pharo's forking of the VM, but we can always hope that good sense prevails and we are able to work together once again]
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Hi Clément
On Mon, Dec 2, 2019 at 2:33 AM Clément Béra bera.clement@gmail.com wrote:
Hi,
Experimenting for half an hour yesterday, I think the first step is to move the simulator printOop: logic to an explorer or inspector tool. printOop: requires an address and the simulator objects. It then figures out what the address is (stack frame, heap object and which kind, native code zone item and what kind, etc) and print the relevant information of the different items.
My thought was to create a subclass of Inspector, called e.g. VMInspector, and have it have at least two additional inst vars, coInterpreter and objectMemory. Then it can simply send the messages printOop: et all to the relevan objects as needed. The problem with moving printOop: et al into the inspectors is then you have to modify Slang to make sure that printOop: et al get translated into C and included in gcc3x-cointerpreter.c et al. Whereas if you have a special VMInspector object t that holds onto the VM context, no changes are necessary.
I can see benefit in taking printing out of StackInterpreter et al, but that may mean lots of overrides. For example, CoInterpreter has to override printOop: (or parts of it) to make sure that CompiledCode objects are printed usefully, including the JIIT information, etc.
So if you do decide to move the printing code into an Inspector hierarchy just remember you're also signing on for a significant refactoring of the Slang for ensuring that debug printing routines get translated to C. This is a warning, not a discouragement.
I want to have that information in an inspector/explorer and that on each field I can click inspect/explore to get a new inspector/explorer window on that. Then I want to expand the tool a bit to have previous and next item in memory (like inspector on a heap object should allow me to quickly inspect previous and next object. And lastly I want a tool resistant to errors, because when debugging a bug memory is corrupted, and I don't want the tool to fail in that case but just to show me a message such as "That address is suspicious".
Right. And so I think a simple VMInspector can provide this with minimal change.
A long time ago I extended the original inspector framework [1]. I could do it again in a similar way. It's just not as convenient as in GT.
Right. But with Marcel's help we may be able to improve things a lot.
[1] https://clementbera.wordpress.com/2012/11/15/how-to-create-a-pharo-inspector...
On Mon, Dec 2, 2019 at 10:25 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
it reads like you are looking for an easier way to explore the tree (or graph) structure behind the oops-object combinations. This seems to be similar to unfolding an object graph by navigating an object's instance variables. Squeak's Object Explorer ([cmd]+[shift]+[i]) can do that in a basic fashion, the Inspector ([cmd]+[i]) cannot.
Here are some thoughts on how to approach this challenge:
- A specialized #explorerContents implementation on your VM objects can
help customizing the appearance of Squeak's Object Explorer. For simple filters, the default ObjectExplorerWrapper might be sufficient. See Dictionary >> #explorerContents or CompiledCode >> #explorerContents. If oops would be kind of a custom class, that class could provide #explorerContents to look up that oops.
- Squeak has only one kind of tree widget at the moment, the
PluggableTreeMorph. As you suggested, a column-based version with infinite columns would be a worthwhile addition to provide a different exploration experience to users. Once available, a preference could then toggle the kind of tree widget in Squeak's Object Inspector.
- In Squeak's Inspector, the value pane is able to show text with
clickable links to, for example, spawn more inspectors. See CompiledMethod
#inspectorClass and CompiledMethodInspector >> #selection for the
mechanism. Now, that #selection can return a formatted text. So your custom inspector could "style" all those oops in the printString with PluggableTextAttribute.
- In Squeak's text morphs, the double-click action cannot easily be
changed. Single click, however, works through text actions (e.g., PluggableTextAttribute). See Squeak's help topics (and help browser) for examples.
~~
So, which domain objects are you talking about? Do they all have custom classes? Or is it numbers, associations, symbols, ...?
Best, Marcel
Am 30.11.2019 22:10:28 schrieb Eliot Miranda eliot.miranda@gmail.com: Hmph, I often hit send too soon...
On Sat, Nov 30, 2019 at 1:03 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
Clément and I were talking earlier today (about issues around thesolving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
One obvious idea is to have a special menu constructed for the selected item, so that in the text pane, when something is selected, instead of the default "set font.../set style.../...copy (c)/cut (x)..." text menu one gets a menu populated from pragmas in the Vm classes, which might include printOop:. shortPrintOop:, printFrame:, etc, (and of course copy, but not cut/paste), and that these would output to the sub-inspector in the column to the right, which ideally would cascade.
With the right pragma design we could render tis both in Squeak and in GT, and (as I'm doing in my prototyping) the Squeak-specific UI goes in its own package (VMMakerUI-Squeak) so that while the pragmas are common to both Squeak and Pharo, a Pharo VMMaker isn't polluted with Squeak UI gizmos.
[yes, this effort at cross-platform portability is probably moot given Pharo's forking of the VM, but we can always hope that good sense prevails and we are able to work together once again]
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/
Hi Eliot, hi Clément,
after the 5.3 release, we can first integrate those inspector refactorings Christoph (ct) made, which are sitting in the inbox, waiting for a final review. Also, I made some first sketches on that columnar tree widget that macOS offers in its Finder. I shouldn't be too hard to offer a similar experience in Squeak, even with ToolBuilder support.
Best, Marcel Am 10.12.2019 22:13:07 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Clément
On Mon, Dec 2, 2019 at 2:33 AM Clément Béra <bera.clement@gmail.com [mailto:bera.clement@gmail.com]> wrote:
Hi,
Experimenting for half an hour yesterday, I think the first step is to move the simulator printOop: logic to an explorer or inspector tool. printOop: requires an address and the simulator objects. It then figures out what the address is (stack frame, heap object and which kind, native code zone item and what kind, etc) and print the relevant information of the different items.
My thought was to create a subclass of Inspector, called e.g. VMInspector, and have it have at least two additional inst vars, coInterpreter and objectMemory. Then it can simply send the messages printOop: et all to the relevan objects as needed. The problem with moving printOop: et al into the inspectors is then you have to modify Slang to make sure that printOop: et al get translated into C and included in gcc3x-cointerpreter.c et al. Whereas if you have a special VMInspector object t that holds onto the VM context, no changes are necessary.
I can see benefit in taking printing out of StackInterpreter et al, but that may mean lots of overrides. For example, CoInterpreter has to override printOop: (or parts of it) to make sure that CompiledCode objects are printed usefully, including the JIIT information, etc.
So if you do decide to move the printing code into an Inspector hierarchy just remember you're also signing on for a significant refactoring of the Slang for ensuring that debug printing routines get translated to C. This is a warning, not a discouragement.
I want to have that information in an inspector/explorer and that on each field I can click inspect/explore to get a new inspector/explorer window on that. Then I want to expand the tool a bit to have previous and next item in memory (like inspector on a heap object should allow me to quickly inspect previous and next object. And lastly I want a tool resistant to errors, because when debugging a bug memory is corrupted, and I don't want the tool to fail in that case but just to show me a message such as "That address is suspicious".
Right. And so I think a simple VMInspector can provide this with minimal change.
A long time ago I extended the original inspector framework [1]. I could do it again in a similar way. It's just not as convenient as in GT.
Right. But with Marcel's help we may be able to improve things a lot.
[1] https://clementbera.wordpress.com/2012/11/15/how-to-create-a-pharo-inspector... [https://clementbera.wordpress.com/2012/11/15/how-to-create-a-pharo-inspector...]
On Mon, Dec 2, 2019 at 10:25 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Eliot,
it reads like you are looking for an easier way to explore the tree (or graph) structure behind the oops-object combinations. This seems to be similar to unfolding an object graph by navigating an object's instance variables. Squeak's Object Explorer ([cmd]+[shift]+[i]) can do that in a basic fashion, the Inspector ([cmd]+[i]) cannot.
Here are some thoughts on how to approach this challenge:
- A specialized #explorerContents implementation on your VM objects can help customizing the appearance of Squeak's Object Explorer. For simple filters, the default ObjectExplorerWrapper might be sufficient. See Dictionary >> #explorerContents or CompiledCode >> #explorerContents. If oops would be kind of a custom class, that class could provide #explorerContents to look up that oops.
- Squeak has only one kind of tree widget at the moment, the PluggableTreeMorph. As you suggested, a column-based version with infinite columns would be a worthwhile addition to provide a different exploration experience to users. Once available, a preference could then toggle the kind of tree widget in Squeak's Object Inspector.
- In Squeak's Inspector, the value pane is able to show text with clickable links to, for example, spawn more inspectors. See CompiledMethod >> #inspectorClass and CompiledMethodInspector >> #selection for the mechanism. Now, that #selection can return a formatted text. So your custom inspector could "style" all those oops in the printString with PluggableTextAttribute.
- In Squeak's text morphs, the double-click action cannot easily be changed. Single click, however, works through text actions (e.g., PluggableTextAttribute). See Squeak's help topics (and help browser) for examples.
~~
So, which domain objects are you talking about? Do they all have custom classes? Or is it numbers, associations, symbols, ...?
Best, Marcel Am 30.11.2019 22:10:28 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>: Hmph, I often hit send too soon...
On Sat, Nov 30, 2019 at 1:03 PM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:
Hi All,
Clément and I were talking earlier today (about issues around the solving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider).
So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel.
One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this:
16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor:
One obvious idea is to have a special menu constructed for the selected item, so that in the text pane, when something is selected, instead of the default "set font.../set style.../...copy (c)/cut (x)..." text menu one gets a menu populated from pragmas in the Vm classes, which might include printOop:. shortPrintOop:, printFrame:, etc, (and of course copy, but not cut/paste), and that these would output to the sub-inspector in the column to the right, which ideally would cascade.
With the right pragma design we could render tis both in Squeak and in GT, and (as I'm doing in my prototyping) the Squeak-specific UI goes in its own package (VMMakerUI-Squeak) so that while the pragmas are common to both Squeak and Pharo, a Pharo VMMaker isn't polluted with Squeak UI gizmos.
[yes, this effort at cross-platform portability is probably moot given Pharo's forking of the VM, but we can always hope that good sense prevails and we are able to work together once again]
Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation.
So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction?
How would one build a cascading Inspector as per GT?
And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM.
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
--
Clément Béra https://clementbera.github.io/ [https://clementbera.github.io/] https://clementbera.wordpress.com/ [https://clementbera.wordpress.com/]
--
_,,,^..^,,,_
best, Eliot
vm-dev@lists.squeakfoundation.org
-
Clément Béra -
Eliot Miranda -
Marcel Taeumel -
tim Rowledge