Random access to meta repos?
Hi, Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine? Uko
Hi Uko, I've noticed as well. I believe it is lazy-loading some version history data, and I've never explored further. I suspect some side-effect of Monticello tendency to ask everything to everybody (that is all repositories in the image). Would need to fire Jejak and trace calls inside Monticello to know what is being loaded and why. Thierry Le 22/08/2015 21:29, Yuriy Tymchuk a écrit :
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again nicolas On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
I think that it is trying to get every information. And yes we would gain all if we can understand this issue. Le 23/8/15 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Le 23/08/2015 12:14, stepharo a écrit :
I think that it is trying to get every information. And yes we would gain all if we can understand this issue.
Found it; it's lazy loading the version info of a package. Thierry
Le 23/8/15 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Hi Nicolas, Uko, I added an optimisation to gitfiletree which avoids the unnecessary loading all file names. Available on Pharo4 and Pharo5 (development and stable). Thierry Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Thanks Thierry! Iâm not completely aware about the issue details, but maybe it makes sense to change something in metacello itself? Uko
On 23 Aug 2015, at 20:26, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Nicolas, Uko,
I added an optimisation to gitfiletree which avoids the unnecessary loading all file names. Available on Pharo4 and Pharo5 (development and stable).
Thierry
Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Le 23/08/2015 22:00, Yuriy Tymchuk a écrit :
Thanks Thierry!
Iâm not completely aware about the issue details, but maybe it makes sense to change something in metacello itself?
No, not really, or maybe in a very complex way... The issue is inside Monticello, in the way the Monticello GUI interacts with each package version history, and how that interacts with the lazy version info I added late in the Pharo 4 development cycle. The Monticello GUI is designed to be able to display the newer/not newer version feedback (you know, the underlined, bold, non bold package version status you see in a repository) out of two things: first the complete knowledge of the complete version history of all the packages loaded in the image. And second, the names of the mcz files in the repository. Why the names? To avoid downloading all the mcz in the repository to get their version history... Monticello just pray and hopes the names are right... Oh, by the way, Gofer also prays and hopes that the names are right when you are loading something via a configuration and a script[*]. When I added[**] lazyness to the version history in the image, I removed that complete history Monticello relies on (and a bit of memory out of the image). And, as a result, this has immediately created issues in the GUI that are taken care of as they come. Some are simple, like the gitfiletree ones, because you get all the proper version history with a few git commands in the repository. But you can't do that with a http repository (smalltalkhub, squeaksource) since you can't get the remote repository version history. Thierry [*] Which is very fun because, at times, the names aren't right... and the wrong package get loaded. Incomprehensible pain and confusion ensue:( [**] I'm the second guy doing this lazy thing with Monticello. Smalltalk/X seems to had (have?) the same thing before. Would like to share the experience one day;)
Uko
On 23 Aug 2015, at 20:26, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Nicolas, Uko,
I added an optimisation to gitfiletree which avoids the unnecessary loading all file names. Available on Pharo4 and Pharo5 (development and stable).
Thierry
Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
I wanted to harvest the changes in squeak to have MCName but I failed a couple of years ago. Now relying on name is a bad idea (we got sometimes burnt by that). Stef Le 24/8/15 00:00, Thierry Goubier a écrit :
Le 23/08/2015 22:00, Yuriy Tymchuk a écrit :
Thanks Thierry!
Iâm not completely aware about the issue details, but maybe it makes sense to change something in metacello itself?
No, not really, or maybe in a very complex way...
The issue is inside Monticello, in the way the Monticello GUI interacts with each package version history, and how that interacts with the lazy version info I added late in the Pharo 4 development cycle.
The Monticello GUI is designed to be able to display the newer/not newer version feedback (you know, the underlined, bold, non bold package version status you see in a repository) out of two things: first the complete knowledge of the complete version history of all the packages loaded in the image. And second, the names of the mcz files in the repository. Why the names? To avoid downloading all the mcz in the repository to get their version history... Monticello just pray and hopes the names are right... Oh, by the way, Gofer also prays and hopes that the names are right when you are loading something via a configuration and a script[*].
When I added[**] lazyness to the version history in the image, I removed that complete history Monticello relies on (and a bit of memory out of the image). And, as a result, this has immediately created issues in the GUI that are taken care of as they come. Some are simple, like the gitfiletree ones, because you get all the proper version history with a few git commands in the repository. But you can't do that with a http repository (smalltalkhub, squeaksource) since you can't get the remote repository version history.
Thierry
[*] Which is very fun because, at times, the names aren't right... and the wrong package get loaded. Incomprehensible pain and confusion ensue:(
[**] I'm the second guy doing this lazy thing with Monticello. Smalltalk/X seems to had (have?) the same thing before. Would like to share the experience one day;)
Uko
On 23 Aug 2015, at 20:26, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Nicolas, Uko,
I added an optimisation to gitfiletree which avoids the unnecessary loading all file names. Available on Pharo4 and Pharo5 (development and stable).
Thierry
Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Le 24/08/2015 18:11, stepharo a écrit :
I wanted to harvest the changes in squeak to have MCName but I failed a couple of years ago.
Do you know what those changes are? Many of the things I thought were wrong with MC naming a while ago do not matter anymore once moved to git. Now MC naming quirks are just annoying :(
Now relying on name is a bad idea (we got sometimes burnt by that).
The numbering is user-friendly, but unreliable... A safe numbering would be less user-friendly, IMO. Thierry
Stef
Le 24/8/15 00:00, Thierry Goubier a écrit :
Le 23/08/2015 22:00, Yuriy Tymchuk a écrit :
Thanks Thierry!
Iâm not completely aware about the issue details, but maybe it makes sense to change something in metacello itself?
No, not really, or maybe in a very complex way...
The issue is inside Monticello, in the way the Monticello GUI interacts with each package version history, and how that interacts with the lazy version info I added late in the Pharo 4 development cycle.
The Monticello GUI is designed to be able to display the newer/not newer version feedback (you know, the underlined, bold, non bold package version status you see in a repository) out of two things: first the complete knowledge of the complete version history of all the packages loaded in the image. And second, the names of the mcz files in the repository. Why the names? To avoid downloading all the mcz in the repository to get their version history... Monticello just pray and hopes the names are right... Oh, by the way, Gofer also prays and hopes that the names are right when you are loading something via a configuration and a script[*].
When I added[**] lazyness to the version history in the image, I removed that complete history Monticello relies on (and a bit of memory out of the image). And, as a result, this has immediately created issues in the GUI that are taken care of as they come. Some are simple, like the gitfiletree ones, because you get all the proper version history with a few git commands in the repository. But you can't do that with a http repository (smalltalkhub, squeaksource) since you can't get the remote repository version history.
Thierry
[*] Which is very fun because, at times, the names aren't right... and the wrong package get loaded. Incomprehensible pain and confusion ensue:(
[**] I'm the second guy doing this lazy thing with Monticello. Smalltalk/X seems to had (have?) the same thing before. Would like to share the experience one day;)
Uko
On 23 Aug 2015, at 20:26, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Nicolas, Uko,
I added an optimisation to gitfiletree which avoids the unnecessary loading all file names. Available on Pharo4 and Pharo5 (development and stable).
Thierry
Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that last week over a slow connection, I noticed that it "loaded all file names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
per this discussion: https://github.com/dalehenrich/metacello-work/issues/354 You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar Uko2 wrote
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Screen Shot 2015-08-21 at 19.06.39.png (587K) <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2...;
-- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Paul, do you still see some of this in one of the filetree branches when doing metacello integration testing? Thierry Le 24/08/2015 19:41, Paul DeBruicker a écrit :
per this discussion: https://github.com/dalehenrich/metacello-work/issues/354
You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar
Uko2 wrote
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Screen Shot 2015-08-21 at 19.06.39.png (587K) <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2...;
-- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
So was this fixed or not? Because if Iâm opening a git repo â it checks the meta, Iâm saving to git repo â it checks the meta⦠Uko
On 24 Aug 2015, at 22:05, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Paul,
do you still see some of this in one of the filetree branches when doing metacello integration testing?
Thierry
Le 24/08/2015 19:41, Paul DeBruicker a écrit :
per this discussion: https://github.com/dalehenrich/metacello-work/issues/354
You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar
Uko2 wrote
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Screen Shot 2015-08-21 at 19.06.39.png (587K) <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2...;
-- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 27/10/2015 02:22, Yuriy Tymchuk a écrit :
So was this fixed or not? Because if Iâm opening a git repo â it checks the meta, Iâm saving to git repo â it checks the metaâ¦
Hi Uko, I thought I fixed it; but yes it is checking the meta too much. I'll have a look. Thierry
Uko
On 24 Aug 2015, at 22:05, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Paul,
do you still see some of this in one of the filetree branches when doing metacello integration testing?
Thierry
Le 24/08/2015 19:41, Paul DeBruicker a écrit :
per this discussion: https://github.com/dalehenrich/metacello-work/issues/354
You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar
Uko2 wrote
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Screen Shot 2015-08-21 at 19.06.39.png (587K) <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2...;
-- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 27/10/2015 02:22, Yuriy Tymchuk a écrit :
So was this fixed or not? Because if Iâm opening a git repo â it checks the meta, Iâm saving to git repo â it checks the metaâ¦
Ok, I added a LRUCache of version info for handling that. Should / does certainly accelerate things (GitFileTree on Pharo3 is a lot faster than on Pharo4/5...). https://pharo.fogbugz.com/f/cases/16881/MCLazyVersion-avoid-aggressive-fetch... Slice in inbox. There is an additional optimisation that can be added to GitFileTree, but it has to wait integration first. Thierry
Uko
On 24 Aug 2015, at 22:05, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Paul,
do you still see some of this in one of the filetree branches when doing metacello integration testing?
Thierry
Le 24/08/2015 19:41, Paul DeBruicker a écrit :
per this discussion: https://github.com/dalehenrich/metacello-work/issues/354
You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar
Uko2 wrote
Hi,
Iâve noticed that when I try to open a gitfiletree repo, before displaying its contents something from meta repos is loaded (seen on screenshot). Why does it need file names from meta repos to display contents of the repo which is present on my machine?
Uko
Screen Shot 2015-08-21 at 19.06.39.png (587K) <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2...;
-- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (5)
-
Nicolas Anquetil -
Paul DeBruicker -
stepharo -
Thierry Goubier -
Yuriy Tymchuk