In menu Help/Extending the system there is already a entry Installer ensureRecentMetacello. Maybe we should add the Installer installGitInfrastructure there ?

Best, Karl

On Tue, Apr 2, 2019 at 6:33 PM Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi, there.

Can you please restore those lines:

Installer ensureRecentMetacello. Installer installGitInfrastructure.

What is this commit part of? It removes a dot at the end and also the recent additions I mentioned above. :-)

Best, Marcel

Am 02.04.2019 01:09:14 schrieb commits@source.squeak.org < commits@source.squeak.org>: Chris Muller uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-cmm.1059.mcz

==================== Summary ====================

Name: System-cmm.1059 Author: cmm Time: 1 April 2019, 6:08:54.797918 pm UUID: 6ab6befc-9fa5-4aa5-a1b6-3570ba2853b9 Ancestors: System-eem.1058

Organize configuration scripts in the "Extending The System" workspace or SqueakMap.

=============== Diff against System-eem.1058 ===============

Item was changed: ----- Method: Utilities class>>initializeCommonRequestStrings (in category 'common requests') ----- initializeCommonRequestStrings "Initialize the common request strings, a directly-editable list of expressions that can be evaluated from the 'do...' menu."

CommonRequestStrings := StringHolder new contents:

• 'Utilities emergencyCollapse.

• 'Installer ensureRecentMetacello.
• Installer installGitInfrastructure.
• Utilities emergencyCollapse.

Utilities closeAllDebuggers.

Sensor keyboard. ParagraphEditor abandonChangeText. Cursor normal show.

CommandHistory resetAllHistory. Project allInstancesDo: [:p | p displayDepth: 16]. ScriptingSystem inspectFormDictionary. Form fromUser bitEdit. Display border: (0@0 extent: 640@480) width: 2.

Undeclared inspect. Undeclared removeUnreferencedKeys; inspect. Transcript clear. Utilities grabScreenAndSaveOnDisk. FrameRateMorph new openInHand.

Utilities reconstructTextWindowsFromFileNamed: ''TW''. Utilities storeTextWindowContentsToFileNamed: ''TW''. ChangeSorter removeEmptyUnnamedChangeSets. ChangeSorter reorderChangeSets.

ActiveWorld installVectorVocabulary. ActiveWorld abandonVocabularyPreference.

• Smalltalk saveAsNewVersion'

• Smalltalk saveAsNewVersion.'

"Utilities initializeCommonRequestStrings"!

On 2019-04-02, at 1:53 PM, Chris Muller asqueaker@gmail.com wrote:

The last entry of the Do menu is "edit this list", this is how it was intended to be personalized. Is that okay?

How about extending the preferences so that saving your prefs to file includes these items in some manner?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- QUIP PRO QUO - A fast retort

Am Di., 2. Apr. 2019 um 22:54 Uhr schrieb Chris Muller <asqueaker@gmail.com

:

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

On the other hand, installing Metacello is nearly every time the first thing I have to do in a fresh Trunk image to load any projects from GitHub with their dependencies. The shorter the way to install Metacello, the better. I was delighted to have it in the menu. Not that I particularly like Metacello, but I *need* it.

In fact, this menu item is the only one in the Do menu I have ever used. Well except for the git infrastructure one, but since I developed the things that it installs, I am biased. Note that it was not me who put the item on the list, although I felt flattered about it.

The last entry of the Do menu is "edit this list", this is how it was intended to be personalized. Is that okay?

Not if you would first have to edit this list to get your initialize-your-trunk-image items into it. ¯_(ツ)_/¯ On that note, if there was a way to restore the saved list (or preferences for that matter) quickly from a well-known file name, it should be on that list. Saving it to the well-known file should be on there too.

Installing the current incarnation of the refactoring tools might be another good candidate for an image initialization shortlist. I mostly live without them just because the buttons to install them are too many clicks away...

Am Di., 2. Apr. 2019 um 22:54 Uhr schrieb Chris Muller <asqueaker@gmail.com

:

Hi Marcel,

The Do menu was targeted toward newcomers as a way to introduce some basics of Squeak. It gives the newcomer list of Squeak expressions which are generically useful, and have been unchanged since 2002.

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

