The Inbox: System-cmm.1059.mcz

or

Installer ensureRecentMetacello.
Metacello new
        configuration: 'RefactoringTools';
        load.

¯\_(ツ)_/¯

On 2019-04-04 12:54, Jakob Reschke wrote:

By the way, why are the refactoring tools not in Trunk? Other IDEs that call themselves like that come with their refactoring tools preinstalled.

 

I don’t know about anyone else but refactoring tools should be a requirement. 

 

On 2019-04-04 12:54, Jakob Reschke wrote:

By the way, why are the refactoring tools not in Trunk? Other IDEs that call themselves like that come with their refactoring tools preinstalled.

 

 

As a goal of Squeak is to be accessible to newcomers, I'm fine with the refactoring tools not being the default, even if they are present.  I like the default Browsers and Package Pane Browser but would also like to occasionally switch to RB to learn it and experiment.  This is what makes that blue drop-down menu button in the upper-right of a browser window useful to me:  "Choose new default browser" and "register this browser as default."  I like that!

 

Thanks,
Tim J

 

 

 

Hi Jakob,

I agree with the UI problems you mention about the in-image SqueakMap
client window, but those are just ToolBuilder configuration
superficialities I or someone will eventually fix.  In the meantime, I
adamantly want to reduce the number of places in the IDE where we tell
people to load things from.  For now I've moved them to the Tools
menu, as you suggested.

I also recognize a perception on your part of Squeak and its community
being like the group identified on the home-page of github.com:

    "Built for developers"

so hope you won't mind me reminding that the audience for Squeak goes
beyond that group.  Squeak should continue to cater to Users, because
they're not as tough as Developers.  As a developer, you can
appreciate a modular system capable of loading IDE plug-ins.

> 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.

> 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.  That's
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.

 - Chris




 - Chris






On Thu, Apr 4, 2019 at 3:22 PM Jakob Reschke <[hidden email]> wrote:

Hi Jakob,

Of course, I believe I said that.

> 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?

>> > 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.

"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...

> 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.

> 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.

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.

> 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.

> 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.

You made the argument above that "it is doomed to become stale" but
then above you say, "responsibility to test".  Which is it Jakob?

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
won't.

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.

Barring that, all I ask that we don't confuse how software
Installation is done in Squeak.


 - Chris

Hi Jakob,

> Sigh, I feel thoroughly misunderstood. Am I expressing myself so unclear? If that's the case I apologize. Let's have another try:

Thanks for your effort to broaden our mutual understanding.  The fact
that these menu items are at the nexus of broad and complex topics of
configuration, community and UX, it's no surprise that there's a lot
to say.

In the interests of clarity, I'm going to be liberal in snipping out a
lot of what I consider to be "weeds" in this discussion, so that
what's left will hopefully be a distillation of what's relevant.

> Consequently, my current free time development platform of choice is Squeak. It is not Pharo.

Okay, I didn't know.

>> Are you saying Metacello does not have its own browser and never will?
> (...snip...) Metacello has no browser and I think it never will.

Okay, but for reasons I'll explain below, this does not excuse it back
to the Do menu.

> 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.

This is where I would like to ask you to take a step back and imagine
there is _another university_, or perhaps two or three, or five, each
with their own way to "initialize a trunk image to a state from which
we can start working."  We ALL face this issue of "initial
configuration", Jakob.  So far, no one else has added theirs to the Do
menu, not because they agree with Marcel that it isn't much to type
into a workspace, but because they respect that such a thing is
completely unscalable and unsustainable.  The Do menu is like a
"commons".

None of the other parts of the discussion below (SqueakMap, etc.)
really matters beyond the point above, except as it can be interesting
to entertain alternative ideas with you.  I don't want to force you or
anyone to use SqueakMap, just please don't make an unscalable third
place for general-installation of software by polluting the Do menu.
Or, do it only in the university image, not the release image.

That is exacly how I understood you the first time, and my first
response remains the same.  The problem with your argument is you are
pretending "the rest of the world" group, the "does not agree" group,
and "does not comply" groups actually care about having those items on
the Do menu or on SqueakMap.  Since they don't use or care about
Squeak, they don't.  So correct, we DON'T expect them to make
SqueakMap entries.

