[squeak-dev] The Inbox: System-cmm.1059.mcz
forums.jakob at resfarm.de
Sun Apr 7 00:28:45 UTC 2019
Sigh, I feel thoroughly misunderstood. Am I expressing myself so unclear?
If that's the case I apologize. Let's have another try:
Some general remarks at the beginning: when I write about "those GitHub
projects", I do not (only) mean my own projects. I mean Smalltalk projects
on GitHub in general. Many of them are developed in Pharo, I suppose, since
Pharo had the better Git support first (with GitFileTree and later Iceberg).
My own hobby projects are
1) Squot/Squit/FileSystem-Git, which has the installGitInfrastructure
snippet you removed from the Do menu in its readme:
https://github.com/hpi-swa/Squot/blob/develop/README.md The text below that
does not include ensureLatestMetacello because it was written before either
of those methods existed in the Installer class.
2) the "bare minimum" Tonel fork for Squeak, which has the
ensureLatestMetacello line in its readme:
And actually, I have no other ongoing hobby software development projects
at the moment, except if you also count the Squeak version of FileSystem
which I dug into for FileSystem-Git (which is, like FileSystem, something I
picked up, rather than invent).
Consequently, my current free time development platform of choice is
Squeak. It is not Pharo.
Am Sa., 6. Apr. 2019 um 04:38 Uhr schrieb Chris Muller <ma.chris.m at gmail.com
> > I do not see the conflict in this case. Having a shortcut to install
> Metacello is nothing like twisting the concept of Morphic, turning your
> browser into a command line tool, or showing debugging annotations on every
> graphical widget, or something like that. It is not invasive. Neither are
> the refactoring tools. They extend the system browser, which is a
> developer's tool anyway.
> Are you saying Metacello does not have its own browser and never will?
Well, that's not what I said, but actually it is true: Metacello has no
browser and I think it never will. Metacello configurations, or rather only
baselines in the case of Git projects, are written with the system browser;
they are Smalltalk code. See
applies to Squeak)
What I instead wanted to say is that the install item in the Do menu does
not make the image less friendly for a newcomer. But it makes it easier for
some of us---myself included---to initialize a trunk image to a state from
which we can start working.
> >> > These projects place a Metacello load script in their README files.
> >> I wasn't trying to change you if you have a special use-case or
> >> preference for doing configuration that way.
> > It is not a matter of my taste of writing install scripts. It is a
> matter of how people in general write install scripts (see below). We can
> procilaim the "correct" way to do that all day long, but it is meaningless
> if the rest of the world does not agree or does not comply.
> This entire statement above is completely meaningless... The "world"
> does not "agree" on anything, nor is there any need to "agree" or
> "comply" with anything w.r.t. what we're talking about.
Let me try again by mapping the generalizations in my sentence to more
- we = actually you and anybody else who says that SqueakMap should be the
sole way of loading packages into a Squeak image. I put myself in these
shoes in partial agreement with you and, to be less dismissive, wrote "we"
instead of "you". Unfortunately there are no separate pronouns known to me
that distinguish "others and me, including you" (which is what I meant)
from "others and me, but without you" (which you might have interpreted).
- the "correct" way to do that = putting the install script for the project
- the rest of the world = non-Squeakers, but Smalltalkers, who put their
projects on GitHub. Especially Pharoers. Not me, not you.
- does not agree = they don't want to deal with SqueakMap or don't want to
check which loading prerequisites a fresh Squeak Trunk image fulfills and
which not (that is Metacello)
- does not comply = does not include the ensureLatestMetacello line in
their readme (maybe they don't even know that it is required in Squeak)
So to put it together again: I do make sure that the readme of my projects
has a snippet that can be run in a fresh trunk image and it will load
everything that is needed. I could, and probably should, put that exact
snippet on SqueakMap, too. The current state of affairs is that there are
other projects on GitHub (not mine) that don't include the
ensureLatestMetacello line. Because they are probably not aware that it is
required in Squeak. Nobody can blame them for that if they only work in
Pharo and have never used Squeak. Even if we would agree that the best way
is to register the project on SqueakMap, and that every project with a
Metacello configuration should include the ensureLatestMetacello line in
their installation instructions (readme) for Squeak, it would not change
the fact that the maintainers of those projects will probably do neither of
The case where a third person creates a SqueakMap entry for such a project
I will comment below.
> >> > Yeah, projects that use Pharo or GemStone as their primary platform
> will be delighted to hear that they have to maintain a SqueakMap entry to
> give squeakers a chance to try their stuff. Not!
> >> Of course it's not mandatory, but I think you're kidding yourself if
> >> you think Users (and even Developers) in 2019 will be delighted to
> >> know they have to do a lot of research and work (hint: a lot more
> >> than 9 clicks) just to figure out how to try out your project.
> > Well, the Smalltalk projects on GitHub that I came across typically have
> an "Installing" section at the top of their README, which is displayed on
> the project's front page on GitHub. This section often contains a snippet
> like the following:
> > Metacello new
> > baseline: 'NameOfTheProject';
> > repository: 'github://...';
> > load.
> > That's easy enough to copy&paste and run and requires less than 9
> interactions, *if* Metacello is available in the image already.
> "Easy enough" means you've accepted a compromise. You will never
> achieve a high level of participation until its easier for newbie
> developers. But that's not my business, only Squeak's IDE...
Assuming a newbie project maintainer's point of view (not someone who looks
at Squeak for the first time), I don't see a more practical solution than a
copy&paste-able install script in my readme right now. Forcing newbies to
learn how to put entries on SqueakMap does not make Squeak more appealing
as a platform, IMHO. Although it is a worthwhile thing to learn. An analogy
(as perceived by me): You would not want to force a newbie C GNU/Linux
developer to set up a Debian package for the calculator they have just
written and are eager to share (...)
Second, even if you put up a SqueakMap entry, you have two things to
maintain now: your readme (which you have to keep for Pharo, for example)
and the SqueakMap entry. More on that maintenance further down this message.
Third, "easy enough" actually means "very easy" for someone who does not
have Squeak open in front of them for the first time. The precondition to
meet is to be able to use a workspace and evaluate code in it. That does
not apply to a Squeak user who never touches any Smalltalk code. If that's
your point, I agree with you.
> > Some projects (typically those developed in Squeak) include the hint for
> Squeak that you first have to install the latest Metacello because it is
> not included in Squeak. Ideally every project would also include the
> Installer ensureRecentMetacello snippet.
> Why don't they? If they wish to support Squeak, then that's a
> configuration error in those packages, full stop.
Because "every project" also includes projects whose developers do not use
Squeak. But the project might still be interesting for Squeakers. For
example, there is Clément's Scorch:
seems to use Pharo only, but Eliot wants to have Scorch in Squeak. (Though,
the most severe hurdle at the moment is that Scorch is kept in Tonel format
and tools for that are not yet ready or comfortable to use in Squeak.
Eliot's problem is not the fact that the readme does not include the
The case is that these projects might not "wish to [officially] support
Squeak", but Squeakers might wish to use them anyway. And in my opinion,
even if Squeak is at a disadvantage in this case, Squeak should not put
more obstacles, or rather nuisances, in the way than necessary. That's why
my favorite solution would be to have Metacello in each trunk image (we
discussed about such inclusion and its problems with Marcel in the other
thread). The workaround solutions are:
1) make Metacello as quickly installable as possible: the Do (or whatever)
2) post pull requests to those projects and add that ensureLatestMetacello
line: might be rejected because the maintainers don't want to assume
responsibility for the project to work in Squeak
3) create "third-party-maintained" SqueakMap entries: see below
> > But as a matter of fact, not all projects include these hints. Because
> they are built in Pharo and Pharo has the latest Metacello loaded already.
> And if they don't use Squeak in the first place, you cannot tell them to go
> to the SqueakMap.
> But Jakob, **they don't mention to find the Metacello pre-req on
> Squeak's Do menu either**, right? So, either way, newbies trying to
> use your projects in Squeak are confused and lost.
This particular point is not about newbies (I'll switch back to newcomers
since it sounds nicer to me). But if you have read all the latest posts,
you have found out that it is contested whether the Do menu is a thing for
newcomers, or rather a thing for "power users". I count myself among the
people that assumed the latter.
You are right, however, that having the menu item in either of the menus
won't make it easier to load such projects as a newcomer. In my opinion,
neither does the snippet buried in "Extending the system" help in that
case. For that, it should rather read "How to install software in Squeak".
But the actor in the use case I describe is not a newcomer. It is a
developer or a Squeak power user.
> Which is sad, because normally someone using Squeak knows about
> SqueakMap, it's part of their main knowledge / training, because
> SqueakMap is how projects are loaded in Squeak.
I may be mistaken about that because of my own history, but I doubt that
SqueakMap is a well-known tool for people that are relatively new to
Squeak. I have never used SqueakMap until roughly a year ago. I have first
used Squeak in 2012.
SqueakMap is also not something I remember being used in any university
course that I attended and that was related to Squeak. If you would like to
challenge and discuss why that was not done, I suggest to do that in a
> > On the other hand, we should not dismiss them or their projects just
> because they don't know or care enough about supporting Squeak. That would
> be a huge, arrogant mistake, IMHO.
> I'm not sure why you feel dismissed when it's actually Squeak that's
> being dismissed -- by omitting ensureMetacello at the top of your
> project README's, and further by trying to compensate for this by
> trampling Squeak's menu with your personal hack that confuses and
> dilutes the hard work that went into making configuration in Squeak a
> breeze for anyone; developer or user.
See above: Your interpretation of me feeling dismissed or having omitted
the Metacello line is false as I did not refer to me or my projects.
I referred to the kind of projects I described above instead.
Otherwise I would not have used the pronouns "they", "them", and "their",
but rather "we", "us", and "our".
> > If a Squeaker tries to maintain the SqueakMap entry for such a project,
> it is doomed to become stale sooner or later in my opinion.
> As someone in Pharo-land, I don't expect you to understand SqueakMap
> or the goals it solves, but just so you know, correctly defined
> SqueakMap configurations _never_ get stale.
How did you get the impression that I am "someone in Pharo-land"? I only
start Pharo when I have to look up how something works there when I port
something to Squeak. It would not make much sense to develop Git tools for
Squeak if I would use Pharo primarily, wouldn't it? Not being used to
Pharo, I very much favor Squeak. I am not even subscribed the Pharo mailing
list at this time.
But I have different workflows in Squeak and different opinions about that
than you have, Chris. And, since it seems to me that you have never used
Metacello or maintained a Squeak project outside of Monticello or
changeset-land, I also use different tools. Though, I am not an exceptional
case on that matter, believe me.
On the meaning of "stale": I know that a non-head SqueakMap configuration
will continue to work for a particular Squeak release because the
configuration is expected to pin down the version of the project being
loaded. What I meant is that there might be no updated, new configurations
for new versions of Squeak or the project. SqueakMap entries for Squeak 3.x
don't help me if I am not also willing to use that old Squeak version.
SqueakMap entries that are several years old for a project that has evolved
since then don't help me either if I want to use the newer version. I
consider this a "stale" project entry as well, although its dated
configurations may still work fine.
> >> what SqueakMap was designed to solve: fixed configurations that
> >> present the project, and work forever on a particular version. It's
> >> targeted to helping _others besides you_ configure their system so
> >> they can evaluate your project's latest working version to decide if
> >> they want to invest the time in setting up a dev configuration. But
> >> often others will capture load scripts and document them on SqueakMap
> >> for themselves, you don't have to do it if you don't want.
> > That's all nice and I see the benefit. You don't have to convince me.
> But the reality is that it places a burden on the project or entry
> > The devs have to step outside their repository to make their stuff more
> easily available. A third person that creates a SqueakMap entry assumes the
> responsibility to retest that project for every new release and update the
> entry. It might be simple, but it is not at all appealing for someone who
> only uses Squeak as a hobby (or not at all).
> You made the argument above that "it is doomed to become stale" but
> then above you say, "responsibility to test". Which is it Jakob?
It is not a contradiction at all. If someone creates an entry, but does not
assume that responsibility, the entry will become stale. And even if
someone is aware of that responsibility and assumes it wittingly, they
might change their mind or lose interest at a later time. Or they simply
don't have time for Squeak anymore. The consequence: the entry (the project
on SqueakMap) becomes stale (as in my definition). Unless somebody else
picks it up, but the cycle may repeat.
Of course, it does not *always* happen that people leave Squeak and their
SqueakMap entries behind. So "doomed" as in "destined" is indeed an
> As I tried to explain above, neither. Because if a project is worth
> installing for someone else, THEY will do it. If it isn't, they
> In the meantime, I hope you'll close the gap in your configurations
> with a "ensureMetacello" at the top of your README's. You can easily
> be inclusive of all platforms OOTB without hurting Pharo at all, if
> you want to be.
See above, you misunderstood me.
> Barring that, all I ask that we don't confuse how software
> Installation is done in Squeak.
As written above: You present that as an uncontested fact. I doubt that it
is. My doubts might be unjustified, but as a matter of fact software *is*
loaded into Squeak images *without* using SqueakMap. Just like someone
using Debian GNU/Linux is not restricted to install software exclusively
from the official package repositories of that distribution. Although my
impression is that the usage rate of apt and the official repository to
install software in Debian, Ubuntu etc. is less debatable than the usage
rate of SqueakMap in Squeak.
We could have a poll to capture the current usage of SqueakMap both from a
user's and a maintainer's point of view, but again I propose to move that
to a separate thread. Also I acknowledge that the poll would be biased by
the fact that not every Squeak user is on the mailing list.
To avoid a further misunderstanding: I don't think that SqueakMap should
not be used or were the wrong tool for the purpose. I rather think that you
might overestimate its current role. I don't remember seeing anyone using
SqueakMap in front of my eyes, and I have seen many screens with Squeak.
Yet, my perception might be biased, that's why I would be interested in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev