- Pharo-dev - lists.pharo.org

Re: Stack overflow support?

by Nicolas Anquetil

On 09/11/2023 10:13, Guillermo Polito wrote: [...] > ## Why Ctrl-dot does not always work > not related to the topic, but may I take the opportunity to mention that ctrl-dot does not work on Linux. So this is not a solution, ever sorry for the noise nicolas > Cheers, > Guille -- Nicolas Anquetil RMod team -- Inria Lille

Nov. 9, 2023

Re: Stack overflow support?

by Sven Van Caekenberghe

This is super important. I always thought that this was an implementation problem in the sense that the overflow check was too costly/slow. Anyway, in most Common Lisp implementations the stack is also limited. When you hit the limit, a resumable exception is raised, allowing you to make the stack larger and continue. And of course you can set a large initial stack size per process. > On 9 Nov 2023, at 10:13, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > We started (with many interruptions over the last months) working a bit with Stephane on understanding what is the (positive and negative) impact of stack-overflow support in Pharo. > The key idea is that if a process consumes too much stack (potentially because of an infinite recursion) then the process should stop with an exception. > > ## Why we want better stack consumption control > > This idea comes up to solve issues that are pretty common and hit especially newbies. > For example, imagine you accidentally write an accessor such as > > ``` > A >> foo > ^ self foo > ``` > > Students do this all the time, and Iâve also seen it in experienced people who go too fast :). > More importantly, such recursions could happen also with not-so-obvious indirect recursions (a sends b, b sends c, c sends a), and these could hit anybody. > > This is aggravated because the current execution model allows us to have infinite stacks âmeaning: limited by available memory only. > This is indeed a nice feature for many use cases but it has its own drawbacks when one of these kind of recursions are hit: > - code just loops forever taking space in the stack > - when there is no more stack space, context objects are created and moved to the heap > - but those contexts are strongly held, so they are never GCed and take up extra space > - even worse! they are there adding more work to the GC every time and making the GC run more often looking for space that is not there > > ## Why Ctrl-dot does not always work > > Of course, super users know there is this âCtrl dotâ hidden feature that should help you recover from this. > First, let's take out of the equation that this is only known by super users. > Now, in this situation, when Ctrl-dot is hit it will trigger a handler that suspends the problematic process and opens a debugger on it. > But it could happen that, > - the stack is so big that the debugger is very sluggish (best-case scenario) > - the VM is just flooded doing GCs so maybe the Ctrl dot event does not even arrive at Pharo or the trigger > - if the recursion is hit when printing an object (which is more common than you could imagine), opening the debugger could trigger a new recursion and never give back the control to the user > > ## What are we working on > > The main idea here is: Can we have a simple and efficient way to prevent such kinds of situations? > > After many discussions around detecting recursion, we kinda arrived at the simple solution of just detecting a stack overflow. > The solution is easy to understand (because itâs like other languages work) and easy to implement because there is already support for that. > But this leaves open two questions: > - what happens when people want to use the âinfinite stackâ feature? > - when should a process stack overflow? What is a sensitive default value? > > Our draft implementation here https://github.com/pharo-project/pharo-vm/pull/710 does the following to cope with this: > - we can now parametrize the size of the stack (of each stack page to be more accurate) when the VM starts up > - the stack overflow check can be disabled per process > > We also are running experiments to see what could be a sensitive stack size for our normal usages. Here, for example, we ran almost all test cases in Pharo separately (one suite per line below), and we observed how many tests broke (x-axis) with different stack sizes (y-axis). > Here we see that most test suites require at least 20-24k to run properly, some go up to 36k of stack before converging (i.e., the number of broken tests does not change). > > <ImagenPegada-10.tiff> > Youâll notice in the graph that There are some scenarios that break all the time. This is because exception handling itself is recursive and may produce more stack overflows depending on the size of the stack between the exception and the exception handler. > So some more work is still required, mostly changing Pharo libraries to properly support this. For example: > - should tests run in a fresh process with a fresh stack? > - should the exception mechanism use less recursion? > - resumable exceptions add stack pressure because they do not âunstackâ until the exception is finally handled, meaning that the stack used by exception handling just adds up to the stack of the original code, can we do better here? > > Probably there are more interesting questions here, thatâs the âwhy" behind this email. > Iâm interested in opinions and scenarios you may come up with that should be taken into account. > > Cheers, > Guille

Nov. 9, 2023

Re: Stack overflow support?

by David Mason

Tail call elimination would reduce stack usage significantly. See Tail Call Elimination in OpenSmalltalk, Ralston & Mason, IWST2019 This really should be part of any stack solution. Particularly people coming from a functional language background are likely to use it. Also double dispatch would benefit significantly. ../Dave On Thu, 9 Nov 2023 at 04:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > We started (with many interruptions over the last months) working a bit > with Stephane on understanding what is the (positive and negative) impact > of stack-overflow support in Pharo. > The key idea is that if a process consumes too much stack (potentially > because of an infinite recursion) then the process should stop with an > exception. > > ## Why we want better stack consumption control > > This idea comes up to solve issues that are pretty common and hit > especially newbies. > For example, imagine you accidentally write an accessor such as > > ``` > A >> foo > ^ self foo > ``` > > Students do this all the time, and Iâve also seen it in experienced people > who go too fast :). > More importantly, such recursions could happen also with not-so-obvious > indirect recursions (a sends b, b sends c, c sends a), and these could hit > anybody. > > This is aggravated because the current execution model allows us to have > infinite stacks âmeaning: limited by available memory only. > This is indeed a nice feature for many use cases but it has its own > drawbacks when one of these kind of recursions are hit: > - code just loops forever taking space in the stack > - when there is no more stack space, context objects are created and > moved to the heap > - but those contexts are strongly held, so they are never GCed and take > up extra space > - even worse! they are there adding more work to the GC every time and > making the GC run more often looking for space that is not there > > ## Why Ctrl-dot does not always work > > Of course, super users know there is this âCtrl dotâ hidden feature that > should help you recover from this. > First, let's take out of the equation that this is only known by super > users. > Now, in this situation, when Ctrl-dot is hit it will trigger a handler > that suspends the problematic process and opens a debugger on it. > But it could happen that, > - the stack is so big that the debugger is very sluggish (best-case > scenario) > - the VM is just flooded doing GCs so maybe the Ctrl dot event does not > even arrive at Pharo or the trigger > - if the recursion is hit when printing an object (which is more common > than you could imagine), opening the debugger could trigger a new recursion > and never give back the control to the user > > ## What are we working on > > The main idea here is: Can we have a simple and efficient way to prevent > such kinds of situations? > > After many discussions around detecting recursion, we kinda arrived at the > simple solution of just detecting a stack overflow. > The solution is easy to understand (because itâs like other languages > work) and easy to implement because there is already support for that. > But this leaves open two questions: > - what happens when people want to use the âinfinite stackâ feature? > - when should a process stack overflow? What is a sensitive default value? > > Our draft implementation here > https://github.com/pharo-project/pharo-vm/pull/710 does the following to > cope with this: > - we can now parametrize the size of the stack (of each stack page to be > more accurate) when the VM starts up > - the stack overflow check can be disabled per process > > We also are running experiments to see what could be a sensitive stack > size for our normal usages. Here, for example, we ran almost all test cases > in Pharo separately (one suite per line below), and we observed how many > tests broke (x-axis) with different stack sizes (y-axis). > Here we see that most test suites require at least 20-24k to run properly, > some go up to 36k of stack before converging (i.e., the number of broken > tests does not change). > > > Youâll notice in the graph that There are some scenarios that break all > the time. This is because exception handling itself is recursive and may > produce more stack overflows depending on the size of the stack between the > exception and the exception handler. > So some more work is still required, mostly changing Pharo libraries to > properly support this. For example: > - should tests run in a fresh process with a fresh stack? > - should the exception mechanism use less recursion? > - resumable exceptions add stack pressure because they do not âunstackâ > until the exception is finally handled, meaning that the stack used by > exception handling just adds up to the stack of the original code, can we > do better here? > > Probably there are more interesting questions here, thatâs the âwhy" > behind this email. > Iâm interested in opinions and scenarios you may come up with that should > be taken into account. > > Cheers, > Guille >

Nov. 9, 2023

Stack overflow support?

by Guillermo Polito

