Le jeu. 17 janv. 2019 à 02:00, Martin McClure <
[hidden email]> a écrit :
On 1/16/19 1:24 AM, Nicolas Cellier wrote:
> IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion
> because the purpose of a VM is to provide an OS independant façade.
I have not looked at this particular problem in detail, so I have no
opinion on whether the VM is the right place for this particular
functionality.
It is not in the VM currently, only in OSProcessPlugin (and Windows variant).
If some other plugins would depend on environment variables, then it might be interesting to provide this feature as a VM service.
I don't know if it is the case.
Also, some platform could have other strategies like querying the Registry in windows, a configuration file, etc...
So we might provide a service for the basic or multi-level policy.
However, I feel that in general trying to put everything that might be
OS-specific into the VM is not the best design. To me, the purpose of a
Smalltalk VM is to present an object-oriented abstraction of the
underlying machine.
Thinking that way leads me to believe that the following are examples of
things that are good for a VM to do:
* Memory is garbage-collected objects, not bytes.
* Instructions are bytecodes, not underlying machine instructions.
This works well to hide the differences between machine instruction
sets, memory access, and other low-level things. However, no Smalltalk
implementation that I know of has been able to use the VM to iron out
all differences between different OSes.
Files? Sockets?
Until the threaded FFI is consolidated, there is a category of async algorithms that we cannot easily program at image side.
I do believe that it is a good idea to have cleanly-designed layers of
the system, and that there should be an OS-independent layer and an
OS-dependent layer with clean separation. But I think it might be better
to put most of the OS-dependent layer in the image rather than in the
VM. For one thing, the image is easier to change if there is a bug, or a
lacking feature, or you're trying to support a new OS.
For supporting a new OS, I'm not sure.
Having an "edit on known platform-save-resume on new platform-crash" cycles is not a pleasure.
Well for certain persons, the pleasure can be proportional to the hurdle height ;)
You must have the bare minimum services (GUI) running before pleasure comes back.
A Smalltalk without an IDE is not superior to C with a good IDE.
Trial and error is not superior to a good debugger.
And if it's in the image you get to do the programming in Smalltalk
rather than C or Slang, which is more fun for most of us. And, let's
face it, fun is an important metric in an open-source project -- things
that are fun are much more likely to get done.
Regards,
-Martin
For example, the first time I wrote something like Smallapack, there was no choice: it was thru user defined primitives (st80 or Objectworks).
So I had to write a wrapper in C code for each function exposed, with all the marshalling of arguments in C!
When came DLLCC it became more fun.
But this does not apply to every library.
If the library depends on tons of preprocessors definitions, macros, then we currently lack tools for performing an efficient job at image side.
Some possible tools have been sketched in those mailing list, but so far, they are virtual.