Before i stop, here is what I found:
There are still many (old) BlockClosures active in the image (thru
Services, Pluggable*Somthing, etc...)
Debugger will (sometimes?) fail to decompile those BlockClosures if
encountered on the stack (example below).
Not a show stopper, but we should take some corrective action.

--------------

Requestor(Object)>>doesNotUnderstand: #browseMcMethodRevisions
Receiver: a Requestor
Arguments and temporary variables:
aMessage: browseMcMethodRevisions
exception: MessageNotUnderstood: Requestor>>browseMcMethodRevisions
resumeValue: nil
Receiver's instance variables:
caption: 'Enter text'
answer: a WriteStream

[] in MCHttpRepository class(MCRepository
class)>>browseMethodRevisionsService
Receiver: MCHttpRepository
Arguments and temporary variables:
<<error during printing>
Receiver's instance variables:
superclass: MCFileBasedRepository
methodDict: a
MethodDictionary(#allFileNames->(MCHttpRepository>>#allFileNames ...etc...
format: 65547
instanceVariables: #('location' 'user' 'password' 'readerCache' 'indexed'
'webC...etc...
organization: ('overriding')
('private' displayProgress:during: flushCache httpGet:arguments:...etc...
subclasses: nil
name: #MCHttpRepository
classPool: a Dictionary(#UseSharedWebClientInstance->false )
sharedPools: nil
environment: Smalltalk
category: #'Monticello-Repositories'

BlockClosure>>valueWithRequestor:
Receiver: [closure] in MCHttpRepository class(MCRepository
class)>>browseMethodRevisionsService
Arguments and temporary variables:
aRequestor: a Requestor
Receiver's instance variables:
outerContext: MCHttpRepository class(MCRepository
class)>>browseMethodRevisionsService...etc...
startpc: 82
numArgs: 1

ServiceAction>>execute
Receiver: a ServiceAction browseMcMethodRevisions
Arguments and temporary variables:

Receiver's instance variables:
condition: [closure] in MCHttpRepository class(MCRepository
class)>>browseMethodRevisionsService...etc...
action: [closure] in MCHttpRepository class(MCRepository
class)>>browseMethodRevisionsService...etc...
requestor: a BrowserRequestor
label: 'browse revisions'
shortLabel: 'mc'
description: 'Browse revisions of this method from the first-listed HTTP
reposi...etc...
id: #browseMcMethodRevisions
provider: nil
enabled: true

Le dim. 8 mars 2020 à 21:34, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> So I accidentally published a small fix in trunk without thinking that the
> ancestor was in inbox...
> Consequently, all is in trunk now with an advance of half a couple of days.
>
> Le sam. 7 mars 2020 à 21:19, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
>
>> The adaptive optimization (inlining etc...) done at image side is called
>> Scorch.
>> Clément has prototyped it in Pharo at
>> http://smalltalkhub.com/#!/~ClementBera/Scorch
>> then at https://github.com/clementbera/Scorch
>> It's not advertised as ready for consumption yet.
>>
>> Le sam. 7 mars 2020 à 20:45, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>
>>> Hi all,
>>> I agree for moving to trunk asap.
>>> It must happen in early phases so that we test eagerly.
>>> There's a few test failing with wrong expectations now, but no
>>> catastrophic consequences.
>>>
>>> Le sam. 7 mars 2020 à 19:47, David T. Lewis <lewis at mail.msen.com> a
>>> écrit :
>>>
>>>> Hi Christoph,
>>>>
>>>> On Sat, Mar 07, 2020 at 06:11:56PM +0000, Thiede, Christoph wrote:
>>>> > Hi Dave, hi all,
>>>> >
>>>> >
>>>> > this sounds like a really interesting changeover. I have heard and
>>>> > read some rumors about Sista in the past, but I could not find any
>>>> > brief but complete summary of all the changes this will make to our
>>>>  existing Smalltalk system. So it would be great if you could point
>>>> > us to some kind of changelog.
>>>> >
>>>>
>>>> You can think of the bytecode set as the machine level instructions
>>>> that are executed by the virtual machine, analogous to the hardware
>>>> instructions that are executed by a CPU. Eliot has arranged for Squeak
>>>> (and Pharo and others) to be able to change over to an alternate
>>>> instruction set, sort of like changing the CPU on your computer without
>>>> turning the power off.
>>>>
>>>> The motivation for the new bytcodes (called Sista) is to enable certain
>>>> kinds of performance optimizations directly in the image. Think in
>>>> terms of some of the performance optimizations in the Cog/Spur VMs,
>>>> but now potentially being able to do it directly in the image.
>>>>
>>>> Others will have to give you the details, but that's the basic idea.
>>>>
>>>> >
>>>> > In what way will this affect your typical Squeak experience? What
>>>> > about performance? What about debugging/simulating code? As someone
>>>> > who did not yet deal with any VM side effects, I would be interested
>>>> > to hear about the practical effects you can see when playing around
>>>> > with Context & Compiler stuff. I read about FullBlockClosure which
>>>> > appears to be kind of detached of its defining method. How will this
>>>> > change accessing thisContext home etc. from a FullBlockClosure, for
>>>> > example? I read Sista stores an optimization cache between several
>>>> > runs. Where will this information be saved, at the image side or
>>>> > at the VM side?
>>>> >
>>>>
>>>> I cannot answer much of this, other than to say that initially you
>>>> should expect to see no difference in the user experience. Various
>>>> people have been using Sista for some time without problems, so it
>>>> will initially be a transparent change, with the more interesting
>>>> things happening in the future :-)
>>>>
>>>> Dave
>>>>
>>>>
>>>> > Lots of questions, maybe someone can answer a few of them :-)
>>>> >
>>>> >
>>>> > Best,
>>>> >
>>>> > Christoph
>>>> >
>>>> > ________________________________
>>>> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>>> Auftrag von David T. Lewis <lewis at mail.msen.com>
>>>> > Gesendet: Samstag, 7. M?rz 2020 18:29:40
>>>> > An: squeak-dev at lists.squeakfoundation.org
>>>> > Betreff: Re: [squeak-dev] Switching to Sista bytecodes in trunk (was:
>>>> The Inbox: Kernel-dtl.1310.mcz)
>>>> >
>>>> > I will leave this in the inbox for a couple of days, and if there are
>>>> > no objections I will move it to trunk.
>>>> >
>>>> > Dave
>>>> >
>>>> > On Fri, Mar 06, 2020 at 07:43:29PM -0500, David T. Lewis wrote:
>>>> > > The Sista bytecode set enables important reasearch and development
>>>> work.
>>>> > > Eliot and Clemont can explain better than me (apologies to Clemont
>>>> Bera
>>>> > > for using my seven-bit character set on your name).
>>>> > >
>>>> > > Squeak 5.3 is released and we are starting the new release cycle,
>>>> so it
>>>> > > is time to make Sista the default in trunk. Kernel-dtl.1310 (in the
>>>> inbox)
>>>> > > activates Sista in the package postscipt.
>>>> > >
>>>> > > Dave
>>>> > >
>>>> > > On Sat, Mar 07, 2020 at 12:29:13AM +0000, commits at source.squeak.org
>>>> wrote:
>>>> > > > David T. Lewis uploaded a new version of Kernel to project The
>>>> Inbox:
>>>> > > > http://source.squeak.org/inbox/Kernel-dtl.1310.mcz
>>>> > > >
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200308/e1eeb230/attachment.html>