- Pharo-dev - lists.pharo.org

Abut writeOn: versus storeOn:

by StÃ©phane Ducasse

Hi I saw that a couple of collections implement writeOn: in addition to storeOn: and I was wondering if someone knows the reason. My gut feeling is that this is somehow dead code. Because readOn: logic is the inverse of storeOn: and I was wondering what is the equivalent for writeOn: S -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 19, 2020

This week (51/2020) on the Issue Tracker

by Marcus Denker

FFI === - Integrating ThreadedFFI in the image. #8102 https://github.com/pharo-project/pharo/pull/8102 - fixing-initialization-of-ffibackend #8131 https://github.com/pharo-project/pharo/pull/8131 New Features ============= - Class>>#usesTrait: and Class>>#usesTraitTransitively: #8002 https://github.com/pharo-project/pharo/pull/8002 - ThemeIcons should have a #reset method #8050 https://github.com/pharo-project/pharo/pull/8050 Refactoring Engine =========== - 8079-RBRefactoringChangeTesttestAddMetaclassPattern-calls-definition #8107 https://github.com/pharo-project/pharo/pull/8107 - Fixing undo refactory #8051 https://github.com/pharo-project/pharo/pull/8051 Fixes ===== - 8129-Debugger-should-log-the-exception-always #8130 https://github.com/pharo-project/pharo/pull/8130 - Fixed #6391. Filed out methods are now saved into files that have colons in their names #7888 https://github.com/pharo-project/pharo/pull/7888 - Correctly decode file names from SDL2, at SDL2 #8116 https://github.com/pharo-project/pharo/pull/8116 - 8117-RBMethodNode>>methodClass-should-gard-for-nil #8118 https://github.com/pharo-project/pharo/pull/8118 - Bootstrapper in 64 and 32 bits #8064 https://github.com/pharo-project/pharo/pull/8064 - Make use of current working directory primitive on windows #8070 https://github.com/pharo-project/pharo/pull/8070 Graphics ======== - Moving the responsibility to the OSWindowDriver #8123 https://github.com/pharo-project/pharo/pull/8123 - 8086-RSLabelTest-Could-not-find-accessor-for-variable-named-anUTF8EncodedString #8104 https://github.com/pharo-project/pharo/pull/8104 - Enh/win32 athens #8069 https://github.com/pharo-project/pharo/pull/8069 Fluid Class Definitions ======================= Work continous: cleanups and fixes - 7923-Broken-traits-definitions #8046 https://github.com/pharo-project/pharo/pull/8046 - 8122-Expanding-a-class-does-not-respect-superclass #8137 https://github.com/pharo-project/pharo/pull/8137 - ClassParser-reduce-NewUndeclaredWarning #8121 https://github.com/pharo-project/pharo/pull/8121 - 8073-glitch-in-package-template #8106 https://github.com/pharo-project/pharo/pull/8106 - 8036-Spotter-uses-definition-for-class-instead-of-definitionString #8043 https://github.com/pharo-project/pharo/pull/8043 - 8098-definition---definitionString #8099 https://github.com/pharo-project/pharo/pull/8099 - 8080-TraitTesttestPrintingClassSide-is-calling-definition #8091 https://github.com/pharo-project/pharo/pull/8091 - 8078-EpHasImpactVisitorvisitBehaviorChange-calls-definition #8090 https://github.com/pharo-project/pharo/pull/8090 - 081-EpCodeChangeIntegrationTesttestRedundantClassDefinition-calls-definition-and-more #8096 https://github.com/pharo-project/pharo/pull/8096 - 8071-Replying-a-class-definition-with-Epicea-and-fluid-class-does-not-recreate-the-class #8072 https://github.com/pharo-project/pharo/pull/8072 Cleanups Dead Code ================== - Cleanup-ClassOrganization-listAtCategoryNumber #8126 https://github.com/pharo-project/pharo/pull/8126 - SlotScope-DeadCode-Clean #8105 https://github.com/pharo-project/pharo/pull/8105 Cleanups ======= - RBProgramNode>>#doSemanticAnalysis should be correctly packaged #8110 https://github.com/pharo-project/pharo/pull/8110 - Cleanup Variable class comment #8112 https://github.com/pharo-project/pharo/pull/8112 - Small typo in ReExceptionStrategy class comment #8093 https://github.com/pharo-project/pharo/pull/8093 - Typo in handle:about:forProppertiesDo: #8095 https://github.com/pharo-project/pharo/pull/8095 - Move ArrayTest to Collections-Sequenceable-Tests #7995 https://github.com/pharo-project/pharo/pull/7995 - 8075-RunArray-is-not-an-abstract-class #8076 https://github.com/pharo-project/pharo/pull/8076 - TestSkip should be TestSkipped #7997 https://github.com/pharo-project/pharo/pull/7997 - Remove unused ivars in DrTest packages #8085 https://github.com/pharo-project/pharo/pull/8085 - Typo in Path class method name delimeter #8048 https://github.com/pharo-project/pharo/pull/8048 - Cleanup Renraku-Help package #8059 https://github.com/pharo-project/pharo/pull/8059 - Mark abstract classes in Renraku #8061 https://github.com/pharo-project/pharo/pull/8061 - RBGenericNodeVisitor-tests #8067 https://github.com/pharo-project/pharo/pull/8067 Pharo 8 ======= - Backport to ease Moose loading #8124 https://github.com/pharo-project/pharo/pull/8124

