On 30 May 2019, at 11:55, Shaping <[email protected] <mailto:[email protected]> > 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
