On 30/03/16 18:24, Eric Sorenson wrote:
Hi, I've just posted a new Puppet RFC that describes pre-parsed and
pre-validated Puppet files, akin to '.pyc' files for Python. It's called
XPP and the doc is open for comments here:
https://docs.google.com/document/d/17SFn_2PJYcO5HjgA4R65a5ynR6_bng_Ak5W5
On Mon, Apr 4, 2016 at 7:36 AM, John Bollinger
wrote:
>
>
> On Sunday, April 3, 2016 at 8:21:46 PM UTC-5, Henrik Lindberg wrote:
>
> In the long run, in general, we want it to be possible to express as
>> much as possible using the Puppet Language itself, and where that is not
>> practical, that
On 04/04/16 19:42, Thomas Gelf wrote:
Probably not evaluated, because that's where from my understanding the
"it's no longer data" starts. If I'm wrong on that: nice. If not, just
out of curiosity: is evaluation in Ruby expensive?
I forgot - yes evaluation in Ruby is also slow.
- henrik
--
V
On 04/04/16 19:42, Thomas Gelf wrote:
Am 04.04.2016 um 03:21 schrieb Henrik Lindberg:
We are happy if we initially only get 5-10% out of this...
And this is where I currently disagree. Very often I invest lots of time
for just 1%. But being able to run without a fragile caching layer could
be
Am 04.04.2016 um 03:21 schrieb Henrik Lindberg:
>>> We are happy if we initially only get 5-10% out of this...
>>
>> And this is where I currently disagree. Very often I invest lots of time
>> for just 1%. But being able to run without a fragile caching layer could
>> be worth even 50% as long as I
On Sunday, April 3, 2016 at 8:21:46 PM UTC-5, Henrik Lindberg wrote:
In the long run, in general, we want it to be possible to express as
> much as possible using the Puppet Language itself, and where that is not
> practical, that it is easy to integrate an implementation (written in
> c++, r
On 02/04/16 01:18, Thomas Gelf wrote:
Hi Henrik,
thanks a lot for your response!
Am 01.04.2016 um 20:21 schrieb Henrik Lindberg:
The C++ implementation is several orders of magnitudes faster than the
ruby implementation. i.e. something silly like tens of thousands of
times faster.
No doubt o
Am 01.04.2016 um 20:59 schrieb R.I.Pienaar:
> Indeed and if you recall there was a similar outcry when passenger became
> the de facto way. The java stack as delivered by PL in PuppetDB and Server is
> a LOT more manageable than the passenger stack.
I do not agree on this, at least I never had
Hi Deepak,
great to hear from you. Didn't expect you to join the conversation, but
as I offended your baby... sorry for this ;)
Am 01.04.2016 um 20:42 schrieb Deepak Giridharagopal:
> ... Maybe the thing to do here is to try some experiments and post back
> some numbers that could hopefully grou
Hi Henrik,
thanks a lot for your response!
Am 01.04.2016 um 20:21 schrieb Henrik Lindberg:
> The C++ implementation is several orders of magnitudes faster than the
> ruby implementation. i.e. something silly like tens of thousands of
> times faster.
No doubt on this, I believe you without any be
- Original Message -
> From: "Deepak Giridharagopal"
> To: "puppet-dev"
> Sent: Friday, 1 April, 2016 20:42:30
> Subject: Re: [Puppet-dev] Re: Puppet RFC 23 - XPP Files
>>
> But please do forget that the extensibility of a tool is one of the k
On Thu, Mar 31, 2016 at 8:02 PM, Thomas Gelf wrote:
> your dedication in getting Puppet faster is really appreciated. My post
> is absolutely not in favor of XPP, but please don't get me wrong: it is
> meant to be a constructive contribution to the current design process.
>
Thanks for the feedba
On 01/04/16 04:02, Thomas Gelf wrote:
Hi Eric,
your dedication in getting Puppet faster is really appreciated. My post
is absolutely not in favor of XPP, but please don't get me wrong: it is
meant to be a constructive contribution to the current design process.
In my personal opinion we have a
Thomas,
This is certainly a well thought out writeup, and mirrors some of the
concerns that I've heard discussed elsewhere.
I must agree that a large part of the benefit of Puppet is being able to
deep dive into the various components relatively easily and figure out
what's breaking, patch it, an
Hi Eric,
your dedication in getting Puppet faster is really appreciated. My post
is absolutely not in favor of XPP, but please don't get me wrong: it is
meant to be a constructive contribution to the current design process.
In my personal opinion we have a sad history of optimizations focusing a
On 30/03/16 23:12, Jeremiah Powell wrote:
ASTs don't need to be built on a node-by-node basis (unless you
meant manifest-by-manifest basis
Well, manifest-by-manifest where the manifest will vary depending on the
node the compile job is depending upon. Reviewing the code I get the
impre
>
> ASTs don't need to be built on a node-by-node basis (unless you meant
> manifest-by-manifest basis
>
Well, manifest-by-manifest where the manifest will vary depending on the
node the compile job is depending upon. Reviewing the code I get the
impression I just don't understand the existing pa
Hi Jeremiah,
On Wed, Mar 30, 2016 at 11:56 AM, wrote:
> I write a lot of native types for our internal use at work. (I tell
> people that if you are just using Exec in Puppet that ansible is one search
> away in Google. ) Some of the Puppet code used with these types would be
> very challenging
I write a lot of native types for our internal use at work. (I tell people
that if you are just using Exec in Puppet that ansible is one search away
in Google. ) Some of the Puppet code used with these types would be very
challenging to "pre-compile" in any way.
I think a lot of my questions a
19 matches
Mail list logo
