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

[Pharo 9.0] Build #274: Removing classes from ChangeSorter throws DNU

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

There is a new Pharo build available! The status of the build #274 was: FAILURE. The Pull Request #6261 was integrated: "Removing classes from ChangeSorter throws DNU" Pull request url: https://github.com/pharo-project/pharo/pull/6261 Issue Url: https://github.com/pharo-project/pharo/issues/6260 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2020

[Pharo 9.0] Build #273: Lint cleanup #isZipArchive:

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

There is a new Pharo build available! The status of the build #273 was: FAILURE. The Pull Request #6263 was integrated: "Lint cleanup #isZipArchive:" Pull request url: https://github.com/pharo-project/pharo/pull/6263 Issue Url: https://github.com/pharo-project/pharo/issues/6262 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2020

[Pharo 9.0] Build #272: Cleanup InspectDebuggerDebugAction

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

There is a new Pharo build available! The status of the build #272 was: FAILURE. The Pull Request #6265 was integrated: "Cleanup InspectDebuggerDebugAction" Pull request url: https://github.com/pharo-project/pharo/pull/6265 Issue Url: https://github.com/pharo-project/pharo/issues/6264 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2020

[Pharo 9.0] Build #271: Fix typo

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

There is a new Pharo build available! The status of the build #271 was: FAILURE. The Pull Request #6257 was integrated: "Fix typo" Pull request url: https://github.com/pharo-project/pharo/pull/6257 Issue Url: https://github.com/pharo-project/pharo/issues/6243 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2020

[Pharo 9.0] Build #270: SemanticAnalysis-PrimitiveErrorInvisitPragmaNode

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

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

April 28, 2020

[Pharo 9.0] Build #269: NameAnalysis-Test-Cleanup

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

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

April 28, 2020

[Pharo 9.0] Build #268: Revert "refactor-spanNewSessionFrom"

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

There is a new Pharo build available! The status of the build #268 was: FAILURE. The Pull Request #6253 was integrated: "Revert "refactor-spanNewSessionFrom"" Pull request url: https://github.com/pharo-project/pharo/pull/6253 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 28, 2020

Re: [Pharo-dev] Fwd: [Vm-dev] why GT forked the VM and how to kill our fork

by tesonep＠gmail.com

