2017-10-11 14:14 GMT+02:00 Alistair Grant <akgrant0710@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@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@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 -
Web: http://guillep.github.io Phone: +33 06 52 70 66 13