Nevertheless, I would like to stress that the usage of low level libraries to speed up what needs to fast is a correct approach in whatever language that exists, from old turbo pascal enabled an "asm" command to write directly assembly when needed to modern languages that implements their libraries in C and then use it... heck, even C libraries have parts written in assembly when needed! I do not see why we can not gain speed in the places where is needed through a primitive, a plugin or a FFI call. cheers! Esteban On Jan 12 2022, at 6:24 pm, tesonep@gmail.com wrote: > I have activated the plugin in the build for Pharo9, it will be available in the next release. > > It will be interesting to have a Float64 extension to it. > On Wed, Jan 12, 2022, 18:06 Marcus Denker <marcus.denker@inria.fr (mailto:marcus.denker@inria.fr)> wrote: > > > > > > > On 12 Jan 2022, at 17:38, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no (mailto:henrik.s.johansen@veloxit.no)> wrote: > > > True! > > > It’s a little bit of a naming conundrum, since the «Float» in Pharo is already 64-bit, but since we’re speaking «native» arrays, > > > DoubleArray > > > would be the best, I guess. > > > > > > Speaking of, the related new (… to me, anyways) DoubleByte/DoubleWordArray classes have incorrect definitions in Pharo 9 AFAICT- variableByte/WordSubclasses, instead of variableDoubleByte/variableDoubleWordSubclasses… > > > > We finally fixed this in Pharo10 2 days ago: https://github.com/pharo-project/pharo/pull/9792 > > > > Marcus