- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Working Directory Changes

by Alistair Grant

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

Oct. 11, 2017

Re: [Pharo-dev] DelaySpinScheduler and DelayExperimentalSpinScheduler

by Ben Coman

On Wed, Oct 11, 2017 at 4:24 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Two questions from https://pharo.fogbugz.com/f/cases/20510 > > 1. DelaySpinScheduler needs a good comment. Anyone? > Sorry I should have done better. I'll do it now. > > 2. DelayExperimentalSpinScheduler is not used, can we remove it? > yes. I'll do it at the same time. cheers -ben

Oct. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Denis Kudriashov

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

[Pharo 7.0-dev] Build #181: 20508 Class SystemVersionTest need to move to package "System-Support-Tests"

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

There is a new Pharo build available! The status of the build #181 was: SUCCESS. The Pull Request #342 was integrated: "20508 Class SystemVersionTest need to move to package "System-Support-Tests"" Pull request url: https://github.com/pharo-project/pharo/pull/342 Issue Url: https://pharo.fogbugz.com/f/cases/20508 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2017

[Pharo 7.0-dev] Build #180: 20506-Fix-special-objects-array

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

There is a new Pharo build available! The status of the build #180 was: SUCCESS. The Pull Request #338 was integrated: "20506-Fix-special-objects-array" Pull request url: https://github.com/pharo-project/pharo/pull/338 Issue Url: https://pharo.fogbugz.com/f/cases/20506 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 Mariano Martinez Peck

Hi Guille, I think some time ago we discussed exactly this or at least very similar [1]. AFAIR, we didn't arrive to an agreement. Or maybe we did but I was never able to implement it, I don't remember. But I would appreciate if you can at least read the discussion to see if there is something worth considering with your new changes. Cheers, [1] http://forum.world.st/Discussing-FileSystem-gt-gt-workingDirectory-and-VM-p… On Wed, Oct 11, 2017 at 5:27 AM, 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 > > -- > > > > 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 <06%2052%2070%2066%2013> > -- Mariano http://marianopeck.wordpress.com

Oct. 11, 2017

[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