Re: [Pharo-dev] DebugSession>>activePC:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment>
in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc. Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al. So the distinction is important and the utility method is probably useful. Do you want to remove the method simply because there are no senders in the image? If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed. Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Thomas can you integrate such comments in the debugger class comment @Eliot thanks for the explanation. About the method removed, could you please react less negatively? It would be nice. I cannot believe that you the guy that know the VM would get stopped to open a bug entry telling us that isOptimizedBlock has been removed and it should not. How much time opening a bug entry can take? Under 1 min I guess. So why if marcus removed it inadvertly would you want to make him feel bad? I donât want people to feel bad. We can do mistake. I prefer a living system where people can make mistake over a system that is frozen. In that case I prefer to go and code in Java or javascript for many obvious reasons. May be it was removed because it was in an extension method. So if you do not collaborate then how can we know it? Stef Usually at home I move the dirt outside so that people can take them away. Now if my kids tells me not to throw away then I donât.
On 10 Jan 2019, at 15:11, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment>
in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Eliot I would like also two points to this. - First we asked thomas to write tests about the debugger model and you see if they would be tests about methods we could understand that they are used and control what they do. So we should all thank thomas for his energy in this not so easy task. - Second it would be nice if you could refrain to be systematically negative about what we are doing. I think that our development process is much better than many others :) It is not perfect because this does not exist. I think that we are doing a great job make Smalltalk cool. And yes it may happen that one untested, undocumented method get lost. I think that we are doing pretty good given the resources we have. Stef
On 10 Jan 2019, at 15:11, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment>
in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
Hi, @Eliot: Thanks for the clarifying answer. I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand. As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :). @Thomas: Thanks for this effort! Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment>
in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
-- www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
Hi, Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it. @Eliot After taking another look at this method, there's something I don't understand: activePC: aContext ^ (self isLatestContext: aContext) Â Â Â Â Â Â ifTrue: [ interruptedContext pc ] Â Â Â Â Â Â ifFalse: [ self previousPC: aContext ] isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument... Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name? Cheers, Thomas On 11/01/2019 13:53, Tudor Girba wrote:
Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand.
As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :).
@Thomas: Thanks for this effort!
Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. -- www.feenk.com
âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
Hi Thomas,
On Jan 11, 2019, at 6:49 AM, Thomas Dupriez <tdupriez@ens-paris-saclay.fr> wrote:
Hi,
Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it.
@Eliot
After taking another look at this method, there's something I don't understand:
activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ interruptedContext pc ] ifFalse: [ self previousPC: aContext ]
isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument...
Ugh, I had missed that. Thanks for pointing that out. It does look like a bug. The Squeak code is very different (much less elegant code written by me in DebuggerMethodMap) but that code does use only one context. So I expect the code should read activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ aContext pc ] ifFalse: [ self previousPC: aContext ]
Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name?
Because the active pc is used to derive display feedback in the debugger. In particular it is used to derive source ranges for contexts.
Cheers, Thomas
On 11/01/2019 13:53, Tudor Girba wrote: Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand.
As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :).
@Thomas: Thanks for this effort!
Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. -- www.feenk.com
âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
Hi Thomas, forgive me, my first response was too terse. Having thought about it in the shower it becomes clear :-)
On Jan 11, 2019, at 6:49 AM, Thomas Dupriez <tdupriez@ens-paris-saclay.fr> wrote:
Hi,
Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it.
@Eliot
After taking another look at this method, there's something I don't understand:
activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ interruptedContext pc ] ifFalse: [ self previousPC: aContext ]
isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument...
Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name?
There are two âmodesâ where a pc us mapped to a source range. One is when stepping a context in the debugger (the context is on top and is actively executing bytecodes). Here the debugger stops immediately before a send or assignment or return, so that for sends we can do into or over, or for assignments or returns check stack top to see what will be assigned or returned. In this mode we want the pc of the send, assign or return to map to the source range for the send, or the expression being assigned or returned. Since this is the âcommon caseâ, and since this is the only choice that makes sense for assignments ta and returns, the bytecode compiler constructs itâs pc to source range map in terms of the pc of the first byte if the send, assign or return bytecode. The second âmodeâ is when selecting a context below the top context. The pc for any context below the top context will be the return pc for a send, because the send has already happened. The compiler could choose to map this pc to the send, but it would not match what works for the common case. Another choice would appear be to have two map entries, one for the send and one for the return pc, both mapping to the source range. But this wouldnât work because the result of a send might be assigned or returned and so there is a potential conflict. I stead the reasonable solution is to select the previous pc for contexts below the top of context, which will be the pc for the start of the send bytecode. HTH
Cheers, Thomas
On 11/01/2019 13:53, Tudor Girba wrote: Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand.
As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :).
@Thomas: Thanks for this effort!
Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. -- www.feenk.com
âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
Yeah, it's a bit unfortunate you assumed I wanted to remove the method. It brought up a not so pleasant discussion. Everyone makes mistakes. :-) So if I understand, this method gives the pc that maps to the ast node the debugger should highlight when a context is selected in the stack widget? If I'm right, how comes that this method has no senders in the debugger code? That would mean this feature is also implemented somewhere else. Thomas Le 11/01/2019 à 20:28, Eliot Miranda a écrit :
Hi Thomas,
forgive me, my first response was too terse. Having thought about it in the shower it becomes clear :-)
On Jan 11, 2019, at 6:49 AM, Thomas Dupriez <tdupriez@ens-paris-saclay.fr> wrote:
Hi,
Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it.
@Eliot
After taking another look at this method, there's something I don't understand:
activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ interruptedContext pc ] ifFalse: [ self previousPC: aContext ]
isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument...
Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name? There are two âmodesâ where a pc us mapped to a source range. One is when stepping a context in the debugger (the context is on top and is actively executing bytecodes). Here the debugger stops immediately before a send or assignment or return, so that for sends we can do into or over, or for assignments or returns check stack top to see what will be assigned or returned. In this mode we want the pc of the send, assign or return to map to the source range for the send, or the expression being assigned or returned. Since this is the âcommon caseâ, and since this is the only choice that makes sense for assignments ta and returns, the bytecode compiler constructs itâs pc to source range map in terms of the pc of the first byte if the send, assign or return bytecode.
The second âmodeâ is when selecting a context below the top context. The pc for any context below the top context will be the return pc for a send, because the send has already happened. The compiler could choose to map this pc to the send, but it would not match what works for the common case. Another choice would appear be to have two map entries, one for the send and one for the return pc, both mapping to the source range. But this wouldnât work because the result of a send might be assigned or returned and so there is a potential conflict. I stead the reasonable solution is to select the previous pc for contexts below the top of context, which will be the pc for the start of the send bytecode.
HTH
Cheers, Thomas
On 11/01/2019 13:53, Tudor Girba wrote: Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand.
As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :).
@Thomas: Thanks for this effort!
Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. -- www.feenk.com
âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
On 11 Jan 2019, at 20:28, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
forgive me, my first response was too terse. Having thought about it in the shower it becomes clear :-)
On Jan 11, 2019, at 6:49 AM, Thomas Dupriez <tdupriez@ens-paris-saclay.fr> wrote:
Hi,
Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it.
@Eliot
After taking another look at this method, there's something I don't understand:
activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ interruptedContext pc ] ifFalse: [ self previousPC: aContext ]
isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument...
Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name?
There are two âmodesâ where a pc us mapped to a source range. One is when stepping a context in the debugger (the context is on top and is actively executing bytecodes). Here the debugger stops immediately before a send or assignment or return, so that for sends we can do into or over, or for assignments or returns check stack top to see what will be assigned or returned. In this mode we want the pc of the send, assign or return to map to the source range for the send, or the expression being assigned or returned. Since this is the âcommon caseâ, and since this is the only choice that makes sense for assignments ta and returns, the bytecode compiler constructs itâs pc to source range map in terms of the pc of the first byte if the send, assign or return bytecode.
The second âmodeâ is when selecting a context below the top context. The pc for any context below the top context will be the return pc for a send, because the send has already happened. The compiler could choose to map this pc to the send, but it would not match what works for the common case. Another choice would appear be to have two map entries, one for the send and one for the return pc, both mapping to the source range. But this wouldnât work because the result of a send might be assigned or returned and so there is a potential conflict. I stead the reasonable solution is to select the previous pc for contexts below the top of context, which will be the pc for the start of the send bytecode.
I checked with Thomas -> for source mapping, we use the API of the method map. The map does the âget the mapping for the instruction beforeâ, it just needs to be told that we ask the range for an active context: #rangeForPC:contextIsActiveContext: it is called ^aContext debuggerMap rangeForPC: aContext pc contextIsActiveContext: (self isLatestContext: aContext) ] So the logic was move from the debugger to the Map. (I think this is even your design?), and thus the logic inside the debugger is not needed anymore. -> For the question why the AST node of the Block has no simple method to check if it is an âisOptimizedâ block (e.g. in an ifTrue:): Yes, that might be nice. The reason why is is not there is that the compiler internally using OCOptimizedBlockScope and a check on the AST level was never needed. I would have added it as soon as it would be needed (quite easy to do). On the AST level there is already a check, though, if a *send* is optimized, which is used for code generation (#isInlined). The question why we did not add more compatibility layers to the old AST is that is is quite different.. so even with some methods here and there 99% of clients need changes, so I did not even investigate it too much. With the idea that if we end up in a situation where we need just a method, we can just add it as needed. In general, I have no srtong feelings about the details of the implementation of Opal. Itâs just what was possible, with the resources and the understanding that I had at the point it was done. There are for sure even mistakes. I always make mistakes. In addition, it is based on a prior compiler which was done for a different closure model whose Design-choices influenced it too much I think, sometimes good, sometimes not. But I like the âhigh levelâ: using a shared AST between the compiler and the tools *and* having a mapping BC -> AST -> Text. Of course I understand that the choice to use the RB AST for the compiler is not a âtraditionalâ one.. but it turned out to work very well *and* it brings some amazing power, as we have now not only a mapping bc->text offset, but a mapping bc->AST, too. This e.g. (just a a simple example) makes the magic of the runtime transforming deprecations possible. See #transform on class Deprecation, the #sourceNodeExecuted: transform | node rewriteRule aMethod | self shouldTransform ifFalse: [ ^ self ]. self rewriterClass ifNil:[ ^ self signal ]. aMethod := self contextOfSender method. aMethod isDoIt ifTrue:[^ self]. "no need to transform doits" node := self contextOfSender sourceNodeExecuted. rewriteRule := self rewriterClass new replace: rule key with: rule value. (rewriteRule executeTree: node) ifFalse: [ ^ self ]. node replaceWith: rewriteRule tree. Author useAuthor: 'AutoDeprecationRefactoring' during: [aMethod origin compile: aMethod ast formattedCode classified: aMethod protocol]. Marcus
Hi Doru,
On Jan 11, 2019, at 4:53 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
@Eliot: Thanks for the clarifying answer.
I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand.
Indeed. I am responding because of the recent experience we had, that you are intimately aware of, of moving the somewhat functional Pharo 6 VMMaker port forward to Pharo 7, which is frustrating because enough things changes that it was broken. And that is far from an isolated experience. I want very, very much for Pharo to succeed. It is the most important user of the opensmalltalk-vm by far. If Pharo fails, opensmalltalk-vm will very likely become entirely irrelevant and uninteresting. So my career and financial security are wedded to Pharoâs success. At the same time I do not feel positive about Pharo, as I have said, in its stability and in the communityâs difficulty in discussing problems (primarily the stability and development model issues). I am therefore very much interested in solving these problems. So if I jump to conclusions it is because I am concerned and want to change how I feel about Pharo as a viable platform for my work, and that means being able to talk about difficult issues and not be shushed. I want there to be constructive discussion, not defensiveness or blithe positivity. Progress depends on truth and ingenuity, not positive thinking.
As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :).
Indeed I do!
@Thomas: Thanks for this effort!
Cheers, Doru
On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,
On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
<mime-attachment>
in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc.
Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al.
So the distinction is important and the utility method is probably useful.
Do you want to remove the method simply because there are no senders in the image?
If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed.
Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable.
-- www.feenk.com
âThe smaller and more pervasive the hardware becomes, the more physical the software gets."
participants (5)
-
ducasse -
Eliot Miranda -
Marcus Denker -
Thomas Dupriez -
Tudor Girba