Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[ducasse via Pharo-dev]

--- Begin Message ---

> > 
> > 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.
> 
> +100
> 
> The VM *is* developed in Smalltalk
> https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk_VM_Development_Live_VM_Development_through_Simulation_Tools
>  
> 
It is not the point of the message of Martin. I imagine that Martin and Sven 
understand it perfectly that the VM is written in Slang and that there
is a simulator. Still many of us agree with their analysis. The VM logic should 
be on execution and try to delegate to the image most of the rest. 

Stef--- End Message ---

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Eliot Miranda]

On Thu, Jan 17, 2019 at 8:02 AM Sven Van Caekenberghe  wrote:

>
> > On 17 Jan 2019, at 02:00, Martin McClure  wrote:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
>
> +100
>

The VM *is* developed in Smalltalk
https://www.researchgate.net/publication/328509577_Two_Decades_of_Smalltalk_VM_Development_Live_VM_Development_through_Simulation_Tools


> > Regards,
> >
> > -Martin
> >
> >
>
>
>

-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Sven Van Caekenberghe]

> On 17 Jan 2019, at 02:00, Martin McClure  wrote:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

+100

> Regards,
> 
> -Martin
> 
> 

Re: [Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Nicolas Cellier]

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  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.

[Pharo-dev] Purpose of VM [was: Re: Better management of encoding of environment variables]

[Martin McClure]

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.


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.


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.


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