…Trying to have 7.0.3 as my base, not 8.0. I’m not sure what happened with the VM crash, but I can do without the latest version for now. How do I specify the commit with Iceberg? Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of ducasse Sent: Wednesday, May 29, 2019 10:17 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Versioning with Iceberg Hello Can you tell us what you are doing? Because if a project loads always the head then iceberg will load it. Or you should specify a specific commit. Stef On 29 May 2019, at 11:07, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I’m finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Shaping

I’m finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Its not completely clear what you want. You can right-click a repo > Metacello > Install baseline of..... Or right-click a repo > Repository > Remotes and select one of those branches to check out. The baselines look specialized. I want Pharo 7.0.3, not just one package. Shaping

Sorry, I meant progress bar, not histo…. From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, May 29, 2019 20:05 To: 'Pharo Development List' <pharo-dev@lists.pharo.org> Subject: RE: [Pharo-dev] Versioning with Iceberg From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Wednesday, May 29, 2019 10:58 To: Pharo Development List <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Versioning with Iceberg On Wed, 29 May 2019 at 23:08, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I’m finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Its not completely clear what you want. You can right-click a repo > Metacello > Install baseline of..... Or right-click a repo > Repository > Remotes and select one of those branches to check out. I missed the Repository item completely, all this time. I think I was blocking it out mentally because I was already in an Iceberg window that lists repos. The doubling up is confusing and unexpected. So we have Iceberg repos wrapping Git repos? I’m not sure I have the scheme right. Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks? These lock up the system for 1 or 2 minutes often. For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor). This happens when cloning a Git repo, too. The histo opens about ½ second before the about 1-m pull finishes. This happened in the 7.0.3 build. Is there a policy not to use a wait-cursor if not histo is shown? Shaping

Using iceberg - I typically see the normal loading progress bars for long operations on the top left of the screen - often they stack below one another to show nested operations (aside: they are a bit ugly - but it’s a consistent metaphor across Pharo). I get them when loading, pulling, pushing, diffing etc. Do you not see them? I do, but not reliably. Sometimes I wait as I said until the loading threat is done. Then the GUI gets a chance to run, and the progress bar appears at the last moment (99% or so). Back to your version question - what baseline are you loading from a repo? A specific example might help. 7.0.3. It loaded after a fresh clone of pharo, but with a detached head. If i were to load Exercism as an example - the following page describes how to upgrade to a specific version of the baseline in the repo. Eg latest vs v0.2.3 https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md This describes how to do it in the playground - as versions are actually loaded by metacello - and Iceberg builds on top of it to route things via git and make use of version tags etc, and it then gives the push/pull/commit operations. (I’m probably describing this badly - but I suspect the confusion is in here for you). … Hours later the “Checking out v7.0.3 from pharo” progress bar is still stuck. How is the stuck progress bar related to the detached head? Having loaded your particular baseline (the code tagged as v2.0.3 for example), Iceberg will let you compare it to other branches - or hash versions in git. But typically, libraries you use will give you a playground script that specifies a stable version - you eval that in your playground and those libraries will then appear in your image (and also in Iceberg). Yes, I want all of Pharo 7.0.3 this time. I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. ? For your project - you can formalise those dependencies by creating your own baseline that references those scripts as well. I’ll do that once I get the basics working. The problems may be related to not using default install folders. I’m not sure yet. Shaping On 30 May 2019, at 02:07, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: Sorry, I meant progress bar, not histo…. From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, May 29, 2019 20:05 To: 'Pharo Development List' <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: RE: [Pharo-dev] Versioning with Iceberg From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Wednesday, May 29, 2019 10:58 To: Pharo Development List <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Versioning with Iceberg On Wed, 29 May 2019 at 23:08, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I’m finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Its not completely clear what you want. You can right-click a repo > Metacello > Install baseline of..... Or right-click a repo > Repository > Remotes and select one of those branches to check out. I missed the Repository item completely, all this time. I think I was blocking it out mentally because I was already in an Iceberg window that lists repos. The doubling up is confusing and unexpected. So we have Iceberg repos wrapping Git repos? I’m not sure I have the scheme right. Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks? These lock up the system for 1 or 2 minutes often. For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor). This happens when cloning a Git repo, too. The histo opens about ½ second before the about 1-m pull finishes. This happened in the 7.0.3 build. Is there a policy not to use a wait-cursor if not histo is shown? Shaping

