November 2022 - Pharo-dev - lists.pharo.org

Re: Digital Twin applied to Software

by Eliot Miranda

Hi Aik-Siong, the opensmalltalk-vm is such a digital twin, arguably a quadruplet :-). The vm is developed in Smalltalk, actually a subset called Slang. This is called âthe simulatorâ. The Slang Smalltalk code is then transpiled to C, (alongside C, Objective-C & C++ platform support code managed in git), to provide the production vm. The simulator and its resultant generated vm code contain assertions. These are always evaluated when simulating. But in the production vm we have three compilation levels, âproductionâ, level 2 optimized, assertions ifdeffed out, âassertâ, level 1 optimized, assertions included, and âdebugâ, no optimization, assertions included. The simulator is very powerful and a joy to use (see the two versions of âTwo Decades of Live Coding and Debugging of Virtual Machines through Simulation.â on https://squeak.org/research/) The debug vm is a few times slower than the production vm (but this is a weird comparison because they produce very similar JITted code, so JITted code is almost the same speed, but support code isnât) Two further examples of digital twins to observe in the simulator include âlemming debuggingâ, and meta circular plugins. Lemming debugging is duplicating the vm state before each GC, and performing the GC in the clone before in the original. So if the GC has a bug and corrupts the heap it does do in the clone and we still have the unscrambled original from which to clone again and repeat until we fix the bug. [and of course via fork it would be possible to write this in the production vm). Meta circular implementations of plugins, eg the socket plug-in, are those where a plug-in (a set of primitives, typically providing an interface to external functionality) in the simulator is implemented above the current vm. A plug-in primitive in the socket plug-in is typically a piece of glue code between the Smalltalk level and the platform support code implementing a socket operation on the current platform. The glue code is implemented in slang Smalltalk and is executed directly. The simulator then implements the platform support code used in simulation in terms of the real socket plug-in included in the host vm. Eliot _,,,^..^,,,_ (phone) > On Oct 28, 2022, at 12:25 PM, Aik-Siong Koh <askoh(a)askoh.com> wrote: > > ï»¿ Hi: > > I have a novel idea "Digital Twin applied to Software". See attached slides. > It points to the future of improved programming productivity and reliability. > Let me know what you think. > > Thanks, > Aik-Siong Koh > http://ar-cad.com > > > Abstract > > Digital Twin applied to Software > Aik-Siong Koh > askoh.com > > There has been a major dichotomy in computing right from the beginning: Statically Typed vs Dynamically Typed programming languages. The former languages produce fast executables but are inflexible to program. The latter are just the converse. This dichotomy has been frustrating to programmers who always feel they have to make sacrifices when making a choice. It also often leads to futile language wars. The Digital Twin concept was introduced in engineering where a physical system is modeled digitally in geometry, simulation and other information. The concept has proven so successful that it is being applied to almost everything in engineering from simple mouse traps to complex whole cities. It occurred to the author that this concept can be extended to software too. For example, execution in C++ is famously fast. But development in C++ is notoriously difficulty because of language complexity and long build times. A flexible digital twin can be a program written in Smalltalk which is famous for live programming. "Development at the speed of thought" is the motto and is real. What is gained by this duplication? Firstly, the flexible twin can be use to explore new algorithms, features, solutions and fix bugs quickly. Only desired codes are translated to C++ manually or automatically. Secondly, the two programs can check each other so that bugs are reduced significantly. These two gains will define future programming productivity and quality. The Digital Twin concept will also drive the automatic translation of the flexible language to the fast language. > > > Bio > > Dr Aik-Siong Koh has a PhD from The University of Texas at Austin where he programed in FORTRAN to simulation mechanical systems. While teaching at Texas Tech University and Nanyang Technological University, he developed interest in Multibody Dynamics. To develop his own Multibody Dynamics simulator, he researched for the most productive programming language and discovered Smalltalk. The live programming capabilities of Smalltalk permitted him to build a successful simulator which he then proceeded to commercialize. His later experience with C++ at Mechanical Dynamics and MathWorks gave him the idea of Digital Twin for Software.

Nov. 30, 2022

Re: Digital Twin applied to Software

by Pierre Misse-Chanabier

Hello, Slides are indeed better. There is one mistake though, Slide 26: PharoJS does define a smalltalk VM. They reuse the target environment JS VM, and send generate the runtime that they use (*very* basically). My main reserve is the feasability of this approach. Unless you scope it to specific contexts. Maintaining one application is diffficult, maintaining 2 is harder. Plus, it requires experts in both languages. Generating from one to the other has a number of challenges (as we talked about already) IMO, that is the root of the problem, and the main problem to address. The slide are pretty convincing for the rest of the problem :) Pierre On 30/11/2022 08:09, Aik-Siong Koh wrote: > I have updated my slides based on the many feedback. > Digital Twin is better defined and how that helps productivity is > elaborated. > Thanks. > http://askoh.com/twin/DigitalTwinsCppSt20221129.pdf > > > Aik-Siong Koh wrote: >> Hi: >> >> I have a novel idea "Digital Twin applied to Software". See attached >> slides. >> It points to the future of improved programming productivity and >> reliability. >> Let me know what you think. >> >> Thanks, >> Aik-Siong Koh >> http://ar-cad.com >> >> >> Abstract >> >> Digital Twin applied to Software >> Aik-Siong Koh >> askoh.com >> >> There has been a major dichotomy in computing right from the >> beginning: Statically Typed vs Dynamically Typed programming >> languages. The former languages produce fast executables but are >> inflexible to program. The latter are just the converse. This >> dichotomy has been frustrating to programmers who always feel they >> have to make sacrifices when making a choice. It also often leads to >> futile language wars. The Digital Twin concept was introduced in >> engineering where a physical system is modeled digitally in geometry, >> simulation and other information. The concept has proven so >> successful that it is being applied to almost everything in >> engineering from simple mouse traps to complex whole cities. It >> occurred to the author that this concept can be extended to software >> too. For example, execution in C++ is famously fast. But development >> in C++ is notoriously difficulty because of language complexity and >> long build times. A flexible digital twin can be a program written in >> Smalltalk which is famous for live programming. "Development at the >> speed of thought" is the motto and is real. What is gained by this >> duplication? Firstly, the flexible twin can be use to explore new >> algorithms, features, solutions and fix bugs quickly. Only desired >> codes are translated to C++ manually or automatically. Secondly, the >> two programs can check each other so that bugs are reduced >> significantly. These two gains will define future programming >> productivity and quality. The Digital Twin concept will also drive >> the automatic translation of the flexible language to the fast language. >> >> >> Bio >> >> Dr Aik-Siong Koh has a PhD from The University of Texas at Austin >> where he programed in FORTRAN to simulation mechanical systems. While >> teaching at Texas Tech University and Nanyang Technological >> University, he developed interest in Multibody Dynamics. To develop >> his own Multibody Dynamics simulator, he researched for the most >> productive programming language and discovered Smalltalk. The live >> programming capabilities of Smalltalk permitted him to build a >> successful simulator which he then proceeded to commercialize. His >> later experience with C++ at Mechanical Dynamics and MathWorks gave >> him the idea of Digital Twin for Software. >