Hi all, We started (with many interruptions over the last months) working a bit with Stephane on understanding what is the (positive and negative) impact of stack-overflow support in Pharo. The key idea is that if a process consumes too much stack (potentially because of an infinite recursion) then the process should stop with an exception. ## Why we want better stack consumption control This idea comes up to solve issues that are pretty common and hit especially newbies. For example, imagine you accidentally write an accessor such as ``` A >> foo ^ self foo ``` Students do this all the time, and Iâve also seen it in experienced people who go too fast :). More importantly, such recursions could happen also with not-so-obvious indirect recursions (a sends b, b sends c, c sends a), and these could hit anybody. This is aggravated because the current execution model allows us to have infinite stacks âmeaning: limited by available memory only. This is indeed a nice feature for many use cases but it has its own drawbacks when one of these kind of recursions are hit: - code just loops forever taking space in the stack - when there is no more stack space, context objects are created and moved to the heap - but those contexts are strongly held, so they are never GCed and take up extra space - even worse! they are there adding more work to the GC every time and making the GC run more often looking for space that is not there ## Why Ctrl-dot does not always work Of course, super users know there is this âCtrl dotâ hidden feature that should help you recover from this. First, let's take out of the equation that this is only known by super users. Now, in this situation, when Ctrl-dot is hit it will trigger a handler that suspends the problematic process and opens a debugger on it. But it could happen that, - the stack is so big that the debugger is very sluggish (best-case scenario) - the VM is just flooded doing GCs so maybe the Ctrl dot event does not even arrive at Pharo or the trigger - if the recursion is hit when printing an object (which is more common than you could imagine), opening the debugger could trigger a new recursion and never give back the control to the user ## What are we working on The main idea here is: Can we have a simple and efficient way to prevent such kinds of situations? After many discussions around detecting recursion, we kinda arrived at the simple solution of just detecting a stack overflow. The solution is easy to understand (because itâs like other languages work) and easy to implement because there is already support for that. But this leaves open two questions: - what happens when people want to use the âinfinite stackâ feature? - when should a process stack overflow? What is a sensitive default value? Our draft implementation here https://github.com/pharo-project/pharo-vm/pull/710 <https://github.com/pharo-project/pharo-vm/pull/710> does the following to cope with this: - we can now parametrize the size of the stack (of each stack page to be more accurate) when the VM starts up - the stack overflow check can be disabled per process We also are running experiments to see what could be a sensitive stack size for our normal usages. Here, for example, we ran almost all test cases in Pharo separately (one suite per line below), and we observed how many tests broke (x-axis) with different stack sizes (y-axis). Here we see that most test suites require at least 20-24k to run properly, some go up to 36k of stack before converging (i.e., the number of broken tests does not change). Youâll notice in the graph that There are some scenarios that break all the time. This is because exception handling itself is recursive and may produce more stack overflows depending on the size of the stack between the exception and the exception handler. So some more work is still required, mostly changing Pharo libraries to properly support this. For example: - should tests run in a fresh process with a fresh stack? - should the exception mechanism use less recursion? - resumable exceptions add stack pressure because they do not âunstackâ until the exception is finally handled, meaning that the stack used by exception handling just adds up to the stack of the original code, can we do better here? Probably there are more interesting questions here, thatâs the âwhy" behind this email. Iâm interested in opinions and scenarios you may come up with that should be taken into account. Cheers, Guille

Nov. 9, 2023

Last week (44/2023) on the Pharo Issue Tracker

by Marcus Denker

