Re: Versioning with Iceberg

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

On 1 Jun 2019, at 11:08, Shaping <[hidden email]> 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

On 1 Jun 2019, at 22:52, Shaping <[hidden email]> wrote:

[...]

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

 

Okay.  Is one preferred?

 

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

 

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

On 2 Jun 2019, at 00:19, Shaping <[hidden email]> 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. 

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 The Pharo Track repo is 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 [hidden email]

 

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

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

    <a href="github://pharo-exercism/Mocketry" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">github://pharo-exercism/Mocketry

and updated the baseline here...

    https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfExercism/BaselineOfExercism.class.st#L81

 

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

 

Will do.   Thanks.

 

 

Shaping