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

[Pharo 8.0] Build #461: 3679-Regression-with-drag-and-drop

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

There is a new Pharo build available! The status of the build #461 was: FAILURE. The Pull Request #3830 was integrated: "3679-Regression-with-drag-and-drop" Pull request url: https://github.com/pharo-project/pharo/pull/3830 Issue Url: https://github.com/pharo-project/pharo/issues/3679 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

[Pharo 8.0] Build #460: 3802-make-code-completion-experiment-the-default-for-feedback

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

There is a new Pharo build available! The status of the build #460 was: FAILURE. The Pull Request #3835 was integrated: "3802-make-code-completion-experiment-the-default-for-feedback" Pull request url: https://github.com/pharo-project/pharo/pull/3835 Issue Url: https://github.com/pharo-project/pharo/issues/3802 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

Re: [Pharo-dev] Read-only image mode

by ducasse

This is cool to see this effort pushed again. Thanks a lot Pavel. > On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications. It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system. > > In summary: > - the image can be executed with --readOnlyMode image argument > - the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc. > - PharoDebug.log and placeholder files on Windows are not created > - the limitation is only on image-level so it is easy to bypass it. > - the presence of the old file streams makes everything uglier and messier > > We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837 <https://github.com/pharo-project/pharo/pull/3837> > > Comments and reviews are welcome. > > -- Pavel >

July 9, 2019

Re: [Pharo-dev] Read-only image mode

by Max Leske

Awesome! Thanks! On 9 Jul 2019, at 14:28, Pavel Krivanek wrote: > Hi, > > the current Pharo cannot deal very well in situations when you want to run > multiple instances from one image file, especially on Windows, which > complicates the setup of parallel applications. It is not able to work > reasonably on read-only file-systems too. That's why I did the next attempt > to improve this functionality of the system. > > In summary: > - the image can be executed with --readOnlyMode image argument > - the basic system tries to survive such limitation. The changes file is in > read-only mode and new sources are installed into compiled methods > directly, Ombu does not save content, Playground does not save cache etc. > - PharoDebug.log and placeholder files on Windows are not created > - the limitation is only on image-level so it is easy to bypass it. > - the presence of the old file streams makes everything uglier and messier > > We have an open PR for this issue: > https://github.com/pharo-project/pharo/pull/3837 > > Comments and reviews are welcome. > > -- Pavel

July 9, 2019

[Pharo 8.0] Build #459: Use accessors rather than direct references for Pragma.selector

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

There is a new Pharo build available! The status of the build #459 was: SUCCESS. The Pull Request #3827 was integrated: "Use accessors rather than direct references for Pragma.selector" Pull request url: https://github.com/pharo-project/pharo/pull/3827 Issue Url: https://github.com/pharo-project/pharo/issues/Pragma_selector Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

[Pharo 8.0] Build #458: 3820-Spec2-update

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

There is a new Pharo build available! The status of the build #458 was: SUCCESS. The Pull Request #3821 was integrated: "3820-Spec2-update" Pull request url: https://github.com/pharo-project/pharo/pull/3821 Issue Url: https://github.com/pharo-project/pharo/issues/3820 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

Read-only image mode

by Pavel Krivanek

Hi, the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications. It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system. In summary: - the image can be executed with --readOnlyMode image argument - the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc. - PharoDebug.log and placeholder files on Windows are not created - the limitation is only on image-level so it is easy to bypass it. - the presence of the old file streams makes everything uglier and messier We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837 Comments and reviews are welcome. -- Pavel

July 9, 2019

[Pharo 8.0] Build #457: 3811-simplify-and-speedup-unreferencedInstanceVariables

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

There is a new Pharo build available! The status of the build #457 was: FAILURE. The Pull Request #3834 was integrated: "3811-simplify-and-speedup-unreferencedInstanceVariables" Pull request url: https://github.com/pharo-project/pharo/pull/3834 Issue Url: https://github.com/pharo-project/pharo/issues/3811 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