Nov. 30, 2022

Re: Digital Twin applied to Software

by Aik-Siong Koh

I have updated my slides based on the many feedback. Digital Twin is better defined and how that helps productivity is elaborated. Thanks. http://askoh.com/twin/DigitalTwinsCppSt20221129.pdf Aik-Siong Koh wrote: > Hi: > > I have a novel idea "Digital Twin applied to Software". See attached > slides. > It points to the future of improved programming productivity and > reliability. > Let me know what you think. > > Thanks, > Aik-Siong Koh > http://ar-cad.com > > > Abstract > > Digital Twin applied to Software > Aik-Siong Koh > askoh.com > > There has been a major dichotomy in computing right from the > beginning: Statically Typed vs Dynamically Typed programming > languages. The former languages produce fast executables but are > inflexible to program. The latter are just the converse. This > dichotomy has been frustrating to programmers who always feel they > have to make sacrifices when making a choice. It also often leads to > futile language wars. The Digital Twin concept was introduced in > engineering where a physical system is modeled digitally in geometry, > simulation and other information. The concept has proven so successful > that it is being applied to almost everything in engineering from > simple mouse traps to complex whole cities. It occurred to the author > that this concept can be extended to software too. For example, > execution in C++ is famously fast. But development in C++ is > notoriously difficulty because of language complexity and long build > times. A flexible digital twin can be a program written in Smalltalk > which is famous for live programming. "Development at the speed of > thought" is the motto and is real. What is gained by this duplication? > Firstly, the flexible twin can be use to explore new algorithms, > features, solutions and fix bugs quickly. Only desired codes are > translated to C++ manually or automatically. Secondly, the two > programs can check each other so that bugs are reduced significantly. > These two gains will define future programming productivity and > quality. The Digital Twin concept will also drive the automatic > translation of the flexible language to the fast language. > > > Bio > > Dr Aik-Siong Koh has a PhD from The University of Texas at Austin > where he programed in FORTRAN to simulation mechanical systems. While > teaching at Texas Tech University and Nanyang Technological > University, he developed interest in Multibody Dynamics. To develop > his own Multibody Dynamics simulator, he researched for the most > productive programming language and discovered Smalltalk. The live > programming capabilities of Smalltalk permitted him to build a > successful simulator which he then proceeded to commercialize. His > later experience with C++ at Mechanical Dynamics and MathWorks gave > him the idea of Digital Twin for Software.

