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