Dec. 18, 2020

[Pharo 8.0] Build #1143: Backport to ease Moose loading

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1143 was: FAILURE. The Pull Request #8124 was integrated: "Backport to ease Moose loading" Pull request url: https://github.com/pharo-project/pharo/pull/8124 Issue Url: https://github.com/pharo-project/pharo/issues/backport Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2020

MoreVMs 2021 : Workshop on Modern Language Runtimes, Ecosystems, and VMs

by Fabio Niephaus

============================================================================ Call for Extended Abstracts and Talks: MoreVMsâ21 5th International Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with â¹Programmingâºâ21 March 22nd to 26th, 2021, Online, United Kingdom https://2021.programming-conference.org/home/MoreVMs-2021 ============================================================================ Following four previous successful editions, the MoreVMsâ21 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design, and compilation strategies. By bringing together both researchers and practitioners, the workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. In addition to conventional workshop-style submissions, MoreVMs also accepts (and encourages) submissions that present early-stage work and emerging ideas. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- We welcome presentation proposals in the form of extended abstracts (2 to 4 pages long) and talk proposals (title and 400 words abstract) discussing new techniques, insights, experiences, works-in-progress, as well as future visions, from either an academic or industrial perspective. The extended abstracts and talk proposals, and if the speakers wish, their slides, will be published on the workshop's website. Alternatively, extended abstracts can be published as part of the companion of â¹Programmingâºâ21 in the ACM DL. Publication in the ACM DL is conditional on the acceptance by the program committee. Please note that MoreVMsâ21 is organized as an academic workshop, and as such, speakers will be required to register for the workshop. Author Instructions ------------------- Submissions should use the ACM `acmart` format: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions should use the 'acmart' document class with the 'sigconf' option, and with a font size of 9 point. Please use the Libertine/Biolinum font family. Please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. All submissions should be in PDF format. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://easychair.org/conferences/?conf=morevms21 Important Dates --------------- Extended abstract and talk submissions: 2021-01-13 Author notification: 2021-02-15 Camera Ready: 2021-02-26 Workshop: TBA (between 2021-03-22 and 2021-03-26) All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- Maya Armyanova, Google, Germany Maxime Chevalier-Boisvert, UniversitÃ© de MontrÃ©al, Canada Lukas Diekmann, King's College London, United Kingdom Charlie Gracie, Microsoft, Canada Daco Harkes, Google, Denmark Christian Humer, Oracle Labs, Switzerland Sophie Kaleba, University of Kent, United Kingdom Mikel LujÃ¡n, University of Manchester, United Kingdom Ana Milanova, Rensselaer Polytechnic Institute, United States Tobias Pape, Hasso Plattner Institute, University of Potsdam, Germany Tomoharu Ugawa, University of Tokyo, Japan Organizers ---------- Fabio Niephaus, Hasso Plattner Institute, University of Potsdam, Germany David Leopoldseder, Oracle Labs, Austria

Dec. 16, 2020

[ANN] Next Pharo Sprint: Dec 18

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Dec 18 (this Friday). This is a bit earlier due to Christmas times. Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

Dec. 14, 2020

Progress Report -> Refactoring Project - ( December 7 - 11 )

by EVELYN CUSI LOPEZ

