Hi, (For Esteban perhaps...) Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI. Pierce
We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work.... On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com> wrote:
Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
-- Mariano http://marianopeck.wordpress.com
I guess Esteban is busy as he is with Stef in Togo. I started porting to new FFI initial stuff and chatted with Esteban on Slack. When you use the latest Pharo 5 image (together with the spur VM) you have the new FFI right inside. Athens is running already on the new FFI. NB is still not unloaded - but it will be unloaded soon. The idea is that people can recover what they need afterwards. For some cases it should be straightforward to convert. A short summary of my findings: - check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 as of today The name is misleading - it is not the NativeBoost but the new FFI - check the new classes in this package that are prefixed with "FFI" like FFIExternalObject (replacement for NBExternalObject), FFIExternalStructure (replacement for NBExternalStructure), ... - If you generate fields from a struct the accessors are not generated into non-package "*generated-code-non-existing-package" but are now generated into method category "accessing structure variables" and will therefore be part of your MCZ code package - #nbCall: and #nbCall:module: work for compatibility, I guess we should add a deprecation to them - it is better to use ffiCall:, ffiCall:module: now - there is no need to have a pragma with NativeBoostPlugin anymore, at least it worked for me without it just by using #ffiCall: ... - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB since last week, but I guess the code in the image is more recent Problems I've experienced so far while trying to port my OS-Windows project: - FIICallout does not understand #optionAt:, no support for options like #WinUnicode so far - FFIExternalType sizeOf: #ulong failed - the spur VM for Windows does not include all latest fixes for Windows VM, like CTRL keys (https://pharo.fogbugz.com/f/cases/17289) Hope this helps a little bit until some more bugs are sorted out/a more detailed info for conversion is available. Bye T. Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr Von: "Mariano Martinez Peck" <marianopeck@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Preview of new FFI? We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work....  On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com> wrote:Hi, (For Esteban perhaps...) Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI. Pierce    -- Mariano http://marianopeck.wordpress.com[http://marianopeck.wordpress.com]
Hi, This is a good summary, thanks Torsten! Some notes between lines:
On 23 Dec 2015, at 13:30, Torsten Bergmann <astares@gmx.de> wrote:
I guess Esteban is busy as he is with Stef in Togo. I started porting to new FFI initial stuff and chatted with Esteban on Slack.
When you use the latest Pharo 5 image (together with the spur VM) you have the new FFI right inside. Athens is running already on the new FFI.
NB is still not unloaded - but it will be unloaded soon. The idea is that people can recover what they need afterwards. For some cases it should be straightforward to convert.
A short summary of my findings:
- check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 as of today The name is misleading - it is not the NativeBoost but the new FFI - check the new classes in this package that are prefixed with "FFI" like FFIExternalObject (replacement for NBExternalObject), FFIExternalStructure (replacement for NBExternalStructure), ... - If you generate fields from a struct the accessors are not generated into non-package "*generated-code-non-existing-package" but are now generated into method category "accessing structure variables" and will therefore be part of your MCZ code package
yes, you can rewrite the class side method #generatedFieldProtocolName if you still want an special protocol, but I do not see the need for it.
- #nbCall: and #nbCall:module: work for compatibility, I guess we should add a deprecation to them
yes, but that would mean I need to rewrite half of athens to change the methods so I preferred to let it like that for now :) I suppose a path like: transparent in pharo 5, deprecated in pharo 6 and non-exiting in pharo 7 is a good estimation to allow people (and me) to do all the changes. Is not a complicated task, of course⦠but needs to be done :)
- it is better to use ffiCall:, ffiCall:module: now
yes, it is.
- there is no need to have a pragma with NativeBoostPlugin anymore, at least it worked for me without it just by using #ffiCall: â¦
indeed :)
- there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB <http://smalltalkhub.com/#!/~Pharo/FFI-NB> since last week, but I guess the code in the image is more recent
mmm⦠it should be in sync, but I might be wrong. In that case, if someone can sync it, it will be cool.
Problems I've experienced so far while trying to port my OS-Windows project: - FIICallout does not understand #optionAt:, no support for options like #WinUnicode so far
no idea how to implement that, I will check it when Iâm back. Of course, it was previewed some functionality was going to be missing, but the idea is to add them as people report it.
- FFIExternalType sizeOf: #ulong failed
yes, I forgot to implement it. But in any case, that will be replaced by an âin imageâ approach so use it wisely :)
- the spur VM for Windows does not include all latest fixes for Windows VM, like CTRL keys (https://pharo.fogbugz.com/f/cases/17289 <https://pharo.fogbugz.com/f/cases/17289>)
not FFI related, Iâm aware of this⦠is just that I need time to merge latest 3 to 6 months changes in the VM to spur branch.
Hope this helps a little bit until some more bugs are sorted out/a more detailed info for conversion is available.
yes, Iâm working on documentation⦠but as always is not so easy⦠hopefully in next couple of weeks will be ready. cheers, Esteban
Bye T.
Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr Von: "Mariano Martinez Peck" <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Betreff: Re: [Pharo-dev] Preview of new FFI?
We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work....
On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com> wrote:Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
-- Mariano http://marianopeck.wordpress.com[http://marianopeck.wordpress.com] <http://marianopeck.wordpress.com[http://marianopeck.wordpress.com]>
On Wed, Dec 23, 2015 at 10:30 AM, Torsten Bergmann <astares@gmx.de> wrote:
I guess Esteban is busy as he is with Stef in Togo. I started porting to new FFI initial stuff and chatted with Esteban on Slack.
When you use the latest Pharo 5 image (together with the spur VM) you have the new FFI right inside. Athens is running already on the new FFI.
NB is still not unloaded - but it will be unloaded soon. The idea is that people can recover what they need afterwards. For some cases it should be straightforward to convert.
A short summary of my findings:
- check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 as of today The name is misleading - it is not the NativeBoost but the new FFI - check the new classes in this package that are prefixed with "FFI" like FFIExternalObject (replacement for NBExternalObject), FFIExternalStructure (replacement for NBExternalStructure), ... - If you generate fields from a struct the accessors are not generated into non-package "*generated-code-non-existing-package" but are now generated into method category "accessing structure variables" and will therefore be part of your MCZ code package - #nbCall: and #nbCall:module: work for compatibility, I guess we should add a deprecation to them - it is better to use ffiCall:, ffiCall:module: now - there is no need to have a pragma with NativeBoostPlugin anymore, at least it worked for me without it just by using #ffiCall: ... - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB since last week, but I guess the code in the image is more recent
Besides the list mentioned by Torsten, these are the ones I found out: - You now need #ffiLibraryName rather than #nbLibraryNameOrHandle - The #free you should send when you manually #allocate: now clears (put all zeros) in the handle. That means, you must free AFTER having read the value (like getting the handle integer) and kept it. With NB, the #free would only free the external side but would keep the internal value in the handle. That was handy because you could free the resources in one level, pass around the pointer, and get the number later. - Previously, a FFI call to a function that answered an opaque (FFIExternalObject subclass) as return value, AND the answer was a NULL, then NB would answer nil to the FFI call rather than a FFIExternalObject subclass instance. Now, it answers a instance of the FFIExternalObject subclass, which answers true to #isNull. - Previously you could #allocate: and get a NBExternalAddress (a pointer) which could be passed around to a FFI call whose type in the FFI call signature was itself a NBExternalAddress. Right now it seems the new FFI signature must be specified with "void*" ??
Problems I've experienced so far while trying to port my OS-Windows project: - FIICallout does not understand #optionAt:, no support for options like #WinUnicode so far - FFIExternalType sizeOf: #ulong failed
Yes, I would appreciate this too. I really need a "NBExternalType sizeOf: #ulong" so that we can easy the future transition to 64 bits. Right now I am hardcoding stuff ;)
- the spur VM for Windows does not include all latest fixes for Windows VM, like CTRL keys (https://pharo.fogbugz.com/f/cases/17289)
Hope this helps a little bit until some more bugs are sorted out/a more detailed info for conversion is available.
Bye T.
Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr Von: "Mariano Martinez Peck" <marianopeck@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Preview of new FFI?
We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work....
On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com> wrote:Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
-- Mariano http://marianopeck.wordpress.com[http://marianopeck.wordpress.com]
-- Mariano http://marianopeck.wordpress.com
thanks mariano Esteban may be some of the points are worth - documenting - or introducing the NB behavior. Stef Le 29/12/15 00:43, Mariano Martinez Peck a écrit :
On Wed, Dec 23, 2015 at 10:30 AM, Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>> wrote:
I guess Esteban is busy as he is with Stef in Togo. I started porting to new FFI initial stuff and chatted with Esteban on Slack.
When you use the latest Pharo 5 image (together with the spur VM) you have the new FFI right inside. Athens is running already on the new FFI.
NB is still not unloaded - but it will be unloaded soon. The idea is that people can recover what they need afterwards. For some cases it should be straightforward to convert.
A short summary of my findings:
- check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 as of today The name is misleading - it is not the NativeBoost but the new FFI - check the new classes in this package that are prefixed with "FFI" like FFIExternalObject (replacement for NBExternalObject), FFIExternalStructure (replacement for NBExternalStructure), ... - If you generate fields from a struct the accessors are not generated into non-package "*generated-code-non-existing-package" but are now generated into method category "accessing structure variables" and will therefore be part of your MCZ code package - #nbCall: and #nbCall:module: work for compatibility, I guess we should add a deprecation to them - it is better to use ffiCall:, ffiCall:module: now - there is no need to have a pragma with NativeBoostPlugin anymore, at least it worked for me without it just by using #ffiCall: ... - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB <http://smalltalkhub.com/#%21/%7EPharo/FFI-NB> since last week, but I guess the code in the image is more recent
Besides the list mentioned by Torsten, these are the ones I found out:
- You now need #ffiLibraryName rather than #nbLibraryNameOrHandle - The #free you should send when you manually #allocate: now clears (put all zeros) in the handle. That means, you must free AFTER having read the value (like getting the handle integer) and kept it. With NB, the #free would only free the external side but would keep the internal value in the handle. That was handy because you could free the resources in one level, pass around the pointer, and get the number later. - Previously, a FFI call to a function that answered an opaque (FFIExternalObject subclass) as return value, AND the answer was a NULL, then NB would answer nil to the FFI call rather than a FFIExternalObject subclass instance. Now, it answers a instance of the FFIExternalObject subclass, which answers true to #isNull. - Previously you could #allocate: and get a NBExternalAddress (a pointer) which could be passed around to a FFI call whose type in the FFI call signature was itself a NBExternalAddress. Right now it seems the new FFI signature must be specified with "void*" ??
Problems I've experienced so far while trying to port my OS-Windows project: - FIICallout does not understand #optionAt:, no support for options like #WinUnicode so far - FFIExternalType sizeOf: #ulong failed
Yes, I would appreciate this too. I really need a "NBExternalType sizeOf: #ulong" so that we can easy the future transition to 64 bits. Right now I am hardcoding stuff ;)
- the spur VM for Windows does not include all latest fixes for Windows VM, like CTRL keys (https://pharo.fogbugz.com/f/cases/17289)
Hope this helps a little bit until some more bugs are sorted out/a more detailed info for conversion is available.
Bye T.
Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr Von: "Mariano Martinez Peck" <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Betreff: Re: [Pharo-dev] Preview of new FFI?
We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work....
On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com <mailto:pierce@samadhiweb.com>> wrote:Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
-- Mariano http://marianopeck.wordpress.com[http://marianopeck.wordpress.com]
-- Mariano http://marianopeck.wordpress.com
if you are using *anything* of ASMJIT, nit just pars, you are in problems :) it will be removed as the VM does not support it by default anymore. now, if your âparts of ASMJITâ means you are doing nbCall:module:, structs, arrays, etcâ¦. then you are ok. (But if I would be you, I would be working on Pharo 5.0 since what we are asking you is for running there, not in Pharo 4). Of course, âyou are okâ but you will need to tweak some things here and there. Esteban
On 23 Dec 2015, at 12:55, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
We are in the same boat. Even worst, I suspect I am using some parts of ASMJIT which I guess won't be in new FFI, so I have on clue how I would make that parts to work....
On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce@samadhiweb.com <mailto:pierce@samadhiweb.com>> wrote: Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
as Torsten said, is in the image, and I cannot provide support until next week⦠Iâm counting the bytes here, to send mails :) but after that, of course I will provide support, documentation (Iâm already working on it), etc. Esteban
On 23 Dec 2015, at 12:16, Pierce Ng <pierce@samadhiweb.com> wrote:
Hi,
(For Esteban perhaps...)
Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI.
Pierce
On Wed, Dec 23, 2015 at 08:00:31PM +0000, Esteban Lorenzano wrote:
as Torsten said, is in the image, and I cannot provide support until next week⦠Iâm counting the bytes here, to send mails :) but after that, of course I will provide support, documentation (Iâm already working on it), etc.
Thanks. I'll check it out. And thanks to Torsten for the comprehensive summary. Pierce
participants (5)
-
Esteban Lorenzano -
Mariano Martinez Peck -
Pierce Ng -
stepharo -
Torsten Bergmann