What is the term for vm-display-null, vm-sound-ALSA etc??

 

 

 

 

 

 
Bert Freudenberg wrote:

---

On 17.07.2014, at 22:52, gettimothy <[hidden email]> wrote:

Hi Eliot.

thx for the reply.

The goal I am pursing is a consistent mapping of terms from the metal to the smalltalk level. If something is 'turtles' then I want it to be 'turtles' all the way down the chain.

Looking at platforms/unix/vm/SqModule.h, which declares the metaprotocol of these things, arg parsing, help, launch, etc, it's clear these things are VM modules, which is different from plugins.  But you might ask Ian Piumarta directly.

Ian handles them in his CMake script with the term plugins_vm per this code in trunk/platforms/unix/cmake/Plugins.cmake

MACRO (CONFIGURE_PLUGINS)
   CONFIGURE_PLUGIN_LIST (plugins_int)
   CONFIGURE_PLUGIN_LIST (plugins_ext)
   CONFIGURE_PLUGIN_LIST (plugins_vm)
ENDMACRO (CONFIGURE_PLUGINS)

I prefer the term VMModules as that reflects the heuristics you use; I am ok with pluginsVM too as that mimics Ian's code. I will be replacing the term vmDrivers tomorrow when I can pry my eyes back open.

Formally we call the VM extensions "modules" (e.g. listLoadedModules). Informally they are known as VM plugins. And that informal use has spread, so by now we use the terms interchangeably.

To my mind, a module is something that might only be able to be bound at VM compile time, whereas a plugin could be bound to a running VM.  I guess that at some point of history there was only the former, and the latter came along later with new terminology?
cheers -ben

Internal and external modules are supported by pretty much all VMs, providing named primitives and getting loaded on-demand when a named primitive is invoked.

Ian's drivers are unique and use the module mechanism mostly to avoid code duplication. But they are different, they do not provide named primitives, they get loaded on VM startup. They provide alternative implementations of the same platform functions, which is necessary because Unix is a much more diverse platform than the others. 

- Bert -

 
On 18.07.2014, at 03:55, [hidden email] wrote:

> To my mind, a module is something that might only be able to be bound at VM compile time, whereas a plugin could be bound to a running VM.  I guess that at some point of history there was only the former, and the latter came along later with new terminology?

Nope. Before the VM became modularized it was monolithic. Tim can tell you all about that process, but for sure one major point of breaking out parts of the VM into modules was to enable dynamic loading. That was there from the beginning.

The term "module" and "plugin" wrt the Squeak VM mean exactly the same thing, except the latter may be confused with the web browser plugin (which wraps the whole VM into a plugin loadable by a web browser).

- Bert -

 
Bert Freudenberg wrote:

On 18.07.2014, at 03:55, [hidden email] wrote:

  

To my mind, a module is something that might only be able to be bound at VM compile time, whereas a plugin could be bound to a running VM.  I guess that at some point of history there was only the former, and the latter came along later with new terminology?
    

Nope. Before the VM became modularized it was monolithic. Tim can tell you all about that process, but for sure one major point of breaking out parts of the VM into modules was to enable dynamic loading. That was there from the beginning.

The term "module" and "plugin" wrt the Squeak VM mean exactly the same thing, except the latter may be confused with the web browser plugin (which wraps the whole VM into a plugin loadable by a web browser).

- Bert -



  

Nice to know.
cheers -ben

 
On Fri, Jul 18, 2014 at 10:32:45AM +0200, Bert Freudenberg wrote:
>  
> On 18.07.2014, at 03:55, [hidden email] wrote:
>
> > To my mind, a module is something that might only be able to be bound at VM compile time, whereas a plugin could be bound to a running VM.  I guess that at some point of history there was only the former, and the latter came along later with new terminology?
>
> Nope. Before the VM became modularized it was monolithic. Tim can tell you all about that process, but for sure one major point of breaking out parts of the VM into modules was to enable dynamic loading. That was there from the beginning.
>
> The term "module" and "plugin" wrt the Squeak VM mean exactly the same thing, except the latter may be confused with the web browser plugin (which wraps the whole VM into a plugin loadable by a web browser).
>

Also, we tend to speak of a VM "plugin" (such as FilePlugin) when we talk
about the Smalltalk + C source code modules, which may or may not be compiled
as runtime loadable modules ("internal" versus "external" modules). So the
terminology is not rigorously enforced ;-)

Dave