The last entry of the Do menu is "edit this list", this is how it was intended to be personalized. Is that okay?

Best, Chris

PS -- Marcel, can you simply define Metacello and/or GitInfrastructure as prerequisites to whatever package(s) require them?

On Tue, Apr 2, 2019 at 11:33 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Hi, there.

Can you please restore those lines:

Installer ensureRecentMetacello. Installer installGitInfrastructure.

What is this commit part of? It removes a dot at the end and also the

recent additions I mentioned above. :-)

...

Best, Marcel

Am 02.04.2019 01:09:14 schrieb commits@source.squeak.org <

commits@source.squeak.org>:

...

Chris Muller uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-cmm.1059.mcz

==================== Summary ====================

Name: System-cmm.1059 Author: cmm Time: 1 April 2019, 6:08:54.797918 pm UUID: 6ab6befc-9fa5-4aa5-a1b6-3570ba2853b9 Ancestors: System-eem.1058

Organize configuration scripts in the "Extending The System" workspace

or SqueakMap.

...

=============== Diff against System-eem.1058 ===============

Item was changed: ----- Method: Utilities class>>initializeCommonRequestStrings (in

category 'common requests') -----

...

initializeCommonRequestStrings "Initialize the common request strings, a directly-editable list of

expressions that can be evaluated from the 'do...' menu."

...

CommonRequestStrings := StringHolder new contents:

• 'Utilities emergencyCollapse.

• 'Installer ensureRecentMetacello.
• Installer installGitInfrastructure.
• Utilities emergencyCollapse.

Utilities closeAllDebuggers.

Sensor keyboard. ParagraphEditor abandonChangeText. Cursor normal show.

CommandHistory resetAllHistory. Project allInstancesDo: [:p | p displayDepth: 16]. ScriptingSystem inspectFormDictionary. Form fromUser bitEdit. Display border: (0@0 extent: 640@480) width: 2.

Undeclared inspect. Undeclared removeUnreferencedKeys; inspect. Transcript clear. Utilities grabScreenAndSaveOnDisk. FrameRateMorph new openInHand.

Utilities reconstructTextWindowsFromFileNamed: ''TW''. Utilities storeTextWindowContentsToFileNamed: ''TW''. ChangeSorter removeEmptyUnnamedChangeSets. ChangeSorter reorderChangeSets.

ActiveWorld installVectorVocabulary. ActiveWorld abandonVocabularyPreference.

• Smalltalk saveAsNewVersion'

• Smalltalk saveAsNewVersion.'

"Utilities initializeCommonRequestStrings"!

On Tue, 2 Apr 2019, Chris Muller wrote:

Hi Jakob and Tim R.,

...

...

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

On the other hand, installing Metacello is nearly every time the first thing I have to do in a fresh Trunk image to load any projects from GitHub with their dependencies. The shorter the way to install Metacello, the better. I was delighted to have it in the menu. Not that I particularly like Metacello, but I *need* it.

You need a proper solution to dependency management, adding our

You mean a tool like Metacello?

Levente

personal projects to the top of everyone's Do menu isn't it. ;)

Tim R. wrote:

...

How about extending the preferences so that saving your prefs to file includes these items in some manner?

I used to configure my images manually like this -- by a series of clicks on this or that menu, opening up of Preferences to click the "Load Preferences" button, setting my theme, etc.

It was and still is a really bad way to do configuration.

I now use a class-side #initialize method that configures _everything_ I need for preferences and stuff.

I also made sure all my packages have dependency management --

• checking if a pre-requisite package is already present and, if not,
• load that package

The 2nd step may, itself, have dependencies, but they each follow those same two steps, so it doesn't matter how big the tree of dependencies is, nor what overlappings may exist with whatever else may already be loaded.

Best, Chris

...

In fact, this menu item is the only one in the Do menu I have ever used. Well except for the git infrastructure one, but since I developed the things that it installs, I am biased. Note that it was not me who put the item on the list, although I felt flattered about it.

...

The last entry of the Do menu is "edit this list", this is how it was intended to be personalized. Is that okay?

Not if you would first have to edit this list to get your initialize-your-trunk-image items into it. ¯_(ツ)_/¯ On that note, if there was a way to restore the saved list (or preferences for that matter) quickly from a well-known file name, it should be on that list. Saving it to the well-known file should be on there too.

