- Pharo-vm - lists.pharo.org

Re: [Pharo-dev] Stack overflow support?

by Guille Polito

> El 9 nov. 2023, a las 13:35, David Mason <dmason(a)torontomu.ca> escribiÃ³: > > 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. Yes, I agree that tail-call elimination will largely improve performance. But it will also harm debugging unless there is a way to reconstruct the stack when there is a problem, which I suspect could be very expensive. Anyways, this solves a performance problem, not the recursion problem that motivates my mail, right? > > ../Dave > > On Thu, 9 Nov 2023 at 04:38, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@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 <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 > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Nov. 9, 2023

Re: [Pharo-dev] 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: [Pharo-dev] 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

Re: VM Release 10.0.8

by stephane.ducasse＠free.fr

Thanks Guille. It is nice to get your dedication to get a better system. S > On 23 Oct 2023, at 14:25, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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> > > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Oct. 23, 2023

Re: [Pharo-dev] VM Release 10.0.8

by Guillermo Polito

In the launcher? There is a âVMsâ button on the top right that will open a dialog. Then you need to click on the VM to update and click on update. G > El 23 oct. 2023, a las 16:08, Miloslav.Raus--- via Pharo-dev <pharo-dev(a)lists.pharo.org> escribiÃ³: > > 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 <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

Re: [Pharo-dev] 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

Re: VM Release 10.0.6 on the pipe

by stephane ducasse

Thanks you guys for your dedication of making Pharo better Guille/Pablo can you post it to the consortium mailing-list. S > On 9 Aug 2023, at 13:33, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > This email is to tell you that there is a new VM release on the CI pipe, with many fixes and improvements. > This release will be available for versions of Pharo 11 and above. > > Improvements in build environment > * Update build environment for Pharo 10 vm branch by @guillep in https://github.com/pharo-project/pharo-vm/pull/594 > * Make tests run in parallel by @guillep in https://github.com/pharo-project/pharo-vm/pull/596 > * Update Jenkins to use Pharo 110 for building by @PalumboN in https://github.com/pharo-project/pharo-vm/pull/661 > > Cleanups > * Cleanups/externalize internalize by @guillep in https://github.com/pharo-project/pharo-vm/pull/583 > * Fix/warnings by @guillep in https://github.com/pharo-project/pharo-vm/pull/584 > * fixing-categorization in P10 by @tesonep in https://github.com/pharo-project/pharo-vm/pull/625 > > Fixes > * Fix mnuMethodOrNilFor: for method wrappers by @guillep in https://github.com/pharo-project/pharo-vm/pull/578 > * fix function signatures by @pavel-krivanek in https://github.com/pharo-project/pharo-vm/pull/582 > > Debugging improvements > * Gdbinit file and helpers v2 by @guillep in https://github.com/pharo-project/pharo-vm/pull/486 > * VM Debugger improvement with IR by @QDucasse in https://github.com/pharo-project/pharo-vm/pull/342 > > VM Improvements > * improving-permSpace by @tesonep in https://github.com/pharo-project/pharo-vm/pull/614 > * Changing the order of command-line processing and PList in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/609 > * Adding parsing of image parameters from PList by @tesonep in https://github.com/pharo-project/pharo-vm/pull/636 > * Change terminate handler to exit with 128+signal by @jvalteren in https://github.com/pharo-project/pharo-vm/pull/644 > * Improvements in parameters handling in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/639 > * Adding check to fix when the image is open with an older VM by @tesonep in https://github.com/pharo-project/pharo-vm/pull/642 > * Fix/ephemeron list by @guillep in https://github.com/pharo-project/pharo-vm/pull/668 > > New Contributors > * @jvalteren made their first contribution in https://github.com/pharo-project/pharo-vm/pull/644 > > **Full Changelog**: https://github.com/pharo-project/pharo-vm/compare/v10.0.5...v10.0.6 > > Cheers, > Guille et al > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Aug. 11, 2023

Re: VM Release 10.0.6 on the pipe

by stephaneducasse＠mailo.com

Thanks you guys for your dedication of making Pharo better Guille/Pablo can you post it to the consortium mailing-list. S > On 9 Aug 2023, at 13:33, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > This email is to tell you that there is a new VM release on the CI pipe, with many fixes and improvements. > This release will be available for versions of Pharo 11 and above. > > Improvements in build environment > * Update build environment for Pharo 10 vm branch by @guillep in https://github.com/pharo-project/pharo-vm/pull/594 > * Make tests run in parallel by @guillep in https://github.com/pharo-project/pharo-vm/pull/596 > * Update Jenkins to use Pharo 110 for building by @PalumboN in https://github.com/pharo-project/pharo-vm/pull/661 > > Cleanups > * Cleanups/externalize internalize by @guillep in https://github.com/pharo-project/pharo-vm/pull/583 > * Fix/warnings by @guillep in https://github.com/pharo-project/pharo-vm/pull/584 > * fixing-categorization in P10 by @tesonep in https://github.com/pharo-project/pharo-vm/pull/625 > > Fixes > * Fix mnuMethodOrNilFor: for method wrappers by @guillep in https://github.com/pharo-project/pharo-vm/pull/578 > * fix function signatures by @pavel-krivanek in https://github.com/pharo-project/pharo-vm/pull/582 > > Debugging improvements > * Gdbinit file and helpers v2 by @guillep in https://github.com/pharo-project/pharo-vm/pull/486 > * VM Debugger improvement with IR by @QDucasse in https://github.com/pharo-project/pharo-vm/pull/342 > > VM Improvements > * improving-permSpace by @tesonep in https://github.com/pharo-project/pharo-vm/pull/614 > * Changing the order of command-line processing and PList in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/609 > * Adding parsing of image parameters from PList by @tesonep in https://github.com/pharo-project/pharo-vm/pull/636 > * Change terminate handler to exit with 128+signal by @jvalteren in https://github.com/pharo-project/pharo-vm/pull/644 > * Improvements in parameters handling in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/639 > * Adding check to fix when the image is open with an older VM by @tesonep in https://github.com/pharo-project/pharo-vm/pull/642 > * Fix/ephemeron list by @guillep in https://github.com/pharo-project/pharo-vm/pull/668 > > New Contributors > * @jvalteren made their first contribution in https://github.com/pharo-project/pharo-vm/pull/644 > > **Full Changelog**: https://github.com/pharo-project/pharo-vm/compare/v10.0.5...v10.0.6 > > Cheers, > Guille et al > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Aug. 10, 2023