.NET Parser

<div>

<div class="Section1">

<p class="MsoNormal"><span>Dear Yaml fans,<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>We are two computer science
students from the University of Hasselt, Belgium. This year we had to choose a
project and because of the great challenges we choose to[CL] implement a .NET
Yaml parser.<p></p></span></p>

<p class="MsoNormal"><span>The requirements of the
project were to implement it in C# and release it as Open Source. We also took
the challenge to make it a one pass parser.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>After 3 months of hard work
we are proud to release the source code. We are finishing the last parts for
the presentation and after the marking we will release it definitive (begin of
July).<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>All information can be found
on <a href="http://lumumba.uhasselt.be/~christophe/YAML/">http://lumumba.uhasselt.be/~christophe/YAML/</a>.&nbsp;
There is a unfinished manual, NDoc generated documentation and the information
to get the source code from the CVS repository. We will follow the project, but
due of our busy student life we can't say at the moment that we will have time
to do a lot of coding.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>We hope you enjoy our work
and it is useful.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Greats Jonathan Slenders and Christophe Lambrechts<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

</div>

</div>

_______________________________________________
Yaml-core mailing list
Yaml-core@...
https://lists.sourceforge.net/lists/listinfo/yaml-core

add_builtin_type

Using Ruby/Syck. Anyone can tell me what I'm doing wrong here:

  s = %{
  ---
  a: 1
  b: 2
  c: 3
  }

  YAML.add_builtin_type('map'){|t,v| p v}
  o = YAML.load(s)
  p o

It's not catching the map type at all.

Thanks,
T.

[ANN] JvYAML: A Java YAML 1.1 loader

-------------------
 Announcing JvYAML
-------------------

I am pleased to announce JvYAML, version 0.1. JvYAML is a Java YAML 1.1
loader that is both easy to extend and easy to use.
JvYAML originated in the JRuby project (http://jruby.sourceforge.net),
from the base of RbYAML (http://rbyaml.rubyforge.org). For a long time
Java have lacked a good YAML loader and dumper with all the features
that the SYCK using scripting communities have gotten used to. JvYAML
aims to rectify this.

Of major importance is that JvYAML works the same way as SYCK, so that
JRuby can rely on YAML parsing and emitting that mirrors C Ruby.
JvYAML is a clean port of RbYAML, which was a port from Python code
written by Kirill Simonov <xi@...> for PyYAML3000.
The JvYAML project is created and maintained by Ola Bini <ola@...>

Simple usage:
-------------
import org.jvyaml.YAML;

Map configuration = (Map)YAML.load(new
FileReader("c:/projects/ourSpecificConfig.yml"));
List values = (List)YAML.load("--- \n- A\n- b\n- c\n");

There is also support for more advanced loading of JavaBeans with
automatic setting of properties
with the use of domain tags in the YAML document.

More information:
-----------------
At java.net: http://jvyaml.dev.java.net

Download: https://jvyaml.dev.java.net/servlets/ProjectDocumentList

License:
--------
JvYAML is distributed with the MIT license.

Regards
 Ola Bini

Integer vs. String when Dump-ing from Perl?

Hi!

I've been using YAML in both Perl and Ruby without any problem. But 
recently I tried to mix the two languages, and let both work on the the 
same YAML-files. As far as I can see, a string that happens to consist 
of only integers "looses" its type when it is handled by Perl. For example:

     $ cat example.yaml
     ---
     - 11
     - "22"
     - foo
     $
     $ perl -MYAML -00 -e 'print Dump Load <>' example.yaml
     --- #YAML:1.0
     - 11
     - 22
     - foo
     $
     $ ruby -rYAML -e 'print YAML.load(ARGF.read).to_yaml' example.yaml
     ---
     - 11
     - "22"
     - foo

In the Perl case above the "22" is transformed into a number 22.

I'm aware of Perl's indifference and on-the-fly conversion between 
numbers and strings. But I had still hoped that YAML for Perl would have 
left a string looking like a number as it was (like Data::Dumper in Perl 
does).

Is there some way of configuring YAML for Perl to do what I want,
or is it impossible to this behavior?

Regards,
Johan Holmberg

Fixing bools in 1.0 and 1.1

Well, so, I can't remember where we stand with the 'y' and 'n' booleans.  Syck
hasn't supported them because they conflict with other parts of the spec.  (See
examples 2.21 and 2.24 in either version.)

Which of the following works?

  true: y
  false: n

  x: 73
  y: 129

_why

Re: Fixing bools in 1.0 and 1.1

On Wed, Jun 07, 2006 at 08:57:08AM -0600, why the lucky stiff wrote:
> Well, so, I can't remember where we stand with the 'y' and 'n'
> booleans.  Syck hasn't supported them because they conflict with other
> parts of the spec.  (See examples 2.21 and 2.24 in either version.)

PyYAML doesn't support them either for the same reason.  I've
implemented them initially, but then noticed that even the spec examples
contradict them, so I've removed the support.

> Which of the following works?
>
>   true: y
>   false: n
>
>   x: 73
>   y: 129

I believe the latter should be valid.

--

-- 
xi

Re: Fixing bools in 1.0 and 1.1

Yes, I implemented them in RbYAML and JvYAML too, but right now I'm
about to remove them again, since everything about them are so
contradictory.

/O

----- Original Message -----
From: Kirill Simonov <xi@...>
Date: Wednesday, June 7, 2006 7:49 pm
Subject: Re: [Yaml-core] Fixing bools in 1.0 and 1.1
To: why the lucky stiff <yaml-core@...>
Cc: yaml-core@...

> On Wed, Jun 07, 2006 at 08:57:08AM -0600, why the lucky stiff wrote:
> > Well, so, I can't remember where we stand with the 'y' and 'n'
> > booleans.  Syck hasn't supported them because they conflict with 
> other> parts of the spec.  (See examples 2.21 and 2.24 in either 
> version.)
> PyYAML doesn't support them either for the same reason.  I've
> implemented them initially, but then noticed that even the spec 
> examplescontradict them, so I've removed the support.
> 
> > Which of the following works?
> >
> >   true: y
> >   false: n
> >
> >   x: 73
> >   y: 129
> 
> I believe the latter should be valid.
> 
> 
> -- 
> xi
> 
> 
> _______________________________________________
> Yaml-core mailing list
> Yaml-core@...
> https://lists.sourceforge.net/lists/listinfo/yaml-core
> 

Re: Fixing bools in 1.0 and 1.1

On 07/06/06 08:57 -0600, why the lucky stiff wrote:
> Well, so, I can't remember where we stand with the 'y' and 'n' booleans.  Syck
> hasn't supported them because they conflict with other parts of the spec.  (See
> examples 2.21 and 2.24 in either version.)
> 
> Which of the following works?
> 
>   true: y
>   false: n
> 
>   x: 73
>   y: 129

