[Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]
Eliot Miranda
eliot.miranda at gmail.com
Wed Feb 20 20:21:06 UTC 2019
On Wed, Feb 20, 2019 at 12:23 AM Tudor Girba <tudor at tudorgirba.com> wrote:
> Hi,
>
> I have seen that code, and the issue I wanted to address is to have the
> decision about which dialect a piece of code is ran on in one single place.
> This should make it easier to find statically.
>
> Indeed, this will not necessarily be guaranteed to work when moving from
> one version of Pharo to another. But, that problem can be addressed by
> tracing releases in a reproducible fashion. And in the VMMaker case, the
> scenario is about a development environment not a production system. So, it
> should be reasonable to point developers to a working configuration that
> pairs the Pharo/Squeak version and the VMMaker version.
>
> What do you think?
>
I think the solution I've used so far is fine for now. There's no need to
invent another convention. If one wants to identify statically, beyond a
comment saying :Squeak5", "Pharo6" (which can still be used in a static
query), via a message then invent a tag scheme. But for now I don't see
that any effort is justified.
As far as versioning goes, this goes to the heart of the stability issue
for Pharo. Pharo needs to decide to support certain external packages and
not pull the rug from them all the time. Since VMMaker is indeed a
development environment it makes sense for it to function in versions close
to the tip ("trunk" in Squeak). In Pharo that should translate into the
last release and the current development, but as we've seen there are
stability issues with that.
> Cheers,
> Doru
>
>
> > On Feb 20, 2019, at 4:39 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > 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
>
> --
> www.feenk.com
>
> "Beauty is where we see it."
>
>
>
>
>
>
--
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190220/fb7ad805/attachment-0001.html>
More information about the Vm-dev
mailing list