[Pharo4] Slots: GTInspector support
Hi, Now GTInspector can inspect objects that use custom Slot definitions. https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support <https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support> create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared over all instances of A): Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: âPlayground' Inspect A new change âivâ to value (e.g. 5). inspect another "A newâ ==> it should show the value as 5. Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course). The GT support of course needs to be improved later: -> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition -> ⦠I am sure more will be obvious as soon as we use it. Marcus
Excellent! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 16, 2015, at 10:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Now GTInspector can inspect objects that use custom Slot definitions.
https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support <https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support>
create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared over all instances of A):
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: âPlayground'
Inspect
A new
change âivâ to value (e.g. 5).
inspect another "A newâ
==> it should show the value as 5.
Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course).
The GT support of course needs to be improved later:
-> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition -> ⦠I am sure more will be obvious as soon as we use it.
Marcus
Hi Marcus, So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object? Cheers, Andrei On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Now GTInspector can inspect objects that use custom Slot definitions.
https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support
create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared over all instances of A):
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: âPlayground'
Inspect
A new
change âivâ to value (e.g. 5).
inspect another "A newâ
==> it should show the value as 5.
Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course).
The GT support of course needs to be improved later:
-> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition -> ⦠I am sure more will be obvious as soon as we use it.
Marcus
I guess so. Doru On Fri, Jan 16, 2015 at 3:28 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Hi Marcus,
So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object?
Cheers, Andrei
On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Now GTInspector can inspect objects that use custom Slot definitions.
https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support
create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared over all instances of A):
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: âPlayground'
Inspect
A new
change âivâ to value (e.g. 5).
inspect another "A newâ
==> it should show the value as 5.
Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course).
The GT support of course needs to be improved later:
-> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition -> ⦠I am sure more will be obvious as soon as we use it.
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Hi Marcus,
So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object?
Yes, at least for now⦠I am not yet that happy with the naming⦠it is hard to get consistent *and* be resably compatibleâ¦. So the idea is that the old API for (instVarAt:, instVarNamesâ¦) continues to work *but* this shows (and manipulates) what is really there. VM level instance variables. Slots are first class instance variables that a) might redefine what happens of read/write â> all reflective read and write needs to go through the slots. b) they often correspond 1:1 to a low level ivar, but they donât have to (e.g. the TestSlot in the example has no underlying ivar) â> we need to ask for all Slots, not just all instVarNames. For the naming⦠in some way Slots are just âFirst Class Instance Variablesâ that map to VM level Fields. Sometimes I feel it would be nice to use just these two for naming: Fields (VM Level) and Instance Variables (Image level, aka Slots). But then, there is backward compatibility to be taken into account⦠we canât really change instVarAt:⦠but we could of course keep those for legacy and use the âlong formâ for the âreifiedâ instance variables: instanceVariableNamed:, #instanceVariableNames, and so on⦠To make it really consistent and just use âField and Ivar", there would be a lot to be changed: names of byte codes, for example. So maybe having it like it is now is good? âField and Ivarâ are one concept, while the high-level one is âSlotâ. I am not sure myself⦠I have to admit. Marcus
For me it's ok like it is now. I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot). [image: Inline image 1] Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account. Cheers, Andrei On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Hi Marcus,
So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object?
Yes, at least for now⦠I am not yet that happy with the naming⦠it is hard to get consistent *and* be resably compatibleâ¦.
So the idea is that the old API for (instVarAt:, instVarNamesâ¦) continues to work *but* this shows (and manipulates) what is really there. VM level instance variables.
Slots are first class instance variables that a) might redefine what happens of read/write â> all reflective read and write needs to go through the slots. b) they often correspond 1:1 to a low level ivar, but they donât have to (e.g. the TestSlot in the example has no underlying ivar) â> we need to ask for all Slots, not just all instVarNames.
For the naming⦠in some way Slots are just âFirst Class Instance Variablesâ that map to VM level Fields. Sometimes I feel it would be nice to use just these two for naming: Fields (VM Level) and Instance Variables (Image level, aka Slots).
But then, there is backward compatibility to be taken into account⦠we canât really change instVarAt:⦠but we could of course keep those for legacy and use the âlong formâ for the âreifiedâ instance variables: instanceVariableNamed:, #instanceVariableNames, and so onâ¦
To make it really consistent and just use âField and Ivar", there would be a lot to be changed: names of byte codes, for example. So maybe having it like it is now is good? âField and Ivarâ are one concept, while the high-level one is âSlotâ.
I am not sure myself⦠I have to admit.
Marcus
On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei@gmail.com> wrote:
For me it's ok like it is now.
I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot).
<Screen Shot 2015-01-16 at 4.06.03 PM.png>
Wow! And just like that, the byte code debugger is actually very useful to see what happens for real with Slotsâ¦. very useful especially when you emit you own byte code for a Slot.
Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account.
Yes, that would be nice. Marcus
On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei@gmail.com> wrote:
For me it's ok like it is now.
I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot).
<Screen Shot 2015-01-16 at 4.06.03 PM.png>
Wow! And just like that, the byte code debugger is actually very useful to see what happens for real with Slotsâ¦. very useful especially when you emit you own byte code for a Slot.
Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account.
Yes, that would be nice.
I made an issue: https://pharo.fogbugz.com/f/cases/14743/The-debugger-should-skip-the-reading... Now there is still the issue of stepping into a slot write, when stepping into instructions. One solution could be to have a setting that makes the debugger slot sensitive (stepping into enters both slot reads and slot writes). However, with the bytecode debugger one can easily step into slots. Cheers, Andrei
Marcus
Marcus would not it make sense to emit a bytecode marker (kind of no-op) so that the tools can get more information about the encoded computation and get some abtsraction? Stef Le 16/1/15 18:22, Andrei Chis a écrit :
On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > For me it's ok like it is now. > > > I updated the GTDebuggers to use slots. > For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot). > > <Screen Shot 2015-01-16 at 4.06.03 PM.png> >
Wow! And just like that, the byte code debugger is actually very useful to see what happens for real with Slotsâ¦. very useful especially when you emit you own byte code for a Slot.
> Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. > The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account. >
Yes, that would be nice.
I made an issue: https://pharo.fogbugz.com/f/cases/14743/The-debugger-should-skip-the-reading...
Now there is still the issue of stepping into a slot write, when stepping into instructions. One solution could be to have a setting that makes the debugger slot sensitive (stepping into enters both slot reads and slot writes). However, with the bytecode debugger one can easily step into slots.
Cheers, Andrei
Marcus
On 17 Jan 2015, at 04:31, stepharo <stepharo@free.fr> wrote:
Marcus would not it make sense to emit a bytecode marker (kind of no-op) so that the tools can get more information about the encoded computation and get some abtsraction?
Honestly: tools should work on the AST level. Everything is there on the ASTâ¦. Marcus
Hi andrei once it will be fully working I think that we will need a way to activate it or not. Because for most people Slots will be transparent. But your work is great for slot designers. Keep pushing. Stef Le 16/1/15 16:12, Andrei Chis a écrit :
For me it's ok like it is now.
I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot).
Inline image 1
Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account.
Cheers, Andrei
On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > Hi Marcus, > > So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object? >
Yes, at least for now⦠I am not yet that happy with the naming⦠it is hard to get consistent *and* be resably compatibleâ¦.
So the idea is that the old API for (instVarAt:, instVarNamesâ¦) continues to work *but* this shows (and manipulates) what is really there. VM level instance variables.
Slots are first class instance variables that a) might redefine what happens of read/write â> all reflective read and write needs to go through the slots. b) they often correspond 1:1 to a low level ivar, but they donât have to (e.g. the TestSlot in the example has no underlying ivar) â> we need to ask for all Slots, not just all instVarNames.
For the naming⦠in some way Slots are just âFirst Class Instance Variablesâ that map to VM level Fields. Sometimes I feel it would be nice to use just these two for naming: Fields (VM Level) and Instance Variables (Image level, aka Slots).
But then, there is backward compatibility to be taken into account⦠we canât really change instVarAt:⦠but we could of course keep those for legacy and use the âlong formâ for the âreifiedâ instance variables: instanceVariableNamed:, #instanceVariableNames, and so onâ¦
To make it really consistent and just use âField and Ivar", there would be a lot to be changed: names of byte codes, for example. So maybe having it like it is now is good? âField and Ivarâ are one concept, while the high-level one is âSlotâ.
I am not sure myself⦠I have to admit.
Marcus
On 16 January 2015 at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
change âivâ to value (e.g. 5).
How do you do that? When I try iv := 5 in the inspector, it looks like it's changing a local variable instead of the slot (as if the bottom field of the inspector was a workspace) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On 16 Jan 2015, at 12:20, Damien Pollet <damien.pollet@gmail.com> wrote:
On 16 January 2015 at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
change âivâ to value (e.g. 5).
How do you do that?
double click on the value⦠(it is a secret feature for now ;-)
When I try iv := 5 in the inspector, it looks like it's changing a local variable instead of the slot (as if the bottom field of the inspector was a workspace)
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On 16 January 2015 at 16:22, Marcus Denker <marcus.denker@inria.fr> wrote:
How do you do that?
double click on the value⦠(it is a secret feature for now ;-)
hhhaaahhhh :) it worked via writing an accessor method too -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (6)
-
Alexandre Bergel -
Andrei Chis -
Damien Pollet -
Marcus Denker -
stepharo -
Tudor Girba