Installing the current incarnation of the refactoring tools might be another good candidate for an image initialization shortlist. I mostly live without them just because the buttons to install them are too many clicks away...

Am Di., 2. Apr. 2019 um 22:54 Uhr schrieb Chris Muller asqueaker@gmail.com:

...

Hi Marcel,

The Do menu was targeted toward newcomers as a way to introduce some basics of Squeak. It gives the newcomer list of Squeak expressions which are generically useful, and have been unchanged since 2002.

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

The last entry of the Do menu is "edit this list", this is how it was intended to be personalized. Is that okay?

Best, Chris

PS -- Marcel, can you simply define Metacello and/or GitInfrastructure as prerequisites to whatever package(s) require them?

On Tue, Apr 2, 2019 at 11:33 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Hi, there.

Can you please restore those lines:

Installer ensureRecentMetacello. Installer installGitInfrastructure.

What is this commit part of? It removes a dot at the end and also the recent additions I mentioned above. :-)

Best, Marcel

Am 02.04.2019 01:09:14 schrieb commits@source.squeak.org commits@source.squeak.org:

Chris Muller uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-cmm.1059.mcz

==================== Summary ====================

Name: System-cmm.1059 Author: cmm Time: 1 April 2019, 6:08:54.797918 pm UUID: 6ab6befc-9fa5-4aa5-a1b6-3570ba2853b9 Ancestors: System-eem.1058

Organize configuration scripts in the "Extending The System" workspace or SqueakMap.

=============== Diff against System-eem.1058 ===============

Item was changed: ----- Method: Utilities class>>initializeCommonRequestStrings (in category 'common requests') ----- initializeCommonRequestStrings "Initialize the common request strings, a directly-editable list of expressions that can be evaluated from the 'do...' menu."

CommonRequestStrings := StringHolder new contents:

• 'Utilities emergencyCollapse.

• 'Installer ensureRecentMetacello.
• Installer installGitInfrastructure.
• Utilities emergencyCollapse.

Utilities closeAllDebuggers.

Sensor keyboard. ParagraphEditor abandonChangeText. Cursor normal show.

CommandHistory resetAllHistory. Project allInstancesDo: [:p | p displayDepth: 16]. ScriptingSystem inspectFormDictionary. Form fromUser bitEdit. Display border: (0@0 extent: 640@480) width: 2.

Undeclared inspect. Undeclared removeUnreferencedKeys; inspect. Transcript clear. Utilities grabScreenAndSaveOnDisk. FrameRateMorph new openInHand.

Utilities reconstructTextWindowsFromFileNamed: ''TW''. Utilities storeTextWindowContentsToFileNamed: ''TW''. ChangeSorter removeEmptyUnnamedChangeSets. ChangeSorter reorderChangeSets.

ActiveWorld installVectorVocabulary. ActiveWorld abandonVocabularyPreference.

• Smalltalk saveAsNewVersion'

• Smalltalk saveAsNewVersion.'

"Utilities initializeCommonRequestStrings"!

I'm planning a major upgrade to SqueakMap later this year that keeps the existing model but server and UI upgraded to an AppStore-like experience. It'd be great to have GitInfrastructure and Metacello entries in there along with some of the interesting git-based projects. A consistent one-click experience to "load anything" is good for Squeak. One click would get you the whole way there (configuring a new image) instead of only half way as when starting in the Do menu. Easier for others to bootstrap and look. Maybe participate.

Best, Chris

On Tue, Apr 2, 2019 at 8:17 PM Chris Muller asqueaker@gmail.com wrote:

On Tue, Apr 2, 2019 at 7:08 PM Levente Uzonyi leves@caesar.elte.hu wrote:

...

On Tue, 2 Apr 2019, Chris Muller wrote:

...

Hi Jakob and Tim R.,

...

...

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

On the other hand, installing Metacello is nearly every time the first thing I have to do in a fresh Trunk image to load any projects from GitHub with their dependencies. The shorter the way to install Metacello, the better. I was delighted to have it in the menu. Not that I particularly like Metacello, but I *need* it.

You need a proper solution to dependency management, adding our

You mean a tool like Metacello?

In this case Metacello is a pre-req package needing loaded, so, no. Are you making a joke?