Thanks for the explanation, Ben. This isn’t good for the future of Pharo. What a headache. Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? I don’t see how this will ever be done or finished manually, humans being what they are. The fragmented versioning-technologies will persist then indefinitely. Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Thursday, May 30, 2019 08:45 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FW: Versioning with Iceberg On Thu, 30 May 2019 at 18:56, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. Metacello operates at a higher level than Iceberg. Iceberg (like Monticello) versions individual packages. Metacello defines the version dependencies between packages, including different git repos and Monticello repos. The Metacello definition is versioned like any other code, using either Iceberg or Monticello. I'm not completely sure, but I think Metacello uses Iceberg to load from github repos, so what that last code snippet does is... Metacello loads the given baseline from github using Iceberg and parses it, then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in, then loads all the specified code versions using Iceberg or Monticello as appropriate. Also once you've loaded an Iceberg repo containing a Metacello baseline, you can invoke that baseline from within Iceberg. Essentially Iceberg replaces Monticello for git repos, but there is a wealth of historical packages in Monticello format, so its not disappearing either. HTH, cheers -ben

Could you expand your thoughts on that? I don't see why. Linux didn't fall apart with the introduction of... tar, rpm, yum, apt, dnf, etc... Just the fragmentation. Merely not falling apart is not what I would like to see happen. Broad adoption is better. There is only so much time to make the switch. Then you have to real work done again. What a headache. I don't find it so. What is the headache for you? is it confusion about the scope of each? Maybe we need to better communicate this? 3 ways to load code. Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? I believe there has been some work. If no better answers come, search http://forum.world.st/ I don’t see how this will ever be done or finished manually, humans being what they are. What you a promoting is forcing a monoculture. No, just Iceberg. Do we intend to have Iceberg replace Monticello and Metacello? Humans being what they are, don't respond well to that. Inertia, laziness, busy and tight schedules. If we don’t have good reasons and tools to help us use the best of the tools, which I thought was Iceberg, will it ever happen? I recall similar discussions about source management in Squeak during 2002-2004 time-frame. It’s an old problem. The fragmented versioning-technologies will persist then indefinitely. Iceberg/git in only been in broad use for one year since release of Pharo 7. How fast do you expect the world to change? What’s the plan to get everyone on Iceberg? Is there one? The diffusion of innovation applies... https://en.wikipedia.org/wiki/Diffusion_of_innovations Some people work in multiple Smalltalk versions that continue to use Monticello (http://www.squeaksource.com <http://www.squeaksource.com/> ) and want to maintain a cross-platform package. So even with the most perfect conversion script, Monticello will remain an option. Are we using Monticello or STON to move between Smalltalks? I thought STON was the most basic way. The alternative scenario of having only one versioning system would have been to stick with Monticello and avoid using git. I don't consider that viable. Right, that’s not good. I believe Pharo has a great future with a preferred option going forward with Git and an option to access legacy code with Monticello. Is Metacello going away? Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org> ] On Behalf Of Ben Coman Sent: Thursday, May 30, 2019 08:45 To: Pharo Development List <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] FW: Versioning with Iceberg On Thu, 30 May 2019 at 18:56, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. Metacello operates at a higher level than Iceberg. Iceberg (like Monticello) versions individual packages. Metacello defines the version dependencies between packages, including different git repos and Monticello repos. The Metacello definition is versioned like any other code, using either Iceberg or Monticello. I'm not completely sure, but I think Metacello uses Iceberg to load from github repos, so what that last code snippet does is... Metacello loads the given baseline from github using Iceberg and parses it, then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in, then loads all the specified code versions using Iceberg or Monticello as appropriate. Also once you've loaded an Iceberg repo containing a Metacello baseline, you can invoke that baseline from within Iceberg. Essentially Iceberg replaces Monticello for git repos, but there is a wealth of historical packages in Monticello format, so its not disappearing either. HTH, cheers -ben

May I suggest that you ask clear questions if you want to engage nice people to help you. That sounds reasonable. Which questions weren’t clear? Now we as a community will not use Monticello/smalltalkhub anymore Then officially Monticello is deprecated? We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future in Pharo 80. I’m looking forward to it. Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg and many other projects so it works. We will probably improve iceberg again. We will try to make sure that we can still load MC package but since MC package are merely zipped files you will be able to load them by loading the st file. Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it? Is that the slow drift? Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0. Sure, but I’m crashing the VM, not hurting any project’s code in the image. If a baseline says “load latest version” then why iceberg would load only Pharo 70 version? I don’t recall the “load latest version” qualifier. So now you can get frustrated and confused. But did you read the booklet on how to manage code in Pharo70? <http://books.pharo.org> books.pharo.org Which book are you referring to here? Did you check the wiki and the documentation? Yes, some. I’m thinking it’s Smalltalk and shouldn’t be that hard in any case. But there is a lot of Git here, and that is complicating things somewhat. Shaping

