December 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #19: 22731-notification-mail-has-an-error-on-version

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

There is a new Pharo build available! The status of the build #19 was: SUCCESS. The Pull Request #2043 was integrated: "22731-notification-mail-has-an-error-on-version" Pull request url: https://github.com/pharo-project/pharo/pull/2043 Issue Url: https://pharo.fogbugz.com/f/cases/22731 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Wed, 5 Dec 2018 at 23:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi Eliot, >> >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> Iâm slowly working on that VM because we want it to be the default for >> Pharo 8. >> In our vision, it should be a responsibility of the image to start or not >> a graphical UI, so we are preparing (we have been preparing to it for >> years, actually) to achieve this behaviour. >> To make this work, we need all platforms covered (and another huge >> quantity of changes here and there). >> Anyway, I didnât merge because I wanted to have win64 covered, not just >> what we have now, and since no-one was using that VM I didnât feel pression >> to do it :) >> >> >> How does that answer Norbertâs question? By doing the work in your own >> fork you risk forking. Do you want to fork? If not, why not do the work >> in opensmalltalk-vm? >> >> I guess you mean "why not do the work directly on the Cog branch of the > OpenSmalltalk accountâ, > > > Thatâs not how you work on git/github and I prefer to keep it âas > intendedâ. > > because any other branch is no different to any other branch regardless of > which account its stored in. > The "opensmaltalk-vm repo" is a single big commit graph across all > accounts, as you can see... > https://github.com/OpenSmalltalk/opensmalltalk-vm/network > > Whether any development-branch becomes a real-fork in the old vernacular > is not how long it stays unmerged from the mainline-branch > but how often the development-branch is updated to merge in the > mainline-branch. The network graph is useful to understand the situation > here. > > > This is old thing (there is a pull request now, since like 3 weeks). >> I worked on my fork because thatâs how you do it with git: you fork, you >> work, and you do a Pull Request when ready. >> I was explaining why the PR was not still done: I wanted to have covered >> the three platforms before doing it. >> > > On the flip side, release early release is a good policy. > > > Yeah, but for that you need to have something that you can release. > minheadless was developed by Ronie (I just made the makefiles and adapted > to build pharovms). And then it stalled around until I decided to took it > and merge itâ¦ Iâm going to be susceptible and say that frankly I do not > understand the tone of this mails. > > It was your merge of minheadless into Cog that stimulated me to add my > minor minheadless tweaks. > > > And Iâm grateful :) > > I know I could have submitted a PR direct to your minheadless branch, but > somehow it just felt more comfortable > submitting it to the mainline Cog branch. > > >> >> I guess the terminology is confusing you? >> > > That doesn't help. > > > Why? Terminology *is* confusing, at least for me. > It came across sarcastic. My apologies. Email is a poor medium sometimes. cheers -ben

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

> On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi Eliot, > >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> Iâm slowly working on that VM because we want it to be the default for Pharo 8. >>> In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. >>> To make this work, we need all platforms covered (and another huge quantity of changes here and there). >>> Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) >> >> How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? > > I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk accountâ, Thatâs not how you work on git/github and I prefer to keep it âas intendedâ. > because any other branch is no different to any other branch regardless of which account its stored in. > The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network <https://github.com/OpenSmalltalk/opensmalltalk-vm/network> > > Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch > but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here. > > > This is old thing (there is a pull request now, since like 3 weeks). > I worked on my fork because thatâs how you do it with git: you fork, you work, and you do a Pull Request when ready. > I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it. > > On the flip side, release early release is a good policy. Yeah, but for that you need to have something that you can release. minheadless was developed by Ronie (I just made the makefiles and adapted to build pharovms). And then it stalled around until I decided to took it and merge itâ¦ Iâm going to be susceptible and say that frankly I do not understand the tone of this mails. > It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. And Iâm grateful :) > I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable > submitting it to the mainline Cog branch. > > > I guess the terminology is confusing you? > > That doesn't help. Why? Terminology *is* confusing, at least for me. Esteban > > cheers -ben

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for > Pharo 8. > In our vision, it should be a responsibility of the image to start or not > a graphical UI, so we are preparing (we have been preparing to it for > years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge > quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just > what we have now, and since no-one was using that VM I didnât feel pression > to do it :) > > > How does that answer Norbertâs question? By doing the work in your own > fork you risk forking. Do you want to fork? If not, why not do the work > in opensmalltalk-vm? > > I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk account", because any other branch is no different to any other branch regardless of which account its stored in. The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here. This is old thing (there is a pull request now, since like 3 weeks). > I worked on my fork because thatâs how you do it with git: you fork, you > work, and you do a Pull Request when ready. > I was explaining why the PR was not still done: I wanted to have covered > the three platforms before doing it. > On the flip side, release early release is a good policy. It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable submitting it to the mainline Cog branch. > > I guess the terminology is confusing you? > That doesn't help. cheers -ben

Dec. 5, 2018

[Pharo .0] Build #18: 22726 pharo icon in menus is larger than other icons 20 pix instead of 16 making its row height different

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

There is a new Pharo build available! The status of the build #18 was: SUCCESS. The Pull Request #2037 was integrated: "22726 pharo icon in menus is larger than other icons 20 pix instead of 16 making its row height different" Pull request url: https://github.com/pharo-project/pharo/pull/2037 Issue Url: https://pharo.fogbugz.com/f/cases/22726 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

Re: [Pharo-dev] [IMPORTANT] Development branch changed to "Pharo7.0"

by Esteban Lorenzano