It should be handled the same as everything else: a script that checks / loads Metacello and then the dependent app, and store that script in SqueakMap.

• Chris

Chris Muller asqueaker@gmail.com schrieb am Mi., 3. Apr. 2019, 03:18:

On Tue, Apr 2, 2019 at 7:08 PM Levente Uzonyi leves@caesar.elte.hu wrote:

...

On Tue, 2 Apr 2019, Chris Muller wrote:

...

Hi Jakob and Tim R.,

...

...

I understand that you like Metacello and GitInfrastructure and may wish to promote their use to others, but as Karl mentioned we already have existing places in the IDE dedicated to package installation, we should not introduce another new place, especially one so orthogonal to its regular purpose. I guess you wouldn't to see "Installer installMagma" in there, right?

On the other hand, installing Metacello is nearly every time the

first thing I have to do in a fresh Trunk image to load any projects from GitHub with their dependencies.

...

...

...

The shorter the way to install Metacello, the better. I was delighted

to have it in the menu. Not that I particularly like Metacello, but I *need* it.

...

...

You need a proper solution to dependency management, adding our

You mean a tool like Metacello?

In this case Metacello is a pre-req package needing loaded, so, no. Are you making a joke?

Forgive me Chris, but are you joking? You do know what Metacello is, don't you? It provides the very dependency management you are writing about and it is *the* currently accepted standard way to load Smalltalk projects from GitHub. This is not something I made up to fit my case (in fact I don't like Metacello very much), but it is status quo. These projects place a Metacello load script in their README files. It is basically used like a platform requirement, like apt on Debian.

It should be handled the same as everything else: a script that

checks / loads Metacello and then the dependent app, and store that script in SqueakMap.

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!

Am Do., 4. Apr. 2019 um 16:51 Uhr schrieb Tim Johnson digit@sonic.net:

On Apr 2, 2019, at 3:00 PM, Jakob Reschke wrote:

...

Installing the current incarnation of the refactoring tools might be another good candidate for an image initialization shortlist. I mostly live without them just because the buttons to install them are too many clicks away...

Where are they?

That's part of the guessing game, isn't it? ;-) tl;dr: the "Refactoring Tools" are on the SqueakMap for Squeak 5.2

The Squeak Wiki tells you all kinds of things like installing Refactoring Browser from SqueakMap, the third Google hit is actually a diff view of a Wiki page, then there is a note that the OmniBrowser is not supported anymore... alright, don't want to know that. But hey, at least it mentions SqueakMap. (But still you need to know that for the latest Squeak, you need the "Tools", not the "Browser". I'll put the words "Refactoring Tools" on the pages I came across.)

So there we go: 1) open SqueakMap Catalog from Apps menu 2) no packages there (Trunk image), have to right-click the package list and disable "New safely-available packages" 3) enter "refactoring" in the Search package box, hit return. Takes me to AwesomAtom first. Hmm. Unfortunately Refactoring Tools starts with an R, so I won't get there with repeated return hitting any time soon 3½) since I happen to already know the name, scroll down to Refactoring Tools manually 4) right-click, Install. "The package has no published release for your Squeak version [...]". Yes. Another warning prompt, yes. Done!

9 clicks or scroll actions if you know where to look (without step 3). Does not sound too bad actually, but still if you grab a new image every now and then and repeat it for multiple packages... Would have been 2 clicks from the Do menu, or maybe two-and-a-half if the Apps or Tools menu had a submenu to install often-used or recommended packages.

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

On 04.04.2019, at 21:54, Jakob Reschke forums.jakob@resfarm.de wrote:

Am Do., 4. Apr. 2019 um 16:51 Uhr schrieb Tim Johnson digit@sonic.net:

On Apr 2, 2019, at 3:00 PM, Jakob Reschke wrote:

...

Installing the current incarnation of the refactoring tools might be another good candidate for an image initialization shortlist. I mostly live without them just because the buttons to install them are too many clicks away...

Where are they?

That's part of the guessing game, isn't it? ;-) tl;dr: the "Refactoring Tools" are on the SqueakMap for Squeak 5.2

or

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

¯_(ツ)_/¯