Nov. 30, 2022

Re: This week (46/2022) on the Pharo Issue Tracker

by Marcus Denker

Hi T > On 18 Nov 2022, at 12:09, Tim Mackinnon <tim(a)testit.works> wrote: > > Wow - thats even neater... all done with our normal tools - on the fly. So cool. Not sure many environments/languages can reason about things in this way. > > Worthy of a blog post for the wider world I would say - as this kind of stuff should be on more people's radars. Yes, I will do that. > > Thanks again for all this kind of work. It would be so easy to just continue to think the job was done 20 years ago, where in fact we've only scratched the surface as our understanding of effective software development has improved. > Thanks. Sometimes I think my problem was that when I discovered Smalltalk I did *not* see perfection in it but an interesting starting pointâ¦ Marcus

Nov. 25, 2022

Improved Inspectors for Blocks

by Marcus Denker

The inspectors for blocks are now a bit improved: 1) CompiledBlock. This now is more in sync with CompiledMethod and shows - the homew method code with the block highlighted - the AST of the block - the IR if the block Currently, we compile every non-optimized block to a full block that created by a bytecode from a CompiledBlock (which itself is stored as a literal). inspect âCompiledBlock allInstancesâ to see the new inspector: 2) BlockClosure itself, e.g inspect some block in the workspace. This gets more important as we soon will have pre-compiled subclasses of BlockClosure as method literals (and then just execute pushLiteral: to âcreateâ the block). A nice way to play with these is: CompilationContext optionConstantBlockClosure: true. OpalCompiler recompileAll. some 2500 of the blocks are now compiled statically. Inspect: ConstantBlockClosure allSubInstances The inspector shows the same (home method with highlight, IR, AST) But we can do even better: CompilationContext optionCleanBlockClosure: true. OpalCompiler recompileAll. Another 7500 blocks can be statically compiled, inspect CleanBlockClosure allInstances These are not yet the default, as we have to carefully analyse the places where we now assume that blocks know the outerContext and receiver. (in the example above you see one of these: Announcementsâ¦). You can follow these issues to see what still needs to be done: [Meta] Steps needed for ConstantBlocks #11933 https://github.com/pharo-project/pharo/issues/11933 [Meta] Steps needed for CleanBlocks #11195 https://github.com/pharo-project/pharo/issues/11195 Marcus

Nov. 25, 2022

This week (47/2022) on the Pharo Issue Tracker.

by Marcus Denker

