April 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New stable VM for Pharo8?

by Alistair Grant

Hi Guille, On Tue, 2 Apr 2019 at 13:40, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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) 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? :) Cyril has already reported this issue in Pharo 8, so I agree that an updated VM for Pharo 8 would be nice. As you say, this doesn't affect Pharo 7 (or earlier). There is another, similar, issue that does affect Pharo 7 and earlier: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 which is resolved by: commit e9fee6facb61c1163e820673bd8734b59a831535 Author: AlistairGrant <akgrant0710(a)gmail.com> Date: Wed Feb 6 08:23:32 2019 +0100 FilePlugin: reopen the directory when jumping around In dir_Lookup, when jumping around, i.e. index ~= lastIndex+1, reopen the directory rather than rewinding. This is required as the open directory caches entries (at least with CIFS mounted file system), and if files are deleted between calls the wrong answer will be returned. Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 This issue doesn't affect Pharo 8 since dir_Lookup() isn't used anymore. I'm only aware of this being reported once, and the issue has probably been there since 2010, or maybe even earlier. It is worthwhile being aware of it, but probably not enough to force a new VM for Pharo 7 immediately. Cheers, Alistair

April 2, 2019

Re: [Pharo-dev] New stable VM for Pharo8?

by Guillermo Polito

On Tue, Apr 2, 2019 at 2:11 PM ducasse <stepharo(a)netcourrier.com> wrote: > Thanks guille and pablo for you dedication for Pharo, I love you :) > > Now just that I understand, does it mean that the latest open smalltalk vm > does not run on anything else that Mojave and High Sierra? > I don't know exactly on what versions it is not working because I have Windows10 and Mojave. But I know that it's not working for Pablo on OSX Sierra (which dates from 2016...). AFAIU, Ronie has updated the VM's code to render on Metal, which made that at some point the VM was not compiling for latest versions of OSX. In these last weeks Ronie has also updated the code to make it compile in older machines, but still in those versions that not support Metal the main window just renders a black screen. I don't know what are the following steps regarding this, I put Ronie in cc, he may clarify a bit the situation. In the meanwhile, using the build I say in the email above may suffice us all I think ^^. > > Stef (back writing research proposalâ¦..) > > On 2 Apr 2019, at 13:40, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > 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 > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 2, 2019

[Pharo 8.0] Build #209: 3125-Cleanups-and-improved-ComputedSlot

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

There is a new Pharo build available! The status of the build #209 was: SUCCESS. The Pull Request #3126 was integrated: "3125-Cleanups-and-improved-ComputedSlot" Pull request url: https://github.com/pharo-project/pharo/pull/3126 Issue Url: https://github.com/pharo-project/pharo/issues/3125 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2019

Re: [Pharo-dev] New stable VM for Pharo8?

by ducasse

Thanks guille and pablo for you dedication for Pharo, I love you :) Now just that I understand, does it mean that the latest open smalltalk vm does not run on anything else that Mojave and High Sierra? Stef (back writing research proposalâ¦..) > On 2 Apr 2019, at 13:40, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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… <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

April 2, 2019

New stable VM for Pharo8?

by Guillermo Polito

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

April 2, 2019

[ANN] Pharo Workshops in Switzerland: April 30 to May 3rd

by Marcus Denker

Hi, Kertyx is organising a Workshop Series, the Digital Healthcare Innovation Workshops Part of this series will be a workshop around Pharo: Interactive and efficient ways to build technology stacks for experienced developers. - Where? Lavigny/Switzerland - When? April 30 to May 3 - Event web site: http://kertyx.events â¢ Workshop 1 â Introduction to Pharo (Marcus Denker) â¢ Workshop 2 â Web development using Seaside (Cyril Ferlicot) â¢ Workshop 3 â New Integrated Development Environment (IDE) â Glamorous Toolkit (Tudor Girba) Registration via eventbrite is available for all 3 workshops independently at http://kertyx.events Marcus

April 2, 2019

[Pharo 8.0] Build #208: New debugger test for stepOver

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

There is a new Pharo build available! The status of the build #208 was: FAILURE. The Pull Request #3123 was integrated: "New debugger test for stepOver" Pull request url: https://github.com/pharo-project/pharo/pull/3123 Issue Url: https://github.com/pharo-project/pharo/issues/3122 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 1, 2019

[Pharo 8.0] Build #207: 3027-Clean-flags-in-the-system

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

There is a new Pharo build available! The status of the build #207 was: SUCCESS. The Pull Request #3029 was integrated: "3027-Clean-flags-in-the-system" Pull request url: https://github.com/pharo-project/pharo/pull/3029 Issue Url: https://github.com/pharo-project/pharo/issues/3027 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 1, 2019

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

by ducasse

Thanks torsten. I think that christophe will react promptly. I know that guille and pablo found a bug in the VM code related to files (and it crashes iceberg build). Stef > On 1 Apr 2019, at 21:25, Torsten Bergmann <astares(a)gmx.de> wrote: > > If one downloads images with Launcher on Windows and accepts default names like "Pharo 7.0 - 32bit (stable)" this will end up in path names like > > "C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)" > > The dot and space combination in such files can later make trouble when downloading projects (like Seaside) using Iceberg and libgit and leading > later to the "IceGenericError: failed to stat file ... The filename or extension is too long" problem. > > I guess the dot in combination with spaces in the name is sometimes seen as the path element on current directory. > > If one gives an own name like "LatestPharo7" in Launcher (having C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads > even from the FileTree format. > > > As many people prefer to use Launcher now these days they might easily hit this problem. > > I opened an issue already for Launcher so this discussion here on ML is watched: > https://github.com/pharo-project/pharo-launcher/issues/327 > > Feedback and tests from Windows users are welcomed. >

April 1, 2019

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

by Torsten Bergmann

If one downloads images with Launcher on Windows and accepts default names like "Pharo 7.0 - 32bit (stable)" this will end up in path names like "C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)" The dot and space combination in such files can later make trouble when downloading projects (like Seaside) using Iceberg and libgit and leading later to the "IceGenericError: failed to stat file ... The filename or extension is too long" problem. I guess the dot in combination with spaces in the name is sometimes seen as the path element on current directory. If one gives an own name like "LatestPharo7" in Launcher (having C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads even from the FileTree format. As many people prefer to use Launcher now these days they might easily hit this problem. I opened an issue already for Launcher so this discussion here on ML is watched: https://github.com/pharo-project/pharo-launcher/issues/327 Feedback and tests from Windows users are welcomed.

April 1, 2019