The Squeak Wiki tells you all kinds of things like installing Refactoring Browser from SqueakMap, the third Google hit is actually a diff view of a Wiki page, then there is a note that the OmniBrowser is not supported anymore... alright, don't want to know that. But hey, at least it mentions SqueakMap. (But still you need to know that for the latest Squeak, you need the "Tools", not the "Browser". I'll put the words "Refactoring Tools" on the pages I came across.)

So there we go:

1. open SqueakMap Catalog from Apps menu
2. no packages there (Trunk image), have to right-click the package list and disable "New safely-available packages"
3. enter "refactoring" in the Search package box, hit return. Takes me to AwesomAtom first. Hmm. Unfortunately Refactoring Tools starts with an R, so I won't get there with repeated return hitting any time soon

3½) since I happen to already know the name, scroll down to Refactoring Tools manually 4) right-click, Install. "The package has no published release for your Squeak version [...]". Yes. Another warning prompt, yes. Done!

9 clicks or scroll actions if you know where to look (without step 3). Does not sound too bad actually, but still if you grab a new image every now and then and repeat it for multiple packages... Would have been 2 clicks from the Do menu, or maybe two-and-a-half if the Apps or Tools menu had a submenu to install often-used or recommended packages.

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

Am Do., 4. Apr. 2019 um 22:22 Uhr schrieb Tim Johnson digit@sonic.net:

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.

The nice thing about it is that the refactoring tools are not in a separate browser anymore. :-) You can use them from the default browser. But some operations are broken or awkward, which is a pity, and ironically an argument both against and for including them in trunk.

Well, if a recent version of Metacello were in trunk, I would not object dropping the Do menu item for it either. ;-)

Am Do., 4. Apr. 2019 um 21:54 Uhr schrieb Jakob Reschke < forums.jakob@resfarm.de>:

Am Do., 4. Apr. 2019 um 16:51 Uhr schrieb Tim Johnson digit@sonic.net:

...

On Apr 2, 2019, at 3:00 PM, Jakob Reschke wrote:

...

Installing the current incarnation of the refactoring tools might be another good candidate for an image initialization shortlist. I mostly live without them just because the buttons to install them are too many clicks away...

Where are they?

That's part of the guessing game, isn't it? ;-) tl;dr: the "Refactoring Tools" are on the SqueakMap for Squeak 5.2 [...] So there we go:

1. open SqueakMap Catalog from Apps menu
2. no packages there (Trunk image), have to right-click the package list

and disable "New safely-available packages" 3) enter "refactoring" in the Search package box, hit return. Takes me to AwesomAtom first. Hmm. Unfortunately Refactoring Tools starts with an R, so I won't get there with repeated return hitting any time soon 3½) since I happen to already know the name, scroll down to Refactoring Tools manually 4) right-click, Install. "The package has no published release for your Squeak version [...]". Yes. Another warning prompt, yes.

Problems for a newcomer: 1) What is SqueakMap? Or how would I even know I need to look at it, it is not mentioned in the Welcome to Squeak text. 2&4) Newcomers should definitely stick to release images :-) and hope that the packages have versions for the latest one. 3) The search mode seems unintuitive (although I guess I understand why it does what it does)

I hope that the experience is improved and simplified with the changes Chris has coming.

I used to install Metacello via SqueakMap before the item in the Do menu appeared, so my annoyances were 2), 3), 4). Looking up the install snippet on GitHub is not faster. Typing Installer ensureRecentMetacello is faster, but then I have to remember that. I didn't know about the "Extending the system" page until two days ago.

Still I'd rather like to keep the Metacello item in the Do menu. Or Apps or Tools. Doesn't matter to me whether it is at the top, in the middle or at the bottom. After clicking that, I can continue to copy the install script from the GitHub project's README that I had right in front of me when I decided that I need to grab a new trunk image.

The community might decide to drop the Git infrastructure item (remember Chris: I did not put it there, the fans of it did), but I think easing the access to GitHub projects is important in the present and the future.

Kind regards, Jakob

Hi Chris,

Am Fr., 5. Apr. 2019 um 02:44 Uhr schrieb Chris Muller <asqueaker@gmail.com

:

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.

I know that Squeak does not target developers only. But it *also* targets developers.

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.

...

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.

...

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.

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.

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

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.

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.

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

