The yaml.org site is nice because it links to the specs. (It's also
entertaining because the site itself presents as a YAML document.)
Whatever library is being used to handle YAML parsing should declare the
spec version(s) that are supported, and those spec documents helped me when
learni
ice, and so I think that
>> is why 4 spaces works when 2 does not in this case.
>>
>> On Fri, Apr 26, 2019 at 2:32 PM Walt Karas > .invalid>
>> wrote:
>>
>> > So, it seems that with YAML, it sometimes matters whether you use 4
>> spaces
>>
the value for this entry.
>
> Since it is nested, in effect we need to indent twice, and so I think that
> is why 4 spaces works when 2 does not in this case.
>
> On Fri, Apr 26, 2019 at 2:32 PM Walt Karas .invalid>
> wrote:
>
> > So, it seems that with YAML, it som
why 4 spaces works when 2 does not in this case.
On Fri, Apr 26, 2019 at 2:32 PM Walt Karas
wrote:
> So, it seems that with YAML, it sometimes matters whether you use 4 spaces
> of indentation rather that 2 space of indentation. Is there some reason we
> are choosing to use YAML, o
Are you sure that isn't just a failure of your YAML parser? What package are
you using to provide the `yaml` module?
From: Walt Karas
Sent: Friday, April 26, 2019 1:31 PM
To: dev
Subject: [EXTERNAL] YAML
So, it seems that with YAML, it sometimes ma
So, it seems that with YAML, it sometimes matters whether you use 4 spaces
of indentation rather that 2 space of indentation. Is there some reason we
are choosing to use YAML, other than sheer love of Satan?
$ cat load.py
import yaml
import sys
f = open(sys.argv[1], 'r')
y = y
+ 1
-Bryan
> On Mar 14, 2019, at 11:26 AM, Leif Hedstrom wrote:
>
> Hi all,
>
> As we’re making more progress migrating towards YAML configurations, I’d like
> to make two proposals for v9.0.0:
>
>
> 1) As we migrate a configuration to the new YAML format, w
> On Mar 14, 2019, at 5:07 PM, Masaori Koshiba wrote:
>
> proxy.config.ssl.server.multicert.filename
Yes, it should also be removed.
— leif
included? It will be
ssl_multicert.yaml, I think.
- Masaori
On Fri, Mar 15, 2019 at 3:26 AM Leif Hedstrom wrote:
> Hi all,
>
> As we’re making more progress migrating towards YAML configurations, I’d
> like to make two proposals for v9.0.0:
>
>
> 1) As we migrate a confi
> On Mar 14, 2019, at 1:29 PM, John Rushford wrote:
>
> Leif,
>
> Your proposal seems fine to me. I have a PR on github that converts the
> existing parent.config to YAML,
> https://github.com/apache/trafficserver/pull/4857
> In this PR, I had made it backwards comp
Leif,
Your proposal seems fine to me. I have a PR on github that converts the
existing parent.config to YAML,
https://github.com/apache/trafficserver/pull/4857
In this PR, I had made it backwards compatible with the existing format.
The change involves a lot of changes to the ControlMatcher
Hi all,
As we’re making more progress migrating towards YAML configurations, I’d like
to make two proposals for v9.0.0:
1) As we migrate a configuration to the new YAML format, we only support YAML.
I.e. no backwards compatibility layers. Of course, we only break such
compatibility in major
I think a problem here is Canned YAML isn't a library, it's an application.
It reads schemas and generates C++ code. It is not itself linked in to
anything. We could actually use it completely outside of ATS and only check
in the generated code. However, the generated code depends
My suggestion was to add the utilities as part of Canned YAML code base and
bring in Canned YAML as a single library. I don’t think it makes sense to have
two separate libraries (libswoc and canned YAML). This way anyone who would
want to use a C++ schema validation library for YAML can
While working on the YAML support for ATS, I ended up making quite a lot of
changes and updates to a set of support utilities which are also in ATS. To
avoid problems while the work was in progress, and because it was suggested
at the summit, I copied those utilities to a stand alone repository[1
On Debian side, yaml-cpp lib is also available with versions:
- 0.5.2 for stable, testing & unstable
- 0.5.1 for jessie (old-stable) which is under long term support until
end of june 2020.
Wheezy will be definitely end of life in 2 days, so there's no need to
support yaml-cpp in versio
Looks like LLVM has a YAML parser. Maybe we could use that.
https://llvm.org/docs/YamlIO.html
On Mon, May 21, 2018 at 4:16 PM, Randall Meyer <
randallme...@yahoo.com.invalid> wrote:
> Hi, I am looking at/using yaml-cpp (https://github.com/jbeder/yaml-cpp).
> It seems to be a rec
Hi, I am looking at/using yaml-cpp (https://github.com/jbeder/yaml-cpp). It
seems to be a recently-active project, C++-based and the API is simple to
use/comprehend.
I've tried using the 0.3 version, but it uses std::auto_ptr (now removed in
C++17) and it looks like up until 0.
> On May 19, 2018, at 9:26 AM, Alan Carroll
> wrote:
>
> Since it was decided we would shift to using YAML for configuration, have
> there been any suggestions as to a specific library to use? I think that
> would be a good thing to discuss before we go much further down th
Since it was decided we would shift to using YAML for configuration, have
there been any suggestions as to a specific library to use? I think that
would be a good thing to discuss before we go much further down this road.
+1 for replacing LuaJIT configs with YAML.
On Tue, May 8, 2018 at 3:01 AM, Bryan Call wrote:
> +1
>
> -Bryan
>
>
> > On May 7, 2018, at 12:47 PM, Leif Hedstrom wrote:
> >
> > Hi,
> >
> > I’d like to propose that we eliminate the existing LuaJIT con
+1
-Bryan
> On May 7, 2018, at 12:47 PM, Leif Hedstrom wrote:
>
> Hi,
>
> I’d like to propose that we eliminate the existing LuaJIT configurations with
> a simple YAML format. This would be the first step towards a unified
> configuration format, and I think we have t
On Mon, May 7, 2018 at 5:47 AM Leif Hedstrom wrote:
> Hi,
>
> I’d like to propose that we eliminate the existing LuaJIT configurations
> with a simple YAML format. This would be the first step towards a unified
> configuration format, and I think we have to admit defeat
Hi,
I’d like to propose that we eliminate the existing LuaJIT configurations with a
simple YAML format. This would be the first step towards a unified
configuration format, and I think we have to admit defeat on Lua, and do
something simpler and more normal for both developers and users
24 matches
Mail list logo
