In Pharo 4.0 after loading the latest Metacello once you open a repo from the MC browser it never stops downloading package names from all the other repos

[pdebruic]

On a mac.

To recreate

get pharo 4:

curl get.pharo.org | bash

install Metacello scripting API:

Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; get.

Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; onConflict: [:ex | ex allow]; load

Then open the package-cache for the image.

[dalehenrich]

Is there a reason why you think this is a Metacello bug? The package-cache browser is not owned by Metacello ...

[pdebruic]

For some reason, in an unadulterated Pharo 4 image, the Metacello scripting API load dirties 5 packages:

I assumed that meant that it was Metacello's load that created the bug. Is there another forum you think this would be better addressed?

[dalehenrich]

Yeah, I think this should be reported against Pharo4.0 ... when I run the Metacello unit tests against Pharo4.0 they pass so until I hear otherwise I can't imagine how this is a Metacello bug.

If there is a known issue that the Pharo folks have fixed, then I would like them to submit their patch to Metacello and I will integrate it immediately.

[pdebruic]

It looks like the baseilne in this repo loads an outdated version of MCFileRepositoryInspector>>#refresh which causes the problems. The BaselineOfMetacello loads a version of FileTree for Pharo 3. It overrides the one provided by Pharo 4 and refers to an inst var thats no longer there.

Since FileTree is already included in Pharo4 should the BaselineOfMetacello be edited to remove the part where it loads filetree from your github filetree repo for Pharo 4?

[dalehenrich]

Excellent work! This is good to know ... It does look like pharo4.0 and pharo5.0 branches have been created so rather than remove the FileTree dependency, I need to create separate pharo4.0 sections ... pharo5.0 work is in progress...

I'll do that right now.

[dalehenrich]

Looks like the pharo4.0 tests for metacello pass and the pharo4.0 branch of FileTree is now being loaded.

@pdebruic an you take the issue_354 branch for a spin and verify that this addresses the issue? If not we'll have to open bug in the FileTree project and get @ThierryGoubier involved...

[ThierryGoubier]

Hi @dalehenrich , @pdebruic , this issue is an effect of the introduction of MCLazyVersionInfo in Pharo4 (http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-February/106353.html).

The old #refresh force a complete reload of the version history of all packages in the image to mark package versions as new or old :( I don't think the FileTree tests cover those GUI-related methods.

[dalehenrich]

Thanks @ThierryGoubier. Is it fixed in FileTree on the pharo4.0 branch or is this just an open issue for Pharo4.0 to fix? From the mail, it looks like it has been left as open issue for Pharo to fix? Or is there a possible FileTree patch ... I have yet to look at code, because well I don't have a Paro4.0 dev setup

[pdebruic]

The code in the Pharo4 image is the same as the github repo. But they're just classified in different method categories.

the one in the image is in 'private' and the one in the github package is in *monticellofiletree-core

Is there are reason to install Filetree from github into Pharo 4 at all at this point?

On Jul 8, 2015, at 2:34 PM, Dale Henrichs notifications@github.com wrote:

Thanks @ThierryGoubier. Is it fixed in FileTree on the pharo4.0 branch or is this just an open issue for Pharo4.0 to fix? From the mail, it looks like it has been left as open issue for Pharo to fix? Or is there a possible FileTree patch ... I have yet to look at code, because well I don't have a Paro4.0 dev setup

— Reply to this email directly or view it on GitHub.

[dalehenrich]

@pdebruic, yes... I prefer to ask "why is the version of FileTree using in Pharo 4.0 different then the version that is in the official repository for FileTree?" When I do fix bugs in FileTree that are needed by Metacello, I expect that the bugfixes get loaded along with Metacello ... You do realize that Metacello is also installed in Pharo4.0, but it is nowhere the near to the latest version ...

If the "methods are the same" then why does it fail fail after the the new version of FileTree is installed? There must be something else that has been changed ... and not shared with the maintainers of the project ....

[dalehenrich]

From the description of the bug, I assume that the problem does not lie with filetree, but is directly a result of the MCLazyVersionInfo which is causing "all packages to be reloaded" so at the end of the day the fix will be to not install the new version of Metacello to avoid a bug introduced by a hack... So Filetree is probably not a participant in this problem at the end of the day ....

[ThierryGoubier]

@dalehenrich , @debruic, I'm looking but it seems I did properly propagate the changes in 56b77a98a4c377623a17d767274e7588f56045be (in FileTree) . I'll have a deeper look tomorrow evening

[dalehenrich]

@ThierryGoubier, the one bug that did exist is that Metacello was loading the Pharo3.0 branch of FileTree into Pharo 4.0 and that could create problems ... I changed the baseline of Metacello to load the pharo4.0 branch of Filetree and asked @pdebruic to try out the issue_354 branch of Metacello, to see if that fixed the problem...I don't think he answered that question directly ... if there is a Pharo4.0 fix for FileTree, then it should be picked up now ... I guess I'll have to set up a Pharo4.0 dev env, reproduce the bug and then see if using the pharo4.0 branch for FileTree patches the problem ... of course if you know that you've fixed the bug in FileTree then I can assume that it'll work for Metacello, so the same code is loaded ....

[dalehenrich]

@ThierryGoubier ... I've got a dentist appointment this in 20 minutes, so I won't get back to this until tomorrow morning ... so you might as well hold off until we find out whther or not the pharo4.0 branch of FileTree resolves the problem or not ...

[pdebruic]

Oh sorry - Yes - the issue_354 branch fixes issue #354 for the Metacello project in this repository.

It leaves some packages dirty, but is that important?

On Jul 8, 2015, at 3:10 PM, Dale Henrichs notifications@github.com wrote:

@ThierryGoubier, the one bug that did exist is that Metacello was loading the Pharo3.0 branch of FileTree into Pharo 4.0 and that could create problems ... I changed the baseline of Metacello to load the pharo4.0 branch of Filetree and asked @pdebruic to try out the issue_354 branch of Metacello, to see if that fixed the problem...I don't think he answered that question directly ... if there is a Pharo4.0 fix for FileTree, then it should be picked up now ... I guess I'll have to set up a Pharo4.0 dev env, reproduce the bug and then see if using the pharo4.0 branch for FileTree patches the problem ... of course if you know that you've fixed the bug in FileTree then I can assume that it'll work for Metacello, so the same code is loaded ....

— Reply to this email directly or view it on GitHub.

[dalehenrich]

That's good to know ... it's too late for me to push the change tonight (got to hustle to the dentist) ... but I do care bout dirty packages, but I assume that the dirtiness is from changes that were made by incorporating code from the filetree/metacello base without submitting a PR to either Filetree or Metacello, there's not much to be done ... FWIW the pharo folks are supposed to start pulling things directly from the Metacell repo for Pharo5.0 which should avoid things like this in the future...

Thanks for you patience @pdebruic and @ThierryGoubier

[dalehenrich]

greem means go ...

[dalehenrich]

merged: https://github.com/dalehenrich/metacello-work/commit/23f9d8fc6e4e28e28de01335f672d98bb57e24d8