Best regards, Jakob

Hi Chris,

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: https://github.com/j4yk/tonel/blob/squeak/README.md 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@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 http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf (also 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 concrete entities: - 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 on SqueakMap - 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 that.

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: 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). The workaround solutions are: 1) make Metacello as quickly installable as possible: the Do (or whatever) menu item 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 separate thread.

...

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.

...

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.

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

...

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 exaggeration, sorry.

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.

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

Kind regards, Jakob

Hi Chris,

I think the main conflict point is resolved when the MetacelloStub proposal is accepted. I still would like to clarify some things for the benefit of mutual understanding, but I will try to skip the ones that would extend the debate needlessly.

Am Mo., 8. Apr. 2019 um 03:35 Uhr schrieb Chris Muller <asqueaker@gmail.com

:

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.

In 90% of the cases when I fetch a new image, I will install Metacello first, then load something with it. That something varies, Metacello does not. Metacello is the common thing on these paths to the "complete" image, whatever comes after loading Metacello depends on the case. Metacello is a bit like a surrogate for SqueakMap in this alternate workflow, but not completely. And Metacello is not pre-loaded in the image. Imagine the nuisance if you had to install SqueakMap in every new image first and then a shortcut to do it that someone else recently added were removed. ;-) So much about my feelings for that menu entry. Fabio's suggestion and your implementation with the MetacelloStub solves the problem without the need for a menu entry, so it's the best of both worlds. Thank you.

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

No, the readmes are under version control, in Git.

I don't know whether people ever edit them using Squeak, or Pharo, but I guess they don't. Files can be edited directly on GitHub and that usually is the quickest way for the readme because you can immediately see the results of the Markdown formatting. So it even is in-browser editing, albeit not with a Smalltalk browser. ;-) (This time, it really is a joke...)

Maybe the readme should be just one single

line that simply calls an appropriate method on Installer (or whatever) to do everything.

The readmes on GitHub are also "regular" readme files, which contain the project description etc. Like the descriptions on SqueakMap.

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

I thought a moment about automatically collecting SqueakMap entries out of GitHub projects. That is, finding them with the search if you conduct one. But there are all kinds of issues, such as reliably detecting the proper install script (there might be more than one) that applies to Squeak. And it could only provide head configurations, no stable ones, unless you put yet much more effort in. And it would, of course, find projects that won't work at all in Squeak and cannot even be loaded even if Metacello were already in the image.

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.

No I never expect that such an attempt will be painless. Not even for proper Squeak projects in a trunk image. But actually I can seldom expect that from software in general. Still, hope dies last.

...

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?

No no, the scripts and Metacello configurations are only in the repositories of these projects. The code snippet to trigger Metacello to actually load the project is placed in the readme to have it easily found. So when you find something on GitHub and wish to load it, the load script is usually right in front of you, you don't have to know it.

The scenario I have in mind has a different starting point than the one you seem to have in mind: you seem to think of "I want to load project Xyz and I have Squeak in front of me. I go to the SqueakMap to load it", which makes sense (in particular if you are willing to create an entry if it does not exist yet). I think of "I am in my web browser and have project Xyz in front of me and would like to load it in Squeak. It has a (Metacello) load script in its installation instructions, so I go to Squeak (need Metacello) and run that load script". So in my case, the project and the load script is already found. Searching it again in SqueakMap feels a little redundant. However, you are right: if there is a working and up-to-date configuration (or one creates it), and one ever wants to load Xyz again, this will be an attractive way to go for next time.

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.

That's right, it does not get me to the final configuration. But it does make these GitHub projects (and their dependencies) accessible at all. That was the purpose all along. It was better than nothing or getting to the halfway-configured state in more cumbersome ways. The new MetacelloStub lets us skip that state.

...

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

License aside, if someone had a "do this to load in Squeak" section in their text, I would assume that they support Squeak somehow. Also note that Pharo does not have the ensureRecentMetacello method AFAIK, so one cannot include that line in a general install script in the readme without mentioning Squeak. Again, with the MetacelloStub, there is no need to even ask for the line anymore.

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.

