October 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo 7.0-dev] Build #135: 20434-use-Ring2-during-the-bootstrap

by Marcus Denker

> On 20 Sep 2017, at 11:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > More infos about Ring2: > > https://www.slideshare.net/esug/metamodeling-of-custom-pharo-images > Video is just now online (even not public yet ;-) : https://www.youtube.com/watch?v=RfalKwgvf0I <https://www.youtube.com/watch?v=RfalKwgvf0I> Marcus

Oct. 12, 2017

Re: [Pharo-dev] [Spec] ComposableModel renamed to ComposablePresenter

by Sean P. DeNigris

Pavel Krivanek-3 wrote > To be sure that most of the current code which uses the old name will > work, > we created for every renamed class a subclass with the old name. These > subclasses are moved (mostly) into Spec-Deprecated package. Ah, nice trick. Thanks for easing the transition. Pavel Krivanek-3 wrote > it is necessary to make the Spec code less confusing. Sounds good. I often needed a mental pause to translate "model" from "domain model" to "something modelling a UI on the domain model". ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2017

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

by Torsten Bergmann

Another side effect 4. You receive the announce mail for the build http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-October/dat… for 185 being ready much ealier than 183 and 184 So while order should be 183, 184, 185 we today have 185, 183, 184 with 184 now being latest ... > Hi, > > today there was an interesting effect visible for the Pharo build on CI for Pharo 7: > > Esteban merged three contributions for Pharo 7 into #development (see [1]). All three merges on git triggered the CI. > For each a separate build for Pharo 7 started on CI independently. > > While usually one would expect the builds in regular build order 183, 184, 185 the CI job for building 185 job was faster > (as you can see on the attached screenshot). > > So the 185 series of images was copied first to the file server [3] because the job was already finished. > Afterwards 183 build completed on CI and these images were copied to the file server with a newer timestamp. > > So you have the order 185, 183 with 183 having the files with the newest timestamp (but not being the most recent state of Pharo). > > This leads to several unfortunate effects: > 1. When you sort on file server [3] descending by date the build 183 images are newer than the build 185 images > 2. When you use PharoLauncher to download "latest-32" you get an 183 image instead of the "real latest" 185 image > 3. When you ask Zeroconf to download the latest using http://get.pharo.org/70+vm you also get 183 instead of the already > available 185 > > So as the CI build of an older "update" (here 183) finished later than the most recent version (here 185) > you get 183 as "latest" instead of 185. > > Any ideas how we could avoid such a side effect? Maybe a chain on the builds so 183 has to finished before 184 and 185 could be > built? > > Thx > T. > > > > [1] https://github.com/pharo-project/pharo/commits/development > [2] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > [3] http://files.pharo.org/image/70/ >

Oct. 12, 2017

CI Build order and strange "latest" Pharo 7 effect

by Torsten Bergmann

Hi, today there was an interesting effect visible for the Pharo build on CI for Pharo 7: Esteban merged three contributions for Pharo 7 into #development (see [1]). All three merges on git triggered the CI. For each a separate build for Pharo 7 started on CI independently. While usually one would expect the builds in regular build order 183, 184, 185 the CI job for building 185 job was faster (as you can see on the attached screenshot). So the 185 series of images was copied first to the file server [3] because the job was already finished. Afterwards 183 build completed on CI and these images were copied to the file server with a newer timestamp. So you have the order 185, 183 with 183 having the files with the newest timestamp (but not being the most recent state of Pharo). This leads to several unfortunate effects: 1. When you sort on file server [3] descending by date the build 183 images are newer than the build 185 images 2. When you use PharoLauncher to download "latest-32" you get an 183 image instead of the "real latest" 185 image 3. When you ask Zeroconf to download the latest using http://get.pharo.org/70+vm you also get 183 instead of the already available 185 So as the CI build of an older "update" (here 183) finished later than the most recent version (here 185) you get 183 as "latest" instead of 185. Any ideas how we could avoid such a side effect? Maybe a chain on the builds so 183 has to finished before 184 and 185 could be built? Thx T. [1] https://github.com/pharo-project/pharo/commits/development [2] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… [3] http://files.pharo.org/image/70/

Oct. 12, 2017

[Pharo 7.0-dev] Build #184: System-Hashing: Fix some comments

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

There is a new Pharo build available! The status of the build #184 was: SUCCESS. The Pull Request #346 was integrated: "System-Hashing: Fix some comments" Pull request url: https://github.com/pharo-project/pharo/pull/346 Issue Url: https://pharo.fogbugz.com/f/cases/hashing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 12, 2017

