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

[Pharo 7.0-dev] Build #179: 20352-FileStream-and-related-classes-need-to-be-moved-into-different-package

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

There is a new Pharo build available! The status of the build #179 was: SUCCESS. The Pull Request #229 was integrated: "20352-FileStream-and-related-classes-need-to-be-moved-into-different-package" Pull request url: https://github.com/pharo-project/pharo/pull/229 Issue Url: https://pharo.fogbugz.com/f/cases/20352 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2017

[Pharo 7.0-dev] Build #178: 20507 Typos in QACritiqueTest

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

There is a new Pharo build available! The status of the build #178 was: SUCCESS. The Pull Request #339 was integrated: "20507 Typos in QACritiqueTest" Pull request url: https://github.com/pharo-project/pharo/pull/339 Issue Url: https://pharo.fogbugz.com/f/cases/20507 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Torsten Bergmann

Yes - but with having #getCurrentDirectory as a primitive you have a clean interface and boundary to the underlying platform and can nonetheless provide them even when a (sandboxed) VM might not allow external calls. So for instance SqueakJS is able to run in the browser - even when the browser does usually not offer a file system or native calls. So Berts JavaScript implementation of the VM primitives just mocks the file system primitives I guess and it just continues to work. This allows to put the Smalltalk systems (Squeak, Pharo, Cuis, ...) into a sandbox which might be good/necessary for safe environments like cloud based solutions or other. I'm interested in a good command line support too - but we should think also about such scenarios because they make our future even brighter. Side note: The original Squeak VM has the possibility to limit write access only to a sandbox directory (UserDirectory and SecureDirectory) as an example: http://squeakvm.org/win32/settings.html Thanks T. Am 11.10.2017 um 11:08 schrieb Pavel Krivanek: > > > 2017-10-11 10:48 GMT+02:00 Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>>: > > For "safe" environments it would not make sense to offer already > in a minimal base support for > "unsafe" foreign calls and an (U)FFI. > > > They are always accessible as soon as the VM supports them. You can > call FFI calls and do not have any FFI code in the image. To do not > have FFI in the image does not make it safer. > > -- Pavel > > > Out of curiosity: why not moving this to the VM itself to provide > as a service to the image? > > Thanks > T. > > > Am 11.10.2017 um 10:27 schrieb Guillermo Polito: > > 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/ > <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 > <https://github.com/pharo-project/pharo/pull/92> > > > Thanks, > Guille, Pablo and Rajula > > -- > > > > 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 <tel:%2B33%2006%2052%2070%2066%2013> > > > >

Oct. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Pavel Krivanek

2017-10-11 10:48 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > For "safe" environments it would not make sense to offer already in a > minimal base support for > "unsafe" foreign calls and an (U)FFI. > They are always accessible as soon as the VM supports them. You can call FFI calls and do not have any FFI code in the image. To do not have FFI in the image does not make it safer. -- Pavel > > Out of curiosity: why not moving this to the VM itself to provide as a > service to the image? > > Thanks > T. > > > Am 11.10.2017 um 10:27 schrieb Guillermo Polito: > >> 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 >> >> -- >> >> >> >> 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 >> >> > >

Oct. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Esteban Lorenzano

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. 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/ <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 <https://github.com/pharo-project/pharo/pull/92> > > > Thanks, > Guille, Pablo and Rajula > > -- > > 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. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Torsten Bergmann

For "safe" environments it would not make sense to offer already in a minimal base support for "unsafe" foreign calls and an (U)FFI. Out of curiosity: why not moving this to the VM itself to provide as a service to the image? Thanks T. Am 11.10.2017 um 10:27 schrieb Guillermo Polito: > 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 > > -- > > > > 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 >

Oct. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Pavel Krivanek

>From my experiments to execute FFI calls without FFI packages in the image I know that we can do it without it on even lower level but then we will anyway need to somehow handle library paths and so on. So to add these small packages into the bootstrapped kernel is totally reasonable and will open a lot of next possibilities. So definitely yes! Cheers, -- Pavel 2017-10-11 10:27 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > 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 > > -- > > > > 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> >

Oct. 11, 2017

Working Directory Changes

by Guillermo Polito

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 -- 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. 11, 2017

DelaySpinScheduler and DelayExperimentalSpinScheduler

by Torsten Bergmann

Two questions from https://pharo.fogbugz.com/f/cases/20510 1. DelaySpinScheduler needs a good comment. Anyone? 2. DelayExperimentalSpinScheduler is not used, can we remove it?

Oct. 11, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #176: 20505-The-special-objects-array-needs-to-be-recreated-during-bootstrap

by Guillermo Polito

On Tue, Oct 10, 2017 at 2:46 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi Guille, > > For "First": > I looked into this problem with Pavel this morning. The special object > array being incorrectly created leads to problems when a large object > (bigger that growthHeadroom) is created, as it does not go through the > handleFailingBasicNew methods. Typically, Pavel could not load Seaside into > the minimal image because of that. The problem lies with the initialization > of error codes. > Yes we were discussing this with Pavel yesterday too. I pointed him to look for your blogpost on sunday when he would not load seaside :). We I meant is that this should have been in a comment at least in the pull request. Otherwise your private discussion gets lost... > > For "Second": > I don't mind what you do as long as it solves the problem of large > allocations on minimal images. In any case the problems lies with the error > code symbols, so that the code in basicNew: > ec == #'insufficient object memory' ifTrue: > [^self handleFailingBasicNew: sizeRequested]. > takes the correct branch. Before Pavel's change, the condition was false > during bootstrap leading to large allocation crashing the VM, ec was equal > to 9 instead of #'insufficient object memory', since the error codes in > the special object array were incorrectly initialized somehow. > Yes, I understand the error. Now, I was crunching it a bit yesterday, and this looks too error prone. This has a super hidden dependency with the special objects array. I ask myself: do we want this to fail when the special object's array changes? What if somebody suddenly tries to "fix a typo" in the error message and forgots to update the special object's array? Moreover, Why not doing ec == ((Smalltalk specialObjectsArray at: 53) at: 9) ifTrue: [^self handleFailingBasicNew: sizeRequested]. And why not adding also a guard in case ec == 9? ec == 9 ifTrue: [^self handleFailingBasicNew: sizeRequested]. ec == ((Smalltalk specialObjectsArray at: 53) at: 9) ifTrue: [^self handleFailingBasicNew: sizeRequested]. Like that the fallback code could be a bit more robust. What do you think? > > PS: Who is nobody ? > > Cheers > > > On Tue, Oct 10, 2017 at 2:04 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Pavel, >> >> I don't like this change. >> >> First, there is no comment nor explanation why that is needed. This >> change is obscure, if we forget in a couple of months why that line of code >> is there we may >> - delete it unintentionally >> - or leave it forever and fear to clean it up because we do not >> understand it :( >> >> Second, It looks that recreating the special objects array there, like >> that, means that it was not correctly created from the beginning. We should >> instead create it correctly from the beginning. >> >> I think we should revert this change. >> >> On Tue, Oct 10, 2017 at 12:24 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: >> >>> There is a new Pharo build available! >>> >>> The status of the build #176 was: SUCCESS. >>> >>> The Pull Request #336 was integrated: "20505-The-special-objects-arr >>> ay-needs-to-be-recreated-during-bootstrap" >>> Pull request url: https://github.com/pharo-project/pharo/pull/336 >>> >>> Issue Url: https://pharo.fogbugz.com/f/cases/20505 >>> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >>> ull%20request%20and%20branch%20Pipeline/job/development/176/ >>> >> >> >> >> -- >> >> >> >> 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> >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > -- 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. 11, 2017