Thanks nicolas.

We will discuss this during the sprint tomorrow.��

On 25 Apr 2019, at 22:43, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

I've just published a new ConfigurationOfSmallapack

Currently, there is one test failing because I did not finish the support of LegacyFFI for invoking methods with more than 15 arguments (see below).

The other tests are passing, so you may try it now.

gory details:

The failing test requires the Opal Compiler to generate fallback code for invoking primitive 117 (ExternalFunction invokeWithArguments:) under the hood...

Old Compiler workaround was hackish, and is extremely complex to implement in cleaner Opal architecture

(Old compiler enabled mixing AST rewrite/code generation phase without a problem)

The plan was either to enhance primitive 120 to handle the case of many arguments passed through a single array...

Or to switch to UnifiedFFI (but even there, I don't remember if invoking primitive 117 was that straight forward...)

Le��jeu. 25 avr. 2019 ����20:16, Jimmie Houchin <jlhouchin@gmail.com> a ��crit��:

Thanks.

I appreciate your working to make this happen. No pressure from me on time. I am blessed that you are contributing this to the community and that I can benefit from your labors. At your convenience.

I look forward to using Smallapack when available. I am thrilled to be able to stay with Pharo and not have to use Python/Numpy. :)

Thanks.

Jimmie

On 4/25/19 12:38 PM, Nicolas Cellier wrote:

Hi Jimmie,

The Metacello Configuration is not ready for Pharo7.

I have succeeded in loading Smallapack yesterday without Metacello, and could run some of the tests.

I had to modify a few methods because of Pharo refactorings, and there is still some work to make it fully operational.

When ready, I'll update the Metacello configuration and keep you informed.

Le��jeu. 25 avr. 2019 ����19:06, Jimmie Houchin <jlhouchin@gmail.com> a ��crit��:

When I attempt to install via Metacello in Pharo 7, I get the following warning.

This package depends on the following classes:
�� Parser
�� MessageAsTempNode
�� Compiler
�� MessageNode

I do not know how to proceed from there. Any help greatly appreciated.

Thanks.

Jimmie

On 4/24/19 12:20 AM, Nicolas Cellier wrote:

Hi,

I recommand inquiring about Smallapack, the Smalltalk interface to LAPACK,��on squeaksource.com or github. You'll get the speed of numpy. There is a Metacello configuration. I have not checked the port on current��

Pharo, but I can reactivate if there is some interest.

Le mer. 24 avr. 2019 �� 05:55, Jimmie Houchin <jlhouchin@gmail.com> a ��crit��:

I just recently discovered FloatArray by accident.

I was close to having to use Python/Numpy due to considerable
performance differences. Performance is very important.

In one of my test using a 212000 item array of floats and doing a sum on
each iteration through the array Pharo was taking 17 minutes verses
Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40
seconds. That is acceptable.

However when looking at the FloatArray comment it says it uses 32bit
floats. I need 64bit. I don't even know where to look to create 64bit
FloatArrays. I am surprised that they didn't get converted when moving
to 64bit Pharo.

Would I need to change VM source? Compile a new VM and create image side
classes? I have not messed with VM in years. I do not know where the
FloatArray plugin would be.

Any pointers would be a great help. If this needs to be on the vm-dev
list I can move it there.

Thanks.

Jimmie