Smalltalk › Squeak › Squeak VM

Re: [Vm-beginners] Stability of the external plugin interface

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Nicolas Cellier

Re: [Vm-beginners] Stability of the external plugin interface

Le mer. 27 mai 2020 à 07:09, tim Rowledge <[hidden email]> a écrit :

> On 2020-05-26, at 8:10 PM, Eliot Miranda <[hidden email]> wrote:
> DLLCC’s C parser is a nightmare to maintain,

I certainly remember *that*. Poor Marcel Schelvis practically went mad working on it.

If you try putting C++ syntax on a postcard, you probably gonna beat the number of folds you can perform on a sheet before it fits in any mailing box.

> So what the FFI author does is define a shared pool which has platform-specific metadata, specifically the necessary include files and version selection defines for each relevant platform. The FFI shared pool machinery takes care of generating the program when necessary (only when authoring an FFI), and running it when necessary (only once for a single-platform app, only when launching on a different platform to the one snapshotted on)

Sounds good to me. Beats parsing secondhand and possibly inaccurate information intended for an inferior language

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MERCI RIEN - Thanks for nothin'.

timrowledge

Re: [Vm-beginners] Stability of the external plugin interface

> On 2020-05-26, at 10:29 PM, Nicolas Cellier <[hidden email]> wrote:
>
>
>
> Le mer. 27 mai 2020 à 07:09, tim Rowledge <[hidden email]> a écrit :
>
>
>
> > On 2020-05-26, at 8:10 PM, Eliot Miranda <[hidden email]> wrote:
> > DLLCC’s C parser is a nightmare to maintain,
>
> I certainly remember *that*. Poor Marcel Schelvis practically went mad working on it.
>
> If you try putting C++ syntax on a postcard, you probably gonna beat the number of folds you can perform on a sheet before it fits in any mailing box.

I think that 'postcard' would end up the size of one of those giant roadside posters that require guys on a crane to install.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DNPG: Do Not Pass Go

David T. Lewis

Re: [Vm-beginners] Stability of the external plugin interface

In reply to this post by Tobias Pape

On Mon, May 25, 2020 at 07:16:02PM +0200, Tobias Pape wrote:
>
>
> TL;DR: FFI good, Plugins also good.
>
> just my 2ct.
>
> Best regards
> -Tobias
>

Well said. I would only add that Juan Vuletich has written a nice, balanced
overview of the use of FFI and VM plugins here:

https://lists.cuis.st/mailman/archives/cuis-dev/2020-May/001736.html

Dave

timrowledge

Re: [Vm-beginners] Stability of the external plugin interface

wrt the speed of calls to plugins, I wrote that mechanism a few years back (um, actually 15 years apparently) and the actual routine call should be exactly as fast as a number primitive - the code address is in the cache tables. Hmm.. does cog inline cache stuff affect that? I don't think so but could be wrong.

The only slow-down likely would be the potentially longer-winded routines to get stuff of the stack/instvars and put answers back. If one were to postulate changing to only internal plugins (to provide some modicum of modularity and maintain the named prim interface that was a key original driver) and having all external code be ffi called, then I rather think we could improve the get/put code.

> On 2020-05-27, at 3:28 PM, David T. Lewis <[hidden email]> wrote:
>
>
> https://lists.cuis.st/mailman/archives/cuis-dev/2020-May/001736.html

Yup; a very good summary.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A conscience is what hurts when all your other parts feel so good.

Jakob Reschke

Re: [Vm-beginners] Stability of the external plugin interface

In reply to this post by Tobias Pape

Tobias Pape <[hidden email]> schrieb am Mo., 25. Mai 2020, 14:03:

> On 25.05.2020, at 13:34, Jakob Reschke <[hidden email]> wrote:
>
>
>
> Tobias Pape <[hidden email]> schrieb am Mo., 25. Mai 2020, 08:26:
>
>
> This all boils down to "who moves faster".
>
> Here's a story.
>
> When I tried to get the Self VM running again some years ago, one of the agonizing parts was its
> extensive use of FFI. Why so? Well, the FFI was coded against a mid-1990 X11. Which, in that form
> did not exist on either Mac nor Linux. Some parts worked, but a lot of things needed attention
> in _both_ the VM _and_ the Image. In some respect, the "libraries interfaced via FFI" had moved
> faster than the VM.
>
> Had Self had a Display Plugin just like Squeak, changes would have been much more simple, since the
> assumptions in the Self world had nod changed at all.
>
> So, if things move slowly in VM/Image land and more quickly in library land, the answer is Plugins.
> If things move quickly in VM/Image land and are stable in library land, the answer is FFI.
>
> I see this in SqueakSSL very prominently. The stable interface from the Image land helps a lot.
> It would be a nightmare to have this via FFI. The effect would be that we have to
> settle on one SSL library on all platforms, and keep that updated and ship it with the VM.
> That's by the way what the Pharo VM does and I think it is the wrong way for the problem.
>
> How does using plugins solve this problem?
>
> If a library breaks compatibility, you would have to update the plugin and maybe think about how to stay compatible with older Squeaks. If it were FFI with a proper facade that finds out how to link to the external library, you would need to update the facade and worry there about staying compatible, but you could do it in Smalltalk. It requires discipline and guidance to only use the facade, of course.
>
> Do you mean you can hot-fix a plugin underneath the image, so you can run ancient unmodified images on a newer platform/library base? Then maybe we do not really want plugins, but proper modules (Smalltalk shared libraries/image fragments/image components/parcels/...).

Rather the latter. I wouldn't call it hot-fix but rather evolve stuff as they change.
That's how we do with Display and SqueakSSL.
You don't need to touch the image, but you could.
I don't understand how "proper modules" in whatever sense would fix that.

:)

Just to follow up on my modules remark: I meant to split the object memory, or at least the class library, in multiple files, so you can swap one out for another version if needed, even without needing to run the Smalltalk system. Like a Smalltalk shared library. Then you could leave the main part of the image with your work environment untouched, but offline-replace some subystem like the Display or encryption. Like with plugins.

Since your problem with Self seems to be that you could not modify the system because you could not run the system in the first place, such splitting does not help by itself. You would still need a working toolset to modify another Smalltalk image or parts thereof.

Text editors and C compilers seem to be mostly available on developer machines, to edit files that don't belong to the text editor or the C compiler itself. :-)