| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Some spec files like active_record.rb had names that would confuse the
load path and get loaded instead of the intended implentation when the
spec was run from the same directory as the file.
Author: Matt Robinson <matt@puppetlabs.com>
Date: Fri Jun 11 15:29:33 2010 -0700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows you to specify a run stage for either
a class or a resource.
By default, all classes get directly added to the
'main' stage. You can create new stages as resources:
stage { [pre, post]: }
To order stages, use standard relationships:
stage { pre: before => Stage[main] }
Or use the new relationship syntax:
stage { pre: } -> Stage[main] -> stage { post: }
Then use the new class parameters to specify a stage:
class { foo: stage => pre }
If you set a stage on an individual resource, it will
fail; stages can only be set on class resources.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| |
|
|
|
|
|
| |
It previously worked with multiple, but the only caller
actually only ever passed one event.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| | |
|
| |
|
|
|
|
|
| |
If we don't do this, there's a chance we'll get hit
by the ruby yaml bug again.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
| |
This can cause a huge speedup for large numbers of edges.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The way this class was testing edges was
causing them to appear adjacencies to appear magically,
because it was only testing that a hash had a key, not that
the value had any edges.
This fixes the infinite recursion mentioned in #2111.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This was important because the use of the label to store attributes
was a holdover from the GRATR library, and if we didn't cease its
use before we switched to RESTful catalogs, then we'd be stuck with
the @label instance variable forever, essentially.
Now we can add and remove variables however we please.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
|
|
| |
This class is a holdover from when I was using GRATR, and it's
obsolete now.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
| |
|
|
|
| |
the in-degree sometimes resulted in a lower number than the
number of in-edges.
|
| |
|
|
| |
removing the bangs from 'add_vertex!' and 'add_edge!'.
|
| |
|
|
| |
from the system, and implemented my own topsort method.
|
| |
|
|
| |
and I had to make a few small changes to make them work.
|
| |
|
|
| |
on hashing.
|
| |
|
|
|
|
| |
to Puppet::SimpleGraph, which should dramatically enhance
performance. It should be largely functionally equivalent,
with the only difference being that edges are no longer deduplicated.
|
|
|
is just too slow. This class has just about no iteration,
and vertex deletation is dramatically (as in, 1000x) faster).
Here are the results of some very simplistic graph operations:
Vertex tests (add and remove 1000 vertices):
gratr: Add: 0.01; Remove: 9.70
simple: Add: 0.02; Remove: 0.01
Edge tests (add and remove 1000 edges):
gratr: Add: 0.02; Remove: 0.03
simple: Add: 0.07; Remove: 0.02
I expect I can get the cost of the edge addition down some, but even
as it is, it's a couple of orders of magnitude faster.
This doesn't even count things like searching, which I did some other
testing on and got consistently faster results (somewhere between 1.5x and
1500x faster, depending on how the test was set up and how big the graph was).
|
