- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 7 new file stream encoders

by Thierry Goubier

2018-03-16 15:01 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > That should be fixed now. I proposed also the rename. I can revert it if > needed. > Thanks. I'll have a look later. Thierry > > On Fri, Mar 16, 2018 at 1:04 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> >> > On 16 Mar 2018, at 11:29, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > >> > Hi, >> > >> > Yes, I'll provide a PR with that functionality soon. Probably in that >> case *ZnCrPortableWriteStream* is not the right name for that class. Sven, >> do you think renaming it now (before it has lots of users) would be >> acceptable towards backwards compatibility? Otherwise I would name it >> ZnNewLineConverterStream... >> >> Renaming is OK/better, if it works (critical class in IO) >> >> Note #forPlatformLineEnding should do: OSPlatform current lineEnding >> >> > Keep you updated, >> > Guille >> > >> > On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > I think the idea is to use ZnCrPortableWriteStream for that. >> > >> > > On 15 Mar 2018, at 14:58, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> > > >> > > Hi all, >> > > >> > > how does one create a file stream in Pharo 7 that forces a specific >> > > line end convention ? For example, for forcing all end of lines to be >> > > Character lf. >> > > >> > > The old way, >> > > >> > > fileStream lineEndConvention: #'lf'. >> > > >> > > does not work anymore. >> > > >> > > Thanks, >> > > >> > > Thierry >> > > >> > >> > >> > >> > >> > >> > -- >> > >> > 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 >> > >> > Web: http://guillep.github.io >> > Phone: +33 06 52 70 66 13 >> >> >> > > > -- > > > > 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 <+33%206%2052%2070%2066%2013> >

March 16, 2018

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

by tesonep＠gmail.com