We merge 33 PRs this week. Features / Enhancements ========= - Introducing new icons #11896 https://github.com/pharo-project/pharo/pull/11896 - Enhancement: PackageManifest with an own system icon #11956 https://github.com/pharo-project/pharo/pull/11956 - ReNotOptimizedIfNilRule #11932 https://github.com/pharo-project/pharo/pull/11932 - Sync #basicInspect and inspect #11899 https://github.com/pharo-project/pharo/pull/11899 Blocks / Compiler ======= Constant blocks now implement correct error handling wrt to number of arguments, we now have an option to enable compiling constant block (#optionConstantBlockClosure) and can recompile the whole system with compiling constant blocks. - 11912-Compiler-add-option-for-constant-blocks #11927 https://github.com/pharo-project/pharo/pull/11927 - Blocks: pcInOuter-not-Debugging #11951 https://github.com/pharo-project/pharo/pull/11951 - Class comments for Compiler classes (mostly exceptions) #11948 https://github.com/pharo-project/pharo/pull/11948 - Some smaller fixes/cleanups related to Blocks #11936 https://github.com/pharo-project/pharo/pull/11936 - Context-print-no-isClean-check #11922 https://github.com/pharo-project/pharo/pull/11922 - 11901-ConstantBlockClosure-raise-error-if-called-with-wrong-number-of-args #11919 https://github.com/pharo-project/pharo/pull/11919 - Better-CompiledCode-Inspector: highlight in source #436 https://github.com/pharo-spec/NewTools/pull/436 - Inspect-CompiledBlock-IR #435 https://github.com/pharo-spec/NewTools/pull/435 Fixes ===== - fix OSWIndowDriver shutdown while saving #11831 https://github.com/pharo-project/pharo/pull/11831 - do not rebuild all Calypso tools at each selection change #11952 https://github.com/pharo-project/pharo/pull/11952 - EpHasImpactVisitor>>visitProtocolRemoval: handle protocols that only contain trait methods. #11942 https://github.com/pharo-project/pharo/pull/11942 - RubTextEditor: Bind the MENU key to open the context menu #11659 https://github.com/pharo-project/pharo/pull/11659 - Fixes #11925, ExternalBrowser does not show class definition from ST files Bug #11929 https://github.com/pharo-project/pharo/pull/11929 - 11762 cannot view st file content with code file browser #11924 https://github.com/pharo-project/pharo/pull/11924 - Fix debugger to update debugger extensions when a context is selected in the stack + fixing bytecode extension #405 https://github.com/pharo-spec/NewTools/pull/405 Git Support ========== - Forget repository iceberg error on windows #1633 https://github.com/pharo-vcs/iceberg/pull/1633 - Fixing the error handling. #1631 https://github.com/pharo-vcs/iceberg/pull/1631 - Migrate GT inspector extensions to new tools model #1630 https://github.com/pharo-vcs/iceberg/pull/1630 CI Setup ======== - Fixing runKernelTests to make it work with alternating VMs #11935 https://github.com/pharo-project/pharo/pull/11935 - Improve bootstrap.sh #11824 https://github.com/pharo-project/pharo/pull/11824 Cleanup ======= - Remove old comment editors #11945 https://github.com/pharo-project/pharo/pull/11945 - Cleanup on The package TestRunner #11509 https://github.com/pharo-project/pharo/pull/11509 Trivial Cleanups =============== - Cleanup TypingVisitor>>#initialize method category #11958 https://github.com/pharo-project/pharo/pull/11958 - Clenaup MemoryLogger>>#initialize #11962 https://github.com/pharo-project/pharo/pull/11962 - Cleanup: Fix lint TFTestCallbackExceptionHandler>>#initialize #11960 https://github.com/pharo-project/pharo/pull/11960 - simplify some users of #ifNil:ifNotNil: to use not nil arg #11930 https://github.com/pharo-project/pharo/pull/11930 - Use-optimizable-ifTrue #11923 https://github.com/pharo-project/pharo/pull/11923 - remove the unused <return:> pragma in spotter #434 https://github.com/pharo-spec/NewTools/pull/434 - avoid #asSymbol for the defaultFont. fixes #1329 #1330 https://github.com/pharo-spec/Spec/pull/1330

Nov. 25, 2022

[ Smalltalkers wanted... ]

by stephane ducasse

