Nicolas Cellier

Since a stub platforms/Cross/plugins/SerialPlugin/sqNullSerialPort.c has been added, there is now a conflict... I presume that the line in https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/cmake/PluginsPharo.cmake must be revised to select which source file we pick add_vm_plugin_auto(SerialPlugin...

So should we wait a bit for integration? (IMO there's low risk of collision with other devs anyway)

Eliot was working for providing native bit-identical floating point functions for Terf. So we would use the patched fdlibm once finished.

Great! The only thing to be changed is that src/plugins/BitBltPlugin/BitBltPlugin.c is generated from Smalltalk slang code. I think that we can merge first, then modify VMMaker and regenerate BitBltPlugin Thanks!!!

Tim, to be sure about understanding: `realloc` does the right thing, it leaves the original alone. It's we, programmers that do not do the right thing: we overwrite a valid...

mpfr is multiple precision (arbitrary precision if you prefer), and not specially optimized for IEEE 754 double precision. IMO it's too much for FloatMathPlugin. CRLIBM (correctly rounded mathematical library) could...

In the interim, we can modernize fdlibm, it's easier than creating a new plugin from scratch, and it will preserve bit-identical backward compatibility with OpenCobalt/Terf/... while changing the underlying libm...

I've checked that FloatMathPluginTests does not segfault anymore with head Win64 squeak.cog.spur if I replace `platforms/Cross/plugins/FloatMathPlugin/fdlibm` with my master branch. All the tests are red because they depend on Random...

Now that I'm fairly confident that my patches are OK, I suggest this: - we keep fdlibm for backward compatibility; - we maintain our own patched version; - we don't...

Given the introductory comment, shouldn't we just nuke the whole thing?