[Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]
eliot.miranda at gmail.com
Wed Feb 20 03:39:53 UTC 2019
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:
I am doing things on a case-by-case basis. Currently I use classNamed:,
(Smalltalk classNamed: #FileSystem)
ifNotNil: [:fileSystem| fileSystem disk delimiter asInteger]
ifNil: [FileDirectory pathNameDelimiter asInteger]
(Smalltalk classNamed: #CurrentReadOnlySourceFiles)
ifNotNil: [:crosf| crosf cacheDuring: syncAction]
(Smalltalk classNamed: #Project)
ifNotNil: [:project| Project uiProcess] "Squeak"
ifNil: [UIManager default uiProcess] "Pharo"
((Smalltalk classNamed: #FillInTheBlankMorph)
request: 'Input please!'
centerAt: ActiveHand cursorPoint
ifNil: "Pharo; onCancelReturn: nil is the default here"
request: 'Input please!'
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?
> > On Feb 18, 2019, at 7:55 PM, Eliot Miranda <eliot.miranda at gmail.com>
> > Doru,
> > On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor at tudorgirba.com>
> > Hi Eliot,
> > You raise a few technical concerns related to VMMaker that seem
> > 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)
> > 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>
> > >
> > > Hi All, Hi Torsten, Hi Jakob,
> > >
> > > On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares at gmx.de>
> > > Hi,
> > >
> > > as some of you might already know "Tonel" is a file-per-class format
> for monticello repositories .
> > >
> > > 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 . There is also a tool to convert from STORE
> (VisualWorks Source-Code Versioning System)
> > > to Tonel format .
> > >
> > > 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
> > >
> > > 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
> "Sometimes the best solution is not the best solution."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev