FFI without the Pharo sources
Hi, I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore. Does someone (Esteban?) have a solution that I could implement to fix this issue? Thanks! Vincent
On 24 January 2018 at 08:54, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
Thanks!
Vincent
Is removing those files to reduce deployment size? Or to keep code private? Just guessing, but you may be able to file-out the FFI definitions, remove the .changes and .sources files, then file-in FFI definitons. You'll end up with a .changes file, but much smaller. cheers -ben
On 24 Jan 2018, at 01:54, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
Hello, You can embed the sources of just those methods: -> iterate over all methods, select the FFI methods -> call #embeddSourceInTrailer on these methods. Marcus
On 24 Jan 2018, at 08:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 24 Jan 2018, at 01:54, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
Hello,
You can embed the sources of just those methods: -> iterate over all methods, select the FFI methods -> call #embeddSourceInTrailer on these methods.
We should add later something to the compiler for this, too. Imagine you have your system without source, decompiling happily. Then you want to edit a method: -> if it was decompiled, just compile and drop source -> if the source comes from the trailer, it should again compile a method with embedded source. I make a note for my TODO. With Pavel we managed to speed up source reading for methods that have embeddSourceInTrailer quite a lot (with ideas for even more), I will start to merge these patches, too. Marcus
hi, Marcus approach swill work, yes. also, my idea was to reproduce what it was present for nativeboost before: - a command to search for all ffi calls and add a property of the methods with an array of the argument names - then modify method installation to look first for this property and take the argument names just if it is not found only difference is that with NB we searched for a pragma, now we have to search for senders of a list of âffi methodsâ #ffiCall: family and #nbCall: family to implement this is trivial⦠is just I didnât do it ;) Esteban
On 24 Jan 2018, at 09:31, Marcus Denker <marcus.denker@inria.fr> wrote:
On 24 Jan 2018, at 08:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 24 Jan 2018, at 01:54, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
Hello,
You can embed the sources of just those methods: -> iterate over all methods, select the FFI methods -> call #embeddSourceInTrailer on these methods.
We should add later something to the compiler for this, too. Imagine you have your system without source, decompiling happily. Then you want to edit a method: -> if it was decompiled, just compile and drop source -> if the source comes from the trailer, it should again compile a method with embedded source.
I make a note for my TODO.
With Pavel we managed to speed up source reading for methods that have embeddSourceInTrailer quite a lot (with ideas for even more), I will start to merge these patches, too.
Marcus
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
Thanks Vincent we are interested to make the independence on source much simpler. Stef On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
So if you implement a cool solution we will integrate it immediately :) On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
Hi, So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750 It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example: This FFI method should remember the name of the argument named "config": repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #() So, the FFI function should wear the pragma <ffiCalloutTranslator>: call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API. N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma. Cheers, Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources So if you implement a cool solution we will integrate it immediately :) On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
Thanks vincent. is it the comment of some classes? Stef On Wed, Jan 31, 2018 at 3:12 AM, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750
It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example:
This FFI method should remember the name of the argument named "config":
repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #()
So, the FFI function should wear the pragma <ffiCalloutTranslator>:
call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName
To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API.
N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma.
Cheers, Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
So if you implement a cool solution we will integrate it immediately :)
On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
Now, yes it is. See FFICompilerPlugin :) Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: mardi 30 janvier 2018 23:15 To: Pharo Development List Subject: Re: [Pharo-dev] FFI without the Pharo sources Thanks vincent. is it the comment of some classes? Stef On Wed, Jan 31, 2018 at 3:12 AM, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750
It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example:
This FFI method should remember the name of the argument named "config":
repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #()
So, the FFI function should wear the pragma <ffiCalloutTranslator>:
call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName
To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API.
N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma.
Cheers, Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
So if you implement a cool solution we will integrate it immediately :)
On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
I wil merge the PR after the test ran a last time.
On 31 Jan 2018, at 08:30, Vincent BLONDEAU <vincent.blondeau@polytech-lille.net> wrote:
Now, yes it is. See FFICompilerPlugin :)
Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: mardi 30 janvier 2018 23:15 To: Pharo Development List Subject: Re: [Pharo-dev] FFI without the Pharo sources
Thanks vincent. is it the comment of some classes?
Stef
On Wed, Jan 31, 2018 at 3:12 AM, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750
It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example:
This FFI method should remember the name of the argument named "config":
repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #()
So, the FFI function should wear the pragma <ffiCalloutTranslator>:
call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName
To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API.
N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma.
Cheers, Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
So if you implement a cool solution we will integrate it immediately :)
On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
Thanks Marcus! It seems that the tests are OK now: https://github.com/pharo-project/pharo/pull/750 Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Marcus Denker Sent: mardi 30 janvier 2018 23:40 To: Pharo Development List Subject: Re: [Pharo-dev] FFI without the Pharo sources I wil merge the PR after the test ran a last time.
On 31 Jan 2018, at 08:30, Vincent BLONDEAU <vincent.blondeau@polytech-lille.net> wrote:
Now, yes it is. See FFICompilerPlugin :)
Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: mardi 30 janvier 2018 23:15 To: Pharo Development List Subject: Re: [Pharo-dev] FFI without the Pharo sources
Thanks vincent. is it the comment of some classes?
Stef
On Wed, Jan 31, 2018 at 3:12 AM, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750
It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example:
This FFI method should remember the name of the argument named "config":
repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #()
So, the FFI function should wear the pragma <ffiCalloutTranslator>:
call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName
To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API.
N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma.
Cheers, Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
So if you implement a cool solution we will integrate it immediately :)
On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
:) Stef On Wed, Jan 31, 2018 at 8:30 AM, Vincent BLONDEAU <vincent.blondeau@polytech-lille.net> wrote:
Now, yes it is. See FFICompilerPlugin :)
Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: mardi 30 janvier 2018 23:15 To: Pharo Development List Subject: Re: [Pharo-dev] FFI without the Pharo sources
Thanks vincent. is it the comment of some classes?
Stef
On Wed, Jan 31, 2018 at 3:12 AM, <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
So, I suggest this solution: https://github.com/pharo-project/pharo/pull/750
It is a plugin for the OpalCompiler that can be activated with the command "FFICompilerPlugin install." The plugin is pragma-based to detect the methods where the arguments names should be remembered. The pragma should be added in the FFI API methods, i.e., the methods that are called by the FFI methods where the arguments have to be remembered. Example:
This FFI method should remember the name of the argument named "config":
repository_config: config ^ self call: #(#LGitReturnCodeEnum #git_repository_config #(#LGitConfig #* #config #, #self)) options: #()
So, the FFI function should wear the pragma <ffiCalloutTranslator>:
call: fnSpec options: options <ffiCalloutTranslator> ^ (self safeFFICalloutIn: thisContext sender) cdecl; options: options; function: fnSpec module: self ffiLibraryName
To remove to be able to remove the sources (.changes and .sources), you only have to activate the plugin, no recompilation is necessary. You can even import new FFI methods or change the FFI API.
N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> call:options:) also have to wear the pragma.
Cheers, Vincent
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Wednesday, January 24, 2018 9:21 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
So if you implement a cool solution we will integrate it immediately :)
On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Vincent we are interested to make the independence on source much simpler.
Stef
On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> <Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Thanks!
Vincent
_,,,^..^,,,_ (phone)
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 8:09 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources Hi Vincent, > On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> <Vincent.Blondeau@lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: > > Hi, > > I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore. > > Does someone (Esteban?) have a solution that I could implement to fix this issue? One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method. Hi Eliot, Ok. That seems the better solution. But you have to do that for only the FFI methods? Vincent > > Thanks! > > Vincent _,,,^..^,,,_ (phone)
On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau@lamresearch.com> wrote:
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <pharo-dev-bounces@lists.pharo.org>] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 8:09 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> < Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Hi Eliot,
Ok. That seems the better solution. But you have to do that for only the FFI methods?
Right. It would be very wasteful to do it for everything. Also, if there is a Pragma for the FFI information then an even nicer way to do it would be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in.
Vincent
Thanks!
Vincent
_,,,^..^,,,_ (phone)
-- _,,,^..^,,,_ best, Eliot
On Wed, Jan 24, 2018 at 10:21 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau@lamresearch.com> wrote:
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <pharo-dev-bounces@lists.pharo.org>] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 8:09 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources
Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com> < Vincent.Blondeau@lamresearch.com> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method.
Hi Eliot,
Ok. That seems the better solution. But you have to do that for only the FFI methods?
Right. It would be very wasteful to do it for everything. Also, if there is a Pragma for the FFI information then an even nicer way to do it would be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in.
Sorry, I don't mean that. Pgarmas are created when one tries to access a method's pragmas; they are ephemeral. Instead one could add a subclass of AdditionalMethodState. AdditionalMethodState holds the messages for pragmas and the properties. You can use the properties directly; they're a dictionary. But if you added a subclass, AdditionalFFIMethodState?, it could hold the temp names in an inst var.
Vincent
Thanks!
Vincent
_,,,^..^,,,_ (phone)
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 10:24 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources On Wed, Jan 24, 2018 at 10:21 AM, Eliot Miranda <eliot.miranda@gmail.com<mailto:eliot.miranda@gmail.com>> wrote: On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau@lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 8:09 To: Pharo Development List <pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] FFI without the Pharo sources Hi Vincent,
On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau@lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> <Vincent.Blondeau@lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote:
Hi,
I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore.
Does someone (Esteban?) have a solution that I could implement to fix this issue?
One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method. Hi Eliot, Ok. That seems the better solution. But you have to do that for only the FFI methods? Right. It would be very wasteful to do it for everything. Also, if there is a Pragma for the FFI information then an even nicer way to do it would be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in. Sorry, I don't mean that. Pgarmas are created when one tries to access a method's pragmas; they are ephemeral. Instead one could add a subclass of AdditionalMethodState. AdditionalMethodState holds the messages for pragmas and the properties. You can use the properties directly; they're a dictionary. But if you added a subclass, AdditionalFFIMethodState?, it could hold the temp names in an inst var. Ok Eliot! I put the args in a variable of the additional state for ffi that is created when a ffiCall selector is detected in the method at compilation. I think I could finish tomorrow the accessing to the arguments names when the sources vanishes. Thanks! Vincent Vincent
Thanks!
Vincent
_,,,^..^,,,_ (phone) -- _,,,^..^,,,_ best, Eliot -- _,,,^..^,,,_ best, Eliot
participants (7)
-
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Marcus Denker -
Stephane Ducasse -
Vincent BLONDEAU -
Vincent.Blondeau＠lamresearch.com