The only ones that care about access in Squeak is the "we" (more
specifically, you, Marcel, people loading projects from github into
Squeak).  People who, I guess, want to use Squeak and want it be easy
for them.  That makes YOU the "third person" to make that entry, *even
for projects maintained by others*, because for no other reason that
you want to be able to consume it quickly.  Remember, #ensureMetacello
doesn't get you "initialize a trunk image to a state from which we can
start working," does it?  Because you still have to load whatever
package(s) you want to actually work on.

>> ... snip ...

Ah!  This made me just be able to grok Fabio's idea!  Cool!  How about that?

>> > 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.

There you go again, talking about "forcing".  I want to state this
very cleearly -- **all of my ideas in this discussion were always
based on not depending on anything from package maintainers**.
Nothing.

Seriously, please align the incentives with the resultant actions in
your analysis and process development.  The basis of your arguments is
always that these two incentives are mis-aligned, which isn't reality.

> 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.

So you're writing and maintaining multiple lines of code in a README
that is not subject to the benefits of SCM version control and
in-browser editing, etc.?   Maybe the readme should be just one single
line that simply calls an appropriate method on Installer (or
whatever) to do everything.  Maybe even such readme script could be
accessed directly off the network from within Squeak?  Then,
theoretcally, you wouldn't have to "maintain" it...   But, this method
of doing configuration is quickly shows its limitations...

Furthermore, what you're trying to do is expect software written for
Pharo to install and work on Squeak with zero code or effort for
platform-specific configuration issues.  This does not represent a
commitment to Squeak, and is not an excuse to pollute one of its
commons areas just to make arriving at a half-assed configuration
easier.

I also like Fabio's idea...

> Because "every project" also includes projects whose developers do not use Squeak. But the project might still be interesting for Squeakers.

If it was truly "interesting" to a Squeaker they would want an easy
way to consume, so would not mind cut-and-pasting the load-script into
a SqueakMap entry.  They wouldn't add it to the Do menu.

> For example, there is Clément's Scorch: https://github.com/clementbera/Scorch Clément 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 ensureLatestMetacello line.)
>
> 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).

Having Metacello in the image does not eliminate any obstacle to
accessing those projects.  **You still need to know the load script**
to load them.  Are you saying these scripts are in Metacello without
loading the actual project?   If so, wow, I really do not care for
Metacello, and would not care to have it in my image.

The workaround solutions are:
> 1) make Metacello as quickly installable as possible: the Do (or whatever) menu item

You keep conflating this with access to the projects (as provided in 2
and 3, next).  This is the "halfway configured" state.  This is not a
"solution" to configuration.

> 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

MIT license states "softare is AS IS", how in the world does
"ensureMetacello" line suddely make maintainers "responsible"?

I know this doesn't change the fact they could still refuse, but at
least don't let it be for a false reason like that!

> 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.
> ...snip...
>
> 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.

I disagree, because that falls under "Help".  The requirement is we
make a "natural path of discovery", the Help menu is the start of that
path.  The Do menu isn't anywhere on it.

>> 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 separate thread.

What matters is the future.  What we want Squeak to BE.  Who used it
or didn't in the past is irrelevant, only that, going forward, it
serves those who want the flexibility load _anything_, and know that
it will work.

One thing I'm sure we agree on -- the "Do" menu and readme's are not
the university's "final solution" to this matter.

>> ... snip...
>
>> 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.

A catalog is catalog.  We both understand what purpose they serve, and
their limitations...

> 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.

Not at all.  I know exactly what its responsibilities and limitations
are.  The "head" versions which are for devs to load "the latest" are
available for cases like this, but SM's primary purpose is
preservation of working configurations.

> 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 that poll.

As I said before, such a thing is totally irrelevant to voluntaryists;
past, present, or future.  If a github project sufficently interests
someone in Squeak, they'll make a SqueakMap entry for it to serve them
personally.  If it doesn't, they won't.  Either way, no one is
"forced" to do anything whatsoever, but everyone benefits from those
who did voluntarily.

 - Chris