To be clear, I do not militate for putting everything in the VM. I prefer a lean VM. I'm cleaning what already exist in the VM. If something is in the VM, then it should behave as we expect from a VM: uniformely. A small fix in existing code base is more efficient than a full rewrite. But if a full rewrite is wanted for other reasons, no problem.
Le jeu. 17 janv. 2019 à 02:00, Martin McClure <mar...@hand2mouse.com> 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.