I forgot to explain that at the end we choose to name our branches âPharoMAJOR.MINORâ instead âdev-MAJOR.MINORâ as proposed at first because that way was not clear what the branches are. Yes, they are development branches, but they also have the released versions (usually as tags). After searching some other projects with similar characteristics to ours, we think this was the better approach. Esteban > On 5 Dec 2018, at 15:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Working on Pharo7.0 release, I finally changed the default branch. > âDevelopment" does not exists anymore, now all Pull Requests needs to be done against âPharo7.0â. > > This will allow us to : > > - Continue working on Pharo7.0 release > - Open a Pharo8.0 branch (hopefully next week) > > Iâm sorry for the mess I can cause to someones, there should not be a problem for most of you but some may need to update their scripts. > > Cheers! > Esteban

Dec. 5, 2018

[IMPORTANT] Development branch changed to "Pharo7.0"

by Esteban Lorenzano

Hi, Working on Pharo7.0 release, I finally changed the default branch. âDevelopment" does not exists anymore, now all Pull Requests needs to be done against âPharo7.0â. This will allow us to : - Continue working on Pharo7.0 release - Open a Pharo8.0 branch (hopefully next week) Iâm sorry for the mess I can cause to someones, there should not be a problem for most of you but some may need to update their scripts. Cheers! Esteban

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

Hi Eliot, > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> Iâm slowly working on that VM because we want it to be the default for Pharo 8. >> In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. >> To make this work, we need all platforms covered (and another huge quantity of changes here and there). >> Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) > > How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? This is old thing (there is a pull request now, since like 3 weeks). I worked on my fork because thatâs how you do it with git: you fork, you work, and you do a Pull Request when ready. I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it. I guess the terminology is confusing you? Cheers! Esteban > >> >> Cheers, >> Esteban >> >> >>> On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >>> What keeps you from doing a pull request to opensmalltalk-vm ? >>> >>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>>> Hi Ben, >>>> >>>> Sorry for coming here so late, I didnât see this thread before. >>>> I already have a working minheadless branch that was adapted to Eliotâs process. >>>> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >>>> >>>> You can find this branch here: >>>> >>>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> >>>> >>>> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >>>> >>>> Cheers, >>>> Esteban >>>> >>>> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >>>> >>>> >>>>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> >>>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>>> >>>>> Hi Ben, >>>>> Feel free to make this edit and commit >>>>> >>>>> I'm pushing changes here... >>>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-…> >>>>> >>>>> and the diff can be tracked here... >>>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… <https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..…> >>>>> >>>>> >>>>> ------------------------ >>>>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>>> E0651 a calling convention may not be followed by a nested declarator. >>>>> >>>>> The following change reduces build errors to 1... >>>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> but I'm not sure of the implications. >>>>> >>>>> I found the correct solution to this... >>>>> "The trick is placing the [call declaration] inside the parentheses" >>>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co…> >>>>> >>>>> i.e. the following compiles cleanly >>>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> >>>>> ----------------------------- >>>>> Now running the VM (without parameters) I get... >>>>> Debug Assertion Failed! >>>>> Program: ...\x64-Debug\dist\pharo.exe >>>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>>> Line: 106 >>>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>>> >>>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>>> >>>>> >>>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx <https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx> >>>>> x64 does not support _MCW_PC or _MCW_IC >>>>> but I'm clueless about the implications of these FPU flags. >>>>> Could our math guys please advise? >>>>> >>>>> Eliminating those two flags allows a VM run successfully without loading an Image. >>>>> i.e. it successfully passes... >>>>> osvm_initialize(); >>>>> osvm_parseCommandLineArguments(argc, argv); >>>>> osvm_initializeVM(); >>>>> >>>>> Next is to try loading an Image. >>>>> >>>>> cheers -ben >>>> >>

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Eliot Miranda

Hi Esteban, > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for Pharo 8. > In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? > > Cheers, > Esteban > > >> On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> What keeps you from doing a pull request to opensmalltalk-vm ? >> >>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> Hi Ben, >>> >>> Sorry for coming here so late, I didnât see this thread before. >>> I already have a working minheadless branch that was adapted to Eliotâs process. >>> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >>> >>> You can find this branch here: >>> >>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm >>> >>> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >>> >>> Cheers, >>> Esteban >>> >>> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >>> >>> >>>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>> >>>>> Hi Ben, >>>>> Feel free to make this edit and commit >>>> >>>> I'm pushing changes here... >>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… >>>> >>>> and the diff can be tracked here... >>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… >>>> >>>> >>>> ------------------------ >>>>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: >>>>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: >>>>> >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >>>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>>> E0651 a calling convention may not be followed by a nested declarator. >>>>> >>>>> The following change reduces build errors to 1... >>>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> but I'm not sure of the implications. >>>> >>>> I found the correct solution to this... >>>> "The trick is placing the [call declaration] inside the parentheses" >>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… >>>> >>>> i.e. the following compiles cleanly >>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> >>>> >>>> ----------------------------- >>>> Now running the VM (without parameters) I get... >>>> Debug Assertion Failed! >>>> Program: ...\x64-Debug\dist\pharo.exe >>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>> Line: 106 >>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>> >>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >>>> >>>> >>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx >>>> x64 does not support _MCW_PC or _MCW_IC >>>> but I'm clueless about the implications of these FPU flags. >>>> Could our math guys please advise? >>>> >>>> Eliminating those two flags allows a VM run successfully without loading an Image. >>>> i.e. it successfully passes... >>>> osvm_initialize(); >>>> osvm_parseCommandLineArguments(argc, argv); >>>> osvm_initializeVM(); >>>> >>>> Next is to try loading an Image. >>>> >>>> cheers -ben >>> >

Dec. 5, 2018

[Pharo .0] Build #17: SUCCESS

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

There is a new Pharo build available! The status of the build #17 was: SUCCESS. Could not extract further issue information from commit message: restore uploads Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018