[Pharo 7.0-dev] Build #183: 20523-MCOrganizationDefinition-lacks-hash-method

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

There is a new Pharo build available! The status of the build #183 was: SUCCESS. The Pull Request #348 was integrated: "20523-MCOrganizationDefinition-lacks-hash-method" Pull request url: https://github.com/pharo-project/pharo/pull/348 Issue Url: https://pharo.fogbugz.com/f/cases/20523 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 12, 2017

[Spec] ComposableModel renamed to ComposablePresenter

by Pavel Krivanek

Hello, important change for the Spec users. In "The Spec UI Framework" book you can read: Considering the construction and orchestration of the different widgets in > a user interface, Spec is inspired by the Model-View-Presenter pattern. The > model that is defined in Spec corresponds to a presenter in the MVP triad. > Note that because of this, future versions of Spec may rename the > ComposableModel into ComposablePresenter for naming consistency. This change was done in the Pharo 7 development images by this pull request: https://github.com/pharo-project/pharo/pull/344 All other Spec presenters that use suffix -Model were renamed too to end with -Presenter suffix. This is the complete list: AbstractFormButtonModel AbstractWidgetModel ButtonModel CheckBoxModel ComposableModel ContainerModel DateModel DialogWindowModel DiffModel DropListModel DynamicComposableModel FastTableModel IconListModel ImageModel LabelModel ListModel ListSelectionModel MenuGroupModel MenuItemModel MenuModel MultiColumnListModel PickListModel RadioButtonGroupModel RadioButtonModel SliderModel TabManagerModel TabModel TableContainerModel TestingComposableModel TextInputFieldModel TextModel TickingWindowModel TransferModel TreeColumnModel TreeModel TreeNodeModel WindowModel WorldModel To be sure that most of the current code which uses the old name will work, we created for every renamed class a subclass with the old name. These subclasses are moved (mostly) into Spec-Deprecated package. Currently such deprecation does not make any action so no exception is generated nor no code is rewritten. We will add such mechanisms in future as soon as most users and documentation will adopt his change. This deprecation can cause problems in two cases: you use code like 'isKindOf:' or if your package adds extension methods to the basic Spec classes. To rename these classes was only the first step. We need to rename some Spec tests classes and mainly touch methods like *instantiateModels:* and later make them deprecated. We are sorry for troubles that these changes can cause but it is necessary to make the Spec code less confusing. Cheers, -- Pavel

Oct. 12, 2017

[Pharo 7.0-dev] Build #185: 20513-Rename-ComposableModel-to-ComposablePresenter

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

There is a new Pharo build available! The status of the build #185 was: SUCCESS. The Pull Request #344 was integrated: "20513-Rename-ComposableModel-to-ComposablePresenter" Pull request url: https://github.com/pharo-project/pharo/pull/344 Issue Url: https://pharo.fogbugz.com/f/cases/20513 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 12, 2017

Re: [Pharo-dev] Working Directory Changes

by Alistair Grant

Hi Guille, On Thu, Oct 12, 2017 at 11:53:15AM +0200, Guillermo Polito wrote: > > ** The most important argument, that at least I did not see anybody complain > about, is backwards compatibility. This implementation may break backwards > compatibility, because this does not hold anymore: > > FileSystem imageDirectory == FileSystem workingDirectory > > Well, yes, it holds if you start your vm/image from the same directory where > the image is located. Which is what most users do. > I gave poor Rajula quite a bit of trouble over this concern. The end result was that several people replied to say they don't care. I later found out that this assumption was only introduced about half way through Pharo 6 development. Prior to that it was possible to change the workingDirectory as it was stored in an instance variable that could be changed. So there will be very little code in existence that makes this assumption. Cheers, Alistair

Oct. 12, 2017

Re: [Pharo-dev] Working Directory Changes

by Guillermo Polito

