| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |\ \ \ |
|
| | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
spec/unit/indirector/indirection.rb
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
moving.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Shouldn't "confine" produce some output when running spec? Who knows.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
it belongs. Robustifying the request sanitization a bit more.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Finally eliminated dependency on Puppet.start, etc., from WEBrick HTTP server class. {webrick,mongrel}+REST now support request handling uniformly; need encode/decode next.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
bits for request handling prior to the encode/decode/exception-handling bits. Refactored to make the common logic extractable to a base class.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
indirection, as the REST vs. XMLRPC models are different enough that the object must register itself on initialization and handle the request when it comes in.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
into Indirection to look up models from indirected names.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
unknown HTTP Server types; fail fast.
|
| | | | | | | |
|
| | | | | | | |
|
| | |\ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
need to start up a webrick server w/ address + port (this is far too incestuous with Puppet lib & Puppet.start at the moment).
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
classes are named.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
base server / http server classes + specs.
|
| | |\ \ \ \ \ \ |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | |\ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ |
|
|/ / / / / / / / / / / |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
logic around mounting and unmounting. This includes a fix for
bug #761, which required a different regex for Solaris.
|
|\ \ \ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |/ / / / / / / / / / /
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
this just adds the patch from the bugreport
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
when using :include, not (for example) when evaluating
node classes.
|
| | |_|_|_|_|_|_|_|_|_|/
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
'include' function is used, instead of being lazy-evaluated.
Previous work caused resources to get created to model
these classes, but in the process, I removed the fact
that the classes were evaluated immediately. This meant
that you couldn't guarantee that a class was evaluated
before you went to use its variables.
|
|/ / / / / / / / / / /
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
modify the local system and they run fine as
non-root users.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
It was previously using the GRATR::Edge class, which
had wonky overrides that dramatically slowed down
sorting (its hash mechanism hashed the source and
target so that edges with the same source/target got
the same hash, which we actually don't want any more).
This shouldn't change any functionality, just performance.
I didn't retain all functionality from the Edge class, but
a lot of that functionality was, um, horrible, like Edge[]
being equivalent to Edge.new.
|
|\| | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
test, but I do not know of a good way to test this, really.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
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).
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
a drastic performance increase.
However, profiling has shown that GRATR just isn't going
to cut it. I think I'm going to have to replace it as my
graphing base class to avoid the horrible, horrible performance
I keep encountering.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
file recursion was previously not working, because
the relationship graph was setting itself as a resource's
primary configuration, which caused it to try creating its
own relationship graph.
I've now found that the current code is about 5x slower than
the released code, so now I hope to resolve that.
|
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | | |
|