Hi everyone, Last week I did these tasks: - Review Commander2, to migrate refactorings to use Commander2 we must create a decorator class using Calypso, now only exists a decorator with Spec2 (SpCommand). - Fix UI rename method issue ( https://github.com/pharo-project/pharo/pull/7978) - Fix undo refactoring issue ( https://github.com/pharo-project/pharo/pull/8051) - Review Refactoring2 - Start to fix Extract method issues. Tasks for this week: - Finish to fix Extract method issues. - Re-visit all the tests to use a classBuilder instead of string as much as possible. - Improve the refactoring model to support traits and slots. - Fix Push up refactoring issue #2656 ( https://github.com/pharo-project/pharo/issues/2656) - Fix Abstract instance variables issue ( https://github.com/pharo-project/pharo/issues/8100) Cheers, Evelyn

Dec. 14, 2020

Re: Call for Beta-testers Pharo ARM64 JIT

by Sven Van Caekenberghe

Hi, This is fantastic news on several levels - the new JIT itself, but even more the new approach, process, infrastructure and tests. (Sorry, but this is a long/techncal mail). A week ago I was one of the first people outside the development team to be able to test the new ARM64 JIT VM on hardware they did not even test on. In particular I used an Amazon AWS EC2 T4g.micro instance (1 GB) with Ubuntu Server 20.04.1 LTS. These machines use an ARM64 CPU (AWS Graviton2, Neoverse N1, Cortex-A76, ARM v8). https://aws.amazon.com/ec2/graviton/ https://aws.amazon.com/ec2/instance-types/t4/ https://en.wikipedia.org/wiki/Annapurna_Labs#AWS_Graviton2 ubuntu@ip-172-30-0-23:~/test$ uname -a Linux ip-172-30-0-23 5.4.0-1030-aws #31-Ubuntu SMP Fri Nov 13 11:42:04 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ip-172-30-0-23:~/test$ lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 1 Model name: Neoverse-N1 Stepping: r3p1 BogoMIPS: 243.75 L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 2 MiB L3 cache: 32 MiB NUMA node0 CPU(s): 0,1 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs My reaction after one hour ? Wow, wow, wow, this is incredible. It all just works and it seems pretty fast as well. I played with the vm/image for a couple of minutes and so far everything worked as expected and I had no crashes at all. The order of magnitude of 1 tinyBenchmarks is very similar to other (server) machines: "'1894542090 bytecodes/sec; 146296146 sends/sec'" "arm64" "'2767567567 bytecodes/sec; 258718969 sends/sec'" "macOS" "'1227082085 bytecodes/sec; 109422120 sends/sec'" "aws" "'2101590559 bytecodes/sec; 166532391 sends/sec'" "t3 lxd" Here is a benchmark in the HTTP space, how fast can ZnServer respond to multiple concurrent requests over the local network: $ ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' & $ ab -k -n 1024 -c 8 http://localhost:1701/small This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /small Document Length: 124 bytes Concurrency Level: 8 Time taken for tests: 0.268 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 317440 bytes HTML transferred: 126976 bytes Requests per second: 3814.45 [#/sec] (mean) Time per request: 2.097 [ms] (mean) Time per request: 0.262 [ms] (mean, across all concurrent requests) Transfer rate: 1154.76 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 19.0 0 267 Waiting: 0 2 19.0 0 267 Total: 0 2 19.0 0 267 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 0 99% 42 100% 267 (longest request) That is 3800 req/s with 8 concurrent threads, each response 124 bytes. And the output document is dynamically generated each time ! Now a cached static binary document, first a small one (64 bytes): $ ab -k -n 1024 -c 8 http://localhost:1701/bytes This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /bytes Document Length: 64 bytes Concurrency Level: 8 Time taken for tests: 0.214 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 256000 bytes HTML transferred: 65536 bytes Requests per second: 4778.62 [#/sec] (mean) Time per request: 1.674 [ms] (mean) Time per request: 0.209 [ms] (mean, across all concurrent requests) Transfer rate: 1166.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 12.3 0 207 Waiting: 0 2 12.3 0 207 Total: 0 2 12.3 0 207 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 5 99% 64 100% 207 (longest request) That is 4700 req/s Now a larger one, 1024 bytes: $ ab -k -n 1024 -c 8 http://localhost:1701/bytes/1024 This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /bytes/1024 Document Length: 1024 bytes Concurrency Level: 8 Time taken for tests: 0.228 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 1241088 bytes HTML transferred: 1048576 bytes Requests per second: 4484.93 [#/sec] (mean) Time per request: 1.784 [ms] (mean) Time per request: 0.223 [ms] (mean, across all concurrent requests) Transfer rate: 5308.34 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 16.2 0 227 Waiting: 0 2 16.2 0 227 Total: 0 2 16.2 0 227 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 0 99% 41 100% 227 (longest request) Still 4400 req/s - 1024 requests finished in about 0.25 seconds, transferring 1Mb. These are really good numbers ! Of course, with an actual network between the client and the server, the numbers are much lower, but this localhost benchmark gives you an idea of the maximum speed that is theoretically possible. And under this load, the image+vm remained totally stable. Since then I started a public Zn HTTP server, Pharo 9 live on an ARM64 JIT VM: http://34.245.183.130:1701 http://34.245.183.130:1701/status http://34.245.183.130:1701/help I want to see how long it keeps running. You can test this for yourself. Idle load of the VM is also excellent: 0.3% CPU. Overall machine load is 0.00 ! I fiddled around a bit more the next day. Everything kept on going smooth, nothing unexpected happened. I could use the command line tools to save a new image, load several of my packages using metacello from github using a baseline and tonel, I could run all test suites just fine. Everything was just *fast*. I installed NeoConsole so that I could use telnet to get a REPL into a running image. A week later, the server Pharo image was still running fine. In summary: Great, great work and thanks again everyone for the effort. You (in particular Pablo, Guille, Esteban and the whole Pharo community) can be very proud of this achievement. Sven > On 12 Dec 2020, at 17:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Dear happy Pharoers and others, > > Over the last months we have been working on the implementation of a MIT-licensed ARMv8 Just-In-Time compiler for Pharo VM. > We are very happy with the advance on this subject, as we have not only implemented a new backend but we have added more than 2500 > tests to the JIT, the primitives, code generation, plugins and the VM in general. In the process we fixed many problems. > It shows that following the roadmap that was decided during General assembly of PharoDays, we have been investing in the Pharo VM and that > our efforts are greatly paying off. > Also, we are generating a lot of documentation and improving the process to really democratize the development of the VM. > So Pharo is a better shape than ever on such matter and this opens a lot of possibility for the future. > > ## Call for Beta-Testers > > We would like to announce that a first version of our JIT backend is available for beta-testing for ARM Linux machines using Ubuntu. > We are now entering into a beta testing stage of the VM and the image in Ubuntu ARM 64. > We would like to invite you to our beta testing phase for the VM. If you're interested in participating, > please contact pablo.tesone(a)inria.fr. > > The following sections give more details of the current status, and the following steps including Apple Silicon, Windows ARM64 and Linux Open Build System support. > > ## Current Status > > Our objective is to have a running JIT for the new aarch64 architecture (ARM 64bits). This task includes not only a new backend for the JIT compiler but also adding support for external libraries, dependencies and the build process. > This means having a working VM with comparable features as the one existing in Intel X64. We are targeting all the major operating systems running in this platform (Linux, OSX, Windows). > Each of them present different restrictions and conditions. > > This is the current status: > > - We implemented a full backend for the JIT compiler targeting aarch64. > - All the image side was adapted to run on it, tested on Ubuntu ARM 64 bits. > - We added support for: Iceberg (Libgit) / Athens (Cairo) / SDL / GTK > - We implemented a LibFFI-based FFI backend as the default one for Pharo 9 in aarch64 (next to come in all platforms). > This opens the door to ease port the features to other platforms and OSes. > > ## Following Steps and Open Betas: Linux Open Build System (OBS), Windows ARM64 and Apple Silicon > > Linux Systems: In the following days, we will also support Raspbian (Debian) and Manjaro on ARM64. For doing so, we are pushing the last details in having a single Linux build system through OBS. So, if you want to start doing beta-testing of these versions please contact us. A public beta will be open in around two weeks. > > Windows Systems: We have extended the build process to fully support Microsoft Visual Studio compilers and more flexibility to select the targets, also we are building it to run in Windows ARM. To correctly run the VM in Windows it is needed to build all dependencies for aarch64. In the following weeks, we expect to have a working Non-JIT version and a JIT version. The remaining points to have a JIT version are related with the build process as the API of the operating system has not changed from X64 to aarch64. > > OSX Systems: Our third target is to have a working version for the newest Apple silicon. We are acquiring the corresponding hardware to test and to address the differences in the API exposed to JIT applications. As it is the case of the Windows VM, there is not need to change the machine code generation backend; but to compile external libraries, and particularities of the new OS version. > > Thanks for your support, and again, if you like to start beta testing the VM please contact us. In the meantime, we will continue giving you news about the current state and where are we going. > > The consortium would like to particularly thank Schmidt Buro and Lifeware for their contracts. > > Regards, > > Pablo in behalf of the Pharo Consortium Engineers > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Dec. 13, 2020

Call for Beta-testers Pharo ARM64 JIT

by StÃ©phane Ducasse

Dear happy Pharoers and others, Over the last months we have been working on the implementation of a MIT-licensed ARMv8 Just-In-Time compiler for Pharo VM. We are very happy with the advance on this subject, as we have not only implemented a new backend but we have added more than 2500 tests to the JIT, the primitives, code generation, plugins and the VM in general. In the process we fixed many problems. It shows that following the roadmap that was decided during General assembly of PharoDays, we have been investing in the Pharo VM and that our efforts are greatly paying off. Also, we are generating a lot of documentation and improving the process to really democratize the development of the VM. So Pharo is a better shape than ever on such matter and this opens a lot of possibility for the future. ## Call for Beta-Testers We would like to announce that a first version of our JIT backend is available for beta-testing for ARM Linux machines using Ubuntu. We are now entering into a beta testing stage of the VM and the image in Ubuntu ARM 64. We would like to invite you to our beta testing phase for the VM. If you're interested in participating, please contact pablo.tesone(a)inria.fr. The following sections give more details of the current status, and the following steps including Apple Silicon, Windows ARM64 and Linux Open Build System support. ## Current Status Our objective is to have a running JIT for the new aarch64 architecture (ARM 64bits). This task includes not only a new backend for the JIT compiler but also adding support for external libraries, dependencies and the build process. This means having a working VM with comparable features as the one existing in Intel X64. We are targeting all the major operating systems running in this platform (Linux, OSX, Windows). Each of them present different restrictions and conditions. This is the current status: - We implemented a full backend for the JIT compiler targeting aarch64. - All the image side was adapted to run on it, tested on Ubuntu ARM 64 bits. - We added support for: Iceberg (Libgit) / Athens (Cairo) / SDL / GTK - We implemented a LibFFI-based FFI backend as the default one for Pharo 9 in aarch64 (next to come in all platforms). This opens the door to ease port the features to other platforms and OSes. ## Following Steps and Open Betas: Linux Open Build System (OBS), Windows ARM64 and Apple Silicon Linux Systems: In the following days, we will also support Raspbian (Debian) and Manjaro on ARM64. For doing so, we are pushing the last details in having a single Linux build system through OBS. So, if you want to start doing beta-testing of these versions please contact us. A public beta will be open in around two weeks. Windows Systems: We have extended the build process to fully support Microsoft Visual Studio compilers and more flexibility to select the targets, also we are building it to run in Windows ARM. To correctly run the VM in Windows it is needed to build all dependencies for aarch64. In the following weeks, we expect to have a working Non-JIT version and a JIT version. The remaining points to have a JIT version are related with the build process as the API of the operating system has not changed from X64 to aarch64. OSX Systems: Our third target is to have a working version for the newest Apple silicon. We are acquiring the corresponding hardware to test and to address the differences in the API exposed to JIT applications. As it is the case of the Windows VM, there is not need to change the machine code generation backend; but to compile external libraries, and particularities of the new OS version. Thanks for your support, and again, if you like to start beta testing the VM please contact us. In the meantime, we will continue giving you news about the current state and where are we going. The consortium would like to particularly thank Schmidt Buro and Lifeware for their contracts. Regards, Pablo in behalf of the Pharo Consortium Engineers -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 12, 2020

This week (50/2020) on the Issue Tracker

by Marcus Denker

Another week with ~50 merged pull requests. Class Definitions ================== Mostly stabilizing the last changes... - Class>>#asRingDefinition should not send #definition but #definitionString #8024 https://github.com/pharo-project/pharo/pull/8024 - ReSearchStringSourceAnchor>>#interval should not use deprecated #definition #8022 https://github.com/pharo-project/pharo/pull/8022 - 7980-fix-checkClassRebuild #7982 https://github.com/pharo-project/pharo/pull/7982 - Move old definition printing to a the legacy printer #7894 https://github.com/pharo-project/pharo/pull/7894 Halt Cleanup ============= Finished: we now have a release test. There can never be a #halt left without the test failing. - 7925-halt-left-in-FFIFunctionParsersetOn #7932 https://github.com/pharo-project/pharo/pull/7932 - 7928-halt-left-in-FBDDecompilerpushFullClosurenumCopiedreceiverOnStackignoreOuterContext #7970 https://github.com/pharo-project/pharo/pull/7970 - 7975-ReleaseTesttestMethodsContainNoHalt #7977 https://github.com/pharo-project/pharo/pull/7977 - "Browse Breakpoints" should not show implementation methods #7969 https://github.com/pharo-project/pharo/pull/7969 Fixes ===== - Lazily file open in Zip archive #7999 https://github.com/pharo-project/pharo/pull/7999 - 8037-Scrolling-messages-leads-to-red-square-of-death #8039 https://github.com/pharo-project/pharo/pull/8039 - Fixed #8014. Renamed Random >> nextInt: and nextIntBetween:and: to nextInteger: and nextIntegerBetween:and: #8021 https://github.com/pharo-project/pharo/pull/8021 - Fix win32 library name for freetype #7778 https://github.com/pharo-project/pharo/pull/7778 - 7966-Temporary-Variables-Cannot-be-used-in-loops-in-a-playground #7983 https://github.com/pharo-project/pharo/pull/7983 - Only concrete Font descriptions should be installable #7986 https://github.com/pharo-project/pharo/pull/7986 - Fixed #7612. The bug that happened when an IntegerArray was added to a FloatArray #7622 https://github.com/pharo-project/pharo/pull/7622 - Fixed #7937. Implemented Random>>nextBetween:and:, nextIntBetween:and:, and wrote tests for them #7938 https://github.com/pharo-project/pharo/pull/7938 - 7956-Completion-broken-in-Transcript #7958 https://github.com/pharo-project/pharo/pull/7958 - fixing-FFIBackend-initialization #7973 https://github.com/pharo-project/pharo/pull/7973 - Fixing mem leak after debugger proceeding #7992 https://github.com/pharo-project/pharo/pull/7992 - 7953 huge debugger st pharo application memory leak #7976 https://github.com/pharo-project/pharo/pull/7976 - 8005-ClassHierarchyPrinter-glitches #8012 https://github.com/pharo-project/pharo/pull/8012 - 8001-Improving-ClassHierarchyPrinter #8003 https://github.com/pharo-project/pharo/pull/8003 - tagsForClasses #8008 https://github.com/pharo-project/pharo/pull/8008 - add Trait>>#isUsed. #7981 https://github.com/pharo-project/pharo/pull/7981 Refactoring ============ Work has begun to check (and fix) refactorings. More to come. - Review refactorings #7965 https://github.com/pharo-project/pharo/pull/7965 - Fix rename refactoring issue - 7947 #7978 https://github.com/pharo-project/pharo/pull/7978 AST Improvements / Cleanups ============================ The visitor now calls #visitGlobalVariableNode:, visitClassVariableNode:, if you inherit (or use the trait) the change is backward compatible (it makes sure to call the same methods as before). - AST-add-more-Variable-visit-methods #7929 https://github.com/pharo-project/pharo/pull/7929 - TRBProgramNodeVisitor-methods-missing #7962 https://github.com/pharo-project/pharo/pull/7962 - AST-Cleanup-visitUnreachableStatement #7951 https://github.com/pharo-project/pharo/pull/7951 - CoTypeInferencer should inherit from RBProgramNodeVisitor #8040 https://github.com/pharo-project/pharo/pull/8040 - 7993-Completion-broken-while-editing #7998 https://github.com/pharo-project/pharo/pull/7998 Cleanups and improvements Code Critique ====================== - ReSendsUnknownMessageToGlobalRule laments wrongly on class variables #8031 https://github.com/pharo-project/pharo/pull/8031 - Mark abstract test classes in Renraku-Tests #8029 https://github.com/pharo-project/pharo/pull/8029 - Cleanup ReAbstractRule #8057 https://github.com/pharo-project/pharo/pull/8057 - Clean selector casing in Renraku #8063 https://github.com/pharo-project/pharo/pull/8063 - Add script pragmas to CriticBrowser #8035 https://github.com/pharo-project/pharo/pull/8035 - Simplify-ReUnaryAccessingMethodWithoutReturnRule #7839 https://github.com/pharo-project/pharo/pull/7839 Dead Code ========= - Gofer-UI package should be removed in Pharo 9 #8027 https://github.com/pharo-project/pharo/pull/8027 - Deprecate leadingChar and old encoders. #7892 https://github.com/pharo-project/pharo/pull/7892 - remove-unused-charScannerPrimitive #7884 https://github.com/pharo-project/pharo/pull/7884 - Cleanup-EncoderForV3PlusClosures #7972 https://github.com/pharo-project/pharo/pull/7972 - Remove unused lastKeyboardFocus ivare from OSSDL2BackendWindow #7946 https://github.com/pharo-project/pharo/pull/7946 Other Cleanups ============== - ReSourceAnchor typo in class comment #8066 https://github.com/pharo-project/pharo/pull/8066 - Tag uncategorized classes in package Morphic-Widgets-Tabs #8015 https://github.com/pharo-project/pharo/pull/8015 - EpApplyPreviewerTest calls deprecated method #8007 https://github.com/pharo-project/pharo/pull/8007 - HDTestCoverage and HDCoverageReport use obsolete actualClass #7991 https://github.com/pharo-project/pharo/pull/7991 - fixes #7924: Enhance CodeImporter with better comment #7988 https://github.com/pharo-project/pharo/pull/7988

Dec. 11, 2020

Re: Pharo 8 Image blows up after restart

by Guillermo Polito

Cool :) Glad to help > El 9 dic 2020, a las 10:46, Sabine Manaa <manaa.sabine(a)gmail.com> escribiÃ³: > > Hi Eliot, hi Guille, > > you saved my day! > > starting from command line and killing with SIGUSR1 showed the stack below. > > Starting the image without mongoservice running avoids the blowup. > > Then, saving the image, starting mongoservice again and then I can proceed > using the image. > > I don't know yet why I get the > MongoWireProtocolError(MongoNativeError)>messageText but I have a point > where I can start seaching. > > Thanks a lot > Sabine > > > > > SIGUSR1 Wed Dec 9 09:51:45 2020 > > > VM: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git > Date: Wed Feb 12 11:07:12 2020 CommitHash: 2bd9e39 > Plugins: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git > > C stack backtrace & registers: > rax 0x00000001107d28f0 rbx 0x0000000000000003 rcx 0x0000000000000000 rdx > 0x0000000000000008 > rdi 0x00000003351a4690 rsi 0x00000003351a4690 rbp 0x00007ffeea61f050 rsp > 0x00007ffeea61f020 > r8 0x00ffffffffffffff r9 0x0000000000000001 r10 0x00000003351a4698 r11 > 0x000000022b0c8fc8 > r12 0x00000003351a45d8 r13 0x0000000000000001 r14 0x0000000000000000 r15 > 0x0000000000000006 > rip 0x00000001055f9862 > 0 Pharo 0x00000001055f9862 > scavengeReferentsOf + 277 > 1 Pharo 0x00000001056392da reportStackState > + 952 > 2 Pharo 0x00000001056394f8 sigusr1 + 182 > 3 libsystem_platform.dylib 0x00007fff725995fd _sigtramp + 29 > 4 ??? 0x00000000c0000000 0x0 + 3221225472 > 5 Pharo 0x00000001055d5eea doScavenge + 542 > 6 Pharo 0x00000001055de05e > scavengingGCTenuringIf + 333 > 7 Pharo 0x00000001055c163a > checkForEventsMayContextSwitch + 111 > 8 Pharo 0x00000001055c5815 ceStackOverflow + > 110 > 9 ??? 0x0000000109cca53b 0x0 + 4459373883 > 10 Pharo 0x00000001055adb0a interpret + 632 > 11 Pharo 0x000000010563aa62 > -[sqSqueakMainApplication runSqueak] + 393 > 12 Foundation 0x00007fff3aac429b > __NSFirePerformWithOrder + 360 > 13 CoreFoundation 0x00007fff38330335 > __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 > 14 CoreFoundation 0x00007fff38330267 > __CFRunLoopDoObservers + 457 > 15 CoreFoundation 0x00007fff3832f805 __CFRunLoopRun + > 874 > 16 CoreFoundation 0x00007fff3832ee3e > CFRunLoopRunSpecific + 462 > 17 HIToolbox 0x00007fff36f5babd > RunCurrentEventLoopInMode + 292 > 18 HIToolbox 0x00007fff36f5b6f4 > ReceiveNextEventCommon + 359 > 19 HIToolbox 0x00007fff36f5b579 > _BlockUntilNextEventMatchingListInModeWithFilter + 64 > 20 AppKit 0x00007fff355a1039 _DPSNextEvent + > 883 > 21 AppKit 0x00007fff3559f880 > -[NSApplication(NSEvent) > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 > 22 AppKit 0x00007fff3559158e -[NSApplication > run] + 658 > 23 AppKit 0x00007fff35563396 NSApplicationMain > + 777 > 24 libdyld.dylib 0x00007fff723a0cc9 start + 1 > 25 ??? 0x0000000000000002 0x0 + 2 > > > All Smalltalk process stacks (active first): > Process 0x120172de8 priority 20 > 0x7ffeea630130 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63d980 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63d9b0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63d9e0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63da10 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63da40 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63da70 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63daa0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dad0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63db00 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63db30 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63db60 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63db90 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dbc0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dbf0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dc20 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dc50 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dc80 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dcb0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dce0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dd10 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > > (repeat 100.000 times).... > 0x1196a9fa8 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa060 s MongoWireProtocolError>errorMessage > 0x1196aa118 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa1d0 s MongoWireProtocolError>errorMessage > 0x1196aa288 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa340 s [] in MongoWireProtocolError(Exception)>description > 0x1196aa3f8 s String class(SequenceableCollection > class)>new:streamContents: > 0x1196aa4b0 s String class(SequenceableCollection > class)>streamContents: > 0x1196aa568 s MongoWireProtocolError(Exception)>description > 0x1196aa620 s MongoWireProtocolError(Exception)>debug > 0x1196aa6d8 s MorphicUIManager>unhandledErrorDefaultAction: > 0x1196aa790 s UnhandledError>defaultAction > 0x1196aa848 s UndefinedObject>handleSignal: > 0x1196aa900 s Context>handleSignal: > 0x1196aa9b8 s UnhandledError(Exception)>signal > 0x1196aaa70 s UnhandledError class>signalForException: > 0x1196aab28 s MongoWireProtocolError(Error)>defaultAction > 0x1196aabe0 s UndefinedObject>handleSignal: > 0x1196aac98 s Context>handleSignal: > 0x119b91af8 s MongoWireProtocolError(Exception)>signal > 0x119b91d20 s MongoWireProtocolError(Exception)>signal: > 0x119b91f48 s MongoWireProtocolError class(Exception class)>signal: > 0x119b91988 s MongoCursor>execute > 0x119b91c68 s Mongo>queryOne: > 0x119b91e90 s Mongo>command:database:flags: > 0x119b920b8 s Mongo>command:database: > 0x119b92228 s [] in > SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: > 0x119b91a40 s BlockClosure>on:do: > 0x120221980 s > SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: > 0x120221c48 s > SCRAMSHA1AuthMechanism(MongoAuthMechanism)>authenticateUsername:password:database: > 0x120222010 s Mongo>authenticateUsername:password:database: > 0x120222300 s RKARepositoryManager class>authenticateAdminRepository > 0x120223688 s RKARepositoryManager class>databaseNames > 0x120223988 s RKARepositoryManager class>customerDatabaseNames > 0x120223be8 s RKAMailSender class>sendReminderMails > 0x120223d88 s [] in RKAScheduler class>newReminderMailsScheduler > 0x12043fac0 s [] in ScheduledTask>run > 0x120442d98 s BlockClosure>ensure: > 0x120445d90 s [] in ScheduledTask>run > 0x120448eb0 s [] in BlockClosure>newProcess > > processes at priority 10 > Process 0x1191f2220 priority 10 > 0x1201735e8 s ProcessorScheduler class>idleProcess > 0x1201879e8 s [] in ProcessorScheduler class>startUp > 0x1191f7d80 s [] in BlockClosure>newProcess > > Process 0x119f75ed0 priority 10 > 0x12eaa4228 s [] in BlockClosure>newProcess > > Process 0x181024e98 priority 10 > 0x1810253c8 s [] in BlockClosure>newProcess > > Process 0x1d5a8e568 priority 10 > 0x1d5a8f020 s [] in BlockClosure>newProcess > > Process 0x17eaa3c78 priority 10 > 0x1f23c8698 s [] in BlockClosure>newProcess > > Process 0x2111a5f20 priority 10 > 0x2111a6320 s [] in BlockClosure>newProcess > > Process 0x2590f8cd8 priority 10 > 0x2590faa98 s [] in BlockClosure>newProcess > > Process 0x279aadfa0 priority 10 > 0x27ac91450 s [] in BlockClosure>newProcess > > Process 0x2b6261ee0 priority 10 > 0x2b62624f0 s [] in BlockClosure>newProcess > > Process 0x2de054360 priority 10 > 0x2de0549b0 s [] in BlockClosure>newProcess > > Process 0x29eb28580 priority 10 > 0x2fcdffb28 s [] in BlockClosure>newProcess > > Process 0x31b7dfa68 priority 10 > 0x31b7e05d0 s [] in BlockClosure>newProcess > > suspended processes > Process 0x1191f2cb0 priority 50 > 0x1191f8af0 s WeakArray class>finalizationProcess > 0x120173ea0 s [] in WeakArray class>restartFinalizationProcess > 0x119ed8b78 s [] in BlockClosure>newProcess > > Process 0x10cd52ed0 priority 80 > 0x109f28000 s DelayMicrosecondTicker>waitForUserSignalled:orExpired: > 0x10da04408 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x10da04620 s BlockClosure>ensure: > 0x10ce7e868 s > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x10da04350 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x10ce7e940 s [] in BlockClosure>newProcess > > Process 0x1121775c0 priority 31 > 0x118db5a88 s AtomicSharedQueue>waitForNewItems > 0x118e51048 s AtomicSharedQueue>next > 0x119196820 s [] in ClyDataSourceUpdateScheduler>processQueue > 0x112187878 s BlockClosure>repeat > 0x11217e940 s ClyDataSourceUpdateScheduler>processQueue > 0x1121877c0 s [] in ClyDataSourceUpdateScheduler>ensureRunning > 0x11217ea18 s [] in BlockClosure>newProcess > > Process 0x1191f21d0 priority 60 > 0x1191f7cc8 s SmalltalkImage>lowSpaceWatcher > 0x120173d30 s [] in SmalltalkImage>installLowSpaceWatcher > 0x119ed8100 s [] in BlockClosure>newProcess > > Process 0x1191f2998 priority 40 > 0x326d25100 s [] in DelayWaitTimeout>wait > 0x327434bf0 s BlockClosure>ensure: > 0x326d258b8 s DelayWaitTimeout>wait > 0x327435268 s Semaphore>waitTimeoutMSecs: > 0x3274355e0 s [] in UnixOSProcessAccessor>grimReaperProcess > 0x120204400 s BlockClosure>repeat > 0x119ed8cb0 s [] in UnixOSProcessAccessor>grimReaperProcess > 0x119ed8d98 s [] in BlockClosure>newProcess > > Process 0x1191f3120 priority 60 > 0x1408b30d0 s InputEventFetcher>waitForInput > 0x120174528 s InputEventFetcher>eventLoop > 0x12018b9e8 s [] in InputEventFetcher>installEventLoop > 0x119ed8a50 s [] in BlockClosure>newProcess > > Process 0x1191f3030 priority 70 > 0x1191f9070 s [] in DelayWaitTimeout>wait > 0x120173998 s BlockClosure>ensure: > 0x119e57648 s DelayWaitTimeout>wait > 0x120173a50 s Semaphore>waitTimeoutMSecs: > 0x12018adb0 s Socket>waitForConnectionFor:ifTimedOut: > 0x119ed84b8 s Socket>waitForAcceptFor:ifTimedOut: > 0x119ed8590 s Socket>waitForAcceptFor: > 0x120173b08 s > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>serveConnectionsOn: > 0x12018ae68 s [] in > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x12019a808 s BlockClosure>repeat > 0x119ed8668 s [] in > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x120173bc0 s BlockClosure>ifCurtailed: > 0x119ed8760 s > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x120173c78 s [] in > ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start > 0x12018af20 s BlockClosure>repeat > 0x119ed8838 s [] in > ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start > 0x119ed8910 s [] in BlockClosure>newProcess > > Process 0x1191f27c8 priority 70 > 0x109f280b8 s [] in Delay>wait > 0x109f2cbc8 s BlockClosure>ifCurtailed: > 0x109f2cf40 s Delay>wait > 0x109f2d260 s [] in OSSVMProcess>initializeChildWatcher > 0x12021cd08 s BlockClosure>repeat > 0x119ed82b8 s [] in OSSVMProcess>initializeChildWatcher > 0x119ed8398 s [] in BlockClosure>newProcess > > Most recent primitives > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > stack page bytes 4096 available headroom 1480 minimum unused headroom 848 > > (SIGUSR1) > bash: line 1: 29529 Terminated: 15 > "/Users/sabine/Documents/Pharo/vms/80-x64/Pharo.app/Contents/MacOS/Pharo" > "/Users/sabine/Documents/Pharo/images/Pharo 8.0 - 64bit (15)/Pharo 8.0 - > 64bit (15).image" > Sabines-MBP:~ sabine$ > . > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2020