Hi all, I want to add a little more details, event that the mail of Doru was much more than clear. I can tell for more details that those changes have been integrated in December, thanks to Github it is easy to check the changes in the PRs 42, 50, 53, 56, 57 and 58 that Ronie has proposed and that have been integrated (https://github.com/pharo-project/opensmalltalk-vm/pulls?q=is%3Apr+is%3Aclos…) There is a single PR that Alistair have open, that I need to do some work to be able to implement it. As the C code generator requires a way of adding the EXPORT declaration in the generated function that requires so, so it is not needed to do by hand. Also, the changes proposed to the Queue-based ThreadedFFI plugin have been integrated (https://github.com/pharo-project/threadedFFI-Plugin/pulls?q=is%3Apr+is%3Acl…) Thanks Ronie and Alistair for the collaborations. The remaining PR is not integrated as it removes a tool that we consider useful for debugging the incorrect return order of Callbacks. We have added checks in the plugin and in the image side to detect the attempts to return in an incorrect order the callbacks avoiding corruptions in the C stack. Just another clarification, that maybe Alistair can explain more, they are using the queue-based solution as it can handle better concurrent calls to Smalltalk code without the need to be inside a callout to C. As this is a known limitation of the scheme where the active Smalltalk process is hijacked to execute the callback. We are more than thankfully to the contribution of Doru, Ronie, Alistair and all the team of Feenk to the improvement of Pharo and the VM. They are doing an excellent job, and it is not only these contributions but also the work they have done to migrate the Smalltalk code of the VM into Git preserving the history, without that it would have been imposible to get to the state where we are. Cheers, Pablo On Mon, Apr 27, 2020 at 6:01 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > _,,,^..^,,,_ (phone) > > Begin forwarded message: > > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 26, 2020 at 10:39:35 AM PDT > To: Open Smalltalk Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] why GT forked the VM and how to kill our fork > > ï»¿Hi Doru, > > > On Apr 26, 2020, at 12:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > ï»¿ > > Hi, > > > Currently, at feenk we have feenkcom/opensmalltalk-vm: > > https://github.com/feenkcom/opensmalltalk-vm > > > This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. > > > For Glamorous Toolkit we aimed for the following functionality: > > â¢ Open the GUI natively and have native display quality (GUI opened through FFI calls) > > â¢ Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS > > â¢ Create end-user applications that are fully customisable (executable name, menus, etc) > > â¢ Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. > > â¢ Have Iceberg running in native windows (which requires nested FFI callbacks) > > > There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. > > > Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. > > > To have native GUIs we relied on Ronie Salgadoâs work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: > > https://github.com/pharo-project/opensmalltalk-vm/tree/headless > > That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. > > > On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. > > > To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). > > > Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56) > > > The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/) When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin) Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17) > > > One detail here is that Alien provides the callback machinery used alongside ThreadedFFIPlugin. The Alien call-out machinery is an old hack used only by Newspeak, that could be eliminated in non-Newspeak builds. But AFAIA Alienâs callback machinery is *the* callback machinery everywhere for the OpenSmalltalk vm. > > While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. > > > > To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. > > > We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. > > > Can it be done with pull requests? Should we try and firm a team of volunteers, eg one from feenk and one from OpenSmalltalk to try and merge in the feenk code? > > I would volunteer but I am way too busy getting the Terf system working. TFir e able, the ARMv8 JIT has been working for months but Iâve had no time to release it because of Terf and other payed work (got to pay the bills). > > Please let us know you would prefer to coordinate. > > > Any volunteers? > > Cheers, > > Tudor, on behalf of the feenk team > > > -- > > feenk.com > > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > > -- Pablo Tesone. tesonep(a)gmail.com

April 28, 2020

[Pharo 9.0] Build #267: refactor-spanNewSessionFrom

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

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

April 28, 2020

[Pharo 9.0] Build #266: Improve Tests OCBytecodeToASTCache

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

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

April 28, 2020

Statement about the VM

by StÃ©phane Ducasse

As promised the consortium engineering team composed of G. Polito, P. Tesone, E. Lorenzano, M. Denker, C. Demarey and S. Ducasse produced a statement about the Pharo VM. This statement was reviewed by the Pharo board and follows decisions taken during the 2019 consortium general assembly held during PharoDays. S. Ducasse on the behalf of the consortium -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas 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

April 27, 2020

Fwd: [Vm-dev] why GT forked the VM and how to kill our fork

by Eliot Miranda

_,,,^..^,,,_ (phone) Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 26, 2020 at 10:39:35 AM PDT > To: Open Smalltalk Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] why GT forked the VM and how to kill our fork > > ï»¿Hi Doru, > > >> On Apr 26, 2020, at 12:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> ï»¿ >> Hi, >> >> Currently, at feenk we have feenkcom/opensmalltalk-vm: >> https://github.com/feenkcom/opensmalltalk-vm >> >> This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. >> >> For Glamorous Toolkit we aimed for the following functionality: >> â¢ Open the GUI natively and have native display quality (GUI opened through FFI calls) >> â¢ Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS >> â¢ Create end-user applications that are fully customisable (executable name, menus, etc) >> â¢ Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. >> â¢ Have Iceberg running in native windows (which requires nested FFI callbacks) >> >> There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. >> >> Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. >> >> To have native GUIs we relied on Ronie Salgadoâs work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: >> https://github.com/pharo-project/opensmalltalk-vm/tree/headless >> That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. >> >> On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. >> >> To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). >> >> Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56) >> >> The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/) When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin) Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17) > > One detail here is that Alien provides the callback machinery used alongside ThreadedFFIPlugin. The Alien call-out machinery is an old hack used only by Newspeak, that could be eliminated in non-Newspeak builds. But AFAIA Alienâs callback machinery is *the* callback machinery everywhere for the OpenSmalltalk vm. > >> While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. >> >> >> To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. >> >> We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. > > Can it be done with pull requests? Should we try and firm a team of volunteers, eg one from feenk and one from OpenSmalltalk to try and merge in the feenk code? > > I would volunteer but I am way too busy getting the Terf system working. TFir e able, the ARMv8 JIT has been working for months but Iâve had no time to release it because of Terf and other payed work (got to pay the bills). > >> Please let us know you would prefer to coordinate. > > Any volunteers? > >> Cheers, >> Tudor, on behalf of the feenk team >> >> -- >> feenk.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> >> >>