We are looking for Smalltalkers for adesso insurance solutions GmbH. Remote work is possible and German language is required (at least B2). Links: https://www.adesso.de/de/jobs-karriere/unsere-stellenangebote/Software-Engi… <https://www.adesso.de/de/jobs-karriere/unsere-stellenangebote/Software-Engi…> https://www.linkedin.com/jobs/view/3353601212/ <https://www.linkedin.com/jobs/view/3353601212/> Text: About the job FÃ¼r unsere Tochtergesellschaft, die adesso insurance solutions GmbH, suchen wir einen Software Engineer Smalltalk (all genders) Als Teil der adesso group bÃ¼ndelt die adesso insurance solutions GmbH das eigene Produktportfolio fÃ¼r den Versicherungsmarkt und treibt innovative Software-LÃ¶sungen in diesem Umfeld voran. Wir sind ein Team aus Ã¼ber 200 engagierten Kollegen und Kolleginnen. Und du kannst ein Teil davon werden. DEINE ROLLE - DAS WARTET AUF DICH Du kennst dich mit objektorientierter Programmierung aus? Smalltalk ist fÃ¼r dich eine Programmiersprache mit Tiefgang? Dann suchen wir genau dich als Software Engineer fÃ¼r unser Professional Services Team im Umfeld des Pensionsmanagements. Bei uns arbeitest du gemeinsam im Team mit Entwicklern, Testern und Projektmanagern an den besten LÃ¶sungen fÃ¼r unsere CollPhir-Software. Ãbrigens: Wir sind langjÃ¤hriger Sponsor der EUSG. Deine Aufgaben Â· Auf Basis von Smalltalk programmierst du neue Anforderungen und Erweiterungen. Â· Neue Anforderungen unserer CollPhir-Software setzt du um. Â· Du analysierst, konzipierst und realisierst eigenstÃ¤ndig kundenspezifische Erweiterungen. Â· Im Third-Level unterstÃ¼tzt du das Support-Team bei technischen Fragen zur Software. Â· Die Dokumentation und das Beheben von Fehlern gehÃ¶ren auch zu deinen Aufgaben. Deine Skills - Das Bringst Du Mit Â· Du verfÃ¼gst Ã¼ber einen technischen Hochschulabschluss (Informatik, Ingenieurwissenschaften, Mathematik, Physik, o.Ã.) oder hast bereits Erfahrung in der Softwareentwicklung mit Smalltalk gesammelt Â· Du hast keine Scheu vor Datenbankmanagementsystemen und verfÃ¼gst Ã¼ber â zumindest rudimentÃ¤res â Wissen in technologisch benachbarten Bereichen (z.B. Java) Â· Du bist neugierig und lernbereit, denn bei uns wird Weiterentwicklung sowohl technologisch als auch persÃ¶nlich groÃgeschrieben Â· Deine Deutschkenntnisse sind sehr gut und mindestens auf Level B2 CHANCENGEBER - WAS ADESSO AUSMACHT Unser Versprechen: Du wirst dich bei uns wohlfÃ¼hlen! Kollegial, familiÃ¤r und auf AugenhÃ¶he â wir leben Austausch, Teamgeist und einen respektvollen Umgang miteinander. Das und viel mehr steht fÃ¼r unser ganz besonderes Wir-GefÃ¼hl. FÃ¼r das es sogar ein Wort gibt: adessi. Denn wir sind alle adessi ab Tag Eins und bei uns bist du von Anfang an Teil des Teams. Unsere Kultur und das Zusammenarbeiten sind geprÃ¤gt von gegenseitiger WertschÃ¤tzung, Anerkennung und UnterstÃ¼tzung. Das verbindet uns hierarchieÃ¼bergreifend â auch im Home-Office. Jeder und jedem adessi stehen alle MÃ¶glichkeiten zur persÃ¶nlichen und beruflichen Entwicklung offen. Unser umfangreiches Trainings- und Weiterbildungsangebot sorgt dafÃ¼r, dass deine Entwicklung bei uns nicht stillsteht. Denn Chancengeber zu sein, das liegt in unserer DNA. Â· Welcome Days - Zwei Tage zum Reinkommen und Netzwerken Â· Bis zu drei Tage mobiles Arbeiten â keine Frage von Pandemien, sondern von Ãberzeugung Â· Deine Entwicklung - Ã¼ber 260 Lern- und Trainingsthemen Â· Events - fachlich und mit SpaÃfaktor Â· Hemden-/Blusenreinigung - zweimal die Woche frisch aufgebÃ¼gelt Â· SportfÃ¶rderung - Zuschuss zum Fitnessstudio und mehr Ã¼ber qualitrain sowie Ãbernahme der Platzmiete fÃ¼r die Sporthalle Â· adesso Mind - Das adesso-Programm rund um Mindfulness Â· PrÃ¤mien fÃ¼r Mitarbeitende - eine Vielzahl an PrÃ¤mien fÃ¼r zusÃ¤tzliches Engagement Â· Auszeitprogramm - Raum fÃ¼r deine persÃ¶nliche Lebensplanung KONTAKT Du bist offen fÃ¼r neue und anspruchsvolle Aufgaben? Dann sende uns deine Bewerbungsunterlagen (inkl. deines CV, deiner Arbeits- und Studienzeugnisse sowie deiner Gehaltsvorstellungen und dem frÃ¼hestmÃ¶glichen Eintrittstermin) vorzugsweise Ã¼ber unser Webformular. Â· Sina MÃ¶schl Â· Recruiting Â· +49 231 7000 7100 Best wishes, -- FÃ©lix Madrid adesso insurance solutions GmbH Agrippinawerft 26 50678 KÃ¶ln T +49 221 27850-355 M +49 152 38869-784 F +49 221-27850-500 E felix.madrid(a)adesso-insurance-solutions.de <mailto:felix.madrid@adesso-insurance-solutions.de> www.adesso-insure.de <http://www.adesso-insure.de/>

