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 :)
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 :)
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
ByeT. Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 UhrVon: "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 workwith SQLcipher (for transparent database encryption) but don't want to spendany effort refactoring if I need to redo for the new FFI.Pierce --Marianohttp://marianopeck.wordpress.com[http://marianopeck.wordpress.com]