Circular Dependency

11 views
Skip to first unread message

Sean DeNigris

unread,
Sep 30, 2020, 12:15:49 PM9/30/20
to Metacello
In the two baselines below, I assumed that since one used "requires" and the other "includes", there would be no circular dependency. Unfortunately, when I try to load or record, MetaC churns endlessly between the two.

Here's one:

baseline: spec
<baseline>

spec for: #'common' do: [
spec
baseline: 'PharoEnhancements' with: [
spec repository: 'github://seandenigris/Pharo-Enhancements' ];
baseline: 'SimplePersistence' with: [
spec repository: 'github://seandenigris/Simple-Persistence' ];
baseline: 'Superuser' with: [
spec repository: 'github://seandenigris/Superuser' ];
baseline: 'Tesseract' with: [
spec
repository: 'github://seandenigris/Tesseract-St' ].
spec package: #ResourcesLive with: [
spec requires: #('PharoEnhancements' 'SimplePersistence' 'Superuser' 'Tesseract'). ]. ].

And here is the other:
baseline: spec
<baseline>
spec for: #common do: [
spec
baseline: 'OSSubprocess' with: [
spec repository: 'github://pharo-contributions/OSSubprocess' ];
baseline: 'ResourcesLive' with: [
spec repository: 'github://seandenigris/Resources-Live' ];
baseline: 'Superuser' with: [
spec repository: 'github://seandenigris/Superuser' ];
baseline: 'Tempfile' with: [
spec repository: 'github://seandenigris/TempfileSt' ].
spec
package: 'Tesseract'
with: [ spec 
requires: #('OSSubprocess' 'Superuser' 'Tempfile');
includes: #('ResourcesLive') ] ].
spec for: #GToolkit do: [
spec package: 'Tesseract-Bloc' with: [ spec requires: #('Tesseract') ] ]

Dale Henrichs

unread,
Sep 30, 2020, 12:40:07 PM9/30/20
to meta...@googlegroups.com

Sean,

I don't have enough information to understand what is going on .... you've given me two baseline specs, but I don't know which projects they belong to ... as a result I don't know which "two" are endlessly churning .... A snippet of the Transcript might help as well as there would possibly be clues as to which packages are involved in the loop ...

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/944da425-b790-451d-bd99-3c91584dc383n%40googlegroups.com.

Sean DeNigris

unread,
Sep 30, 2020, 1:35:24 PM9/30/20
to Metacello
On Wednesday, September 30, 2020 at 12:40:07 PM UTC-4 Dale wrote:

I don't have enough information to understand what is going on ..... A snippet of the Transcript might help as well as there would possibly be clues as to which packages are involved in the loop ...

Sorry :) Here is some of the (seemingly endless) transcript output after the following (GT with Pharo 8 64-bit underneath, MacOS):
EpMonitor current disable.
Metacello new
baseline: 'Tesseract';
repository: 'github://seandenigris/Tesseract-St/src';
onConflict: [ :ex | ex allow ];
load.
EpMonitor current enable 

Sean DeNigris

unread,
Sep 30, 2020, 1:38:26 PM9/30/20
to Metacello
On Wednesday, September 30, 2020 at 12:40:07 PM UTC-4 Dale wrote:Sean,

I don't have enough information to understand what is going on .... you've given me two baseline specs, but I don't know which projects they belong to

Ugh.  Yes. now I see I didn't fully qualify the baseline methods. Here they are with BaselineOf class attached.

Here's one:

BaselineOfResourcesLive>>#baseline: spec
<baseline>

spec for: #'common' do: [
spec
baseline: 'PharoEnhancements' with: [
spec repository: 'github://seandenigris/Pharo-Enhancements' ];
baseline: 'SimplePersistence' with: [
spec repository: 'github://seandenigris/Simple-Persistence' ];
baseline: 'Superuser' with: [
spec repository: 'github://seandenigris/Superuser' ];
baseline: 'Tesseract' with: [
spec
repository: 'github://seandenigris/Tesseract-St' ].
spec package: #ResourcesLive with: [
spec requires: #('PharoEnhancements' 'SimplePersistence' 'Superuser' 'Tesseract'). ]. ].

And here is the other:
BaselineOfTesseract>>#baseline: spec

Sean DeNigris

unread,
Oct 7, 2020, 12:19:43 PM10/7/20
to Metacello
On Wednesday, September 30, 2020 at 1:35:24 PM UTC-4 Sean DeNigris wrote:
Sorry :) Here is some of the (seemingly endless) transcript output after the following (GT with Pharo 8 64-bit underneath, MacOS):
Any thoughts on how to get around this? It's causing me grief on my current project, which gets loaded into a fresh image almost daily... 

