Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares(a)gmx.de> wrote:
> 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
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:
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.