On Fri, Mar 16, 2018 at 3:26 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Pablo, > > Thanks for your quick reply. > > On 16 March 2018 at 14:38, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > Hi, > > sorry my mistake when updating the scripts. As the bootstrap.sh is > not > > executed during the Jenkins process it has not been validated (locally > I'm > > not using that script, because is trying to download each time the VM and > > the bootstraping process image) > > Right. Can we make one of the goals of the refactoring to avoid any > code duplication? > > e.g. at the moment (ignoring changes proposed below), Jenkins should > be calling bootstrap.sh. > > Yes that is part of the plan. > > > The correct line is the one from the JenkinsFile, it should be something > > like: > > > > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st > --ARCH=${architecture} > > --BUILD_NUMBER=${env.BUILD_ID} --quit > > > > I will submit a PR to fix it, as soon as the CI infrastructure is less on > > fire. > > Until the fix, if you are building the image locally you can change the > > error line with: > > > > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit > > > > And it will work. > > Shall do. > > > > The idea is to migrate more parts of the process to pure Pharo code, > > +1 > > > > everything is implemented in a project PharoBootstrapProcess, which is > > located in bootstrap/src in the same Pharo repository. > > The best way to check what is there is to do the same as the process. > > 1) Take an image with VMMaker, Espell and Ficus (we have them already > made > > in > > https://github.com/guillep/PharoBootstrap/releases/ > download/v1.4/bootstrapImage.zip). > > 2) Execute bootstrap/scripts/prepare_image.st > > > > That is the same image used to bootstrap Pharo. > > I will do another pass on this first part of the process and generate > some > > documentation about the changes and how to modify the whole process. > > We decided to migrate the process by parts to be able to review it easily > > than waiting to have a whole migration of the process. > > > > The next step is to do the same with the build.sh file, as you can see > it, > > is a little complex and have lots of steps. > > The idea is again convert them into Pharo code. > > Can we also re-order the bootstrap and break it into several distinct > phases. > > 1. Clean up (this ensures a clean environment for Jenkins) > 2. Download all pre-requisites. > The main change here is moving the call to download_vm.sh out of > build.sh. > This would allow a particular VM to be installed by hand for step > 4, see below. > 3. Initial preparation, i.e. all the execution prior to build.sh, e.g. > prepare_image.st. > Currently this is done with the Pharo 6 VM and image, which makes sense > as it > provides stability. > 4. Main image bootstrap. Which is done with the Pharo 7 VM (currently > what is in build.sh). > > That will allow the first three steps to be run once and then skipped > when doing personal development / testing. > > I want to be able to manually load the VM to be used in step 4 as part > of some stability testing so we can promote a new Pharo 7 VM to > stable. > > Are you open to me submitting some PRs that do this restructure to the > phases listed above and removing duplicate code from Jenkinsfile? > > Yes of course. Thanks > > > Again sorry if the partial change made some problems in your local > execution > > of the bootstrap. > > No problem. > > Thanks, > Alistair > > > > > Cheers. > > > > > > On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant <akgrant0710(a)gmail.com> > > wrote: > >> > >> Hi Pablo & Everyone, > >> > >> The bootstrap process seems to be in an inconsistent state at the > >> moment as the scripts in: > >> > >> - Jenkinsfile and > >> - bootstrap/scripts/bootstrap.sh > >> > >> don't match. > >> > >> bootstrap/scripts/bootstrap.sh has an error in it: > >> > >> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit > >> > >> fails because the "--quit" option is valid for the st handler > >> (executing a smalltalk file), but isn't recognised by the eval > >> handler. > >> > >> Can someone, Pablo?, confirm what the status is, what it should be and > >> what the next steps are? :-) > >> > >> Thanks, > >> Alistair > >> > > > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > -- Pablo Tesone. tesonep(a)gmail.com

March 16, 2018

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

by Alistair Grant

Hi Pablo, Thanks for your quick reply. On 16 March 2018 at 14:38, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, > sorry my mistake when updating the scripts. As the bootstrap.sh is not > executed during the Jenkins process it has not been validated (locally I'm > not using that script, because is trying to download each time the VM and > the bootstraping process image) Right. Can we make one of the goals of the refactoring to avoid any code duplication? e.g. at the moment (ignoring changes proposed below), Jenkins should be calling bootstrap.sh. > The correct line is the one from the JenkinsFile, it should be something > like: > > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --ARCH=${architecture} > --BUILD_NUMBER=${env.BUILD_ID} --quit > > I will submit a PR to fix it, as soon as the CI infrastructure is less on > fire. > Until the fix, if you are building the image locally you can change the > error line with: > > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit > > And it will work. Shall do. > The idea is to migrate more parts of the process to pure Pharo code, +1 > everything is implemented in a project PharoBootstrapProcess, which is > located in bootstrap/src in the same Pharo repository. > The best way to check what is there is to do the same as the process. > 1) Take an image with VMMaker, Espell and Ficus (we have them already made > in > https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapI…) > 2) Execute bootstrap/scripts/prepare_image.st > > That is the same image used to bootstrap Pharo. > I will do another pass on this first part of the process and generate some > documentation about the changes and how to modify the whole process. > We decided to migrate the process by parts to be able to review it easily > than waiting to have a whole migration of the process. > > The next step is to do the same with the build.sh file, as you can see it, > is a little complex and have lots of steps. > The idea is again convert them into Pharo code. Can we also re-order the bootstrap and break it into several distinct phases. 1. Clean up (this ensures a clean environment for Jenkins) 2. Download all pre-requisites. The main change here is moving the call to download_vm.sh out of build.sh. This would allow a particular VM to be installed by hand for step 4, see below. 3. Initial preparation, i.e. all the execution prior to build.sh, e.g. prepare_image.st. Currently this is done with the Pharo 6 VM and image, which makes sense as it provides stability. 4. Main image bootstrap. Which is done with the Pharo 7 VM (currently what is in build.sh). That will allow the first three steps to be run once and then skipped when doing personal development / testing. I want to be able to manually load the VM to be used in step 4 as part of some stability testing so we can promote a new Pharo 7 VM to stable. Are you open to me submitting some PRs that do this restructure to the phases listed above and removing duplicate code from Jenkinsfile? > Again sorry if the partial change made some problems in your local execution > of the bootstrap. No problem. Thanks, Alistair > Cheers. > > > On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> Hi Pablo & Everyone, >> >> The bootstrap process seems to be in an inconsistent state at the >> moment as the scripts in: >> >> - Jenkinsfile and >> - bootstrap/scripts/bootstrap.sh >> >> don't match. >> >> bootstrap/scripts/bootstrap.sh has an error in it: >> >> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit >> >> fails because the "--quit" option is valid for the st handler >> (executing a smalltalk file), but isn't recognised by the eval >> handler. >> >> Can someone, Pablo?, confirm what the status is, what it should be and >> what the next steps are? :-) >> >> Thanks, >> Alistair >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com

March 16, 2018

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

by Peter UhnÃ¡k

> 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 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- > 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. > > 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

Re: [Pharo-dev] Pharo 7 new file stream encoders

by Guillermo Polito

That should be fixed now. I proposed also the rename. I can revert it if needed. On Fri, Mar 16, 2018 at 1:04 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 16 Mar 2018, at 11:29, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Hi, > > > > Yes, I'll provide a PR with that functionality soon. Probably in that > case *ZnCrPortableWriteStream* is not the right name for that class. Sven, > do you think renaming it now (before it has lots of users) would be > acceptable towards backwards compatibility? Otherwise I would name it > ZnNewLineConverterStream... > > Renaming is OK/better, if it works (critical class in IO) > > Note #forPlatformLineEnding should do: OSPlatform current lineEnding > > > Keep you updated, > > Guille > > > > On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I think the idea is to use ZnCrPortableWriteStream for that. > > > > > On 15 Mar 2018, at 14:58, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > Hi all, > > > > > > how does one create a file stream in Pharo 7 that forces a specific > > > line end convention ? For example, for forcing all end of lines to be > > > Character lf. > > > > > > The old way, > > > > > > fileStream lineEndConvention: #'lf'. > > > > > > does not work anymore. > > > > > > Thanks, > > > > > > Thierry > > > > > > > > > > > > > > > -- > > > > 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 > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 > > > -- 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

March 16, 2018

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

by tesonep＠gmail.com

Hi, sorry my mistake when updating the scripts. As the bootstrap.sh is not executed during the Jenkins process it has not been validated (locally I'm not using that script, because is trying to download each time the VM and the bootstraping process image) The correct line is the one from the JenkinsFile, it should be something like: ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --ARCH=${architecture} --BUILD_NUMBER=${env.BUILD_ID} --quit I will submit a PR to fix it, as soon as the CI infrastructure is less on fire. Until the fix, if you are building the image locally you can change the error line with: ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit And it will work. The idea is to migrate more parts of the process to pure Pharo code, everything is implemented in a project PharoBootstrapProcess, which is located in bootstrap/src in the same Pharo repository. The best way to check what is there is to do the same as the process. 1) Take an image with VMMaker, Espell and Ficus (we have them already made in https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapI… ). 2) Execute bootstrap/scripts/prepare_image.st That is the same image used to bootstrap Pharo. I will do another pass on this first part of the process and generate some documentation about the changes and how to modify the whole process. We decided to migrate the process by parts to be able to review it easily than waiting to have a whole migration of the process. The next step is to do the same with the build.sh file, as you can see it, is a little complex and have lots of steps. The idea is again convert them into Pharo code. Again sorry if the partial change made some problems in your local execution of the bootstrap. Cheers. On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Pablo & Everyone, > > The bootstrap process seems to be in an inconsistent state at the > moment as the scripts in: > > - Jenkinsfile and > - bootstrap/scripts/bootstrap.sh > > don't match. > > bootstrap/scripts/bootstrap.sh has an error in it: > > ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit > > fails because the "--quit" option is valid for the st handler > (executing a smalltalk file), but isn't recognised by the eval > handler. > > Can someone, Pablo?, confirm what the status is, what it should be and > what the next steps are? :-) > > Thanks, > Alistair > > -- Pablo Tesone. tesonep(a)gmail.com

March 16, 2018

Re: [Pharo-dev] Idea to manager package comment in better way

by Denis Kudriashov

And at the end I found that #packageComment: is not really work because it expects already formatted string suitable for source code insertion. So you can't just call: aPackage packageComment: 'my comment'. Instead all users (only Nautilus exists) should write aPackage packageComment: 'my comment' printString I will create pull request with all this changes 2018-03-14 16:51 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > And I found that manifest classes are already commented as package comment. > > 2018-03-14 16:40 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi. >> >> I look at hierarchy of PackageManifest and I was wondering that all these >> classes are commented but most of packages which they describe are not. >> >> Also interesting that most of manifest comments are same. >> >> Then I found that package comment is managed as special class side method >> #description which is generated when you call "aPackage packageComment: >> 'test'". >> >> Now the idea: will not it be better to manage package comment as manifest >> class comment? >> >> Manifest is already responsible to describe the package. So it looks >> logical to have "manifest comment = package comment". >> Also it will simplify code and remove duplication of texts. >> In addition it will add extra place indicating that package needs to be >> commented because uncommented classes are marked in the browser. >> >> What you think? >> >> >

March 16, 2018

pharo bootstrap is in inconsistent state

by Alistair Grant

Hi Pablo & Everyone, The bootstrap process seems to be in an inconsistent state at the moment as the scripts in: - Jenkinsfile and - bootstrap/scripts/bootstrap.sh don't match. bootstrap/scripts/bootstrap.sh has an error in it: ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit fails because the "--quit" option is valid for the st handler (executing a smalltalk file), but isn't recognised by the eval handler. Can someone, Pablo?, confirm what the status is, what it should be and what the next steps are? :-) Thanks, Alistair

March 16, 2018

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

by Christophe Demarey

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.… <http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-installer-1.1-x86.…> > > 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

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

by Christophe Demarey

> Le 15 mars 2018 Ã 09:27, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > - OBS for the launcher (to have linux packaging) yes, would be nice > - signing the launcher on mac (we already did this for the VM, we can do the same for launcher). you sign the executable, so it mean signe the VM with another certificate => rebuild the VM > And distribute it as dmg, not zip (a dmg is just a zip renamed so no problem here). It is already a dmg. Did you try it? ;) > - a windows installer Here also, it is already like that. You forgot to mention: sign Windows app so that Windows Defender does not warn you that it is a malicious software and you should not install it Christophe

March 16, 2018