# Pharo 11 - Backport Pharo11: Optimize Dictionary>>unreferencedKeys #15196 https://github.com/pharo-project/pharo/pull/15196 # External Packages - Update roassal v1.05b #15159 https://github.com/pharo-project/pharo/pull/15159 # Features - Calypso: Introduce a project view based on baselines in the image #15155 https://github.com/pharo-project/pharo/pull/15155 https://github.com/pharo-project/pharo/pull/15176 # Fixes - Spotter not opening minimized window (issue #603) #604 https://github.com/pharo-spec/NewTools/pull/604 - Following symbolic links when canonicalising FileReferences. #14773 https://github.com/pharo-project/pharo/pull/14773 - fix 13709: Code Completion: completion sometimes has its window in a â¦ #15151 https://github.com/pharo-project/pharo/pull/15151 - Fix moving classes in tags #15146 https://github.com/pharo-project/pharo/pull/15146 - Force rescheduling of inactive process when changing its priority (fixes #14701) #14905 https://github.com/pharo-project/pharo/pull/14905 - Replacing the use of species new with copyEmpty. #15150 https://github.com/pharo-project/pharo/pull/15150 - Fix depth conversion in #image:size: on AlphaImageMorph to use the original Formâs extent #15170 https://github.com/pharo-project/pharo/pull/15170 - Fix random bug in auto completion #15175 https://github.com/pharo-project/pharo/pull/15175 - Inlining select:thenCollect: and reject:thenCollect: to not do two iterations on the same collection #15149 https://github.com/pharo-project/pharo/pull/15149 - Replace extracted expression only in containing scope (fixes #14771) #14906 https://github.com/pharo-project/pharo/pull/14906 - Calypso: Fix regression in taskbar label #15220 https://github.com/pharo-project/pharo/pull/15220 - Refactor AlphaImageMorph to replace âcachedFormâ by âcachedFormSetâ #15189 https://github.com/pharo-project/pharo/pull/15189 # RPackage - RPackage: Remove last listeners to SystemAnnouncer #15208 https://github.com/pharo-project/pharo/pull/15208 - RPackage: Do not register to MethodAdded #15180 https://github.com/pharo-project/pharo/pull/15180 - Calypso:â¯Improve some namings on package tags #15179 https://github.com/pharo-project/pharo/pull/15179 - RPackage: Clean protocols management #15132 https://github.com/pharo-project/pharo/pull/15132 # Fluid ClassDefs / ClassBuilder - Reduce usage of category for protocol #15166 https://github.com/pharo-project/pharo/pull/15166 - Remove more old class creation API #15165 https://github.com/pharo-project/pharo/pull/15165 - Do a pass on shift after recent improvements #15187 https://github.com/pharo-project/pharo/pull/15187 - Deprecate ClassRenamed>>category #15186 https://github.com/pharo-project/pharo/pull/15186 - Simplify ChunkImportTestCase #15181 https://github.com/pharo-project/pharo/pull/15181 # Monticello / Metacello - Monticello: Fix loading of erroneous methods #15203 https://github.com/pharo-project/pharo/pull/15203 - Monticello: Fix problem in package loading logic #15207 https://github.com/pharo-project/pharo/pull/15207 - Monticello: Multiple MethodAddition cleanings (announce protocol changes, compile before installing, cleanup) #15172 https://github.com/pharo-project/pharo/pull/15172 - Metacello: Clean the way to create a class #15188 https://github.com/pharo-project/pharo/pull/15188 # Package Dependencies - Cut dependency from AST-Core-Tests to SystemCommands-SourceCodeCommands #15141 https://github.com/pharo-project/pharo/pull/15141 - Split finalization registry from WeakArray and sort dependencies #15139 https://github.com/pharo-project/pharo/pull/15139 - Fix cyclic dependencies between compiler and ASTs/parser and their tests #15144 https://github.com/pharo-project/pharo/pull/15144 - Update dependencies to Roassal and Array2D #15148 https://github.com/pharo-project/pharo/pull/15148 - Pusing down dependencies of Collection-Abstract #15138 https://github.com/pharo-project/pharo/pull/15138 - Move critics UI methods to critic UI package #15184 https://github.com/pharo-project/pharo/pull/15184 # Variables / Undeclared - Another pass on #usingMethods for UndeclaredVariable: filter for installed methods #15190 https://github.com/pharo-project/pharo/pull/15190 - SystemDictionary>>declare:from: should not be an extension #15197 https://github.com/pharo-project/pharo/pull/15197 # CI / Tests - tiny speedup for testNoShadowedVariablesInMethods #15173 https://github.com/pharo-project/pharo/pull/15173 - Guard RubAbstractTextArea>>#recomputeSelection for empty paragraphs #15140 https://github.com/pharo-project/pharo/pull/15140 - Improve ClassFactoryForTestCase #15185 https://github.com/pharo-project/pharo/pull/15185 # Cleanup - Remove #acceptsLoggingOfCompilation #15182 https://github.com/pharo-project/pharo/pull/15182 - Bootstrap: Remove dead code #15195 https://github.com/pharo-project/pharo/pull/15195 - Fix DateParser comment #15174 https://github.com/pharo-project/pharo/pull/15174

