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

Re: [Pharo-dev] [Pharo-users] Something is happening...

by Eliot Miranda

Hi Nicolas, Hi Marcus, > On Mar 15, 2018, at 4:05 AM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > >> On 15/03/2018 10:31, Marcus Denker wrote: >> [...] >> What I would like to have is a way to count âcurrently running imagesâ. >> But I guess adding that by default (like all mobile apps now do) would not >> be wanted.. but one could add some config option. >> > spotter has it and nobody complained as it is off by default (not sure how much people turned it on) > <Screenshot from 2018-03-15 12-02-08.png> If the spotter packet was also a "are there updates (image and/or vm) available?" request then - it could be on by default - it would give as well as receive :-) Of course it should work in the background and not slow down image launch, and it should fail silently if there is no network connection. > nicolas > -- > Nicolas Anquetil > RMod team -- Inria Lille

March 16, 2018

[Pharo 7.0-dev] Build #700: 21600 Use "instance creation" protocol in Monticello

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

There is a new Pharo build available! The status of the build #700 was: SUCCESS. The Pull Request #1114 was integrated: "21600 Use "instance creation" protocol in Monticello" Pull request url: https://github.com/pharo-project/pharo/pull/1114 Issue Url: https://pharo.fogbugz.com/f/cases/21600 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 16, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Thierry Goubier

Le 16/03/2018 Ã 18:37, Denis Kudriashov a Ã©critÂ : > > 2018-03-05 16:17 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com > <mailto:cyril.ferlicot@gmail.com>>: > > On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hi Pablo. > > > > Dev branch approach not really works. Because any merge into master will > > break master baseline. (notice that baseline is in same repo). > > And managing merges by hand all the time is not a solution. > > > > > Hi! > If you don't want to manage the merges by hand you can maybe > have two bsaelines? > BaselineOfCalypso and BaselineOfCalypsoDev? > > > At the end I found that this approach with two baselines is not really > working. > So I will adopt my projects to the following pattern: > > Each release will point to static version of dependencies. They all in > master branch. > Floating version like 0.5.x will be maintained in separate branch > instead of floating tag. In this branch baseline will reference > dependencies using similar "floating" branch in their repositories. > > So to get all minor fixes from all dependencies the code should be > loaded from such floating branch (0.5.x). The main project can be locked > to fix current version (only dependencies will be updated). > And all released versions (0.5.3 tag) will be completely reproducible. That sounds like a nice scheme. Thierry > > It should work. But is it right way that everybody should follow? > > With configurations it was easy to do in single class. > > > -- > Cyril Ferlicot > https://ferlicot.fr > > >

March 16, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-05 16:17 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > Hi Pablo. >> > >> > Dev branch approach not really works. Because any merge into master will >> > break master baseline. (notice that baseline is in same repo). >> > And managing merges by hand all the time is not a solution. >> > >> > >> Hi! >> If you don't want to manage the merges by hand you can maybe have two >> bsaelines? >> BaselineOfCalypso and BaselineOfCalypsoDev? >> > At the end I found that this approach with two baselines is not really working. So I will adopt my projects to the following pattern: Each release will point to static version of dependencies. They all in master branch. Floating version like 0.5.x will be maintained in separate branch instead of floating tag. In this branch baseline will reference dependencies using similar "floating" branch in their repositories. So to get all minor fixes from all dependencies the code should be loaded from such floating branch (0.5.x). The main project can be locked to fix current version (only dependencies will be updated). And all released versions (0.5.3 tag) will be completely reproducible. > It should work. But is it right way that everybody should follow? > > With configurations it was easy to do in single class. > > >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> >

March 16, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Sven Van Caekenberghe

