You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/12/17 00:51:17 UTC

[revelation!!] circular dependencies do NOT exist!

It came to me as a revelation today: one of the problems with gump that 
I could never figure out is the fact that circular dependencies prevent 
the ability to "bootstrap" after a certain point.

Example, subversion is stored in a subversion repository, thefore, 
before building, we need to update the repository... but then how can we 
do that?

So

  A --(needs)--> B

and

  B --(needs)--> A

Until today, i thought that no matter how well maintained, a dependency 
graph would always be a general graph, and cycles would develop, sooner 
of later (it is still amazing that gump reached 750 projects without 
explicit circular dependencies).

I was also starting to think at a way to map the concept of 
'autocatalysm' that incurs in networks of genes and proteins interaction 
(and is the most acclaimed theory that explains the emergence of life 
out of primordial broth)

Turns out I was wrong: there is no such thing as circular dependency.

NEVER! It's physically impossible!

Let me explain.

Let's start with changing the above diagram a little:

  ---------A----------------------------->
          /
       needs
        /
       v
  -----B--------------------------------->
                                        time

let's call them A:1 and B:1 to indicate their name and their time 
coordinate (1 could be a timestamp or a version, doesn't matter), so

  --------A:1----------------------------->
          /
       needs
        /
       v
  ----B:1--------------------------------->

no, the previous diagram said that A needs B and B needs A... but the 
fact is that at the time of B:1, A:1 was not even existing, so it's 
impossible to draw the above "uses" line bidirectionally. The 
appropriate diagram is

  A:0-------A:1----------------------------->
   ^        /
    \      /
   needs needs
      \  /
       \v
  -----B:1--------------------------------->

and we can continue like that backwards until we reach the *initial 
stage* of one of the projects where one of them did *NOT* exist at all, 
therefore the thing.

Now.

This seems to imply that in order to bootstrap anything we need to 
"regenerate" the entire history of buildings. Well, turns out that is 
not the case since we can take a snapshot of a previous build and 
continue from there.

In fact, a particular version is the crystallization of all the time 
dependencies across the above trallis, but if we take into consideration 
the time axis, there is no such a thing as circular dependencies.

:-D

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [revelation!!] circular dependencies do NOT exist!

Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:

> So while we can probably build gump to work like this (heck, it already 
> works like this "manually"), we'd need to do some powerful visualisation 
> to make people understand what's going on.

eheh, here is where the fun (for me, as a research scientist) starts :-)

> "A:20041215 failed because B:20041214 depends on C:20041213 for 
> bootstrapping which depends on behaviour of A:20041212 that was broken 
> from A:20041213 on."
> 
> try and figure that out for 700 projects, and explain it properly! :-D
> 
> So while circular dependencies don't exist if we ingrain our graph with 
> the time dimension completely, it will at the same time become a lot 
> more difficult to understand the graph and act upon changes to it. :/

I've been spending a few weeks now studying hard about pretty much 
everything there is to know about user interface design for data 
visualization tecniques.

I'm not done yet (I have some 20 books to go ;-) but I'm seeing the 
light at the end of the tunnel.

more (and some screenshots) soon.

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: [revelation!!] circular dependencies do NOT exist!

Posted by Eric Pugh <ep...@opensourceconnections.com>.
Isn't the "fallback" idea for artifacts that is already in Gump something
like the time travel?  If project A depends on B, and A.today can't build
with B.today, then try with B.yesterday.  If that fails, then try
B.daybeforeyesterday.  If that fails, then try
B.daybeforedaybeforeyesterday!

I agree that the visualization would be hard, makes me think of all the
various tools (like FishEye) that attempt to visualize the branching of code
in CVS.

(Sorry for the crypto timestamp notation!)

Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [revelation!!] circular dependencies do NOT exist!

Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> It came to me as a revelation today: one of the problems with gump that 
> I could never figure out is the fact that circular dependencies prevent 
> the ability to "bootstrap" after a certain point.
<snip/>
> In fact, a particular version is the crystallization of all the time 
> dependencies across the above trallis, but if we take into consideration 
> the time axis, there is no such a thing as circular dependencies.

:). Aye.

A common approach in physics (or in math) is to add in another variable, 
constant, dimension, whatever, in order to get around annoying 
limitations of a model. The key problem with that is that the model 
becomes harder and harder to understand and work with, up to the point 
where like 3 people on the planet really understand it (I certainly 
don't get why string theorists think there's 13 dimensions. 7, maybe. 
But after that I get lost).

The same is true of bootstrapping. Someone who's doing, for example, 
linux from scratch (linuxfromscratch.org I think), is almost certainly 
not thinking about


  A:0-------A:1----------------------------->
   ^        /
    \      /
   needs needs
      \  /
       \v
  -----B:1--------------------------------->


but is using one very specific often-used snapshot provided by someone 
else (the "(A,B):bootstrap" distro).

