- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #155: 2975-Problem-when-you-read-an-mcz-pharo7
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #155 was: SUCCESS. The Pull Request #3160 was integrated: "2975-Problem-when-you-read-an-mcz-pharo7" Pull request url: https://github.com/pharo-project/pharo/pull/3160 Issue Url: https://pharo.fogbugz.com/f/cases/2975 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #218: Added comments to class ExceptionTests and ExceptionTester
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #218 was: FAILURE. The Pull Request #3162 was integrated: "Added comments to class ExceptionTests and ExceptionTester" Pull request url: https://github.com/pharo-project/pharo/pull/3162 Issue Url: https://github.com/pharo-project/pharo/issues/3161 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

New stable VM for Pharo8?
by Guillermo Polito April 11, 2019

April 11, 2019

Hi all, Esteban, In the last sprint with Pablo and Pierre we have detected several misbehaviours with files. The issue was particular reproducible when trying to run iceberg tests: the VM kind of ran out of slots for opening files. The strangest thing is that the leaks seemed to happen when deleting directories, so we had a look at the changes done to iterate directories, get file attributes and so on. While on the FileReference code everything seemed ok, we have observerd with `lsof` that still several directories remained open even after deleting them. Latest VM fixes this issue but contains another one related to Metal rendering, which prevents rendering in OSX versions < than High Sierra. Tracking the issue a bit, this seems to be a bug in the FileAttributes plugin that was fixed by this PR by alistair ( https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc2… ). We have tested that particular commit ( a838346b1a67712cc28298534dafbd0c26ea34fb <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc2…>) and this one contains Alistair's fixes but not yet the new rendering using Metal. We have been testing that VM since yesterday and it seems stable, what do you think about marking it stable for Pharo8? Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it contains the same issue. However, since on the image side the code does not use the problematic primitives, we do not think we need to change the VM for Pharo7 (yet). However, there is seemingly a fix for directories containing blanks, maybe Alistair can give us some input here? :) Ideas? Thanks, Guille and Pablo

5 12

FreeType and the over amorous glyphs (overlapping)
by tesonep＠gmail.com April 11, 2019

April 11, 2019

Hello, After checking the problem with Guille, we have the hypothesis of the source of the problem. We have seen that accessing Free Type is not thread-safe. Basically, the FTFace holds a structure that is filled up with the glyph and its information. As this structure is part of the Font Face (a font face is a font plus size and attributes), only one request to a glyph can be executed at the time. As we are sharing the same font in many places, you will be starting to see the problem. Also, we have seen that there many accesses to the glyphs outside the UI process. This problem started to appear as we starting to use Calypso (but it is not limited to it), as Calypso uses lazy tabs. The creation of these tabs is done outside the UI process. This is only a hack to test our hypothesis. To fix it correctly we will have to rewrite the drawing of the glyphs and synchronize the access to the glyph data information. Also, we want to do it in a way that does not penalize the processing in the UI process. I have only patched the code that is used by the rendering of morphic, other renderings like Athens or any other user using FT should be correctly rewritten. Once we are sure that synchronizing the access to FT fixes the problem, we will do a real fix not a dirty hack like this. I will be testing this new Image to see if there is an improvement. I will really love you try to use this image and tell me if you still find the problem. There is a PR generating a Pharo8 image (it is called wrong, but... it is a Pharo8) 32 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 64 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… If somebody is willing to use it in Pharo 7, I can create a PR against Pharo7 to generate patched P7 images. Thanks! -- Pablo Tesone. tesonep(a)gmail.com

6 10

[Pharo 8.0] Build #217: 3006-When-a-test-fails-open-the-debugger-on-the-test-instead-of-on-Objectassert
by ci-pharo-ci-jenkins2＠inria.fr April 10, 2019

April 10, 2019

There is a new Pharo build available! The status of the build #217 was: SUCCESS. The Pull Request #3116 was integrated: "3006-When-a-test-fails-open-the-debugger-on-the-test-instead-of-on-Objectassert" Pull request url: https://github.com/pharo-project/pharo/pull/3116 Issue Url: https://github.com/pharo-project/pharo/issues/3108 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #216: 3140-Fixing-all-executable-comments
by ci-pharo-ci-jenkins2＠inria.fr April 10, 2019

April 10, 2019

There is a new Pharo build available! The status of the build #216 was: FAILURE. The Pull Request #3141 was integrated: "3140-Fixing-all-executable-comments" Pull request url: https://github.com/pharo-project/pharo/pull/3141 Issue Url: https://github.com/pharo-project/pharo/issues/3140 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?
by Mariano Martinez Peck April 10, 2019

April 10, 2019

On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi, I'd like to play around with pharo on ARM devices (like a > HummingBoard, the ones from ODROID or one of the beagleboards). But I am > not sure if I have to take care of the ARM architecture version (ARMv6 / > ARMv7 / ARMv8) when choosing my toy. > > I found this vm: > http://files.pharo.org/vm/pharo-spur32/linux/armv6/ > Is it only for armv6 like the folder name says or is ARMv7 and ARMv8 > working too? > > Are there any limitations I should know before choosing a ARM device? > > Is there a vm for 64bit (aarch64)? > Hi Albrecht, I am also interested in this answer. In general, I am interested in IoT support for Smalltalk. The only thing I found aside from ARMv6 is this: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM… But I don't know what's the status of it. You may have more chances to get an answer with the vm list: <vm-dev(a)lists.squeakfoundation.org> Or maybe Pharo dev list. Cheers, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