> On 16 Mar 2018, at 17:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Ben Coman wrote >> it seems some people want to push PharoLauncher to *be* Pharo. >> To me this seems a poor strategyâ¦ This seems strange to me and highly >> likely to confuse newcomers. > > Yes, this was already discussed at length on the ML. > > The term Pharo already has a meaning: a vm + image containing both an OOP > language (is it Smalltalk or Smalltalk inspired? Please don't actually > answer that lol) and IDE written therein - or you could call it prototype > Dynabook software. > > If we now try to redefine the above (or really overload, because the former > definition will still coexist) to mean an app that manages images, it may > just be the final straw to make sure that no one ever will be able to give > any acceptable answer in less than 2038 hours to the question: What is > Pharo? ;) > > But just in case we step into the quicksand even further, in this dystopian > future you can just copy paste this definition: > Pharo is a Pharo app that manages Pharo images, which can be used to make > Pharo apps, which can be used to manage Pharo images, [which can be used to > make Pharo apps, which can be used to manage Pharo images]* Haha, yes it is so fluid it cannot be described only be experienced through prolonged exposure, it is truly magical. Actually, that is not so far from the truth. > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 16, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Sean P. DeNigris

Ben Coman wrote > it seems some people want to push PharoLauncher to *be* Pharo. > To me this seems a poor strategyâ¦ This seems strange to me and highly > likely to confuse newcomers. Yes, this was already discussed at length on the ML. The term Pharo already has a meaning: a vm + image containing both an OOP language (is it Smalltalk or Smalltalk inspired? Please don't actually answer that lol) and IDE written therein - or you could call it prototype Dynabook software. If we now try to redefine the above (or really overload, because the former definition will still coexist) to mean an app that manages images, it may just be the final straw to make sure that no one ever will be able to give any acceptable answer in less than 2038 hours to the question: What is Pharo? ;) But just in case we step into the quicksand even further, in this dystopian future you can just copy paste this definition: Pharo is a Pharo app that manages Pharo images, which can be used to make Pharo apps, which can be used to manage Pharo images, [which can be used to make Pharo apps, which can be used to manage Pharo images]* ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 16, 2018

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

by Sean P. DeNigris

Stephane Ducasse-3 wrote > we are planning to migrate a selection of the old > deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage > with deprecatedWithTransform rule > to help the migration of the old code to new one. Cool!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 16, 2018

[Pharo 7.0-dev] Build #699: 21601 Use "instance creation" in FT classes

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

There is a new Pharo build available! The status of the build #699 was: SUCCESS. The Pull Request #1115 was integrated: "21601 Use "instance creation" in FT classes" Pull request url: https://github.com/pharo-project/pharo/pull/1115 Issue Url: https://pharo.fogbugz.com/f/cases/21601 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 16, 2018

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

by Ben Coman

On 16 March 2018 at 20:53, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi Ben, > > Le 16 mars 2018 Ã 13:22, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > I popped over to Windows for a moment to try to make my CloudflareUn > crossplatform, > and installed PharoLauncher from the downloads page... > http://files.pharo.org/pharo-launcher/1.1/pharo-launcher- > installer-1.1-x86.exe > > I logged in as an Admin to do this, but when I open it I get an error... > "PrimitiveFailed: primitive #createDirectory: in WindowsStore failed Â» > > > Did you try to right-click on the installer and select Â« Run as > administrator Â« ? Iâm not sure that apps are all run with admin privileges > even if you are logged in with an admin account. > I tried "Run as administrator" from Non-Admin account with the same result. An Admin privileged that is no the "Administrator" account (which Microsoft have hard to access) only needs UAC to ask the question to approve things to happen. > > Also, I would expect trouble for Non-Admin users trying to use the Admin > installed Pharo Launcher.trying to write to "pharo-local" under "Program > Files Â». > > > Yes, that for sure! > For now, if you are admin, you could install PharoLauncher under Â« Program > Files Â» but then, you also need to be admin to run it. If you are not > admin, you should install PharoLauncher elsewhere. > Strange. I tried and the Installer hung when I tried to Browse for a new directory. I'll try again later after a reboot. > > I did not yet had time to test what Vincent on app packaging but probably, > it will solve the issue as Pharo Launcher does not need to write anything > to the installation directory (was needed by tools like GT, epicea, stdout). > > Does PharoLauncher have its own CI testing to ensure it can open okay > and run an image? I'm glad to see it promoted in importance but with this > it probably needs such CI testing of its own separate to the usual Pharo CI > testing. On Windows such CI testing *should* run as a Non-Admin user. > > > Functional testing like this is done by hand for this part. There are unit > tests. you can check that on CI: https://ci.inria.fr/pharo- > ci-jenkins2/job/PharoLauncher/ > There is room for improvement here. If you have an idea on how to automate > functional testing like this, it would be a great addition! > I've not much time with my current 12 hour work roster and side commitments, but I'll keep it in mind to look if I get the chance. > tw, requiring Administrative pbrivileges to install PharoLauncher is going > to lock out people who don't have administrative control over their PCs > e.g. University student labs. > > > It was like that before. I removed this check from the installer so that > standard users can install PharoLauncher in a folder where they have write > access. This way, PharoLauncher works. > > Wanting to run a quick demo for someone in a corporate office. Why don't > we make it the same as OSX and Linux and be usable without Admin > privileges. That would lower a barrier to entry. > > > It is already possible. Just, do not install PharoLauncher in a folder > requiring admin rights. > One improvement would be if there lack of Admin rights is detected, suggest an alternate default install location, but I guess thats highly dependent on what is available from the installer-system. cheers -ben > Thanks for feedbacks, > Christophe >

March 16, 2018

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

by Ben Coman

On 16 March 2018 at 22:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > For now, if you are admin, you could install PharoLauncher under Â« > Program Files Â» but then, you also need to be admin to run it. If you are > not admin, you should install PharoLauncher elsewhere. > > As I see this recommendation for the Nth time, maybe it is time the > default location to C:\Pharo (or C:\PharoLauncher) ... > > other languages don't seem to have any problem with that whatsoever (I see > in my dir C:\Python27, C:\Ruby24-x64, cygwin, msys, mingw, ...) > > If the installer cannot escalate on its own, it shouldn't try in the first > place. Otherwise it's just bad experience in literally the first step > people will take with Pharo. > > Interestingly Python 3 has installed itself in %APPDATA%\Local\Programs\Python\Python36-32 > ... so maybe that's also a location to consider which doesn't require admin > rights. > > Peter > I think Python 3 has it right. Its also where GitForWindows installs itself. Alternatively the parent %APPDATA%\Local\ (equivalently %LOCALAPPDATA% which can be typed into Windows Explorer) is where many apps seem to put their main executable. On my system I discover... %LOCALAPPDATA% \ Discord \ app-0.0.298 \ Discord.exe %LOCALAPPDATA% \ Atom \ atom.exe %LOCALAPPDATA% \ GitHubDesktop \ GitHubDesktop.exe %LOCALAPPDATA% \ slack \ slack.exe %LOCALAPPDATA% \ Roblox \ Versions \ RobloxStudioLauncherBeta.exe cheers -ben > > > On Fri, Mar 16, 2018 at 1:53 PM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > >> Hi Ben, >> >> Le 16 mars 2018 Ã 13:22, Ben Coman <btc(a)openinworld.com> a Ã©crit : >> >> I popped over to Windows for a moment to try to make my CloudflareUn >> crossplatform, >> and installed PharoLauncher from the downloads page... >> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-ins >> taller-1.1-x86.exe >> >> I logged in as an Admin to do this, but when I open it I get an error... >> "PrimitiveFailed: primitive #createDirectory: in WindowsStore failed Â» >> >> >> Did you try to right-click on the installer and select Â« Run as >> administrator Â« ? Iâm not sure that apps are all run with admin privileges >> even if you are logged in with an admin account. >> >> Also, I would expect trouble for Non-Admin users trying to use the Admin >> installed Pharo Launcher.trying to write to "pharo-local" under "Program >> Files Â». >> >> >> Yes, that for sure! >> For now, if you are admin, you could install PharoLauncher under Â« >> Program Files Â» but then, you also need to be admin to run it. If you are >> not admin, you should install PharoLauncher elsewhere. >> >> I did not yet had time to test what Vincent on app packaging but >> probably, it will solve the issue as Pharo Launcher does not need to write >> anything to the installation directory (was needed by tools like GT, >> epicea, stdout). >> >> Does PharoLauncher have its own CI testing to ensure it can open okay >> and run an image? I'm glad to see it promoted in importance but with this >> it probably needs such CI testing of its own separate to the usual Pharo CI >> testing. On Windows such CI testing *should* run as a Non-Admin user. >> >> >> Functional testing like this is done by hand for this part. There are >> unit tests. you can check that on CI: https://ci.inria.fr/pharo- >> ci-jenkins2/job/PharoLauncher/ >> There is room for improvement here. If you have an idea on how to >> automate functional testing like this, it would be a great addition! >> >> btw, requiring Administrative privileges to install PharoLauncher is >> going to lock out people who don't have administrative control over their >> PCs e.g. University student labs. >> >> >> It was like that before. I removed this check from the installer so that >> standard users can install PharoLauncher in a folder where they have write >> access. This way, PharoLauncher works. >> >> Wanting to run a quick demo for someone in a corporate office. Why don't >> we make it the same as OSX and Linux and be usable without Admin >> privileges. That would lower a barrier to entry. >> >> >> It is already possible. Just, do not install PharoLauncher in a folder >> requiring admin rights. >> >> Thanks for feedbacks, >> Christophe >> > >

March 16, 2018