April 27, 2020

[Pharo 9.0] Build #265: 6186-System-end-up-in-a-bad-state-when-adding-a-class-in-a-trait-composition-instead-of-a-trait

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

There is a new Pharo build available! The status of the build #265 was: FAILURE. The Pull Request #6214 was integrated: "6186-System-end-up-in-a-bad-state-when-adding-a-class-in-a-trait-composition-instead-of-a-trait" Pull request url: https://github.com/pharo-project/pharo/pull/6214 Issue Url: https://github.com/pharo-project/pharo/issues/6186 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 27, 2020

Re: [Pharo-dev] _ and precedence

by John Brant

On 4/27/20 7:51 AM, StÃ©phane Ducasse wrote: > Hi > > Doig the XP for magic literals I found > > Symbol >> precedence > "Answer the receiver's precedence, assuming it is a valid Smalltalk > message selector or 0 otherwise. Â The numbers are 1 for unary, > 2 for binary and 3 for keyword selectors." > > self size = 0 ifTrue: [^ 0]. > (self first isLetter or: [ self first = $_ ]) ifFalse: [^ 2]. > self last = $: ifTrue: [^ 3]. > ^ 1 > > > > #'_foo' precedence. > "1" > #'_+' precedence. > "1" > #'+' precedence. > "2" > #'foo' precedence. > "1" > #'foo:' precedence. > "3" > #'_foo:' precedence. > â3" > > And I wonder why we are concerned with _ Underscores and letters are treated the same by the Smalltalk grammar. Unary, keyword and variables can all begin with letters or underscores. "_" is a valid variable and unary message name. As for your tests, you would get the same results if you replaced $_ with $a -- "#'a+' precedence = 1". John Brant

April 27, 2020

Re: [Pharo-dev] _ and precedence

by Nicolas Anquetil

isn't it historical ? it used to mean :=, no? nicolas On Mon, 2020-04-27 at 14:51 +0200, StÃ©phane Ducasse wrote: > Hi > > Doig the XP for magic literals I found > > Symbol >> precedence > "Answer the receiver's precedence, assuming it is a valid > Smalltalk > message selector or 0 otherwise. The numbers are 1 for unary, > 2 for binary and 3 for keyword selectors." > > self size = 0 ifTrue: [^ 0]. > (self first isLetter or: [ self first = $_ ]) ifFalse: [^ 2]. > self last = $: ifTrue: [^ 3]. > ^ 1 > > > > #'_foo' precedence. > "1" > #'_+' precedence. > "1" > #'+' precedence. > "2" > #'foo' precedence. > "1" > #'foo:' precedence. > "3" > #'_foo:' precedence. > â3" > > And I wonder why we are concerned with _ > > S. > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > 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 > -- Nicolas Anquetil RMod team -- Inria Lille

April 27, 2020

_ and precedence

by StÃ©phane Ducasse