We will try to make sure that we can still load MC package but since MC package are merely zipped files you will be able to load them by loading the st file. Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it? Is that the slow drift? No. Use iceberg and tonel format. Ok. So Iceberg will not try to wrap other modes of conversion and versioning like STON and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)? Shaping

ducasse <stepharo@netcourrier.com> wrote:

Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello.

Could you explain how configurations are simpler? Stephan

Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 1 Jun 2019, at 10:41, Stephan Eggermont <stephan@stack.nl> wrote:

...

Could you explain how configurations are simpler?

Stephan

Because BaselineOfs are simpler than ConfigurationOfs.

Of course, they don't do the same thing, since tags/branches in git manage versions.

That is not what I see actually happening with baselines. They are referring to branches and versions Stephan

Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:

Configurations were managing project versionning and project dependencies while baselines are only managing the dependencies since the project versionning is done by git with it commit by project opposed to the commit by package of Monticello.

Ok, so that makes the handling of projects with lots of packages easier by eliminating the simple problem of having to write down the exact version number of these packages. That helps Stephan

On 1 Jun 2019, at 11:08, Shaping <shaping@uurda.org> wrote:

Ok.

So Iceberg will not try to wrap other modes of conversion and versioning like STON

STON is not for versioning code. But objects.

Yes, I know. I was referring to its possible use in moving Smalltalk between environs. It’s normally used for domain objects, but it could be used to serialize code itself (just another domain object), if we have no universal chunk format for Smalltalk. Seems that STON could be managed somehow from within Iceberg to move class/method definitions, but we also have the different package- and namespace- structures needing specialization for each environment. Similar comments apply to unique syntax specializations, like the period-delimited literal-array evaluables possible in Pharo, but not in VW, for example. STON under Iceberg might also let us add or strip class-name prefixes, automatically, when porting between Smalltalks with/without modules/namespaces, like VW and Pharo, for example. I’m thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ.

Tonel (and FileTree) are representations and models of code.

For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3?

Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and I’m wondering whether this is causing the crashes.

Iceberg works very well in 7.x and 8, it is the default after all. You are on Windows, other Windows users should answer.

...

and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)?

No because the distance is too large. We cannot burn our two engineers on “nice to have” when the “must have” is not yet done. Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello.

Stef

Shaping

On 1 Jun 2019, at 22:52, Shaping <shaping@uurda.org> wrote:

[...] Tonel (and FileTree) are representations and models of code.

Okay. Is one preferred?

Tonel Filetree is not nice for Windows users. And Tonel has been designed to solve all the issues of filetree

...

For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3?

Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and I’m wondering whether this is causing the crashes.

Iceberg works very well in 7.x and 8, it is the default after all.

You are on Windows, other Windows users should answer.

Yes, Windows 10 Pro and running 64-bit Pharo.

So tonel is a must for you else you will die.

Please cut your questions in different threads.

On 1 Jun 2019, at 11:08, Shaping <shaping@uurda.org> wrote:

Ok.

So Iceberg will not try to wrap other modes of conversion and versioning like STON

STON is not for versioning code. But objects.

Yes, I know. I was referring to its possible use in moving Smalltalk between environs. It’s normally used for domain objects, but it could be used to serialize code itself (just another domain object), if we have no universal chunk format for Smalltalk. Seems that STON could be managed somehow from within Iceberg to move class/method definitions, but we also have the different package- and namespace- structures needing specialization for each environment. Similar comments apply to unique syntax specializations, like the period-delimited literal-array evaluables possible in Pharo, but not in VW, for example. STON under Iceberg might also let us add or strip class-name prefixes, automatically, when porting between Smalltalks with/without modules/namespaces, like VW and Pharo, for example. I’m thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ.

For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3?

Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and I’m wondering whether this is causing the crashes.

...

and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)?

No because the distance is too large. We cannot burn our two engineers on “nice to have” when the “must have” is not yet done. Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello.

Stef

Shaping

