Thanks for the example.
On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:
On 15 Oct 2015, at 15:50, Jimmie Houchin <[email protected]
<mailto:[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.
Thanks.
Jimmie
Jimmie
[snip]
