[Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]

[Eliot Miranda]

Doru,

On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor at tudorgirba.com> wrote:

> Hi Eliot,
>
> You raise a few technical concerns related to VMMaker that seem
> addressable:
>
> 1. Rendering technology: Both in Pharo and in GT, there exist in-image
> canvases, Athens and Sparta respectively, that are backend independent.
> This allows us to have image-based drawing logic, like BitBlt or even
> better, the drawing capabilities that Juan Vuletich built in Morphic 3,
> transparently. In fact, we even started to look at the code from Morphic 3
> and we think it’s not much effort to make it work behind Sparta. This would
> provide a complete solution that would not rely on any external libraries.
>
> 2. Git history. We used to have the author and timestamp in the metadata
> of Tonel but because it generated unwanted conflicts it was decided to
> remove it. I think this is a good decision and one based on the experience
> of using it. But, why do you think the algorithm of retrieving Git could
> not be made to work in Squeak? Is there a specific technical reason, or is
> it more that you do not see the effort being spent in this direction? I am
> asking to understand what could a possible solution be.
>
>
> But, let’s take a step back. George and Andrei did move the VMMaker code,
> including all its history, into Git using (and enhancing)
> https://github.com/peteruhnak/git-migration.
>
> The code is here:
> https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
>
> Our goal was to make the code loadable and runnable in Pharo through Git.
> We have a reproducible process to produce this history, and this means that
> we can also synchronize all changes from the Monticello VMMaker repository
> and produce a history-preserving Git repository.
>
> The current code comes with a BaselineOfVMMaker that loads in Pharo, and
> the code generation seems to work to a good extent without much effort.
> There is still work that needs to be done especially on the simulation
> part, but we think most of it can be addressed through a Pharo-specific
> package that provides compatibility logic.
>
> I see two benefits for doing this:
> 1. It allows people in Pharo to play with the VM within the Pharo context
> and consequently contribute.
> 2. It allows us to build an environment dedicated for VM development
> without affecting the current contribution process. We can judge later
> whether this is useful.
>

All this is great work.  But I cannot use it until I can also function in
Squeak.  I know you want me to move to Pharo, but I am not convinced that
it is a safe place for me to land.  I have voiced my concerns before
(stability, moving away from support I need (e.g. Pharo dropping
read./write file streams is the latest example).  Let me simply restate
that "t6he devil you know is better than the devil you don't", and that I
know I am productive with VMMaker in Squeak, but I *do not* know that I can
be productive in Pharo (in fact, I have lots of experience of the
contrary).  So I will not move to Pharo any time soon and so, until there
is a solution to git/tonel/squeak integration I cannot join the unified
repository, must as I would like to.

I'm sorry for the frustration this causes other.  I am radical in some
things, but deeply conservative in others.  And my ability to be productive
is obviously foundational.


> Cheers,
> Doru
>
>
> > On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > Hi All, Hi Torsten, Hi Jakob,
> >
> > On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares at gmx.de> wrote:
> > Hi,
> >
> > as some of you might already know "Tonel" is a file-per-class format for
> monticello repositories [1].
> >
> > In Pharo land many projects are already converted to it - as regular
> "file tree" solution faces issues
> > with git handling due to very long file names / deep file hierarchy
> (often leading to trouble on Windows).
> >
> > Dales's Rowan (a new project/package manager for Smalltalk) supports
> FileTree and also Tonel
> > repositories [2]. There is also a tool to convert from STORE
> (VisualWorks Source-Code Versioning System)
> > to Tonel format [3].
> >
> > So I wonder about adoption of Tonel in Squeak land.
> >
> > Any status/comments?
> >
> > Last year I was given contract employment by Tudor Girba's feenk which
> in part was to involve me porting VMMaker.oscog to Pharo in order to reap
> the productivity benefits of the Glamorous Toolkit when applied to
> VMMaker.  The major direction was to unify the opensmalltalk-vm repository
> with a Toned-Format repository holding the Smalltalk code.
> >
> > This project, though no fault of feenk's did not go well.  A big part of
> it was my own emotional attachment to Squeak, my "muscle memory" with
> Squeak and my long experience with Smalltalk-80 derived meta programming
> which I make extensive use of in VMMaker.oscog.  But a key issue was that I
> was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it
> can live in both places.  In particular I will not risk VMMaker.oscog being
> stranded on Pharo as it moves away from the "image-based rendering model".
> This is not because I don't believe in pixel-independent rendering models,
> but because productivity in VMMaker depends much more than on GToolkit
> inspection on the key architectural feature of being completely, safely
> simulateable (not a real English word; but meaning capable of being
> simulated).  As Pharo moves towards external libraries to implement its UI
> so the degree to which VMMaker is simulated is reduced.  Thus crashes in
> external code cannot be handled with the same power as with errors
> presented within the Smalltalk environment itself, and this (as harsh
> experience over thirty five years has taught me) is far more important for
> overall productivity than having powerful tailorable inspectors.
> >
> > I therefore wanted a Tonel that could both function for Squeak's
> Monticello and for Pharo's Iceberg.  I had modified the Tonel serialization
> a little to provide well-formatted support for method timestamps, which are
> still a key and extremely useful part of Squeak Monticello's "blame"
> equivalent.  Until git author attribution can be imported into Squeak's
> Monticello (something I don't see happening) I wanted merely to be able to
> have a variant of Tonel, enabled for example by a class variable, and hence
> /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but
> still be functional inside Squeak.  I asked Esteban and was met by a flat
> no.  Not "OK, but this is an option only you will use", but a flat "not
> under any circumstance".
> >
> > So here I am joining in this thread reluctantly.  I'm extremely
> frustrated by the state of Tonel in Squeak and between the two dialects.
> Clément had moved his Scorch optimizer to Tonel/git and I tried to use
> Metacello and Jakob's Tonel code to at least allow me to load that code and
> try and push forward on Sista/Scorch.  The port *does not work*.  Metacello
> fails to load Scorch.  Neither Jakob nor Fabio, after putting in some
> effort, were able to fix the problem, and it is well beyond me.  So I have
> accepted the fact that I will have to use the Monticello repository for
> Scorch/Sista.
> >
> > I had deep concerns that the pursuit of git integration would end up
> splitting the Pharo and Squeak communities and indeed this is now in
> progress.  I am utterly unmotivated by the lack of cooperation, the sheer
> arrogance and bullying of those that say "you will move to git/tonel or
> else", and considering leaving VMMaker altogether.  The only things that
> are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD
> on register allocation in the context of Sista/Scorch with Robert
> Hirshfeld's group at HPI.
> >
> > Here's the kind of crap people like Ducasse throw at me:
> >
> > "Eliot
> >
> > At the end of the day I will probably ask the two phds that should work
> on language design to use truffle or pypy
> > because let us face it we cannot work with the Pharo VM. Else we will
> simply have to fork it (because we do not want to have
> > to jump over cuis, newspeak, squeak code constraints and I do not what)
> and it will be another drama is in the pico world
> > of the “open” smalltalk VM. "
> >
> > I am so over this crap.
> > _,,,^..^,,,_
> > best, Eliot
>
> --
> www.feenk.com
>
> “Software has no shape. Actually, it has no one shape. It has many."
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190218/34c1d3e9/attachment.html>