Nov. 6, 2023

Pragma Improvements: Identity, sourceNode and Inspector

by Marcus Denker

Last week we merged some improvements related to Pragma in Pharo12 1) Pragma will not be shalowCopied by AdditionalMethodState anymore when growing/shrinking This was a bit odd, but AdditionalMethodState was calling #shalowCopy on the pragmas (and Associations) that are contained in it. This was bad for many reasons: - makes it hard to e.g. cache Pragmas by Identity (we had a bug due to that) - lots of copies are created during creation of a CompiledMethod and usage of Method Properties see the two PRs: - 15074-Pragmas-lost-when-updating-methods #15087 https://github.com/pharo-project/pharo/pull/15087 - AdditionalMethodState: do not copy the Associations/Pragmas when growing or shrinking #15090 https://github.com/pharo-project/pharo/pull/15090 2) make sure to create the Pragma *once* from the RBPragmaNode If you look at the senders of #asPragma, there used to be more than one. To make sure that Identity is preserved (and simplify things), we now create the Pragma *once* during name analysis. In OCASTSemanticAnalyzer>>#visitPragmaNode:, the Pragma instance is now created and added to the RBPragmaNode (there is now a pragma instance variable with a getter). ``` visitPragmaNode: aPragmaNode | varNode | super visitPragmaNode: aPragmaNode. aPragmaNode pragma: aPragmaNode asPragma. aPragmaNode selector = #compilerOptions: ifTrue: [ aPragmaNode pragma sendTo: self compilationContext ]. ... ``` This means that we can now use it in OCASTTranslator >> visitPragmaNode: instead of calling #asPragma: ``` visitPragmaNode: aPragmaNode | var | aPragmaNode isParseError ifTrue: [ ^self ]. methodBuilder addPragma: aPragmaNode pragma. ... ``` This should make it easier to (in the future) experiment with the idea to use subclasses of Pragma. 3) add #sourceNode We never added #sourceNode on Pragma... now we have it. This uses the idea that the order is the same of Pragmas on the CompiledMethod and RBPragmaNodes on the RBMethodNode: sourceNode [ | index | index := method pragmas identityIndexOf: self. ^ method ast pragmas at: index see PR #15092 for both 2 and 3: https://github.com/pharo-project/pharo/pull/15092 4) with #sourceNode implemented, we can improve the source view of the inspector (the default view). See PR https://github.com/pharo-spec/NewTools/pull/602

Oct. 30, 2023

This week (43/2023) on the Pharo Issue Tracker

by Marcus Denker

