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 <jlhouchin@gmail.com> wrote:

Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:

On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouchin@gmail.com> 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]