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:[email protected]:exercism/pharo-smalltalk.git> [email protected]: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/BaselineOfExercism/BaselineOfExercism.class.st#L81> 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