# Pharo 11 - [P11] Add Support for proxy in Iceberg #15099 https://github.com/pharo-project/pharo/pull/15099 - Make finalization registry a normal strong double linked list #15107 https://github.com/pharo-project/pharo/pull/15107 - [P11] Update document browser to 1.0.1 to 1.0.2, which depends on iceberg 2.2.2 #15130 https://github.com/pharo-project/pharo/pull/15130 - Honouring Proxy Settings in P11 #1750 https://github.com/pharo-vcs/iceberg/pull/1750 # Fixes - Make finalization registry a normal strong double linked list P12 #15108 https://github.com/pharo-project/pharo/pull/15108 - Fix Jump to test method from implementors view #15045 https://github.com/pharo-project/pharo/pull/15045 - 15074-Pragmas-lost-when-updating-methods #15087 https://github.com/pharo-project/pharo/pull/15087 - AdditionalMethodState: do not copy the Associations/Pragmas when growing or shrinking #15090 https://github.com/pharo-project/pharo/pull/15090 # Features - Improve the inspector for Pragma to highlight the pragma in the source #602 https://github.com/pharo-spec/NewTools/pull/602 - Refactor ImageMorph to support more than one Form depicting the same image at different scales #14998 https://github.com/pharo-project/pharo/pull/14998 - Icenberg: Adding support for Proxy URL #1748 https://github.com/pharo-vcs/iceberg/pull/1748 # Packages Cleanup - RPackage: Create packages for extension protocols without announcements #14552 https://github.com/pharo-project/pharo/pull/14552 - Do not use categories in ShiftClassInstaller #15122 https://github.com/pharo-project/pharo/pull/15122 - Fix bug marking too many packages as dirty in Iceberg #15073 https://github.com/pharo-project/pharo/pull/15073 - Fix moving a class from a tag in Calypso #15077 https://github.com/pharo-project/pharo/pull/15077 - RPackage: Simplify protocol management #15080 https://github.com/pharo-project/pharo/pull/15080 - Improve ShiftClassBuilder>>category: #15094 https://github.com/pharo-project/pharo/pull/15094 - Deprecate ClassRecategorized #15127 https://github.com/pharo-project/pharo/pull/15127 - Do not announce method recategorization when removing a selector from a protocol #15133 https://github.com/pharo-project/pharo/pull/15133 - SpChangeSorterPresenter shouldnt use ClassRecategorized #601 https://github.com/pharo-spec/NewTools/pull/601 # Monticello - Monticello: Improve MCZ management #15114 https://github.com/pharo-project/pharo/pull/15114 - Introduce and use CategoryConverter #15102 https://github.com/pharo-project/pharo/pull/15102 - Improve MCSystemCategoryParser #15086 https://github.com/pharo-project/pharo/pull/15086 - Monticello: remove unused announcements #15082 https://github.com/pharo-project/pharo/pull/15082 - Monticello: Make MethodAddition closer to system behavior #15081 https://github.com/pharo-project/pharo/pull/15081 - Monticello: Class/Trait definition creation shouldnt use categories #15088 https://github.com/pharo-project/pharo/pull/15088 - Monticello: Add an option to read old format #15103 https://github.com/pharo-project/pharo/pull/15103 - Update location of setting the MCZ old format flag #15111 https://github.com/pharo-project/pharo/pull/15111 # Metacello - Deprecate MetacelloPlatfrom>>#authorName: #15079 https://github.com/pharo-project/pharo/pull/15079 - Simplify bootstraping of Metacello #15072 https://github.com/pharo-project/pharo/pull/15072 - Simplify Metacello platform code #15066 https://github.com/pharo-project/pharo/pull/15066 - Move regex core loading #15069 https://github.com/pharo-project/pharo/pull/15069 # Compiler - RBPragmaNode/Pragma: add #sourceNode, reduce #asPragma #15092 https://github.com/pharo-project/pharo/pull/15092 - Cleanup: #recompile and CompilerPlugin tests #15109 https://github.com/pharo-project/pharo/pull/15109 - Undeclared: keep weak reference to all methods using the Undeclared Variable #15100 https://github.com/pharo-project/pharo/pull/15100 - Add test: reading 'thisContext' in a DoIt #15117 https://github.com/pharo-project/pharo/pull/15117 - Merge OCPragmaTest into MethodPragmaTest #15113 https://github.com/pharo-project/pharo/pull/15113 - Fix testRecompileMethodToInBlockContext++ using clean blocks #605 https://github.com/pharo-spec/NewTools/pull/605 # Bootstrap - Remove BaselineOfTelePharoSupport #15119 https://github.com/pharo-project/pharo/pull/15119 - Improve the management of TTranscript #15116 https://github.com/pharo-project/pharo/pull/15116 # Refactoring Engine - Refactor: move precondition checking code to checkPreconditions #15078 https://github.com/pharo-project/pharo/pull/15078 # Cleanup - Deprecate old class creation methods #14837 https://github.com/pharo-project/pharo/pull/14837 - Move traceCr & co to non interactive transcript #15115 https://github.com/pharo-project/pharo/pull/15115 - Calypso: Remove duplicated registration of SycRemoveClassCommand #15084 https://github.com/pharo-project/pharo/pull/15084 - remove TextEditor #15064 https://github.com/pharo-project/pharo/pull/15064 - Cleanup Message Hierarchy #15095 https://github.com/pharo-project/pharo/pull/15095 # Trivial Cleanup - Cleanup: TIterateTest>>#testSumNumbers #15124 https://github.com/pharo-project/pharo/pull/15124 - Clean AthensFontDescription>>#asString #15123 https://github.com/pharo-project/pharo/pull/15123 - Small cleanup: use pragma, not #expectedFailures method #15112 https://github.com/pharo-project/pharo/pull/15112 - remove two duplicated methods #15097 https://github.com/pharo-project/pharo/pull/15097 - Rewrite == nil ifFalse: into ifNotNil: #15101 https://github.com/pharo-project/pharo/pull/15101 - Rewrite notNil ifTrue: into ifNotNil: in packages starting by M #15129 https://github.com/pharo-project/pharo/pull/15129 - Transform notNil ifFalse: into ifNil: #15128 https://github.com/pharo-project/pharo/pull/15128 - Rewrite = nil ifTrue: to ifNil: #15083 https://github.com/pharo-project/pharo/pull/15083 - Rewrite notNil ifTrue: into ifNotNil: #15135 https://github.com/pharo-project/pharo/pull/15135 - Rewrite == nil ifTrue: to ifNil: #15085 https://github.com/pharo-project/pharo/pull/15085 - Cleanup: CornerGripMorph should be abstract #15068 https://github.com/pharo-project/pharo/pull/15068

