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