[Vm-dev] Fwd: minheadless future (was Re: [OpenSmalltalk/opensmalltalk-vm] CONTRIBUTING.md: Add some style guidelines (#350))

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Jan 6 15:27:41 UTC 2019


Hi Ben,

Le dim. 6 janv. 2019 à 15:53, Ben Coman <btc at openinworld.com> a écrit :

>
> On Sun, 6 Jan 2019 at 18:57, Nicolas Cellier <notifications at github.com>
> wrote:
>
>> A side note: the legacy platforms/win32 is using these settings:
>>
> Side question: (I've been meaning for a while to ask...)
>
> I've understood the minheadless arrangement aligns with Pharo's vision
> from years back
> and it seems destined for Pharo 8.  I've been curious what the perspective
> is from the Squeak side,
> so the use of the term "legacy" here caught my attention.  I know
> Squeaker's are more
> concerned about backward compatibility and I guess the minheadless
> requires
> significant image changes that might complicate that.  Has it been
> discussed by the Squeak Oversight Board?
>
>
I don't know if this was dicussed in last meeting because i missed it
(blush!) :(
But it would sure make a good subject.
All I will say here is my own opinion, not that of the SOB.

I've seen Nicolas recently synchronising the minheadless and original
> platforms.
> Knowing whether everyone is aligned with a future move to minheadless, or
> otherwise knowing what concerns there are would help my own approach to
> working between the two streams.
>
> A minimal headless is interesting per se, whatever the Smalltalk flavour.
I'm thinking of embedding a VM into another app for example (even if not
with power of full Smalltalk IDE).
The goal to replace low level GUI with alternatives (SDL2 or whatever) is
also interesting.

So my own motivations are:
- curiosity
- to not let good initiatives rot
- to not take risk of breaking just freshly commited minheadless code by my
own UNICODE cleaning
- to verify compatibility and study eventual possibility to reconcile

For example, for file that are identical between the two,
> perhaps its useful to have one be empty except for a #include of the other
> ??
>
>
In short term, duplicating code can be OK, but not sustainable in mid term
IMO we already have too many duplicated things (particularly for building,
the mvm scripts, the plugins.int/ext as you shown recently etc...).
Forking is super easy, but then maintaining all the copies is close to
impossible.

All the good refactorings included in minheadless could be re-integrated in
a shared core.
(minheadless is very close that what the core should be since minimal...).
And all the headfull extension cleanly separated.
But this is some more work!
minheadless has gone half way, which is already something.

btw, to familiarise myself better with minheadless I produced and overview
> spreadsheet.
> Its incomplete and quite busy, but perhaps of use to others. Feel free to
> update it as you see fit...
>
> https://docs.google.com/spreadsheets/d/1HnHzPPM0-OBF7oJt49YIrTCMqwfq7ggdMHQcVwQHOTU/edit?usp=sharing
>
> cheers -ben
>

At one moment, we also need paperboard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190106/74624db7/attachment.html>


More information about the Vm-dev mailing list