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

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 19 22:39:53 EST 2019


Hi Doru,

On Mon, Feb 18, 2019 at 8:14 PM Tudor Girba <tudor at tudorgirba.com> wrote:

> Hi Eliot,
>
> Please, let me clarify the current direction: I am not trying to get you
> to Pharo at this point. I only want to reach a point where the VMMaker code
> runs in Pharo. This will allow us to bootstrap an environment that can
> later be evaluated.
>
> Having the sources in Git is secondary at this point. With the current
> infrastructure, we get those sources in Git while preserving the history
> from the Squeaksource repo automatically. The code will be loadable from
> either Git or Squeaksource, but the commit repository is still the
> Squeaksource one. So, nothing would change from the  workflow of the
> current committers. What we gain with the Git repository is a test ground
> and an easier ability to load the code in Pharo, all at no extra cost and
> without affecting your flow.
>
> Let me emphasize this again: the Git support should not be the main issue
> at this point. Now we would only need to get the code to run in Pharo. For
> this, we would need to introduce a few support methods. One key method that
> Andrei and I would like to propose, and that we used before in other
> porting projects, is:
> Object>>vmMakerForSqueak: aBlockToBeExecutedOnlyInSqueak forPharo:
> aBlockToBeExecutedOnlyInPharo
>

I am doing things on a case-by-case basis.  Currently I use classNamed:,
e.g.

(Smalltalk classNamed: #FileSystem)
ifNotNil: [:fileSystem| fileSystem disk delimiter asInteger]
ifNil: [FileDirectory pathNameDelimiter asInteger]

(Smalltalk classNamed: #CurrentReadOnlySourceFiles)
ifNil: syncAction
ifNotNil: [:crosf| crosf cacheDuring: syncAction]

(Smalltalk classNamed: #Project)
ifNotNil: [:project| Project uiProcess] "Squeak"
ifNil: [UIManager default uiProcess] "Pharo"

 ((Smalltalk classNamed: #FillInTheBlankMorph)
ifNotNil: "Squeak"
[:fITBM|
fITBM
request: 'Input please!'
initialAnswer: ''
centerAt: ActiveHand cursorPoint
inWorld: ActiveWorld
onCancelReturn: nil
acceptOnCR: true]
ifNil: "Pharo; onCancelReturn: nil is the default here"
[UIManager default
request: 'Input please!'
initialAnswer: '']).

this at least allows Squeak to migrate to FileSystem without having to
rewrite.  Using the above I was already able to get most of VMMaker working
in Pharo6.  Things broke for Pharo7, which indicates that the
vmMakerForSqueak:forPharo: approach has vulnerabilities.


> Andrei will propose a commit in VMMaker Inbox this week.
>
> What do you say?
>
> Cheers,
> Doru
>
>
> > On Feb 18, 2019, at 7:55 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > 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
>
> --
> www.feenk.com
>
> "Sometimes the best solution is not the best solution."
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190219/a7cdc024/attachment.html>


More information about the Pharo-dev mailing list