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