Nov. 23, 2022

Re: This week (46/2022) on the Pharo Issue Tracker

by Tim Mackinnon

Wow - thats even neater... all done with our normal tools - on the fly. So cool. Not sure many environments/languages can reason about things in this way. Worthy of a blog post for the wider world I would say - as this kind of stuff should be on more people's radars. Thanks again for all this kind of work. It would be so easy to just continue to think the job was done 20 years ago, where in fact we've only scratched the surface as our understanding of effective software development has improved. Tim On Fri, 18 Nov 2022, at 10:19 AM, Marcus Denker wrote: > > > > On 18 Nov 2022, at 08:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > We merged 18 PRs > > > > Lots of improvements related to BlockClosures this week. > > > > First some helper methods on the AST: > > - #hasNonLocalReturn: check if there is a non-local return > > - #isConstant: Blocks of the kind [#justSomeLiteral] > > - #constantValue: return that literal (and nil for empty [] ) > > - #numArgs for RBBlockNode, as we have already for BlockClosure "[:a | ] sourceNode numArgsâ > > > > Some numbers: > > "there are lots of blocks" > allBlocks := Smalltalk globals allMethods flatCollect: [:meth | meth ast blockNodes ]. > allBlocks size. "100140" > > "but many are compiled inline (eg argunments of #ifTrue:)" > currentFullBlocks := allBlocks select: [:blockNode | blockNode isInlined not]. > currentFullBlocks size. "45193" > > "What we could compile as CleanBlockClosure" > cleanBlocks := currentFullBlocks select: [:blockNode | blockNode isClean]. > cleanBlocks size. "11090" > > "many clean blocks are actually constant" > constantBlocks := cleanBlocks select: [:blockNode | blockNode isConstant]. > constantBlocks size. "3200" > > "FullBlocks that need the outerContext to return" > fullBocksWithReturn := currentFullBlocks select: [ :each | each hasNonLocalReturn ]. > fullBocksWithReturn size â3816â > > We can inspect the collections and then use the inspector to browse the code (with the block > that you look at hightlighted), to get a feel where these are used, e.g. for constant: > > > >

Nov. 18, 2022

Re: This week (46/2022) on the Pharo Issue Tracker

by Marcus Denker

> On 18 Nov 2022, at 08:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > We merged 18 PRs > > Lots of improvements related to BlockClosures this week. > > First some helper methods on the AST: > - #hasNonLocalReturn: check if there is a non-local return > - #isConstant: Blocks of the kind [#justSomeLiteral] > - #constantValue: return that literal (and nil for empty [] ) > - #numArgs for RBBlockNode, as we have already for BlockClosure "[:a | ] sourceNode numArgsâ > Some numbers: "there are lots of blocks" allBlocks := Smalltalk globals allMethods flatCollect: [:meth | meth ast blockNodes ]. allBlocks size. "100140" "but many are compiled inline (eg argunments of #ifTrue:)" currentFullBlocks := allBlocks select: [:blockNode | blockNode isInlined not]. currentFullBlocks size. "45193" "What we could compile as CleanBlockClosure" cleanBlocks := currentFullBlocks select: [:blockNode | blockNode isClean]. cleanBlocks size. "11090" "many clean blocks are actually constant" constantBlocks := cleanBlocks select: [:blockNode | blockNode isConstant]. constantBlocks size. "3200" "FullBlocks that need the outerContext to return" fullBocksWithReturn := currentFullBlocks select: [ :each | each hasNonLocalReturn ]. fullBocksWithReturn size â3816â We can inspect the collections and then use the inspector to browse the code (with the block that you look at hightlighted), to get a feel where these are used, e.g. for constant:

