[Pharo-dev] Working Directory Changes

Denis Kudriashov dionisiydk at gmail.com
Wed Oct 11 07:32:52 EDT 2017


2017-10-11 10:54 GMT+02:00 Esteban Lorenzano <estebanlm at 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 at 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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171011/6b23c792/attachment-0002.html>


More information about the Pharo-dev mailing list