Dale Henrichs

unread,
Oct 7, 2020, 12:48:43 PM10/7/20
to meta...@googlegroups.com

Sean,

Sorry I am a bit buried with work on a couple of releases (we shipped one release yesterday and are scheduled to make another release in the next couple of weeks:) so I haven't had a lot of time to analyze the problem ...

With that said, I will try to make some time in the next couple of days, to see what I can figure out ...

I've taken a quick look at the file and nothing jumped out at me - I wasn't able to get a handle on the loop, but it does seem to involve a whole bunch of projects, so it is a subtle loop ... My screen is tall enough for me to see the loop:)

Just the other day, I did the work to break an infinite Metacello load loop between Seaside and Parasol, so I did learn a couple of things that may or may not help.

Metacello does not detect project loops. Metacello will detect package dependency loops, but a project reference loop not involving packages will go undetected ... Of course by detecting a loop, I mean that an error was thrown.

I see that you are using a number public projects intermixed with your own projects, so I'm going to guess that the loop is introduced by one of your projects. The public projects don't usually have undetected load loops ...

The Seaside/Parasol loop was interesting, because the initial bare install succeeded and the loop didn't show up until I tried to reload a project. Are you seeing something similar.

Since you are familiar with all of the projects, you should think about where you have created a dependency on a project on only a subset of a larger project that is used in its entirety elsewhere ... if you know of this you need to arrange to remove the loop by deciding which project is the master and arrange for it to be loaded first.

If you learn things before I have a chance to dig in deeper, please let me know

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.

Sean DeNigris

unread,
Oct 7, 2020, 1:06:47 PM10/7/20
to Metacello
> (we shipped one release yesterday and are scheduled to make another release in the next couple of weeks:)
Sounds like a good problem to have :) 

My screen is tall enough for me to see the loop:)

Another good problem ;-) 

I see that you are using a number public projects intermixed with your own projects, so I'm going to guess that the loop is introduced by one of your projects. The public projects don't usually have undetected load loops ...

I'm guessing you mean "personal" rather than private, because I think all the dependencies are publicly accessible.

The Seaside/Parasol loop was interesting, because the initial bare install succeeded and the loop didn't show up until I tried to reload a project. Are you seeing something similar.

It's happening on the initial load. 

Since you are familiar with all of the projects, you should think about where you have created a dependency on a project on only a subset of a larger project that is used in its entirety elsewhere ... if you know of this you need to arrange to remove the loop by deciding which project is the master and arrange for it to be loaded first.

Okay, let me think along those lines and let you know if I come up with anything... 

Thanks!!

Dale Henrichs

unread,
Oct 7, 2020, 1:37:35 PM10/7/20
to meta...@googlegroups.com

The hazards of writing email on the critical path:)

On 10/7/20 10:06 AM, Sean DeNigris wrote:

My screen is tall enough for me to see the loop:)

My screen is NOT tall enough for me to see the loop:)

Another good problem ;-) 

I see that you are using a number public projects intermixed with your own projects, so I'm going to guess that the loop is introduced by one of your projects. The public projects don't usually have undetected load loops ...

I'm guessing you mean "personal" rather than private, because I think all the dependencies are publicly accessible.

I should have said that public projects don't usually have undetected load loops when the standard entry points are used, otherwise they would have been reported and fixed.

Magritte, OSSubProcess, Grease, NeoCsv are used in a number of places without hitting loops, but the fact that these projects appear to be part of the loop leads me to believe the the loop is introduce in one of "your projects" ---

I see that you are using very few public projects without a personal fork and I would be suspicious of any changes that you have made to the baselines of these projects  ...

Oh look almost all of the projects involved in the loop seem to involve *-CompatibleUserName baselines and those are all presumably additions that you have made and the loop is almost certainly in the customization that you've done in those baselines ...

The log doesn't have information about the first entry point into the *-CompatibleUserName baselines in your load, but I would look very closely at that first entry point and find the other projects involved in the loop and find the one that uses the same entry point ...

Dale


Reply all
Reply to author
Forward
0 new messages