Oct. 30, 2023

Re: VM Release 10.0.8

by Miloslav.Raus＠cuzk.cz

Hi how exactly does one do this on Windows, without violating the "msi contract" (i.e. one was as dumb enogh to install the proposed msi package some time back) ? Ie. I'm perfectly capable of overwriting the VM, but don't tell me it's the right thing to do" (tm). M.R. ________________________________ From: Guillermo Polito <guillermopolito(a)gmail.com> Sent: Monday, October 23, 2023 2:25:32 PM To: Pharo Development List; Any question about pharo is welcome; pharo-vm(a)lists.pharo.org Subject: [Pharo-dev] VM Release 10.0.8 Hi all, TL;DR; update your launcher VMs and your download scripts! There is a new VM version: release 10.0.8 which fixes, among others, a performance regression that showed in some cases that overly relied on the interpreter. See below the changes log, and for those interested, the fix for the performance issue is here: https://github.com/pharo-project/pharo-vm/pull/705 What's Changed * Fixes #14768: File class>>primFileAttributesð· answers corrupted result by @akgrant43<https://github.com/akgrant43> in #697<https://github.com/pharo-project/pharo-vm/pull/697> * Fix/speed regression by @tesonep<https://github.com/tesonep> in #705<https://github.com/pharo-project/pharo-vm/pull/705> Full Changelog: v10.0.7...v10.0.8<https://github.com/pharo-project/pharo-vm/compare/v10.0.7...v10.0.8>

Oct. 23, 2023

VM Release 10.0.8

by Guillermo Polito

Hi all, TL;DR; update your launcher VMs and your download scripts! There is a new VM version: release 10.0.8 which fixes, among others, a performance regression that showed in some cases that overly relied on the interpreter. See below the changes log, and for those interested, the fix for the performance issue is here: https://github.com/pharo-project/pharo-vm/pull/705 <https://github.com/pharo-project/pharo-vm/pull/705> What's Changed Fixes #14768: File class>>primFileAttributesð· answers corrupted result by @akgrant43 <https://github.com/akgrant43> in #697 <https://github.com/pharo-project/pharo-vm/pull/697> Fix/speed regression by @tesonep <https://github.com/tesonep> in #705 <https://github.com/pharo-project/pharo-vm/pull/705> Full Changelog: v10.0.7...v10.0.8 <https://github.com/pharo-project/pharo-vm/compare/v10.0.7...v10.0.8>

Oct. 23, 2023

Pharo Launcher default directory issue

by Aik-Siong Koh

On Windows 11, I run "C:\Users\askoh\OneDrive\askoh\smalltalk\pharo\pharo-launcher-3.0.1.msi" I find that it installed directories and files in C:\Users\askoh\Documents\Pharo I run pharo-launcher-3.0.1.msi again to remove PharoLauncher. I run pharo-launcher-3.0.1.msi again and change installation directory to C:\Users\askoh\OneDrive\askoh\smalltalk\pharo I launch PharoLauncher I click on Settings Again the default directory is C:\Users\askoh\Documents\Pharo instead of C:\Users\askoh\OneDrive\askoh\smalltalk\pharo I manually change the default directory to C:\Users\askoh\OneDrive\askoh\smalltalk\pharo I click Save Settings I quit PharoLauncher. I restart PharoLauncher. I click on Settings Again the default directory is C:\Users\askoh\Documents\Pharo I click Load Settings. Nothing changed. Please advise. Aik-Siong Koh

Oct. 22, 2023