[Pharo-dev] Working Directory Changes

Esteban Lorenzano estebanlm at gmail.com
Wed Oct 11 04:54:45 EDT 2017


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171011/1be7fbd9/attachment-0002.html>


More information about the Pharo-dev mailing list