I've just uploaded YAML::Tiny 1.21 to the CPAN.
This release fixes a major bug in the serialization that caused any unprintable character (which includes newlines and tab) to be serialized to a reference, which then stringified to REF(memorylocation).
Anything using YAML::Tiny for light weight serialization of arbitrary data is strongly recommended to upgrade.
The root cause of this bug was a trivial typo, with the primary cause attributed to a lack of unit tests (or even sample documents) for unprintable characters, which would have otherwise caused the problems to be picked up by routine round-trip testing.
This has also been resolved.
This bug was also the underlying cause of the CGI::Capture TERMCAP bug.
A new release of CGI::Capture has been uploaded with an updated YAML::Tiny 1.21 dependency to resolve the TERMCAP problem.
This is the final dependency issue preventing a 1.00 release of TinyAuth, which I hope now to complete shortly, after a little more polishing of error handling and the installation code.
Re:Specless
Alias on 2007-12-06T05:09:40
YAML.pm is not compliant with the YAML spec.
YAML::Syck is not compliant with the YAML spec.
There's a number of instances in YAML::Tiny's comparative tests where I've had to skip comparisons with those modules because they fail.
YAML::Tiny is quite clear about what it is, a module that supports reading and writing of the block-mode JSON-subset of the YAML specification.
Re:Specless
srezic on 2007-12-06T17:46:20
At least YAML.pm and YAML::Syck are aiming to be compliant with the YAML spec. If I find a problem with one of these modules, I can look into a spec and decide if it's a bug and file a report. With YAML::Tiny it's difficult to tell whether it's intended or a bug.About the JSON-subset: where can I read this? I grepped the documentation and could not find a reference to it.
I am not against a tiny implementation of YAML, but it should go together with a tiny spec.
Re:Specless
Alias on 2007-12-06T22:53:04
Will doRe:Specless
Alias on 2007-12-06T05:11:22
As to that message, I believe we ended up with the position that for the purposes of the core, it was just fine to call it something like CPAN::ParseMETAyml or whatever, as long as it implemented something similarly light to the read half of YAML::Tiny.Re:Specless
mauzo on 2007-12-06T05:46:01
Perl doesn't have a formal spec, either, yet it seems to acquire its fair share of bugs:). YAML::Tiny has a perfectly decent (informal, implicit) spec:
- if write_string is passed any Perl data structure consisting only of unmagical scalars, arrays and hashes, produce a spec-compliant YAML document representing it which can be parsed by YAML::Tiny or any more complete YAML parser;
- if write_string is passed any other Perl data structure, report an error saying so;
- if read_string is passed any spec-compliant YAML document, either
- parse that document correctly and return the corresponding Perl data structure, or
- report an error that this document is unsupported and a more complete parser should be used;
- if read_string is passed anything that isn't a spec-compliant YAML document, report an error saying so.
Any other behaviour, such as Adam has just fixed, is a bug. The only thing that might be useful is documentation of which cases get 3.1 and which get 3.2.
Re:Specless
Alias on 2007-12-06T11:36:40
The elements that belong in 3.1 SHOULD be something like "any block-mode YAML content that resolves to the classes of Perl structures supported by write-out".Re:Specless
chromatic on 2007-12-06T14:17:24
Perl doesn't have a formal spec, either, yet it seems to acquire its fair share of bugs:). Do you see someone distributing software with "Perl" in the name that doesn't actually do what Perl does? I haven't, at least since kurila picked up its new name.
Re:Specless
sigzero on 2007-12-06T15:07:03
Doesn't YAML::Tiny tell the user exactly what it is?
NAME:
YAML::Tiny - Read/Write YAML files with as little code as possible
PREAMBLE ^
The YAML specification is huge. Really, really huge. It contains all the functionality of XML, except with flexibility and choice, which makes it easier to read, but with a formal specification that is more complex than XML.
The original pure-Perl implementation YAML costs just over 4 megabytes of memory to load. Just like with Windows.ini files (3 meg to load) and CSS (3.5 meg to load) the situation is just asking for a YAML::Tiny module, an incomplete but correct and usable subset of the functionality, in as little code as possible.
Like the other::Tiny modules, YAML::Tiny will have no non-core dependencies, not require a compiler, and be back-compatible to at least perl 5.005_03, and ideally 5.004. I read that and knew exactly what it did. It doesn't attempt to follow the huge YAML spec but doesn't allow you to read/write basic YAML files.
Re:Specless
Alias on 2007-12-06T22:55:07
> I read that and knew exactly what it did. It doesn't attempt to follow the huge YAML spec but doesn't allow you to read/write basic YAML files.
huh? Is that a typo?
Look at the samples contain in the tests, it lets you read/write all sorts of basic YAML files.Re:Specless
chromatic on 2007-12-07T06:13:07
Doesn't YAML::Tiny tell the user exactly what it is?I suppose that depends on your definition of the words incomplete, correct, usable, and specification.
Re:Specless
educated_foo on 2007-12-11T18:59:46
YAML looks simple, but is actually a bloated nightmare. Implementing the full YAML spec is tedious and difficult. Most uses of "YAML" actually use only a small subset. YAML::Tiny tries to implement this small, simple subset. I'm not sure why you find this so hard to understand.Re:Specless
LaPerla on 2007-12-11T21:53:20
> YAML::Tiny tries to implement this small, simple subset.
If you read the manpage from the first to the last line you still have no idea what this small, simple subset actually is. Whenever you have a small, simple YAML file that fails, or a small simple perl data structure that cannot be represented in YAML via YAML::Tiny, you cannot tell if it fails because of a bug or if it fails because the author has chosen to not implement some aspect of that small simple YAML file or that small, simple perl datastructure.
This is why I said: we have here a module that is unable to say what it does. And whenever a module does not say, exactly, what it does, we cannot tell if some behaviour is a bug or correct behaviour.
This has nothing to do with the perception of YAML being bloated or not. I'm not opposed to having some Tinyyaml spec that is (presumably) less bloated than YAML. But somebody has to write it and thus prove that it is worth the effort. Simply saying that doing less is better is not enough, the behaviour of the lesser implementation must be specced too. Otherwise it is unusable because unpredictable.
I hope this clarifies what I tried to say in my provocation.Re:Specless
educated_foo on 2007-12-15T00:19:26
I see your point, but I'm more willing to have the line between "bug" and "outside the spec" be negotiated between author and user. Many specs are so hairy that in practice you can only deal with them by having a general idea of their intent, then trying stuff to see what breaks. I haven't read the HTML 4 spec (746 KB of text), don't plan to, and couldn't remember it all if I did, but I can still hack together a webpage based on my rough understanding.The same goes (for me) for YAML::Tiny -- I'll use it for the simple stuff where it works, and deal with any breakage when I see it. YAML's in a unique position here, because it tries harder than most markup to look simple, but it is also formally specified. Kind of like English -- I usually get it right when speaking it but, even as a native, I don't pretend to remember all the rules.
