> On 15 Oct 2015, at 17:35, Robert Withers <[email protected]> wrote: > > > > On 10/15/2015 10:51 AM, Jimmie Houchin wrote: >> Thanks for the example. >> >> On 10/15/2015 09:04 AM, Esteban Lorenzano wrote: >>> >>>> On 15 Oct 2015, at 15:50, Jimmie Houchin >>>> <<mailto:[email protected]>[email protected]> wrote: >>>> >>>> Yes, we need excellent FFI. I would love to see in Pharo FFI as easy >>>> as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. >>>> And I do not know how possible, how much effort or likely it is. >>> >>> in pharo a FFI call is as easy as: >>> >>> copy: source to: dest >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>> errorCode> >>> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: >>> ‘libc’. >>> >>> we can improve performance, but I do not think we will succeed on make >>> it easier than that. >>> >>> of course, someone could do a symbol introspector (and I think someone >>> already did something to interpret header files), to be able to have >>> things like: >>> >>> LibC.strcpyWith: dest with: source >>> >>> but I do not thing is a big win over the first one. >>> >>> Esteban >> >> That does not look to difficult. >> >> Now my current problem is that we are being told that NativeBoost is >> going away. Then what does FFI look like and with what? >> >> The main problem I had with NativeBoost is that it had problems I >> couldn't understand or fix. And problems that Igor didn't have time for. >> I was writing a wrapper around a proprietary library. The small part I >> had written to test out Pharo and NB worked on Windows and crashed in >> Linux. Exact same code. >> >> This message from April 3, 2013 is my request for help. >> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html >> >> I never got anywhere with that project. Thus goes my tortured history >> with Pharo and programming. Not a judgment against Igor or Pharo. I know >> the resources of both are stretched to the max. And I am complicit in >> the problem as I have to few skills to help myself. So it did and >> sometimes does, send me on programming journeys to explore other >> languages and tools to empower me within my abilities. I could have done >> that project in LuaJIT or Julia when it matures a little more. Julia >> might be approaching that point. >> >> My torture is pursuing the language/environment I enjoy, Pharo. Which >> sometimes can or sometimes can not easily do what I need within my skill >> set. Or pursuing learning other languages and tools which are better at >> integrating other external libraries. Or do to the much larger >> communities have already ready to use wrappers around most anything you >> want to do. >> >> I am no longer pursuing that project. My requirements have changed and I >> do not require wrapping a proprietary C library. >> >> I am reticent to invest in learning FFI that is changing without an idea >> of the direction of the change. So at the moment I am studying SQL and >> then possibly spend some time learning C so that I can better help >> myself and the community and not be as dependent. That way when the dust >> settles on the FFI as will be in Pharo5/6. I can hopefully be better to >> use and contribute. > > Exactly right, I feel the same way. I thank you for expressing yourself > thusly and being a mirror in words of my own passion.
FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with it… we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :) but well… in the mean time we learn and do steps. We will have a cool FFI, don’t worry… sooner than later :D Esteban > > Best, > Robert > > >> >> >> Thanks. >> >> Jimmie >> Jimmie >> >> [snip] >
