Stef wrote:
Our goal is to remove the dependencies to nativeboost.
I know that FFI is now maintained again and there is some initiative
on a (more) unified FFI. Also there may be some issues with NB: harder to
understand than FFI, not complete for ARM, ...
not working with Spur, not working with 64bits
Also for Apple devices it is not able to generate/perform machine code
in memory. But when you go native you usually have to take care of the
underlying system anyway.
But if I understood correctly all this new improvements/movements away from
NB will be at the cost of performance: FFI will slower than NB. Or did I
misunderstood?
probably in the first period.
The only issues I had with NB so far ist that it initially takes
some effort to know the details. But it worked great once one get
used to it and I like that Pharo gets fast with it...
Me too. But between fast on principle and not working in reality and
slower and working, I chose the second.
I want Pharo to run on Spur.
Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible
provide the NB layer?
Do you know how to do it? Should we burn months of Esteban to learn it
so that after he can extend it.
Should we be relying on the knowledge of one single person?
For other platforms we can fall back to FFI when needed.
For sure there could be a more unified way to call.
I spent 14 000 Euros on my budget to pay max as intern to work on
virtualCPU with igor so that
NB could take advantage of having a CPU abstraction.
They worked great and hard. But NB was never updated to take advantage
of virtualCPU and probably
virtual CPU was not totally finished.
I thought that Igor would continue to improve NB and use Virtual CPU but
I was wrong.
To me this is a pure lost of money and max should have worked on updates.
So I learned something: I will not pay interns on projects that I cannot
use/or maintain myself
I was stupid but I'm learning.
Maybe thats the goal of the unified FFI and I just do not know the
details. Maybe NB is already planned as a possible backend and it is
still possible to use it. Or will it be legacy afterwards?
NB will be a possible backend if
uFFI happens
and if NB works with the system.
So the first step is
use NB syntax for "uFFI front end"
provide FFI as back-end
hope that ronie delivers low end
hope that igor release NB Spur
I do not care if it is called "NB" or "FFI" or other, but I would dislike if I
had
to give up performance or native possibilities or if we just throw away
something that was developed/integrated with effort into the image initially.
I can tell you that I did my best (and even more) but that this is not
something that I can control.
If Igor turned into a pumpskin is not my fault or wish. He always got
all my support (you can ask the team here).
Now there is a lesson in that story: we should not rely on a single person.
I guess more info or patience is required...
We want Pharo on Spur!
This is key for clement's works and for all the community.
Stef