I’m thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ. Let it makes this clear. I’m personally not interested in moving code from Pharo to VW. I gave its chance long time ago to VW and I only got bad feelings and frustration. Yes, the bad feelings mostly pass; it takes many years. But there are still those occasional, special moments of deep resentment. So do not expect me to push any action in this direction. The same applies to Squeak. If I would not have created Pharo I would work in Ruby or Python. People paid by VW should do their job not me. Or you can do it if this is in your roadmap. My goal is to have the best environment possible and I’m working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM. Now GS is not VW. :) Yes, GS is a very different system. For now, I’ll settle for getting Iceberg to work reliably in 7.0.3. Perfect. We all use it daily so let know. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Check both you may find some little differences but in general this is stable. Which Iceberg material is most up-to-date for Pharo 7.0.3? I do not know. Nothing important changes between 7.0.3 and 8. Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? I do not know. Windows is often a pain (with file name encodings and others). Indeed, Windows is a pain. If you report situations that we can reproduce and that are not super super specific we will definitively have a look. My Pharo 3.0.7 install and all repos are in non-default directories, and I’m wondering whether this is causing the crashes. I do not know what is a non-default repo. I’m referring only to a non-default directory for the repo files, which you would think would not matter, or perhaps a file-not-found exception would be raised. But I don’t see that. On Windows, the default folder is in an \images subfolder. I currently keep all my Git repos on a separate RAID drive. Now on windows the state of the libraries to run scripts is making us trouble Can you give more details on that? What are the problems? and we will have to fix it. Shaping

This is our goal as well... Dale On 6/1/19 6:37 AM, ducasse wrote:

My goal is to have the best environment possible and I’m working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM.

Haha, I agree! Dale On 6/3/19 11:06 AM, ducasse wrote:

We will make it :)

Stef

...

This is our goal as well...

Dale

On 6/1/19 6:37 AM, ducasse wrote:

...

My goal is to have the best environment possible and I’m working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM.

On 30 May 2019, at 11:55, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: 7.0.3. It loaded after a fresh clone of pharo, but with a detached head. So are you trying to actually contribute to Pharo? You don’t normally need to reload pharo (if I’ve understood what you are doing). I think ben has raised a bug for you for that. Yes, generally to start, I need to track my changes on 7.0.3, save them down to a local repo, and have a way to use that local repo (Iceberg-on-Git repo) to regenerate an image that is 7.0.3 plus my stuff or 8.0 plus my stuff when 8.0 is in better shape. This is a really important loop for anyone trying to switch environs, and it should get lots of attention and TLC from Pharo veterans wanting Smalltalkers to migrate to Pharo. If the new guy can do that loop reliably and repeatedly, the probability that he sticks around and pushes on with Pharo, instead of running back home to VW (done this a lot), increases greatly. And along the way, there should be no VM crashes. I still need to determine what caused those. However, back to your other question - I had misunderstood - actually you can load specific project (like exercism) via Iceberg (although a metacello script is often more convenient - and sometimes more precise) That bit is golden, and worries me. Can we make Iceberg do what Metacello does (the thorough dependency structure) as well as it does, and phase-out Metacello? - if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but won’t load any packages). After I do the above, Iceberg lists a repo called pharo-smalltalk. Was this intentional? <https://github.com/exercism/pharo-smalltalk> https://github.com/exercism/pharo-smalltalk Above is the Exercism GitHub page. The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging). I just cloned Exercism. I thought it would be identified somewhere besides in the Git commit comments. The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as ‘Repository of pharo-smalltalk’ with a master node, origin node and several version tags. These can’t be Pharo versions because the numbers are too small. They must be Exercism versions, but ‘exercism’ isn’t mentioned anywhere, except in some of the Git commit comments, or I missed it. So there is some immediate disorientation on that account. If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism. Should we need to dig even one step into an Iceberg repo to remind ourselves of what we have? I would think that a clear identifier for the Repo would be created immediately after the initial connection using the project name and owner data. (BTW, is there a complete list of all pharo project repos showing the correct spellings of the project and owner names? That would be a great place to start.) Is there a more ergonomic way to present an Iceberg repo? Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane? We could have bubble-help on the listed repos and details in the right pane on repo selection. Checking out the latest tag didn’t seem to do anything. The Iceberg repo show Detached HEAD? Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. ‘dev’ for exercism). I loaded the default baseline and see 4 packages up to date and the rest unloaded. When I tried ‘dev’ I got an assertion failure on the SSH creds. Did I miss a step concerning SSH creds on install? But the loading seemed to continue. I also got the error: LGit_GIT_EEXISTS: Failed to stat file 'F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo...derReturnedAnotherObjectAndNobodyReturnedGivenObject.st': The filename or extension is too long. Here’s the file name that was too long: F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st' There seems to be a general problem with the context of a walkback when something goes wrong. In some, not all cases, I don’t see the error window until long after the error has occurred. It does not pop up in view when the error happens. I find it later while poking around. It’s probably in the tab list at the bottom, but I don’t see it until the original context of the error is gone. This one probably happened when I tried to load the Exercism base line using ‘dev’. If you want a different version than master, then have to open the repository view (cmd-r), there you can select a tag to load, and then you can use the metecallo menu. Yeah, doesn’t work. Probably related to the detached HEAD. How can I fix this from inside Iceberg? You can also (although somewhat painfully), right click on all the packages in a repository and select “load” to do them one by one. Right. Hope this helps. It does. But this tool is painful to use, and my install or usage pattern is still broken. Not sure which yet. Shaping

