Thanks for the information.
And thank you for all that you do to move Pharo forward.
I know some of this must be tedious. But Pharo is getting more beautiful
all the time.
Jimmie
On 10/15/2015 10:02 AM, Esteban Lorenzano wrote:
On 15 Oct 2015, at 16:51, Jimmie Houchin <[email protected]
<mailto:[email protected]>> wrote:
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]> 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?
NB is going away in spur, BUT NOT his syntax… you still will do FFI
calls in the old way. This is going to be 95% compatible (so far, I
needed to introduce changes on: structures and callbacks… all the rest
is same… and the changes are not really complicated to adapt).
Now, is a bit frustrating because I have said this millions of times
(at least once for each one I say we are removing NB… and I’m the only
one saying it :P)
Esteban
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]
