Hi Esteban, Eliot & Ronie,

Ronie, thanks for the history and explanation re Unicode.

Esteban & Ronnie, can I ask what the long term goals are for this code base?

The reason is that it appears to be adding significant complexity to the code base:

It's breaking the existing directory structure, e.g. the two instances of sqUnixCharConv.c are in:

./platforms/minheadless/unix/sqUnixCharConv.c
./platforms/unix/vm/sqUnixCharConv.c

It adds 69 file names. Some of these obviously need to be duplicated, e.g. make files are specific to the build type, but other examples include:

• sqUnixCharConv.h is copied unchanged.
• Changes the return types of some functions with the same name, e.g. 'int' to 'sqInt'.
• sqWin32Heartbeat.c where the entire file is copied so that 1 function can be extended (ioHighResClock()).

And with an admission of being too lazy to figure it out, I'm not sure how to build the Windows minheadless variant of, e.g., pharo.cog.spur. There's:

build.linux64x64/pharo.cog.spur.minheadless/build/mvm

for linux 64 bit, and the equivalent for linux 32 bit and MacOS 32 bit, but not MacOS 64 bit or Windows. Should:

build.minheadless.cmake/x86/pharo.cog.spur/mvm

be used?

I can understand the problems of chasing a moving target, but without a commitment to continue working on this it looks like it will increase technical debt.

Or am I missing something?

Thanks,
Alistair

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.