Hi Doig the XP for magic literals I found Symbol >> precedence "Answer the receiver's precedence, assuming it is a valid Smalltalk message selector or 0 otherwise. The numbers are 1 for unary, 2 for binary and 3 for keyword selectors." self size = 0 ifTrue: [^ 0]. (self first isLetter or: [ self first = $_ ]) ifFalse: [^ 2]. self last = $: ifTrue: [^ 3]. ^ 1 #'_foo' precedence. "1" #'_+' precedence. "1" #'+' precedence. "2" #'foo' precedence. "1" #'foo:' precedence. "3" #'_foo:' precedence. â3" And I wonder why we are concerned with _ S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas 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

April 27, 2020

[Pharo 9.0] Build #264: FixBlockBytecodePrinting

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

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

April 27, 2020

[Pharo 9.0] Build #263: 6171-Enhance-Collection-with-rollingAvegra

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

There is a new Pharo build available! The status of the build #263 was: SUCCESS. The Pull Request #6220 was integrated: "6171-Enhance-Collection-with-rollingAvegra" Pull request url: https://github.com/pharo-project/pharo/pull/6220 Issue Url: https://github.com/pharo-project/pharo/issues/6171 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 27, 2020

Re: [Pharo-dev] why GT forked the VM and how to kill our fork

by Sven Van Caekenberghe

Hi Doru, > On 26 Apr 2020, at 09:57, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Currently, at feenk we have feenkcom/opensmalltalk-vm: > https://github.com/feenkcom/opensmalltalk-vm > > This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. > > For Glamorous Toolkit we aimed for the following functionality: > â¢ Open the GUI natively and have native display quality (GUI opened through FFI calls) > â¢ Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS > â¢ Create end-user applications that are fully customisable (executable name, menus, etc) > â¢ Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. > â¢ Have Iceberg running in native windows (which requires nested FFI callbacks) > > There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. > > Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. > > To have native GUIs we relied on Ronie Salgadoâs work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: > https://github.com/pharo-project/opensmalltalk-vm/tree/headless > That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. > > On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. > > To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). > > Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56) > > The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/) When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin) Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17) > > While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. Thanks for the detailed writeup. > To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. I would also love to have *all* your changes back into pharo-project/opensmalltalk-vm ! Sven > We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. > > > Please let us know you would prefer to coordinate. > > > Cheers, > Tudor, on behalf of the feenk team > > -- > feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > >

April 26, 2020

why GT forked the VM and how to kill our fork

by Tudor Girba

