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

Sun Feb 24 20:19:47 UTC 2019

Hi Doru,

Le mar. 19 févr. 2019 à 10:39, Tudor Girba <tudor at tudorgirba.com> a écrit :

>
> Hi Nicolas,
>
>
> > On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> >
> > Hi Tudor,
> > Retrieving author and timestamp from git history is doable.
> > The question is whether it will be still possible to contribute thru MC
> or not.
> > If it is metadataless MC, there's no point, it's unusable.
> > I think that the minimal metadata we have to maintain is the last MC
> ancestor. This can be done by convention thru a .last_mc_ancestor file. Of
> course, there will be conflicts, but easy to (automatically) solve.
> > That could also lie in commit message, but is somehow a bit more
> fragile... it would mean scanning thru ancestry for getting such
> information.
> > By symmetry, merged agit sha should be in mc commit, either a specific
> file in mcz, or commit message.
>
> That sounds intriguing and interesting at the same time. However, I do not
> have a qualified enough opinion on this matter.
>
>
> > Also note that vmmaker history as proposed in opensmalltalk pr was
> broken (no respect of branch topology). Maybe retry with Squot?
> > https://github.com/hpi-swa/Squot
> > There is still a problem of synching commits of other packages (cog,
> various plugins ...), and if nobody is working on it, we are condemned to a
> mediocre solution.
> > IMO, a broken history has not much interest.
>
> We know it was broken, and thank you for pointing it out. We went through
> multiple iterations, and we think the latest one should be better. Please
> take a look and let us know if you still find issues:
> https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
>
>
Ah OK, I'll try to have a look.

> > The question is whether it is possible to come to acceptable compromise?
>
> As I wrote in the reply to Eliot, I believe the main point at this moment
> is not Git, but getting the VMMaker code to run in Pharo. I think we should
> start there, and see if we can produce an alternative environment that
> provides value.
>
> Cheers,
> Doru
>
> Maybe some well trained Pharoer should pair with Eliot then, otherwise
it's like wasting Eliot's time on non fundamental VM subjects.

> > Le lun. 18 févr. 2019 à 07:33, Tudor Girba <tudor at tudorgirba.com> a
> écrit :
> >
> > 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.
> >
> > 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."
> >
>
> --
> www.feenk.com
>
> “How do you feenk today?"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190224/ddc4adf9/attachment-0001.html>