Extending the above mechanism to 40 (or 4000!) projects all with 
time-invariant circular dependencies among themselves is kind of a pain, 
and I think most, for example, cocoon developers certainly aren't aware 
of their time-variant dependency graph.

So while we can probably build gump to work like this (heck, it already 
works like this "manually"), we'd need to do some powerful visualisation 
to make people understand what's going on.

"A:20041215 failed because B:20041214 depends on C:20041213 for 
bootstrapping which depends on behaviour of A:20041212 that was broken 
from A:20041213 on."

try and figure that out for 700 projects, and explain it properly! :-D

So while circular dependencies don't exist if we ingrain our graph with 
the time dimension completely, it will at the same time become a lot 
more difficult to understand the graph and act upon changes to it. :/


cheers,


- Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [revelation!!] circular dependencies do NOT exist!

Posted by Stefano Mazzocchi <st...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 16 Dec 2004, Stefano Mazzocchi <st...@apache.org> wrote:
> 
> 
>>Until today, i thought that no matter how well maintained, a
>>dependency graph would always be a general graph, and cycles would
>>develop, sooner of later (it is still amazing that gump reached 750
>>projects without explicit circular dependencies).
> 
> 
> Because we've already used the time-travel approach to break them in a
> couple of places
> 
> packaged-dom4j -> jaxen-from-packaged-dom4j -> dom4j -> jaxen
> 
> and
> 
> packaged-jcs -> bootstrap-ojb -> jcs -> db-ojb
> 
> (hmm, the later used to be the case, but right now I don't see any
> difference between bootstrap-ojb and db-ojb anymore)

Cool, see how many things we don't know.

Stefan, before we finish Gump 3.0 make sure you don't get hit by a truck ;-)

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [revelation!!] circular dependencies do NOT exist!

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 16 Dec 2004, Stefano Mazzocchi <st...@apache.org> wrote:

> Until today, i thought that no matter how well maintained, a
> dependency graph would always be a general graph, and cycles would
> develop, sooner of later (it is still amazing that gump reached 750
> projects without explicit circular dependencies).

Because we've already used the time-travel approach to break them in a
couple of places

packaged-dom4j -> jaxen-from-packaged-dom4j -> dom4j -> jaxen

and

packaged-jcs -> bootstrap-ojb -> jcs -> db-ojb

(hmm, the later used to be the case, but right now I don't see any
difference between bootstrap-ojb and db-ojb anymore)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: [revelation!!] circular dependencies do NOT exist!

Posted by Wa...@Lawson.com.
Stefano, my responses below...

Stefano Mazzocchi <st...@apache.org> wrote on 12/16/2004 05:51:17 PM:

> [...]
> 
>   A --(needs)--> B
> 
> and
> 
>   B --(needs)--> A
> 
> Until today, i thought that no matter how well maintained, a dependency 
> graph would always be a general graph, and cycles would develop, sooner 
> of later (it is still amazing that gump reached 750 projects without 
> explicit circular dependencies).

Is this all a matter of the scope of the node in the graph?  In other
words, and I think you get to this in a temporal way, but there are
parts of A on which B depends, and likewise the other direction.  These
parts are build at different times (sequenced), thus you are allowed
the perception of "something within" that is built before the whole.


> [...]
> 
> Let's start with changing the above diagram a little:
> 
>   ---------A----------------------------->
>           /
>        needs
>         /
>        v
>   -----B--------------------------------->
>                                         time
> 
> let's call them A:1 and B:1 to indicate their name and their time 
> coordinate (1 could be a timestamp or a version, doesn't matter), so
> 
>   --------A:1----------------------------->
>           /
>        needs
>         /
>        v
>   ----B:1--------------------------------->

It seems to me it is more of a matter of decomposition than temporal,
that each "larger node" ie, "A", can be decomposed into its smaller
components, "A:0", "A:1", and "B" is decomposed into its components.


> no, the previous diagram said that A needs B and B needs A... but the 
> fact is that at the time of B:1, A:1 was not even existing, so it's 
> impossible to draw the above "uses" line bidirectionally. The 
> appropriate diagram is
> 
>   A:0-------A:1----------------------------->
>    ^        /
>     \      /
>    needs needs
>       \  /
>        \v
>   -----B:1--------------------------------->
> 
> and we can continue like that backwards until we reach the *initial 
> stage* of one of the projects where one of them did *NOT* exist at all, 
> therefore the thing.

The question I have is: It really the case where the dependency on a
portion of another node is really time (version) based, or is it simply
time-based because of the way the entire node is built?

Another way of saying that is: Is what you are doing simply by extending
the model a series of decompositions to get to the smallest nuggest of
significance on which something could depend?  And the only reason why
time is involved is because of the sequencing of the building process?


> [...]
> 
> In fact, a particular version is the crystallization of all the time 
> dependencies across the above trallis, but if we take into consideration 

> the time axis, there is no such a thing as circular dependencies.

I think you can come to the same conclusion by way of "sufficient
decomposition" and remove the time element.  Are we on the same
track of thought?

wade