Hi, Currently, at feenk we have feenkcom/opensmalltalk-vm: https://github.com/feenkcom/opensmalltalk-vm This is a small fork of the headless branch from pharo-project/opensmalltalk-vm that appeared out of practical necessities, but that we would like to avoid having. This post briefly describes the changes in the feenkcom/opensmalltalk-vm repo and the functionality those changes provide for Glamorous Toolkit. For Glamorous Toolkit we aimed for the following functionality: â¢ Open the GUI natively and have native display quality (GUI opened through FFI calls) â¢ Have a Glamorous Toolkit app for Mac OS that works as any other apps for Mac OS â¢ Create end-user applications that are fully customisable (executable name, menus, etc) â¢ Use Github actions for doing all compilations of external libraries and the vm instead of Travis CI. â¢ Have Iceberg running in native windows (which requires nested FFI callbacks) There has been work on these issues in both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm but they were not entirely addressed. We needed to have something reliable a few months ago, and forking and doing some quick changes made that possible. Ideally we want to be able to run Glamorous Toolkit on both OpenSmalltalk/opensmalltalk-vm and pharo-project/opensmalltalk-vm. To have native GUIs we relied on Ronie Salgadoâs work on the headless vm and started with pharo-project/opensmalltalk-vm - headless branch: https://github.com/pharo-project/opensmalltalk-vm/tree/headless That provided a solution for opening the GUI from the image through FFI calls. Currently we use Glutin (a library for OpenGL context creation, written in pure Rust) and this made it possible to run the entire Glamorous Toolkit inside a callback. On macOS when running an app, even a notarized one, the OS warns the user that the app is downloaded from the internet, and the user needs to confirm that they agree. Once the user agrees the app should automatically start. This is not currently possible with Pharo apps (for example PharoLaunched.app) and users have to again run the app manually after giving permission. Also Gatekeeper in macOS runs applications downloaded from zips in a randomized read-only DMG. We do not want this behaviour as users not copying Glamorous Toolkit to the Applications folder on macOS would then experience incorrect application behaviour. To create end-user applications we also need to fully customize the executable name (what the user sees in the Task Runner/Activity monitor), icons, native menus. Part of this work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, Brand the VM executable and package). Since last year Github offers Github Actions similar to Travis. We found it much easier to use than Travis for external libraries and the vm. Also we get to manage the code and the builds in the same place. This work is already integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the VM under GitHub actions: https://github.com/pharo-project/opensmalltalk-vm/pull/56) The issues related to running Iceberg is a bit more technical. By moving to the headless vm we are running the entire image computation inside a callback from Glutin (https://github.com/rust-windowing/glutin/) When using Iceberg we get nested callbacks which we could not get to work using Alien. Instead we are using the ThreadedFFI Plugin and running all callback from Iceberg and Glutin using the Threaded FFI plugin (https://github.com/pharo-project/threadedFFI-Plugin) Currently we have a small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a custom plugin with the VM to fix a race condition due to having two copies of the callback stack (a pull request is here: https://github.com/pharo-project/threadedFFI-Plugin/pull/17) While not specific to our environment, openssl1.0 is no longer supported, and we are seeing users who are unable to run Pharo due to version conflicts, as reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62. To sum up, a fork was the easiest way to get all this running. Now some changes are already in the pharo-project/opensmalltalk-vm - headless branch. What we are still missing are the changes that get the VM to work nicely with Mac OS and a bug fix in ThreadedFFI. We would also love it to have all these changes integrated in OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional coordination as the required changes are somewhat deeper. Please let us know you would prefer to coordinate. Cheers, Tudor, on behalf of the feenk team -- feenk.com "The coherence of a trip is given by the clearness of the goal."

April 26, 2020

[Pharo 9.0] Build #262: simplify-ifNil-conditions

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

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

April 25, 2020

[Pharo 9.0] Build #261: 5494-Rename-rules-to-end-up-with-Rule

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

There is a new Pharo build available! The status of the build #261 was: SUCCESS. The Pull Request #6228 was integrated: "5494-Rename-rules-to-end-up-with-Rule" Pull request url: https://github.com/pharo-project/pharo/pull/6228 Issue Url: https://github.com/pharo-project/pharo/issues/5494 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2020

[Pharo 9.0] Build #260: ifErrorDo: should be onErrorDo: and deprecate with transform

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

There is a new Pharo build available! The status of the build #260 was: FAILURE. The Pull Request #6158 was integrated: "ifErrorDo: should be onErrorDo: and deprecate with transform" Pull request url: https://github.com/pharo-project/pharo/pull/6158 Issue Url: https://github.com/pharo-project/pharo/issues/6157 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2020

[Pharo 9.0] Build #259: #5952-PharoEnvironmentHelp-outdated

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

There is a new Pharo build available! The status of the build #259 was: FAILURE. The Pull Request #6225 was integrated: "#5952-PharoEnvironmentHelp-outdated" Pull request url: https://github.com/pharo-project/pharo/pull/6225 Issue Url: https://github.com/pharo-project/pharo/issues/5952 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 24, 2020

[Pharo 9.0] Build #258: 6165-Spotter-stopped-to-react-on-full-method-name

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

There is a new Pharo build available! The status of the build #258 was: FAILURE. The Pull Request #6226 was integrated: "6165-Spotter-stopped-to-react-on-full-method-name" Pull request url: https://github.com/pharo-project/pharo/pull/6226 Issue Url: https://github.com/pharo-project/pharo/issues/6165 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 24, 2020