Is your application making a lot of changes to existing Pharo code? Not yet, I just want to explore for a bit, and see what Pharo has to offer. But yes, there will be extensive changes to Pharo, eventually, after I get most of my stuff ported. I need to do some speed tests. Speed is one big issue. Others are: which way do I port code in the short-term and long-term, and can I move all to Pharo and stay there? More immediately, in preparation, I'm trying to get all the creature comforts working the way they do in VW. I prefer the more detailed syntax highlighting in VW. I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VW’s. I need to do the same for formatting, which I've not checked out very thoroughly yet. The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paro—and I didn’t know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem. Are you aware of "extension methods" ? Where a method you add to a built-in Pharo class (Collection for example) is saved/loaded with your package. Then you only need to manage your package not Pharo built-in packages as well. Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own packages for extensions/overrides. That’s currently where I’m stuck, and I need to do some VW work this weekend, but I try to work with Pharo as often as I can.

...

- if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but won’t load any packages).

After I do the above, Iceberg lists a repo called pharo-smalltalk. Was this intentional?

Yes, this the the repo name assigned by the Exercism administrators. The Exercism project has 50 language tracks each with their own repo... <https://github.com/exercism> https://github.com/exercism The Pharo Track repo is <https://github.com/exercism/pharo-smalltalk> https://github.com/exercism/pharo-smalltalk

Above is the Exercism GitHub page. The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging).

I just cloned Exercism. I thought it would be identified somewhere besides in the Git commit comments. The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as ‘Repository of pharo-smalltalk’ with a master node, origin node and several version tags.

Cloning the Pharo Track repo from the command line is done like this... $ git clone <mailto:git@github.com:exercism/pharo-smalltalk.git> git@github.com:exercism/pharo-smalltalk.git Sure, but we can do this in Iceberg—and it works. So why use the command line? which creates a folder with the same name as the repo (i.e. "pharo-smalltalk") As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this, so the behaviour is standard git. I was commenting on the ergonomics, and yes this is very much a Git thing.

These can’t be Pharo versions because the numbers are too small. They must be Exercism versions,

yes.

but ‘exercism’ isn’t mentioned anywhere, except in some of the Git commit comments, or I missed it. So there is some immediate disorientation on that account. If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism.

Would a hover tool tip showing "owner/repo" clear this up for you? You see the train of thought, broken down that way in steps to show the clumsiness. Hover help seems like an afterthought, but a good one—much better than nothing. Presenting a Smalltalk project in Iceberg without a name when the name (and owner) is known is not “least astonishing”. I’m wondering why someone thought this was okay. I guess we are just mirroring Git as a default. I’m wondering why the name just isn’t more prominent in the Git scheme of things and if this is @Tim, another way to mitigate such user confusion would be to separate the tools out from <https://github.com/exercism/pharo-smalltalk> https://github.com/exercism/pharo-smalltalk into <https://github.com/pharo-exercism/exercism-tools> https://github.com/pharo-exercism/exercism-tools.

Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane? We could have bubble-help on the listed repos and details in the right pane on repo selection.

I can't parse that description. A graphical mockup would be more useful to discuss. Take the GUI you have already in the Repository window (now opened from the Repository context menu item), and instead make that GUI the right pane in a new GUI, with the current Iceberg repo list becoming the left pane of that new GUI. When using the new GUI, select a repo name in the left pane to see its details populate the right pane. Then go into the right pane, and select a version tag, for example, and do other things with the repo.

...

Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. ‘dev’ for exercism).

I loaded the default baseline and see 4 packages up to date and the rest unloaded.

Thats right, the default-baseline is for students. The other packages are only required by mentors & maintainers.

When I tried ‘dev’ I got an assertion failure on the SSH creds. Did I miss a step concerning SSH creds on install? But the loading seemed to continue.

Given that it already loaded the 4 packages, your SSH creds have already been proven working. Before considering this further, just need to ask how reliable your internet connection is? Very good: 60 Mbps at the low end. A poor connection might also explain some of your PharoLauncher "identifying VM version" issues.

I also got the error:

LGit_GIT_EEXISTS: Failed to stat file '

F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st'

