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

[Pharo 7.0-dev] Build #698: 21595 Use "instance creation" protocol in OSVMWindowHandle

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

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

March 16, 2018

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

by Stephane Ducasse

Hi denis Both solutions are ok for me. STef On Fri, Mar 16, 2018 at 2:38 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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

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

by Ben Coman

On 15 March 2018 at 16:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 15 Mar 2018, at 00:08, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > > On mer. 14 mars 2018 at 18:18, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> >> > On 9 Mar 2018, at 23:34, Torsten Bergmann <astares(a)gmx.de> wrote: >> > >> > Additional portable versions would be nice too (based on a simple ZIP) >> instead of only the installable apps >> > >> >> Is there a deeper reason for this? If I look at âother systemsâ, they >> manage to have *one* download, *one* way of installing. >> For me, offering *a lot* of possible different ways means that the user >> has to choose without knowing why there is even the option to chooseâ¦ >> > > The problem is that Pharo is different from other systems. When you > install eclipse, you'll use the installed eclipse for all your projects for > a long time. > > Pharo images are more like a "disposable". You'll not use the same Pharo > image for multiple big projects and you'll more easily throw away an image > to take a new one from time to time. > > Actually I think I download and delete around 5 images/day sometime. > > This complicate a little things because sometime you want to directly > download one image. Sometime you want to have one application to manage > your images (Pharo launcher) > > For me, the Launcher should be the âVM Downloadâ, that comes with a) a > default template image of the release and b) the launcher too to discover > images. > > *But* it should be done in a way that you can of course just download more > images (and I would love to have images actually being âone fileâ) and, > having Pharo installed, you can run them, using the âPharoâ that you have > installed (the launcher). > > The âLauncherâ should feel more like âI have installed Pharo, now I can > run imagesâ. > > As such, I think we should add back links that point to single image > downloads on the download page. > > Marcus > I'm really glad PharoLauncher has been promoted to the download page, but it seems some people want to push PharoLauncher to *be* Pharo. To me this seems a poor strategy. The README file in the PharoLauncher zip downloads says... "Pharo 1.1-2018.01.16 This distribution was built January 16, 2018." This seems strange to me and highly likely to confuse newcomers. Pharo 1.1 more than a few years old. How can something built in 2018 be named "Pharo 1.1" ? And if PharoLauncher is instead published as Pharo 7, then it seems strange to use it to run Pharo 5 images and later Pharo 8 images. Why not have the Downloads page just say "The recommended way to manage Pharo downloads is with PharoLauncher" and allow PharoLauncher to exist as a separate entity. This would be similar similar to those applications where you download an initial 500kB installer, which then grabs the other 100MB from the net to complete the install. Also, when maybe one day we can use Pharo as a command line shell, how will that relate to PharoLauncher being presented "as" Pharo. cheers -ben P.S. Perhaps the idea of App Store has some similarities to PharoLauncher, since in an App Store you search for programs to download and run. A further evolution of PharoLauncher might become PharoStore Now Apple's app store is not called "OSX" and Microsoft's app store is not called "Windows". They are separate entities .

March 16, 2018

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

by Esteban Lorenzano

but thing is: default download should be the launcher. because this is the ânewbie-friendlyâ approach. All the rest can be in under a link (or a subtitle, doesnât matters). Esteban > On 16 Mar 2018, at 08:50, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I do not see why this is a problem to have the launcher and Pharo. > The launcher is an App and Pharo another. > Yesterday the launcher crashed on Windows when I tried to pair program > with someone so we downloaded > the default Pharo version. > Why do we want to make things complex. > > You want Pharo > - donwload it > > You want to manage your pharo devs and access jenkins and other services > - use the launcher. > > Stef > > On Thu, Mar 15, 2018 at 3:38 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> -> better structure >> -> simplified the large print (no need to talk about downloading zip files) >> >> TODO: >> - add back a section about downloading images. >> >>> On 14 Mar 2018, at 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Ok, I will fix that in the next pass. >>> >>>> On 9 Mar 2018, at 18:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> >>>> Marcus Denker-4 wrote >>>>> comments welcomeâ¦ >>>> >>>> IHMO the structure is a little confusing because the first heading "Usage" >>>> (Launcher implied) is on the same level as other methods like "Linux >>>> Packages". I think there needs to be something like a header one level >>>> higher like "Other Options" between these two sections. >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>> >> >> >

March 16, 2018

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