Nov. 18, 2022

Re: This week (46/2022) on the Pharo Issue Tracker

by Tim Mackinnon

The attention to detail on these cleanups to make everything symmetrical is very nice - cool work. Tim On Fri, 18 Nov 2022, at 7:15 AM, Marcus Denker wrote: > We merged 18 PRs > > Lots of improvements related to BlockClosures this week. > > First some helper methods on the AST: > - #hasNonLocalReturn: check if there is a non-local return > - #isConstant: Blocks of the kind [#justSomeLiteral] > - #constantValue: return that literal (and nil for empty [] ) > - #numArgs for RBBlockNode, as we have already for BlockClosure "[:a | > ] sourceNode numArgs" > > Some improvements for isClean: > - unify between AST and BlockClosure > - more tests > - inlined blocks can be clean, important as it is recursive: [true > ifTrue: []] should be clean > - cleanup code in CleanBlock, receiver is known to be nil > > Compiler support for ConstantBlockClosure: > - We can specialize clean blocks of the kind [#justSomeLiteral] to > execute faster > - add ConstantBlockClosure, add compiler support, active when compiling > with clean blocks enabled > > Compiler support for full block without outer context: > - we only need the outerContext for non-local returns. > - add support to IRBuilder for full blocks without outer context > - implement compiler support (option #optionBlockClosureOptionalOuter, > false for now) > > Quick return for Blocks: > - Compile quickreturn for CompiledBlock, just like CompiledMethod (e.g. > for [^1]). > - speeds up execution a little (but of course not creation) > > Block Closures > ============== > > - AST: add a recursive #hasNonLocalReturn and #isConstant #11882 > https://github.com/pharo-project/pharo/pull/11882 > > - add #numArgs to RBBlockNode #11902 > https://github.com/pharo-project/pharo/pull/11902 > > - CleanBlock cleanup code: there should be no receiver ivar #11884 > https://github.com/pharo-project/pharo/pull/11884 > > - 11881-RBBlockNodeisClean-takes-every-optimized-block-to-be-not-clean #11890 > https://github.com/pharo-project/pharo/pull/11890 > > - 1883-CleanBlockChecker-does-not-recurse-into-the-blocks #11900 > https://github.com/pharo-project/pharo/pull/11900 > > - ConstantBlockClosure: active when compiling with clean blocks enabled #11894 > https://github.com/pharo-project/pharo/pull/11894 > > - CompiledBlocks: compile quick returns #11907 > https://github.com/pharo-project/pharo/pull/11907 > > - IRBuilder: add support for outerContext flag for Closure creation #11905 > https://github.com/pharo-project/pharo/pull/11905 > > - 11911-Compiler-add-compiler-option-for-outerContextNeeded #11917 > https://github.com/pharo-project/pharo/pull/11917 > > > > Fixes > ===== > > - Register-as-basicInspector #431 > https://github.com/pharo-spec/NewTools/pull/431 > > - 11803 return value of inspect should be the receiver and not a sp > window presenter #11886 > https://github.com/pharo-project/pharo/pull/11886 > > - Fixes #429, VersionBrowser: left pane empty #430 > https://github.com/pharo-spec/NewTools/pull/430 > > - Turn off ReLongMethodsRule for test methods #11892 > https://github.com/pharo-project/pharo/pull/11892 > > - ClassParser: Implement #asSlot to return a correct Slot instances for > complex slots #11898 > https://github.com/pharo-project/pharo/pull/11898 > > - Fixes #11802 - Adds full consistency checks to class Time #11891 > https://github.com/pharo-project/pharo/pull/11891 > > - Fixing to correctly get the VM for running the tests #11897 > https://github.com/pharo-project/pharo/pull/11897 > > - Fixes #429, VersionBrowser: left pane empty #430 > https://github.com/pharo-spec/NewTools/pull/430 > > Cleanup > ======= > - 11810-FT2Handle-classstartUp-compiled-code-on-image-startup #11811 > https://github.com/pharo-project/pharo/pull/11811 > > > > Comments > ========= > > - fixing comments in package Regex #11888 > https://github.com/pharo-project/pharo/pull/11888

Nov. 18, 2022