Those very long path names come from a repo in FileTree format. FileTree format was used by some people to fileout code to work with git from the command outside of Pharo. Okay. These long path names are fine on Linux, but on Windows libgit2 is constrained by 260 character paths. Okay. FileTree also had a file per method creating a massive number of small files, which was fine on Linux but a big performance problem on Windows. To address these issues Tonel format was created with a class per file. Okay. So this is an old repo that has not been updated to use Tonel, and all Windows machines will have the name-length limit. I suppose the problem is rare because everyone is converting to Tonel. I experienced the same error and fixed it by converting Mocketry to Tonel format here... github://pharo-exercism/Mocketry and updated the baseline here... <https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfEx...> https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfEx... Try pulling the `pharo-smalltalk` repo to update it and check it has that line updated. Will do. Thanks. Shaping

On 2 Jun 2019, at 00:19, Shaping <shaping@uurda.org> wrote:

Is your application making a lot of changes to existing Pharo code?

Not yet, I just want to explore for a bit, and see what Pharo has to offer. But yes, there will be extensive changes to Pharo, eventually, after I get most of my stuff ported. I need to do some speed tests. Speed is one big issue. Others are: which way do I port code in the short-term and long-term, and can I move all to Pharo and stay there? More immediately, in preparation, I'm trying to get all the creature comforts working the way they do in VW. I prefer the more detailed syntax highlighting in VW.

Check the styler look for <style> in Pharo because you can create your own. We need to do one for the dark theme. There are a lot of variations.

I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VW’s. I need to do the same for formatting, which I've not checked out very thoroughly yet.

For formatting check the BIformatter. We are working on - adding tests (we have about 150 tests ready to get integrated - working on a new tool to see and understand the settings - we want to make sure that we can pretty print the complete system so we will come probably with an extended pretty printer.

The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paro—and I didn’t know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem.

Yes this is super annoying. Can you check with Spec 20 and this should be fixed. Now the font logic is one of the few parts that we did not revisit yet but it is not way it should. Also may users hardcode standardFonts….( the ugly singleton strike back).

Are you aware of "extension methods" ? Where a method you add to a built-in Pharo class (Collection for example) is saved/loaded with your package. Then you only need to manage your package not Pharo built-in packages as well.

Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own packages for extensions/overrides.

yes us know we can also do some screen sharing with you to get you up to speed.

That’s currently where I’m stuck, and I need to do some VW work this weekend, but I try to work with Pharo as often as I can.

...

...

- if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but won’t load any packages).

After I do the above, Iceberg lists a repo called pharo-smalltalk. Was this intentional?

Yes, this the the repo name assigned by the Exercism administrators. The Exercism project has 50 language tracks each with their own repo... https://github.com/exercism <https://github.com/exercism> The Pharo Track repo is https://github.com/exercism/pharo-smalltalk <https://github.com/exercism/pharo-smalltalk>

...

Above is the Exercism GitHub page. The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging). I just cloned Exercism. I thought it would be identified somewhere besides in the Git commit comments. The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as ‘Repository of pharo-smalltalk’ with a master node, origin node and several version tags.

Cloning the Pharo Track repo from the command line is done like this... $ git clone git@github.com:exercism/pharo-smalltalk.git <mailto:git@github.com:exercism/pharo-smalltalk.git>

Sure, but we can do this in Iceberg—and it works. So why use the command line?

which creates a folder with the same name as the repo (i.e. "pharo-smalltalk") As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this, so the behaviour is standard git.

I was commenting on the ergonomics, and yes this is very much a Git thing.

Git is bad :) but this is the way to go. The API sucks.

...

These can’t be Pharo versions because the numbers are too small. They must be Exercism versions,

yes.

...

but ‘exercism’ isn’t mentioned anywhere, except in some of the Git commit comments, or I missed it. So there is some immediate disorientation on that account. If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism.

Would a hover tool tip showing "owner/repo" clear this up for you?

You see the train of thought, broken down that way in steps to show the clumsiness. Hover help seems like an afterthought, but a good one—much better than nothing. Presenting a Smalltalk project in Iceberg without a name when the name (and owner) is known is not “least astonishing”. I’m wondering why someone thought this was okay. I guess we are just mirroring Git as a default.

I’m wondering why the name just isn’t more prominent in the Git scheme of things and if this is

@Tim, another way to mitigate such user confusion would be to separate the tools out from https://github.com/exercism/pharo-smalltalk <https://github.com/exercism/pharo-smalltalk> into https://github.com/pharo-exercism/exercism-tools <https://github.com/pharo-exercism/exercism-tools>.

...

Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane? We could have bubble-help on the listed repos and details in the right pane on repo selection.

