Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Hi Marcus,

On Fri, Jan 18, 2019 at 5:42 AM Marcus Denker 
wrote:

>
> > On 18 Jan 2019, at 14:26, ducasse  wrote:
> >
> > I simply love the dynamic rewriting this is just too cool. We should
> systematically use it.
> > I will continue to use it in any deprecation.
> >
>
> On my TODO is to make it stand-alone and provide is as a “compatibility
> transform”, too.
>
> So we can add it to methods that we want to keep for compatibility, but
> they will nevertheless transform the code automatically.
> (this then might be disabled in production to not transform)
>
> > Now I have a simple question (You can explain it to me over lunch one of
> these days).
> >
> > I do not get why RBAST would not be a good representation for the
> compiler?
> > I would like to know what is the difference.
> >
> I think it is a good one. I have not yet seen a reason why not. But
> remember, Roel left Squeak because his visitor pattern for the compiler was
> rejected as a dumb idea… so there are definitely different views on core
> questions.
>
> E.g. the RB AST is annotated and the whole things for sure uses a bit more
> memory than the compiler designed for a machine from 1978.
>
> > You mean that before going from BC to AST was difficult?
>
> You need to do the mapping somehow, the compiler needs to remember the BC
> offset in the code generation phase and the AST (somehow) needs to store
> that information (either in every node or some table).
>
> > How opal performs it? It does not use the source of the method to
> recreate the AST but he can do it from the BC?
> >
>
> It uses the IR (which I still am not 100% sure about, it came from the old
> “ClosureCompiler” Design and it turned out to be quite useful, for example
> for the mapping: every IR node retains the offset of the BC it creates,
> then the IR Nodes
> retain the AST node that created them.
>
> -> so we just do a query: “IRMethod, give me the IRInstruction that
> created BC offset X. then “IR, which AST node did create you? then the AST
> Node: what is your highlight interval in the source?
>
> The devil is in the detail as one IR can produce multiple byte code
> offsets (and byte codes) and one byte code might be created by two IR
> nodes, but it does seem to work with some tricks.
> Which I want to remove by improving the mapping and even the IR more…
> there is even the question: do we need the IR? could we not do it simpler?
>
> The IR was quite nice back when we tried to do things with byte code
> manipulation (Bytesurgeon), now it feels a bit of an overkill. But it
> simplifies e.g. the bc mapping.
>

I find Bytesurgeon functionality, specifically a bytecode dis/assembler
very useful, but wouldn't use it for the back end of the bytecode
compiler.  It adds overhead that has no benefit.  But I use my version,
MethodMassage, for lots of things:

- transporting compiled methods from one dialect to another, e.g. to do
in-image JIT compilation omg a method from Pharo in Squeak.
- generating JIT test cases
- generating methods that can't be generated from Smalltalk source, e.g. an
accessor for a JavaScript implementation above Smalltalk where inst var 0
is the prototype slot and nil is unbound, and so in a loop one wants to
fetch the Nth inst var from a temporary initialized to self, and ion the
value is non-nil return it, otherwise setting the temporary to
the prototype slot, hence walking up the prototype chain until an
initialized inst var is found.

I based mine around the messages that InstructionStream sends to the client
in the interpretFooInstructionFor: methods; a client that catches
doesNotUnderstand: then forms the basis of the disassembler.  Simple and
light-weight.

Marcus

_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Hi Marcus,

On Fri, Jan 18, 2019 at 5:15 AM Marcus Denker via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
> > On 11 Jan 2019, at 20:28, Eliot Miranda  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 <
> tdupr...@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.
>

"Design" is giving my code a little too much respect.  I was desperately
trying to get something to work to be able to deploy Cog with the new
closure model.  I happily admit that DebuggerMethodMap in Squeak is ugly
code.  It had to be extended recently to handle full blocks. But it would
be great to rewrite it.

I dream of a harmonisation of Squeak/Pharo/Cuis execution classes such that
we have the same Context, CompiledCode, CompiledBlock, CompiledMethod,
debuggerMap and BytecodeEncoder (which is effectively the back end of the
compiler that generates bytecode, and the interface to the debugger when
bytecode is analyses or executed in the debugger), which would make my life
easier maintaining the VM and execution classes, especially as we introduce
Sista.  I think Opal as a separate compiler is great; the work you've done
with mustBeBoleanMagic is superb.  At the same time the Squeak compiler is
fine for its job and I still find it easier to understand than Opal
(probably because I'm not spending enough time with it).

One major reason for the harmonization is bug fixes.  Right now I use
SistaV1 and 64-bits as my default work environment, in a 64-bit Squeak
image that was compiled with V3PlusClosures, so that half the 

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
>> 
>> On my TODO is to make it stand-alone and provide is as a “compatibility 
>> transform”, too.
> 
> I have to dig because I remember that I went over all the deprecation in 
> Pharo 60 and started to look at the ones that I 
> could “transformified” so that we get a nice package that rewrite more :)
> 
> 
>> So we can add it to methods that we want to keep for compatibility, but they 
>> will nevertheless transform the code automatically.
>> (this then might be disabled in production to not transform)
> 
> Yes I like that I will look for my code. 

Apparently I published under 

MCSmalltalkhubRepository
owner: 'PharoExtras'
project: ‘Migrator'

Several packages 
MigratorPharo60 contains what I did for Pharo60
probably 
Migrator contains some of the Pharo70 

Now I would like to understand how to organise it. 

I have the impression that we should keep the one that can be transformed.

I do not think that we should go to Pharo50 because it is too old. 

Stef




--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
Hi marcus

>> I simply love the dynamic rewriting this is just too cool. We should 
>> systematically use it. 
>> I will continue to use it in any deprecation. 
>> 
> 
> On my TODO is to make it stand-alone and provide is as a “compatibility 
> transform”, too.

I have to dig because I remember that I went over all the deprecation in Pharo 
60 and started to look at the ones that I 
could “transformified” so that we get a nice package that rewrite more :)