2 1

Performance Issues
by tesonep＠gmail.com April 9, 2019

April 9, 2019

Hi, this will be a long mail. I have organized it in different sections. Resume: ====== - There are performance issues in Pharo 7. - I have made benchmarks. - With Guille we made an improvement in saving source code in methods. - More improvements to come. - Automation and CI in the future. Background ========= Since the release of Pharo 7 (and before it), it was notorious that there exists a performance regression in the normal execution of the image. By checking the usual operations, we have seen ( and many have also detected) that there was an issue with the loading, compilation, and unloading of code. Also with the creation of classes, traits and the use of slots. Benchmarks ========= Although we were sure that there is a performance regression, we have to show it in a way we can test it and measure it. If we cannot measure it or repeat its execution it is worthless. For doing so, I have created an initial set of micro-benchmarks to cover normal operations of the image. The set of benchmarks is available here: https://github.com/tesonep/pharo-benchmarks These benchmarks are developed on top of SMark, only adding a command line tool and the ability to generate a CSV file. The idea is to run the benchmarks in different versions of Pharo an assert that we are not breaking anything. The first results were basically a nightmare, some operations take almost 20 times more in Pharo 7. Especially, the ones that are compiling methods. In the attached document, there is the detail of all the benchmarks, the different results and the analysis of the improvements and regressions (Positive percentages are regressions (more time), negative are improvements (less time)). I have checked the results in OSX with 64 bits images. But as the problem is in pure Smalltalk implementations the problems are (and the solutions) cross platforms. First Improvement ============== Having the benchmarks, it was easy to start looking for the problems. Thanks to the help of Guille we have detected some problems in the implementation of SourceFile. Objects of this class have the responsibility to handle the save of the source code when a method is modified. Improving this implementation we have gotten to results similar to Pharo 6 in the compilation of methods. Comparing a stock Pharo8 image with the one with the fix, we have the following improvements: AddingAnInstanceVariableToAClassWithASubclass -3.96% AddingAnInstanceVariableToAClassWithoutASubclassAndInstances -15.91% AddingAnInstanceVariableToAClassWithoutSubclasses -28.50% ClassAndSubclassCreation -25.67% ClassUsingATrait -90.05% SimpleClassCreation -26.55% TraitCreation -92.95% TraitCreationUsingOtherTrait -91.68% CompileAMethodAndModifyIt -32.92% CompileAMethodInAClassUsingATrait -83.28% CompileAMethodInATraitNotUsed -85.12% CompileAMethodInATraitUsed -88.16% CompileANewMethod -40.73% CompileANewMethodUsingInstanceVariable -33.93% MethodAccessingAGlobal -47.57% Again there are more details in the attached file. Also, we have ported this fix to Pharo 7. Next Steps ======== - Making it a part of the CI infrastructure: making it run in each PR and build to detect regressions in the changes. - Adding more micro and macro benchmarks. I have a list of things to test, but I am open to more: # Micro - Slot Implementation - Process handling - Refactorings - Files (open / write / read) # Macro - Loading: Moose / Seaside - Recompile All - Condense Sources - Startup - Shutdown We also know that there are platform related issues (especially Windows), so the idea it will be the same, build a benchmark, measure it, improve it. The idea is to have a more robust way of detecting and handling the performance of Pharo. Of course, I am open to all your comments. Cheers, Pablo

9 9

IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows
by Torsten Bergmann April 4, 2019

April 4, 2019

Hi, Windows users of Pharo have been hit by an Iceberg error "IceGenericError: failed to stat file ... The filename or extension is too long" as seen in attached screenshot (for instance when loading Seaside from the original SeasideSt/Seaside master branch). Initially the long filename (who make trouble on Windows according to the message) were blamed - and it was suggested to have Seaside (or other projects) in Tonel format. Johan wanted to try this - but initially it was not possible as Esteban had to provide a fix for the Tonel converter first. This is now available. Following this fix today Johan provided a "tonel" branch of Seaside to check. Roelof Wobben and Mike Davis tried with me on Discord a few combinations and it seems there is a different cause. It seems to be more related to having the image or image path including spaces AND dots. So for instance Pharo Launcher suggests the download of Pharo 7 from the official distribution to be named "Pharo 7.0 - 32bit (stable)". When you just accept the name the Pharo Launcher suggests then you may hit the problem. When you start such an image and try to load the FileTree (master) or Tonel version (tonel branch) of Seaside using Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load or Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:tonel/repository'; load you will get the error. If you use "Foo" as the name for image it seems to work. Requires some more testing but I guess it is related to the naming in Pharo Launcher with "dots" AND "spaces" instead of the long filenames. "pharo 7.0 (stable)" fails "seaside.test" works "seaside test" works also "seaside. test" works also "seaside-test" works also "seaside(test)" works also Maybe more people can try other combinations on their Windows machines too. If our finding is true it would be good if Laucher on Windows could nuke the dot/space combinations for instance by using underlines. Thanks T. (aka astares)

3 3

[Pharo 8.0] Build #215: 3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size
by ci-pharo-ci-jenkins2＠inria.fr April 4, 2019

April 4, 2019

There is a new Pharo build available! The status of the build #215 was: SUCCESS. The Pull Request #3052 was integrated: "3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size" Pull request url: https://github.com/pharo-project/pharo/pull/3052 Issue Url: https://github.com/pharo-project/pharo/issues/3049 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0