I can't parse that description. A graphical mockup would be more useful to discuss.

Take the GUI you have already in the Repository window (now opened from the Repository context menu item), and instead make that GUI the right pane in a new GUI, with the current Iceberg repo list becoming the left pane of that new GUI. When using the new GUI, select a repo name in the left pane to see its details populate the right pane. Then go into the right pane, and select a version tag, for example, and do other things with the repo.

...

...

Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. ‘dev’ for exercism).

I loaded the default baseline and see 4 packages up to date and the rest unloaded.

Thats right, the default-baseline is for students. The other packages are only required by mentors & maintainers.

...

When I tried ‘dev’ I got an assertion failure on the SSH creds. Did I miss a step concerning SSH creds on install? But the loading seemed to continue.

Given that it already loaded the 4 packages, your SSH creds have already been proven working. Before considering this further, just need to ask how reliable your internet connection is?

Very good: 60 Mbps at the low end.

A poor connection might also explain some of your PharoLauncher "identifying VM version" issues.

...

I also got the error:

LGit_GIT_EEXISTS: Failed to stat file ' F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st <http://testfailedvalidationwhenrequiredsenderreturnedanotherobjectandnobodyr...>'

Those very long path names come from a repo in FileTree format. FileTree format was used by some people to fileout code to work with git from the command outside of Pharo.

Okay.

These long path names are fine on Linux, but on Windows libgit2 is constrained by 260 character paths.

Okay.

FileTree also had a file per method creating a massive number of small files, which was fine on Linux but a big performance problem on Windows. To address these issues Tonel format was created with a class per file.

Okay. So this is an old repo that has not been updated to use Tonel, and all Windows machines will have the name-length limit. I suppose the problem is rare because everyone is converting to Tonel.

I experienced the same error and fixed it by converting Mocketry to Tonel format here... github://pharo-exercism/Mocketry <github://pharo-exercism/Mocketry> and updated the baseline here... https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfEx... <https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfEx...>

Try pulling the `pharo-smalltalk` repo to update it and check it has that line updated.

Will do. Thanks.

Shaping

On 2 Jun 2019, at 20:19, Shaping <shaping@uurda.org> wrote:

[…] I prefer the more detailed syntax highlighting in VW.

Check the styler look for <style> in Pharo because you can create your own.

I don’t see this in Settings. I see “Syntax Highlighting…”

It is not exposed in the settings. Probably because it had its own preferences and we should migrate it. I created the issue: https://github.com/pharo-project/pharo/issues/3449 Now we will see if we succeed to find the time to work on it. Check SHRBTextStyler <styleTable: …> here is the default style blueStyleTable "color can be a valid argument to Color class>>colorFrom: , or nil to use the editor text color. Multiple emphases can be specified using an array e.g. #(bold italic). If emphasis is not specified, #normal will be used. if pixel height is not specified , then the editor font size will be used. " <styleTable: 'Blue'> ^ #( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default black) (invalid red) (excessCode red) (comment (gray darker)) (unfinishedComment (red muchDarker)) (#'$' (red muchDarker)) (character (red muchDarker)) (integer (red muchDarker)) (number (red muchDarker)) (#- (red muchDarker)) (symbol (magenta muchDarker)) (stringSymbol (magenta muchDarker)) (literalArray (magenta muchDarker)) (string (magenta muchDarker) normal) (unfinishedString red normal) (assignment nil) (ansiAssignment nil) (literal nil italic) (keyword (black)) (binary (black)) (unary (black)) (#self (cyan muchDarker )) (#super (cyan muchDarker )) (#true (red muchDarker)) (#false (red muchDarker)) (#nil (red muchDarker)) (#thisContext (cyan muchDarker )) (#return (cyan muchDarker ) bold) (patternArg (blue muchDarker)) (methodArg (blue muchDarker)) (blockPatternArg (blue muchDarker)) (blockArg (blue muchDarker)) (argument (blue muchDarker)) (blockTempVar (blue muchDarker)) (blockPatternTempVar (blue muchDarker)) (instVar (blue muchDarker)) (workspaceVar (blue muchDarker)) (tempVar (blue muchDarker)) (patternTempVar (blue muchDarker)) (poolConstant (blue muchDarker)) (classVar (blue muchDarker)) (globalVar (blue muchDarker)) (incompleteIdentifier blue italic) (incompleteKeyword nil italic) (incompleteBinary nil italic) (incompleteUnary nil italic) (undefinedIdentifier red) (undefinedKeyword red) (undefinedBinary red) (undefinedUnary red) (patternKeyword nil bold) (patternBinary nil bold) (patternUnary nil bold) (blockArgColon black) (leftParenthesis black) (rightParenthesis black) (leftParenthesis1 (green muchDarker)) (rightParenthesis1 (green muchDarker)) (leftParenthesis2 (magenta muchDarker)) (rightParenthesis2 (magenta muchDarker)) (leftParenthesis3 (red muchDarker)) (rightParenthesis3 (red muchDarker)) (leftParenthesis4 (green darker)) (rightParenthesis4 (green darker)) (leftParenthesis5 (orange darker)) (rightParenthesis5 (orange darker)) (leftParenthesis6 (magenta darker)) (rightParenthesis6 (magenta darker)) (leftParenthesis7 blue) (rightParenthesis7 blue) (blockStart black) (blockEnd black) (blockStart1 (green muchDarker)) (blockEnd1 (green muchDarker)) (blockStart2 (magenta muchDarker)) (blockEnd2 (magenta muchDarker)) (blockStart3 (red muchDarker)) (blockEnd3 (red muchDarker)) (blockStart4 (green darker)) (blockEnd4 (green darker)) (blockStart5 (orange darker)) (blockEnd5 (orange darker)) (blockStart6 (magenta darker)) (blockEnd6 (magenta darker)) (blockStart7 blue) (blockEnd7 blue) (arrayStart black) (arrayEnd black) (arrayStart1 black) (arrayEnd1 black) (leftBrace black) (rightBrace black) (cascadeSeparator black) (statementSeparator black) (methodTempBar (black)) (blockTempBar (black)) (blockArgsBar (black)) (externalCallType black) (externalCallTypePointerIndicator black) (primitiveOrExternalCallStart black bold) (primitiveOrExternalCallEnd black bold) (primitive (green muchDarker)) (pragmaKeyword (green muchDarker)) (pragmaUnary (green muchDarker)) (pragmaBinary (green muchDarker)) (externalFunctionCallingConvention (green muchDarker) bold) (module (green muchDarker) bold))

