From: Steve H. <sh...@zi...> - 2002-07-17 14:55:01
|
From: "why the lucky stiff" <yam...@wh...> > Steve Howell [16/07/02 12:55 -0400]: > > Why, is there any chance that you could move the Ruby implementation to the > > perforce server? I guess we should make sure Neil is okay with this idea, > > since he is the one who has generously given us use of the box. > > I am totally game for this. And quite convenient for the central testing > ground. Excellent! > Speaking of which, we should nail down a schema for the tests. Here's the > basics I'd like to see: > > --- #YAML:1.0 > name: Sequence of scalars > brief: > > To include a sequence in your document, you can write > out a comma-seperated list of values. Sequences > can also be written as an indented list of strings, > with dashes beginning each entry. The sequence will > be parsed into a list structure, such as an array. > ruby: | > [ 'Mark McGwire', 'Sammy Sosa', 'Ken Griffey' ] > perl: | > [ 'Mark McGwire', 'Sammy Sosa', 'Ken Griffey' ] > yaml: | > - Mark McGwire > - Sammy Sosa > - Ken Griffey > round trip: [ ruby ] I wouldn't use the inline array syntax for the "round trip" specification, because some implementations (like the pure Python implementation) might not support it, and we want to get folks bootstrapped with the tests as soon as possible. We need to decide whether round tripping is the exception or the rule. I think it might make more sense to have a "no_round_trip" specifier, for the following reasons: 1) When you're not round tripping, it's more clearly documented in the tests. 2) When you get round tripping working, you get the satisfaction of removing the line from the test. 3) The test suites stay smaller. > This is a basic idea, so feel free to rip it apart. I'm just trying to get > the discussion rolling. Looks good, thanks! > The "round trip" key is for listing languages capable of round-tripping the > test. I'd really like to see that listed in our cookbook and we could give > percentages for implementations with the highest ability to round trip the > tests. We should define round tripping precisely. When I say things round trip, all I mean is you can take the python, export it to YAML, read it back into python, and it's the same python. The round tripping aspect of a test is often somewhat orthogonal to the "YAML parsing" aspect of the test. Round tripping tests an implementation to be a pure serializer, but it doesn't test its ability to deal with multiple forms of human-entered input. > Also, we have tests for reading multiple documents, which I think warrant > a slightly different format. I'm not sure how to handle this, but I think > we need to have a key listing the number of documents, so we can validate > that as well. > > --- > name: Multiple single-line documents > brief: > > Building documents which contain a single > element or empty construct are available > by adding them to the separator's line. > ruby: | > y = YAML4R::Document.new > y.add( 1 ) > y.add( ' foo ' ) > y.add( "bar\n" ) > y.add( [] ) > y.add( {} ) > return y > perl: | > (1, " foo ", "bar\n", [], {}) > yaml: | > --- #YAML:1.0 1 > --- #YAML:1.0 ' foo ' > --- #YAML:1.0 "bar\n" > --- #YAML:1.0 [] > --- #YAML:1.0 {} > round trip: [ ruby, perl ] > documents: 5 Makes sense. > > I've noticed that Brian also has notes in his tests, which give reasons why > the test won't round trip. It would nice for implementation authors to have > room for notes. Not sure where it would go. > I think we could just do this ad-hoc for now. Add a "notes" key at first if you want notes, and then if different implementations want to note different things, we can work out a system later. > Also, let's say different implementations crop up for different languages. > Maybe it would be nice to accomodate a section for each implementation instead, > with notes. > I don't think naming conflicts will be a big issue. I could see a breakdown like this: perl - Brian's perl ruby - Why's ruby python - Steve's python libyaml_perl - Neil/Brian's perl libyaml_python - Neil/Clarks' python (etc.) |