<div dir="ltr"><div>Before i stop, here is what I found:</div><div>There are still many (old) BlockClosures active in the image (thru Services, Pluggable*Somthing, etc...)</div><div>Debugger will (sometimes?) fail to decompile those BlockClosures if encountered on the stack (example below).</div><div>Not a show stopper, but we should take some corrective action.</div><div><br></div><div>--------------<br></div><div><br>Requestor(Object)>>doesNotUnderstand: #browseMcMethodRevisions<br> Receiver: a Requestor<br> Arguments and temporary variables: <br> aMessage: browseMcMethodRevisions<br> exception: MessageNotUnderstood: Requestor>>browseMcMethodRevisions<br> resumeValue: nil<br> Receiver's instance variables: <br> caption: 'Enter text'<br> answer: a WriteStream<br><br>[] in MCHttpRepository class(MCRepository class)>>browseMethodRevisionsService<br> Receiver: MCHttpRepository<br> Arguments and temporary variables: <br><<error during printing><br> Receiver's instance variables: <br> superclass: MCFileBasedRepository<br> methodDict: a MethodDictionary(#allFileNames->(MCHttpRepository>>#allFileNames ...etc...<br> format: 65547<br> instanceVariables: #('location' 'user' 'password' 'readerCache' 'indexed' 'webC...etc...<br> organization: ('overriding')<br>('private' displayProgress:during: flushCache httpGet:arguments:...etc...<br> subclasses: nil<br> name: #MCHttpRepository<br> classPool: a Dictionary(#UseSharedWebClientInstance->false )<br> sharedPools: nil<br> environment: Smalltalk<br> category: #'Monticello-Repositories'<br><br>BlockClosure>>valueWithRequestor:<br> Receiver: [closure] in MCHttpRepository class(MCRepository class)>>browseMethodRevisionsService<br> Arguments and temporary variables: <br> aRequestor: a Requestor<br> Receiver's instance variables: <br> outerContext: MCHttpRepository class(MCRepository class)>>browseMethodRevisionsService...etc...<br> startpc: 82<br> numArgs: 1<br><br>ServiceAction>>execute<br> Receiver: a ServiceAction browseMcMethodRevisions<br> Arguments and temporary variables: <br><br> Receiver's instance variables: <br> condition: [closure] in MCHttpRepository class(MCRepository class)>>browseMethodRevisionsService...etc...<br> action: [closure] in MCHttpRepository class(MCRepository class)>>browseMethodRevisionsService...etc...<br> requestor: a BrowserRequestor<br> label: 'browse revisions'<br> shortLabel: 'mc'<br> description: 'Browse revisions of this method from the first-listed HTTP reposi...etc...<br> id: #browseMcMethodRevisions<br> provider: nil<br> enabled: true<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 8 mars 2020 à 21:34, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So I accidentally published a small fix in trunk without thinking that the ancestor was in inbox...</div><div>Consequently, all is in trunk now with an advance of half a couple of days.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 7 mars 2020 à 21:19, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The adaptive optimization (inlining etc...) done at image side is called Scorch.</div><div>Clément has prototyped it in Pharo at <a href="http://smalltalkhub.com/#!/~ClementBera/Scorch" target="_blank">http://smalltalkhub.com/#!/~ClementBera/Scorch</a></div><div>then at <a href="https://github.com/clementbera/Scorch" target="_blank">https://github.com/clementbera/Scorch</a></div><div>It's not advertised as ready for consumption yet.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 7 mars 2020 à 20:45, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi all,<div dir="auto">I agree for moving to trunk asap.</div><div dir="auto">It must happen in early phases so that we test eagerly.</div><div dir="auto">There's a few test failing with wrong expectations now, but no catastrophic consequences.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 7 mars 2020 à 19:47, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Christoph,<br>
<br>
On Sat, Mar 07, 2020 at 06:11:56PM +0000, Thiede, Christoph wrote:<br>
> Hi Dave, hi all,<br>
> <br>
> <br>
> this sounds like a really interesting changeover. I have heard and<br>
> read some rumors about Sista in the past, but I could not find any<br>
> brief but complete summary of all the changes this will make to our<br>
existing Smalltalk system. So it would be great if you could point<br>
> us to some kind of changelog.<br>
> <br>
<br>
You can think of the bytecode set as the machine level instructions<br>
that are executed by the virtual machine, analogous to the hardware<br>
instructions that are executed by a CPU. Eliot has arranged for Squeak<br>
(and Pharo and others) to be able to change over to an alternate<br>
instruction set, sort of like changing the CPU on your computer without<br>
turning the power off.<br>
<br>
The motivation for the new bytcodes (called Sista) is to enable certain<br>
kinds of performance optimizations directly in the image. Think in<br>
terms of some of the performance optimizations in the Cog/Spur VMs,<br>
but now potentially being able to do it directly in the image.<br>
<br>
Others will have to give you the details, but that's the basic idea.<br>
<br>
> <br>
> In what way will this affect your typical Squeak experience? What<br>
> about performance? What about debugging/simulating code? As someone<br>
> who did not yet deal with any VM side effects, I would be interested<br>
> to hear about the practical effects you can see when playing around<br>
> with Context & Compiler stuff. I read about FullBlockClosure which<br>
> appears to be kind of detached of its defining method. How will this<br>
> change accessing thisContext home etc. from a FullBlockClosure, for<br>
> example? I read Sista stores an optimization cache between several<br>
> runs. Where will this information be saved, at the image side or<br>
> at the VM side?<br>
> <br>
<br>
I cannot answer much of this, other than to say that initially you<br>
should expect to see no difference in the user experience. Various<br>
people have been using Sista for some time without problems, so it<br>
will initially be a transparent change, with the more interesting<br>
things happening in the future :-)<br>
<br>
Dave<br>
<br>
<br>
> Lots of questions, maybe someone can answer a few of them :-)<br>
> <br>
> <br>
> Best,<br>
> <br>
> Christoph<br>
> <br>
> ________________________________<br>
> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" rel="noreferrer" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von David T. Lewis <<a href="mailto:lewis@mail.msen.com" rel="noreferrer" target="_blank">lewis@mail.msen.com</a>><br>
> Gesendet: Samstag, 7. M?rz 2020 18:29:40<br>
> An: <a href="mailto:squeak-dev@lists.squeakfoundation.org" rel="noreferrer" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
> Betreff: Re: [squeak-dev] Switching to Sista bytecodes in trunk (was: The Inbox: Kernel-dtl.1310.mcz)<br>
> <br>
> I will leave this in the inbox for a couple of days, and if there are<br>
> no objections I will move it to trunk.<br>
> <br>
> Dave<br>
> <br>
> On Fri, Mar 06, 2020 at 07:43:29PM -0500, David T. Lewis wrote:<br>
> > The Sista bytecode set enables important reasearch and development work.<br>
> > Eliot and Clemont can explain better than me (apologies to Clemont Bera<br>
> > for using my seven-bit character set on your name).<br>
> ><br>
> > Squeak 5.3 is released and we are starting the new release cycle, so it<br>
> > is time to make Sista the default in trunk. Kernel-dtl.1310 (in the inbox)<br>
> > activates Sista in the package postscipt.<br>
> ><br>
> > Dave<br>
> ><br>
> > On Sat, Mar 07, 2020 at 12:29:13AM +0000, <a href="mailto:commits@source.squeak.org" rel="noreferrer" target="_blank">commits@source.squeak.org</a> wrote:<br>
> > > David T. Lewis uploaded a new version of Kernel to project The Inbox:<br>
> > > <a href="http://source.squeak.org/inbox/Kernel-dtl.1310.mcz" rel="noreferrer noreferrer" target="_blank">http://source.squeak.org/inbox/Kernel-dtl.1310.mcz</a><br>
> > ><br>
<br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>