Re: Versioning with Iceberg

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

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.

Sorry, I meant progress bar, not histo….

 

From: Shaping [[hidden email]]
Sent: Wednesday, May 29, 2019 20:05
To: 'Pharo Development List' <[hidden email]>
Subject: RE: [Pharo-dev] Versioning with Iceberg

 

 

 

From: Pharo-dev [[hidden email]] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

 

 

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> 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

 

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

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

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