[Pharo-dev] Working Directory Changes

Torsten Bergmann astares at gmx.de
Wed Oct 11 05:31:02 EDT 2017


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 at gmx.de 
> <mailto:astares at 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>
>
>
>
>





More information about the Pharo-dev mailing list