by Christophe Demarey

Hi Torsten, > Le 8 juil. 2019 Ã 20:44, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : > > Without having a deeper look I guess what was done for Windows now is wrapping the usual STARTUPINFO, CreateProcess() > functions and friends yet again â¦ Indeed. A subtle difference is that we use the Unicode version of this API. > > Such wrappers and many other native friends were created from my side already years ago with my "OS-XXX" series > of projects for different platforms: > > - http://smalltalkhub.com/#!/~OS/OS-Windows I know this library as doing a lot of cool things for the integration with the OS but I was not aware there was an implementation of processes forking. I thought it used one of the existing library to do that. > - http://smalltalkhub.com/#!/~OS/OS-OSX > - http://smalltalkhub.com/#!/~OS/OS-Unix > - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS > - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu > - http://smalltalkhub.com/#!/~OS/OS-Raspbian > > So for instance on Windows you could easily use > > WinProcess createProcess: 'explorer.exe' > > or > > WinProcess createAndWaitForProcess: 'cmd.exe'. > > The projects are available on Github now since 2018 and kept up to date for recent Pharo versions. > > - https://github.com/astares/Pharo-OS-Windows > - https://github.com/astares/Pharo-OS-OSX > - https://github.com/astares/Pharo-OS-Unix > - https://github.com/astares/Pharo-OS-Linux-Ubuntu > - https://github.com/astares/Pharo-OS-Raspbian > > All of them are available in Catalog. > > I have no problem with more and more implementations and the double efforts. But for Pharo users I have the feeling > that it gets more and more confusing in the area of OSProcess, OSSubProcess, OSWinSubprocess, .... and more wrappers > for basically the same thing â¦ I think you are right on this point. I have the same feeling. Also, OSSubprocess is now the recommended way to fork processes on Linux like systems, and there is no support yet for Windows, I took the opportunity to create the OSWinSubprocess project that could be easily merged into OSSubprocess once it gets all required features. I based my work on a PR done on Pharo Launcher by Keldon Alleyne. If I knew about the process support in OS-Windows, I would for sure, at least, had a look at it and possibly re-use it. I see you have some support for pipes / streams. If you are willing to we could work together to merge both implementation. The only thing is that we should keep the OSSubprocess API when possible to allow a merge with it in a future. WDYT? Christophe.

July 9, 2019

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

by Christophe Demarey

> Le 8 juil. 2019 Ã 19:48, Esteban Maringolo <emaringolo(a)gmail.com> a Ã©crit : > > On Mon, Jul 8, 2019 at 9:39 AM Christophe Demarey > <christophe.demarey(a)inria.fr> wrote: >> >> Hi Esteban, >> >>> Le 8 juil. 2019 Ã 14:24, Esteban Maringolo <emaringolo(a)gmail.com> a Ã©crit : >>> >>> Thanks, >>> >>> I downloaded the latest one for Windows, and it seems to work, but the >>> "About" says Pharo Launcher is 1.6. >> >> Strange because the version is set during the build on the CI server: ./pharo PharoLauncher.image eval --save 'PhLAboutCommand version: '\â'1.9.1'\''' >> >>> Looking at the installation directory at >>> <C:\Users\Esteban\AppData\Local\PharoLauncher\> the right files are >>> there, so it's just a matter of the text in the About dialog. >> >> Are you sure, you use the right version? To ensure, by using shif+entre in PharoLauncher, you should see OSWSWinProcess class. > > I am sure, and also checked, because you never know... and the > installer copied the files in the same directory as the previous one, > but didn't overwrite them. > > So I uninstalled the previous version and re-installed the latest one > and now it works fine (and faster, it seems). > Which makes me suspicious about whether the 1.8 was installed at all > last time I did it. Hum. Good to know. I will have to investigate on the installer behavior. Thanks.

July 9, 2019