We need to do one for the dark theme. There are a lot of variations.

...

I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VW’s. I need to do the same for formatting, which I've not checked out very thoroughly yet.

For formatting check the BIformatter.

I cannot find class BIFormatter in the 7.0.3 image. What must I load?

BIConfigurableFormatter is in the image. You have it in the settings.

We are working on - adding tests (we have about 150 tests ready to get integrated - working on a new tool to see and understand the settings - we want to make sure that we can pretty print the complete system so we will come probably with an extended pretty printer.

Sounds good.

...

The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paro—and I didn’t know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem.

Yes this is super annoying. Can you check with Spec 20 and this should be fixed.

I’m not sure what Spec 20 is. Are you referring to this document in progress:

This document is just the description of the integration of Commander2 with Spec20. Spec20 has examples. Check SpecDemo Check the examples in Spec-Examples. but I just see that latest version is frrezing the image :(

https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2 <https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2>

?

On Wed, 29 May 2019 at 23:08, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I’m finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Is this what you need... ? https://github.com/pharo-vcs/iceberg/issues/1246 Yes, this seems to describe my confusing scenario exactly. Thanks. The thought is: Pharo 3.0.7 knows that it is version 3.0.7. Why then is Iceberg fetching by default version 8.0 from the Git repo? This destroys your confidence in the versioning system or, in my case, in the Pharo install itself, because I chose non-default folders, and am still wondering whether this is an issue. Can the handler of the installer of Pharo Launcher perhaps do an install to non-default folders, and test this idea. Can we tweak the installer of Pharo Launcher so that it will allow installation outside the user-account folder, without having first to create a folder under Program Files (x86) and add permissions? I’ve managed to crash the VM twice, with both Pharo 8 and Pharo 3.0.7, just by cloning a Git repo via Iceberg, and then by using Iceberg to fetch a version. Sometime during those calculations/comparisons, the VM crashed. I also used Iceberg to delete the pharo repo at several points, in order to start the exercise over. It worked, but Pharo was un-responsive in a tight synchronous thread during this operation, and there was no indication that anything sane was happening, not even a wait cursor. I’m wondering why we choose to leave the user wondering for long stretches (many minutes during the Iceberg/Git repo delete and 1 to 2 minutes during the earlier 20-odd-package delete) what is happening inside his Smalltalk image. Can someone explain the no-wait-cursor default in Pharo GUIs? Can someone look at the .dmp file I attached to the e-mail describing the first VM crash, and tell me what he thinks happened? I saw mentions of a stack overflow. I still have the .dmp file from the second VM crash with Pharo 3.0.7, if anyone wants to see it. Shaping