FWIW, I think the y/n boolean implicits are a little bit cute and could
be removed.

But there are a few points I would like to remind people of:

1) The implicit type repository is not part of the spec. So it follows
   that they have no relation to 1.1 or 1.2.
2) The types are really a recommendation. Domain specific YAML
   processors are free to define their own implicits.
3) The default of a generic YAML processor should be to treat all
   scalars as strings.
4) A good generic processor should not only have an interface to
   turn implicits on and off, but also to turn each specific
   implicit on and off.

In my opinion the type repository definition is a little backwards. It
/should/ be the set of types commonly supported by the implementations.
But that creates a chicken/egg problem, so it is a decent starting
point. The repository is a journey not a destination. :)

Cheers, Ingy

Fixing bools in 1.0 and 1.1

On 6/7/06, Ingy dot Net <ingy@...> wrote:
> On 07/06/06 08:57 -0600, why the lucky stiff wrote:
> > Well, so, I can't remember where we stand with the 'y' and 'n' booleans.  Syck
> > hasn't supported them because they conflict with other parts of the spec.  (See
> > examples 2.21 and 2.24 in either version.)
> >
> > Which of the following works?
> >
> >   true: y
> >   false: n
> >
> >   x: 73
> >   y: 129
>
> FWIW, I think the y/n boolean implicits are a little bit cute and could
> be removed.
>
> But there are a few points I would like to remind people of:
>
> 1) The implicit type repository is not part of the spec. So it follows
>    that they have no relation to 1.1 or 1.2.
> 2) The types are really a recommendation. Domain specific YAML
>    processors are free to define their own implicits.
> 3) The default of a generic YAML processor should be to treat all
>    scalars as strings.
> 4) A good generic processor should not only have an interface to
>    turn implicits on and off, but also to turn each specific
>    implicit on and off.

That may be the official line but its far from the general use. the
default of Syck is to use implicts and personally I think most people
expect that. I agree though that ther should be an easy way to turn
them off. I suspect just about every implementation will follow the
same course, so I think the YAML tema needs to go a little further
than a loose recommendation. Interoberability is a boon for YAML, so
having a standard for common implict behavior would (IMHO) be a very
good idea. Implementation can of course go beyond that (with ability
to turn it one and off), but at least they'd have something to which
to peg a base line of interoperability in this regard.

T.

Re: Fixing bools in 1.0 and 1.1

On 07/06/06 19:56 -0400, TRANS wrote:
> On 6/7/06, Ingy dot Net <ingy@...> wrote:
> > On 07/06/06 08:57 -0600, why the lucky stiff wrote:
> > > Well, so, I can't remember where we stand with the 'y' and 'n' booleans.  Syck
> > > hasn't supported them because they conflict with other parts of the spec.  (See
> > > examples 2.21 and 2.24 in either version.)
> > >
> > > Which of the following works?
> > >
> > >   true: y
> > >   false: n
> > >
> > >   x: 73
> > >   y: 129
> >
> > FWIW, I think the y/n boolean implicits are a little bit cute and could
> > be removed.
> >
> > But there are a few points I would like to remind people of:
> >
> > 1) The implicit type repository is not part of the spec. So it follows
> >    that they have no relation to 1.1 or 1.2.
> > 2) The types are really a recommendation. Domain specific YAML
> >    processors are free to define their own implicits.
> > 3) The default of a generic YAML processor should be to treat all
> >    scalars as strings.
> > 4) A good generic processor should not only have an interface to
> >    turn implicits on and off, but also to turn each specific
> >    implicit on and off.
> 
> That may be the official line but its far from the general use. the
> default of Syck is to use implicts and personally I think most people
> expect that. I agree though that ther should be an easy way to turn
> them off. I suspect just about every implementation will follow the
> same course, so I think the YAML tema needs to go a little further
> than a loose recommendation. Interoberability is a boon for YAML, so
> having a standard for common implict behavior would (IMHO) be a very
> good idea. Implementation can of course go beyond that (with ability
> to turn it one and off), but at least they'd have something to which
> to peg a base line of interoperability in this regard.

I think Syck has gotten a few things wrong, but we haven't been sticklers
because who wants to rain on Why's parade. Still the new xYaml 1.1
implementations are getting things right and I expect Syck to follow their
lead.

Interoperability comes at many levels. Just turning on/off implicits is not
the way to get interoperability. To get it, both sides must agree on what they
are saying to each other. This can be done in several ways as I've noted in
the past.

Cheers, Ingy