I've been looking into various memory leak issues over the last week, with
some limited success (see #2824 patch).
Through various tests and from looking at data from users I'm suspecting
that this is only a partial solution, and that there may be other leaks,
though I've as yet been unable to
Markus Roberts wrote:
It'd be great if you could abolish the parse-order dependency
altogether. As long as all variable/value reference chains form a
directed acylcic graph, they could be evaluated after finishing the
parse, regardless of order.
Could you
On Nov 17, 2009, at 10:10 AM, Markus Roberts wrote:
On Tue, Nov 17, 2009 at 12:57 AM, David Schmitt da...@dasz.at wrote:
Markus Roberts wrote:
It'd be great if you could abolish the parse-order dependency
altogether. As long as all variable/value reference chains
form a
On Nov 16, 2009, at 12:22 PM, Markus Roberts wrote:
At some point someone may want to get the coverage tests
working, but
the coordinates of that point is are not (now,me). This patch
just
comments out the rcov and stops the time consuming trailing stack
trace generation.
On 17/11/09 09:07, Markus Roberts wrote:
I've been looking into various memory leak issues over the last week, with
some limited success (see #2824 patch).
That's some really great news. Too many people are struggling with those
client side leaks (if not server-side).
Up to the point
On Tue, Nov 17, 2009 at 12:57 AM, David Schmitt da...@dasz.at wrote:
Markus Roberts wrote:
It'd be great if you could abolish the parse-order dependency
altogether. As long as all variable/value reference chains form a
directed acylcic graph, they could be evaluated after
Maybe you could remove it, and James could work to make sure a working
separate target exists?
Will do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Developers group.
To post to this group, send email
Monkey-patch workaround for RDoc so it doesn't get confused by rubygems
stub executables.
Signed-off-by: Jesse Wolfe jes5...@gmail.com
---
lib/puppet/util/monkey_patches.rb |8 +++
spec/unit/util/monkey_patches.rb | 103 +
2 files changed, 111
Monkey-patch workaround for RDoc so it doesn't get confused by rubygems
stub executables.
Signed-off-by: Jesse Wolfe jes5...@gmail.com
---
lib/puppet/util/monkey_patches.rb |8 +++
spec/unit/util/monkey_patches.rb | 103 +
2 files changed, 111
What's actually loading this monkey patch into memory when Puppet runs?
Did you confirm that --help now works with the executables? These
tests don't really make it clear.
On Nov 17, 2009, at 12:24 PM, Jesse Wolfe wrote:
Monkey-patch workaround for RDoc so it doesn't get confused by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Roberts wrote:
Maybe you could remove it, and James could work to make sure a working
separate target exists?
Will do.
Leave it with me.
Cheers
James Turnbull
- --
Author of:
* Pro Linux System Administration
On Nov 14, 2009, at 2:07 AM, Markus Roberts wrote:
Trying to synthesize the information from this thread, the #2400
thread, and various other sources I'm seeing a few basic questions:
1. How much information to include
2. How it should be structured
3. How normalized it should be
4. How
I'd love to see someone with memory problems try this out and see how
much of an impact it has.
Maybe put this in the testing branch for a while?
On Nov 17, 2009, at 12:45 AM, Markus Roberts wrote:
This is a moderately ugly workaround for the MRI garbage collection
bug (see the ticket for
On Nov 16, 2009, at 12:35 PM, Markus Roberts wrote:
It'd be great if you could abolish the parse-order dependency
altogether. As long as all variable/value reference chains form a
directed acylcic graph, they could be evaluated after finishing the
parse, regardless of order.
Could you
On Nov 17, 2009, at 2:57 AM, David Schmitt wrote:
Markus Roberts wrote:
It'd be great if you could abolish the parse-order dependency
altogether. As long as all variable/value reference chains form a
directed acylcic graph, they could be evaluated after finishing the
parse, regardless of
Great, thanks. I somehow missed that you put in into an already-used
monkey patch file, rather than in a separate file.
On Nov 17, 2009, at 3:13 PM, Jesse A Wolfe wrote:
I placed it in lib/puppet/util/monkey_patches.rb on Markus's
suggestion, as it's already required by
That's basically it; the more general form is to use the futures
(aka promises) mentioned earlier in this thread. Instead of
stashing a (variable,scope) reference you create a placeholder
object which either holds a value or the tree to evaluate to get
that value.
After parsing is
Replace deprecated method call. This code was not tested before, so I've
tried to capture what I think the method was trying to do.
Signed-off-by: Jesse Wolfe jes5...@gmail.com
---
lib/puppet/type/maillist.rb | 12 +---
spec/unit/type/maillist.rb | 33
Hi all
Luke and I have been discussing road map over the next few months and
I'd like to propose an approach.
Stage 1 - 0.25.2
a. Unless show-stopper don't add any tickets to current 0.25.2 Roadmap
and perhaps triage some of the existing tickets
b. Look at an RC1 at end of November
c.
19 matches
Mail list logo