> So we can add it to methods that we want to keep for compatibility, but they 
> will nevertheless transform the code automatically.
> (this then might be disabled in production to not transform)

Yes I like that I will look for my code. 
> 
>> Now I have a simple question (You can explain it to me over lunch one of 
>> these days).
>> 
>> I do not get why RBAST would not be a good representation for the compiler?
>> I would like to know what is the difference.
>> 
> I think it is a good one. I have not yet seen a reason why not. But remember, 
> Roel left Squeak because his visitor pattern for the compiler was rejected as 
> a dumb idea… so there are definitely different views on core questions.
> 
> E.g. the RB AST is annotated and the whole things for sure uses a bit more 
> memory than the compiler designed for a machine from 1978.
> 
>> You mean that before going from BC to AST was difficult?
> 
> You need to do the mapping somehow, the compiler needs to remember the BC 
> offset in the code generation phase and the AST (somehow) needs to store that 
> information (either in every node or some table).
> 
>> How opal performs it? It does not use the source of the method to recreate 
>> the AST but he can do it from the BC?
>> 
> 
> It uses the IR (which I still am not 100% sure about, it came from the old 
> “ClosureCompiler” Design and it turned out to be quite useful, for example 
> for the mapping: every IR node retains the offset of the BC it creates, then 
> the IR Nodes
> retain the AST node that created them. 
> 
> -> so we just do a query: “IRMethod, give me the IRInstruction that created 
> BC offset X. then “IR, which AST node did create you? then the AST Node: what 
> is your highlight interval in the source?
> 
> The devil is in the detail as one IR can produce multiple byte code offsets 
> (and byte codes) and one byte code might be created by two IR nodes, but it 
> does seem to work with some tricks. 

ok I see.
And all in all it is really nice. 

> Which I want to remove by improving the mapping and even the IR more… there 
> is even the question: do we need the IR? could we not do it simpler? 
> 
> The IR was quite nice back when we tried to do things with byte code 
> manipulation (Bytesurgeon), now it feels a bit of an overkill. But it 
> simplifies e.g. the bc mapping.


We should document this because this is cool. 

Stef



--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[Nicolas Cellier]

Le ven. 18 janv. 2019 à 14:42, Marcus Denker  a
écrit :

>
>
> > On 18 Jan 2019, at 14:26, ducasse  wrote:
> >
> > I simply love the dynamic rewriting this is just too cool. We should
> systematically use it.
> > I will continue to use it in any deprecation.
> >
>
> On my TODO is to make it stand-alone and provide is as a “compatibility
> transform”, too.
>
> So we can add it to methods that we want to keep for compatibility, but
> they will nevertheless transform the code automatically.
> (this then might be disabled in production to not transform)
>
> > Now I have a simple question (You can explain it to me over lunch one of
> these days).
> >
> > I do not get why RBAST would not be a good representation for the
> compiler?
> > I would like to know what is the difference.
> >
> I think it is a good one. I have not yet seen a reason why not. But
> remember, Roel left Squeak because his visitor pattern for the compiler was
> rejected as a dumb idea… so there are definitely different views on core
> questions.
>
> E.g. the RB AST is annotated and the whole things for sure uses a bit more
> memory than the compiler designed for a machine from 1978.
>
> > You mean that before going from BC to AST was difficult?
>
> You need to do the mapping somehow, the compiler needs to remember the BC
> offset in the code generation phase and the AST (somehow) needs to store
> that information (either in every node or some table).
>
> > How opal performs it? It does not use the source of the method to
> recreate the AST but he can do it from the BC?
> >
>
> It uses the IR (which I still am not 100% sure about, it came from the old
> “ClosureCompiler” Design and it turned out to be quite useful, for example
> for the mapping: every IR node retains the offset of the BC it creates,
> then the IR Nodes
> retain the AST node that created them.
>
> -> so we just do a query: “IRMethod, give me the IRInstruction that
> created BC offset X. then “IR, which AST node did create you? then the AST
> Node: what is your highlight interval in the source?
>
> The devil is in the detail as one IR can produce multiple byte code
> offsets (and byte codes) and one byte code might be created by two IR
> nodes, but it does seem to work with some tricks.
> Which I want to remove by improving the mapping and even the IR more…
> there is even the question: do we need the IR? could we not do it simpler?
>
> The IR was quite nice back when we tried to do things with byte code
> manipulation (Bytesurgeon), now it feels a bit of an overkill. But it
> simplifies e.g. the bc mapping.
>
> Marcus
>
>
> agree!
IR is super when we want to manipuate the byte codes (decompiling,
instrumenting, etc...).
But if it's just for generating the CompiledMethod byte codes (compiling),
it's a bit too much and is one contributor of compilation slowdown.
Maybe we could have another polymorphic kind of IRBuilder that would be a
DirectByteCodeGenerator

Re: [Pharo-dev] DebugSession>>activePC:

[Marcus Denker]

> On 18 Jan 2019, at 14:26, ducasse  wrote:
> 
> I simply love the dynamic rewriting this is just too cool. We should 
> systematically use it. 
> I will continue to use it in any deprecation. 
> 

On my TODO is to make it stand-alone and provide is as a “compatibility 
transform”, too.

So we can add it to methods that we want to keep for compatibility, but they 
will nevertheless transform the code automatically.
(this then might be disabled in production to not transform)

> Now I have a simple question (You can explain it to me over lunch one of 
> these days).
> 
> I do not get why RBAST would not be a good representation for the compiler?
> I would like to know what is the difference.
> 
I think it is a good one. I have not yet seen a reason why not. But remember, 
Roel left Squeak because his visitor pattern for the compiler was rejected as a 
dumb idea… so there are definitely different views on core questions.

E.g. the RB AST is annotated and the whole things for sure uses a bit more 
memory than the compiler designed for a machine from 1978.

> You mean that before going from BC to AST was difficult?

You need to do the mapping somehow, the compiler needs to remember the BC 
offset in the code generation phase and the AST (somehow) needs to store that 
information (either in every node or some table).

> How opal performs it? It does not use the source of the method to recreate 
> the AST but he can do it from the BC?
> 

It uses the IR (which I still am not 100% sure about, it came from the old 
“ClosureCompiler” Design and it turned out to be quite useful, for example for 
the mapping: every IR node retains the offset of the BC it creates, then the IR 
Nodes
retain the AST node that created them. 

-> so we just do a query: “IRMethod, give me the IRInstruction that created BC 
offset X. then “IR, which AST node did create you? then the AST Node: what is 
your highlight interval in the source?

The devil is in the detail as one IR can produce multiple byte code offsets 
(and byte codes) and one byte code might be created by two IR nodes, but it 
does seem to work with some tricks. 
Which I want to remove by improving the mapping and even the IR more… there is 
even the question: do we need the IR? could we not do it simpler? 

The IR was quite nice back when we tried to do things with byte code 
manipulation (Bytesurgeon), now it feels a bit of an overkill. But it 
simplifies e.g. the bc mapping.

Marcus

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
I simply love the dynamic rewriting this is just too cool. We should 
systematically use it. 
I will continue to use it in any deprecation. 

Now I have a simple question (You can explain it to me over lunch one of these 
days).

I do not get why RBAST would not be a good representation for the compiler?
I would like to know what is the difference.

You mean that before going from BC to AST was difficult?
How opal performs it? It does not use the source of the method to recreate the 
AST but he can do it from the BC?

Stef


>> 
> 
> 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

--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[Marcus Denker via Pharo-dev]

--- Begin Message ---


> On 11 Jan 2019, at 20:28, Eliot Miranda  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  
>> 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.

Re: [Pharo-dev] DebugSession>>activePC:

[Denis Kudriashov]

Hi guys.

Funny thing that DebugSession does not exists in Squeak. It was introduced
in Pharo to represent the model for debugger.


пт, 11 янв. 2019 г. в 22:34, Thomas Dupriez via Pharo-dev <
pharo-dev@lists.pharo.org>:

> 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 <
> tdupr...@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 
> wrote:
> 
>  Hi Thomas,
> 
> > On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
> >
> > 
>  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 

Re: [Pharo-dev] DebugSession>>activePC:

[Thomas Dupriez via Pharo-dev]

--- Begin Message ---
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  
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  wrote:

Hi Thomas,


On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
 wrote:



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 

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

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  
> 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  wrote:
>>> 
>>> Hi Thomas,
>>> 
 On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
  wrote:
 
 
>>> 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 

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Hi Thomas,


> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez  
> 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  wrote:
>>> 
>>> Hi Thomas,
>>> 
 On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
  wrote:
 
 
>>> 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."
>> 
>> 
> 

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Hi Doru,


> On Jan 11, 2019, at 4:53 AM, 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.

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  wrote:
>> 
>> Hi Thomas,
>> 
>>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>>  wrote:
>>> 
>>> 
>> 
>> 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."
> 
> 

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Craig,

thank you. +1000

> On Jan 11, 2019, at 12:58 AM, Craig Latta  wrote:
> 
> 
> Hi all--
> 
> Eliot writes:
> 
>> 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.
> 
> Esteban responds:
> 
>> ...we are told that we remove things without caring.
> 
> I don't see where Eliot said anyone didn't care.
> 
> Stef responds:
> 
>> About the method removed, could you please react less negatively? It
>> would be nice.
>> 
>> ...
>> 
>> 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?
> 
> Eliot said the system has to be more stable. It doesn't seem like a
> negative reaction, or an attempt to make anyone feel bad. As Ben pointed
> out, the major cost of reporting regressions isn't the time spent
> interacting with the bug-tracking system, it's being switched away from
> what you were doing. Using the automated regression-testing system seems
> like a good way of catching this particular issue (even though it's a
> step away from having full live traceability all the time, before
> committing changes).
> 
>> For calypso we try and sometimes fail and retry. But we do not rant...
>> The solution is also to have ***positive*
>> communication... There is no point to piss on our process... So before
>> bashing us I would expect a bit of respect that it is due to our track
>> record... it would be nice if you could refrain to be systematically
>> negative about what we are doing.
> 
> I don't think Eliot is being systematically negative, or that he
> was ranting, pissing, or bashing. I think introducing those accusatory
> words into the conversation detracts from positive communication.
> 
>> I think that we are doing a great job make Smalltalk cool.
> 
> I do, too! (And thanks for using that word. ;)
> 
> 
> thanks,
> 
> -C
> 
> --
> Craig Latta
> Black Page Digital
> Amsterdam :: San Francisco
> cr...@blackpagedigital.com
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
> 

Re: [Pharo-dev] DebugSession>>activePC:

[Thomas Dupriez]

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  wrote:

Hi Thomas,


On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
 wrote:



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."

Re: [Pharo-dev] DebugSession>>activePC:

[Tudor Girba]

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  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> 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."

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse]

Then perfect!


> On 11 Jan 2019, at 09:58, Craig Latta  wrote:
> 
> 
> Hi all--
> 
> Eliot writes:
> 
>> 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.
> 
> Esteban responds:
> 
>> ...we are told that we remove things without caring.
> 
> I don't see where Eliot said anyone didn't care.
> 
> Stef responds:
> 
>> About the method removed, could you please react less negatively? It
>> would be nice.
>> 
>> ...
>> 
>> 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?
> 
> Eliot said the system has to be more stable. It doesn't seem like a
> negative reaction, or an attempt to make anyone feel bad. As Ben pointed
> out, the major cost of reporting regressions isn't the time spent
> interacting with the bug-tracking system, it's being switched away from
> what you were doing. Using the automated regression-testing system seems
> like a good way of catching this particular issue (even though it's a
> step away from having full live traceability all the time, before
> committing changes).
> 
>> For calypso we try and sometimes fail and retry. But we do not rant...
>> The solution is also to have ***positive*
>> communication... There is no point to piss on our process... So before
>> bashing us I would expect a bit of respect that it is due to our track
>> record... it would be nice if you could refrain to be systematically
>> negative about what we are doing.
> 
> I don't think Eliot is being systematically negative, or that he
> was ranting, pissing, or bashing. I think introducing those accusatory
> words into the conversation detracts from positive communication.
> 
>> I think that we are doing a great job make Smalltalk cool.
> 
> I do, too! (And thanks for using that word. ;)
> 
> 
> thanks,
> 
> -C
> 
> --
> Craig Latta
> Black Page Digital
> Amsterdam :: San Francisco
> cr...@blackpagedigital.com 
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)

Re: [Pharo-dev] DebugSession>>activePC:

[Craig Latta]

Hi all--

 Eliot writes:

> 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.

 Esteban responds:

> ...we are told that we remove things without caring.

 I don't see where Eliot said anyone didn't care.

 Stef responds:

> About the method removed, could you please react less negatively? It
> would be nice.
>
> ...
>
> 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?

 Eliot said the system has to be more stable. It doesn't seem like a
negative reaction, or an attempt to make anyone feel bad. As Ben pointed
out, the major cost of reporting regressions isn't the time spent
interacting with the bug-tracking system, it's being switched away from
what you were doing. Using the automated regression-testing system seems
like a good way of catching this particular issue (even though it's a
step away from having full live traceability all the time, before
committing changes).

> For calypso we try and sometimes fail and retry. But we do not rant...
> The solution is also to have ***positive*
> communication... There is no point to piss on our process... So before
> bashing us I would expect a bit of respect that it is due to our track
> record... it would be nice if you could refrain to be systematically
> negative about what we are doing.

 I don't think Eliot is being systematically negative, or that he
was ranting, pissing, or bashing. I think introducing those accusatory
words into the conversation detracts from positive communication.

> I think that we are doing a great job make Smalltalk cool.

 I do, too! (And thanks for using that word. ;)


 thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
cr...@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
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  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> 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.



--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[ducasse via Pharo-dev]

--- Begin Message ---
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  wrote:
> 
> Hi Thomas,
> 
>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>>  wrote:
>> 
>> 
> 
> 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.



--- End Message ---

Re: [Pharo-dev] DebugSession>>activePC:

[Eliot Miranda]

Hi Thomas,

> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev 
>  wrote:
> 
> 

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.

[Pharo-dev] DebugSession>>activePC:

[Thomas Dupriez via Pharo-dev]

--- Begin Message ---

Hello,

I saw that DebugSession>>activePC: has no senders in pharo. Does someone 
know the intention behind it?


activePC: aContext
    ^ (self isLatestContext: aContext)
        ifTrue: [ interruptedContext pc ]
        ifFalse: [ self previousPC: aContext ]

Thomas Dupriez


--- End Message ---