Hi all, Now I had some minutes to take a further look at this. ** Mariano, yes, I remember that conversation. What we propose is aligned to that: FileSystem workingDirectory shouldBe == getcwd And **almost always** FileSystem workingDirectory shouldBe == $PWD This is because the real working directory is the one held by the process. $PWD is managed by bash and it can get out of sync with getcwd. For more info take a look at rajula's blogpost in the first email. ** About security, I don't really buy the argument. - There are many aspects of security: internal in the image, external. FFI is not the only thing to *care about* - right now we can do stuff like - FileSystem root ensureDeleteAll (and given pharo started with sudo...) - nil become: true - OpalCompiler compile: 'someMethodThatOverriddenBreaksEverything ...' - FFI plugin is shipped with the VM - so removing FFI support is as easy as removing the plugin - but this means that even if that FFI support is not in the image, any piece of code can do: - Myclass compile: 'test Metacello install: ''FFI''; please'; test. - or create a method calling the FFI primitives This does not mean I don't think about security, but I believe it should be managed in some other way. A security solution for real needs to manage reflection as well as external resources, and control how dependencies and packages are loaded. Because, moreover, I believe that while you may want to forbid FFI calls in some part of your app, you may want that some other parts of the system can use FFI. ** About modularity. But I'm sure I'm one of the guys that cares the most about modularity and cries aloud every time we introduce bad dependencies. Now, I'm proposing the introduction of FFI because I think its manageable and it's being controlled. It does not affect the bootstrap, and I don't think it will forbid us to get even smaller kernels. ** The most important argument, that at least I did not see anybody complain about, is backwards compatibility. This implementation may break backwards compatibility, because this does not hold anymore: FileSystem imageDirectory == FileSystem workingDirectory Well, yes, it holds if you start your vm/image from the same directory where the image is located. Which is what most users do. ** I also talked with Esteban about his reasons. His concern was about consistency. If you take a look at how getEnv is resolved: getEnv: varName "This method calls the Standard C Library getenv() function." "OSEnvironment current getEnv: 'HOME' " <primitive: 'primitiveGetenv' module: '' error: ec> ec ifNil: [ ^self getEnvViaFFI: varName ]. ec == #'bad argument' ifTrue: [ varName isString ifFalse: [ ^self getEnv: varName asString ] ]. self primitiveFail If first tries to call a primitive and then, as fallback, it calls FFI by default. I changed the pull request to do the same thing about the working directory. That way, as soon as we have implemented the primitive, that will be in usage instead of the FFI call. Guille On Wed, Oct 11, 2017 at 3:07 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-10-11 14:14 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > >> On Wed, Oct 11, 2017 at 01:32:52PM +0200, Denis Kudriashov wrote: >> > 2017-10-11 10:54 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> > >> > in general, this core-core functions is better to implement them as >> > primitives. >> > and you put a fallback using UFFI (in case the primitive is not >> there). >> > of course, your solution works? but it adds dependency with >> FFI-Kernel, >> > which is also not good to have it in the bootstrap IMO. >> > >> > take a look at OSEnvironment>>getEnv implementation. >> > >> > we can go that direction and I think it will be better. >> > >> > >> > +1 for new primitive. Because instead any new platform will require >> implemented >> > FFI which is not easy. >> >> >> Would it make sense to add this to FilePlugin? The plugin has to be >> working for general file system access anyway. >> > > I think it is good idea > > >> >> >> Cheers, >> Alistair >> >> >> > Esteban >> > >> > >> > On 11 Oct 2017, at 10:27, Guillermo Polito < >> guillermopolito(a)gmail.com> >> > wrote: >> > >> > Hi all, >> > >> > I'd like to push a really core change in file management: the >> working >> > directory. This is really needed for command line apps, when >> you have >> > your app deployed in some directory and you're launching it from >> > another one. The current implementation, where workingDirectory >> = >> > imageDirectory, forces to have absolute paths or extra handling >> all >> > over the place to manage this complexity. >> > >> > Rajula proposed a couple of months ago a solution for this >> based on the >> > getcwd functions. You can read in his blogpost why using getcwd >> is >> > better than $PWD in general here: >> > >> > https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/ >> > >> > Now, since accessing the working directory is a core part of >> Pharo but >> > based on UFFI, his implementation was breaking the build >> process. We >> > cannot and we will not integrate UFFI in the bootstrap because >> it >> > depends mainly on the compiler which is a big beast. Instead, I >> propose >> > that only for this core-core-core feature, we use directly FFI. >> > >> > In other words, the bootstrap will include just a couple of >> classes to >> > manage the basics of FFI. And the working directory will be >> fetched by >> > using this low level API. Such a call looks like this: >> > >> > (ExternalLibraryFunction >> > name: 'getcwd' >> > module: 'libc.dylib' >> > callType: 1 >> > returnType: ExternalType char asPointerType >> > argumentTypes: { >> > ExternalType char asPointerType. >> > ExternalType long }) >> > invokeWith: buffer with: bufferSize. >> > >> > We reviewed it with Pablo two days ago. The build process works >> with >> > this implementation and tests are still running. The pull >> request is in >> > here: >> > >> > https://github.com/pharo-project/pharo/pull/92 >> > >> > >> > Thanks, >> > Guille, Pablo and Rajula >> > >> > -- >> > [presentation] Guille Polito >> > [CNRS-filaire] 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

Oct. 12, 2017