<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> schrieb am Mo., 25. Mai 2020, 14:03:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<br>
> On 25.05.2020, at 13:34, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank" rel="noreferrer">forums.jakob@resfarm.de</a>> wrote:<br>
> <br>
> <br>
> <br>
> Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank" rel="noreferrer">Das.Linux@gmx.de</a>> schrieb am Mo., 25. Mai 2020, 08:26:<br>
>  <br>
> <br>
> This all boils down to "who moves faster".<br>
> <br>
> Here's a story.<br>
> <br>
> When I tried to get the Self VM running again some years ago, one of the agonizing parts was its<br>
> extensive use of FFI. Why so? Well, the FFI was coded against a mid-1990 X11. Which, in that form<br>
> did not exist on either Mac nor Linux. Some parts worked, but a lot of things needed attention<br>
> in _both_ the VM _and_ the Image. In some respect, the "libraries interfaced via FFI" had moved<br>
> faster than the VM.<br>
> <br>
> Had Self had a Display Plugin just like Squeak, changes would have been much more simple, since the <br>
> assumptions in the Self world had nod changed at all.<br>
> <br>
> So, if things move slowly in VM/Image land and more quickly in library land, the answer is Plugins.<br>
> If things move quickly in VM/Image land and are stable in library land, the answer is FFI.<br>
> <br>
> I see this in SqueakSSL very prominently. The stable interface from the Image land helps a lot.<br>
> It would be a nightmare to have this via FFI. The effect would be that we have to<br>
> settle on one SSL library on all platforms, and keep that updated and ship it with the VM.<br>
> That's by the way what the Pharo VM does and I think it is the wrong way for the problem.<br>
> <br>
> How does using plugins solve this problem?<br>
> <br>
> 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.<br>
> <br>
> 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/...).<br>
<br>
Rather the latter. I wouldn't call it hot-fix but rather evolve stuff as they change.<br>
That's how we do with Display and SqueakSSL.<br>
You don't need to touch the image, but you could.<br>
I don't understand how "proper modules" in whatever sense would fix that.<br>
<br>
:)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. :-)</div></div>