[Pharo-users] Re: [Pharo-dev] Pharo VM Release - v9.0.21

[Stewart MacLean]

Hi Pablo,

I'm on Pharo 10 and intermittently experience "the spinning wheel" when
making LibC calls. The spin dump is below.

I'm wondering if the last fix:

- Allocating the opcodes and fixup structs only once and reusing them
(Reducing risk of C Stack Overflow))

would potentially rectify this?

Thanks to you and the whole team for all the great work on the machine!

Stewart

 Thread 0x9a54d1000 samples (1-1000)priority 46 (base 46)
  1000  ??? [0x1062e1a78]
1000  ??? [0x1063c2374]
  1000  ??? [0x1062e1ab8]
1000  ??? [0x10637a0e0]
  1000  ??? [0x10637a324]
1000  ??? [0x1062e27f4]
  1000  ??? [0x10637763c]
1000  ??? [0x1062e070c]
  1000  ceStackOverflow + 196 (libPharoVMCore.dylib +
451716) [0x10453a484]
1000  checkForEventsMayContextSwitch + 828
(libPharoVMCore.dylib + 430696) [0x104535268]
  1000  ioProcessEvents + 16 (libPharoVMCore.dylib +
25800) [0x1044d24c8]
1000  aioPoll + 80 (libPharoVMCore.dylib + 788412)
[0x10458c7bc]
  1000  _sigtramp + 56 (libsystem_platform.dylib +
17636) [0x1a20a84e4]
1000  handleSignal + 80
(libUnixOSProcessPlugin.dylib + 46264) [0x11cf674b8]
  1000  signalSemaphoreWithIndex + 264
(libPharoVMCore.dylib + 786524) [0x10458c05c]
1000  aioInterruptPoll + 104
(libPharoVMCore.dylib + 789424) [0x10458cbb0]
  1000  platform_semaphore_wait + 20
(libPharoVMCore.dylib + 36804) [0x1044d4fc4]
1000  _dispatch_semaphore_wait_slow +
132 (libdispatch.dylib + 18420) [0x1a1ed37f4]
  1000  
1000  semaphore_wait_trap + 8
(libsystem_kernel.dylib + 6544) [0x1a2055990]
 *1000  ??? (kernel.release.t8101 +
575116) [0xfe000799868c]


On Tue, Dec 13, 2022 at 2:30 AM teso...@gmail.com  wrote:

> Hello,
>   I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and
> Pharo 11. This VM is accessible right now from Zero-Conf, updating it in
> the Pharo Launcher or using the usual downloads (as described in
> pharo.org/download).
>
> This version includes a series of bug fixes and upgrades on the
> third-party libraries.
>
> Changelog:
>
> - Implementing High resolution clock for ARM64 (Used during profiling)
> - Updating third party libraries for all the graphic layer.
> - Fixing a performance regression on the allocation of opcodes and fix-ups.
> Cleaning only the ones that are going to be used.
> Like this, this version has the same speed than before when
> allocating in the stack.
> - Correctly handling the encoding of the command line arguments of the VM
> (Windows)
> - Allocating the opcodes and fixup structs only once and reusing them
> (Reducing risk of C Stack Overflow)
>
> Thanks a lot, and any doubt please let me know.
> Cheers,
>
> Pablo on behalf of the whole Pharo team.
>
> --
> Pablo Tesone.
> teso...@gmail.com
>

[Pharo-users] [Issue Tracker] Please check your issues

[Marcus Denker]

Hi,

The issue tracker has a bit the problem that outdated issues are never cleaned

- sometimes PRs are merged but the issue is not closed because it was never 
connected to the PR
( github sometimes just does not do it correctly )

- Duplicated reports, bug is fixed but the other issue was closed

- Problem fixed due to other reasons

Or your issue might have seen someone asking a question. People tend to just 
wait for an answer to those.

Or maybe the issue has just not enough information for others to take action?

Maybe you could submit a PR instead of just describing the change you think 
should be done?


The best would be if everyone who opened an issue would check all the issues 
they submitted.

you can just add a filter to https://github.com/pharo-project/pharo/issues, e.g.


 author:MarcusDenker 

shows you all that I submitted


Marcus