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, [email protected] 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 <[email protected] > (mailto:[email protected])> wrote: > > > > > > > On 12 Jan 2022, at 17:38, Henrik Sperre Johansen > > > <[email protected] (mailto:[email protected])> > > > 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
