[Pharo-dev] Working Directory Changes

Denis Kudriashov dionisiydk at gmail.com
Wed Oct 11 09:07:26 EDT 2017


2017-10-11 14:14 GMT+02:00 Alistair Grant <akgrant0710 at gmail.com>:

> On Wed, Oct 11, 2017 at 01:32:52PM +0200, Denis Kudriashov wrote:
> > 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.
>
>
> Would it make sense to add this to FilePlugin?  The plugin has to be
> working for general file system access anyway.
>

I think it is good idea


>
>
> Cheers,
> Alistair
>
>
> >     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
> >
> >         --
> >            [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
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171011/c2750659/attachment-0002.html>


More information about the Pharo-dev mailing list