About that I had no doubts. I meant its popularity, but somehow that word didn't come to my mind yesterday, sorry. However, I did a little research and must acknowledge that my impression stems from the very limited exposure to SqueakMap at university. Most projects I know from there I don't find on SqueakMap. And since nobody uses Squeak in my regular surroundings today, that covers most of the projects I know. So my perception on that is indeed biased, as I feared.

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.

It's not that simple. I know some squeakers personally who care very much about Squeak and they put a lot of effort into it. But their attention apparently does not extend to SqueakMap, and neither did mine. They probably have valid reasons, but I better refrain from trying to advocate any further. I have spent far too many hours of possible sleep on this discussion already. ;-) Have a nice day everyone.

Kind regards, Jakob

Ah, ok. It makes sense now :-)

Thanks, Dave

On Tue, Apr 02, 2019 at 09:30:23PM -0500, Chris Muller wrote:

Hi Dave,

Installer metacello is already in the Extending The system Workspace. My plan was to add the same GitInfrastructure right there too and submit that to Inbox too, but I got an Error when I tried to save it straight in the window.

I had already committed this one to Inbox, I just haven't had time to debug whatever broke the ability to update the Extending The System workspace yet. Once fixed, the comment will make sense in conjunction with that commit.

• Chris

...

I am not happy with the System-cmm.1059 proposal because it reverts previous updates but does not provide a solution to the problem that it is intended to address.

Here is what it says that it does:

...

Name: System-cmm.1059 Time: 1 April 2019, 6:08:54.797918 pm

Organize configuration scripts in the "Extending The System" workspace or SqueakMap.

What it actually does is revert these three prior commits:

...

Name: System-fn.1044 Time: 15 October 2018, 10:11:52.454872 am

Fixes dot inconsistency.

...

Name: System-pre.1043 Time: 8 October 2018, 2:14:05.659633 pm

In order to make the new Git version control infrastructure more accessible, this commit adds the new Installer script to the Do menu.

...

Name: System-mt.1019 Time: 16 April 2018, 10:47:59.119614 am

Adds script for installing (or updating) Metacello to the "Do" menu.

(Add it yourself or run "Utilities cleanUp: true" to test.)

If we think that the two menu items in question might better be put on SqueakMap or in "Extending The System", then let's do that, then tidy up the "Do" menu after the better solution has been implemented.

Dave

On Mon, Apr 01, 2019 at 11:09:06PM +0000, commits@source.squeak.org wrote:

...

Chris Muller uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-cmm.1059.mcz

==================== Summary ====================

Name: System-cmm.1059 Author: cmm Time: 1 April 2019, 6:08:54.797918 pm UUID: 6ab6befc-9fa5-4aa5-a1b6-3570ba2853b9 Ancestors: System-eem.1058

Organize configuration scripts in the "Extending The System" workspace or SqueakMap.

=============== Diff against System-eem.1058 ===============

Item was changed: ----- Method: Utilities class>>initializeCommonRequestStrings (in category 'common requests') ----- initializeCommonRequestStrings "Initialize the common request strings, a directly-editable list of expressions that can be evaluated from the 'do...' menu."

  CommonRequestStrings := StringHolder new contents:

• 'Utilities emergencyCollapse.

• 'Installer ensureRecentMetacello.
• Installer installGitInfrastructure.
• Utilities emergencyCollapse. Utilities closeAllDebuggers.
  Sensor keyboard. ParagraphEditor abandonChangeText. Cursor normal show.
  CommandHistory resetAllHistory. Project allInstancesDo: [:p | p displayDepth: 16]. ScriptingSystem inspectFormDictionary. Form fromUser bitEdit. Display border: (0@0 extent: 640@480) width: 2.
  Undeclared inspect. Undeclared removeUnreferencedKeys; inspect. Transcript clear. Utilities grabScreenAndSaveOnDisk. FrameRateMorph new openInHand.
  Utilities reconstructTextWindowsFromFileNamed: ''TW''. Utilities storeTextWindowContentsToFileNamed: ''TW''. ChangeSorter removeEmptyUnnamedChangeSets. ChangeSorter reorderChangeSets.
  ActiveWorld installVectorVocabulary. ActiveWorld abandonVocabularyPreference.

• Smalltalk saveAsNewVersion'

• Smalltalk saveAsNewVersion.'

  "Utilities initializeCommonRequestStrings"!