From: <yam...@wh...> - 2002-07-08 17:09:43
|
After a few weeks of distraction (camping, hiking, vaction, etc.), I found some time this weekend to plug away at YAML4R. And great success was had! The parser is working great and thanks to Racc (yacc for Ruby), the parser took about 300 lines of code! I haven't done any benchmarks, but I imagine it's quite slower than YAML.pm, as the parser takes a couple passes to do its job. Still, it's not terribly slow and its worth the clean code to me until I can hook into libyaml someday. I don't know how Brian does it. I started writing a straight-forward parser from the regular expressions in YAML.pm, but its a long and winding road that I couldn't find the endurance to climb. (Thank the 16 miles I hiked last week... It stole my stamina...) The parser is rather elegant though, and I daresay it'll be useful if someone wants to construct a parser with lex and yacc. My yaml.y could easily be ported to C. So this release is 0.14. I've been keeping versions and milestones to myself so far, but I believe the module is quite useable now, so I figured I would release it publicly. A few things: the parser doesn't handle tabs right. Also, blocks are all literal at the moment. Parsing multiple documents is coming soon. And special keys aren't supported. But most everything else is there. You can check the README for a list of what from the spec is supported and any details as to compliance. I'll be announcing this on ruby-talk shortly and I've announced it on Freshmeat. I've attached the README to this message in case you want to read about the release without needing to download it all. I've set up a page on Wiki with examples: http://wiki.yaml.org/yamlwiki/YamlForRuby Version 0.14 is here: http://west.dl.sourceforge.net/sourceforge/yaml4r/yaml4r-0.14.tar.gz The project page is: http://sf.net/projects/yaml4r/ Hopefully I'll have some readable details up at the home page: http://yaml4r.sf.net/ Peace, love, and tons of questions forthcoming! _why |
From: <yam...@wh...> - 2002-07-08 22:16:00
|
A couple questions: 1. The order of aliases and anchors in relation to transfer methods. It seems that I have seen the following allowed in the spec, but I can't see it at the moment: key: !float &NA "10" key2: *NA This syntax does not fit into my parser right now, as the transfer method is needed to type the double-quoted string. The !float doesn't know what to do with the anchor. This makes sense, as you'd likely want the typing information to affect the alias in key2. So if: key: &NA !float "10" key2: *NA ...then the key2 is equal to 10.0. Does the order of the alias, anchor, or transfer method matter? Are there rules defining this that I cannot see? 2. Unit tests I've been throwing together some unit tests for YAML4R. You can find them in tests/basic.rb. The tests parallel Ingy's. I would like to start using Brian's unit tests directly, though. For example: perl: | ['foo ' x 20] ruby: | ['foo ' * 20] yaml: | --- #YAML:1.0 - >- foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo Are we to the stage where we could start throwing together a round-trip YAML validation suite for the implementations to use? I don't mind having to update my unit tests, but I think changes to the spec could be implemented more quickly. And we could develop a mechanism for comparing the implementations' speed and degrees of compliance. 3. Yaml-core My project is rather small at the moment. Would anyone object to YAML4R users using Yaml-core as their mailing list. I figured this ML doesn't get a whole lot of traffic and other YAML people might enjoy scanning the discussion. I don't suspect I'll have a whole lot of users anyway and I didn't really want to add another mailing list to the mix yet. _why |
From: why t. l. s. <yam...@wh...> - 2002-07-08 23:27:07
|
Not a problem at all, Clark. I have a bunch of stuff to keep me busy. And YAML4R won't get much activity until several months down the road at least... Hope the stress level fades out. _why Clark C . Evans (cc...@cl...) wrote: > I'm stressed today; but will answer tomorow! > > ;) Clark |
From: why t. l. s. <yam...@wh...> - 2002-07-09 06:23:51
|
Ryan King (rk...@pa...) wrote: > On 2002.07.08, yam...@wh... <yam...@wh...> wrote: > > 2. Unit tests > > [..] > > perl: | > > ['foo ' x 20] > > ruby: | > > ['foo ' * 20] > > Awesome. Beautiful. Perfect. Keep bugging Ingy until he caves > in and does this. I love it. Yeah, this excites me too. Not only do the files function as unit tests, but they could plausibly build a definitive YAML Cookbook. In other words, we could go for a structure that includes brief descriptions. title: Simple implicit map description: | This implicit map has unquoted strings for keys, with various numeric types for values. perl: | { hr => 65, avg => 0.278, rbi => 147 } ruby: | { 'hr' => 65, 'avg' => 0.278, 'rbi' => 147 } python: | { 'hr': 65, 'avg': 0.278, 'rbi': 147 } yaml: | avg: 0.278 hr: 65 rbi: 147 spec: http://www.yaml.org/spec/#trans-map Seems like a really neat use of YAML... > On a different note (err.. on a different key... er... on a > different keyboard), what's up with this?: > > ~/yaml4r-0.14$ ruby -Isrc tests/basic.rb > tests/basic.rb:6:in `require': No such file to load -- yaml4r (LoadError) > from tests/basic.rb:6 yaml4r.rb isn't actually born until you run install.rb. The grammar is in yaml.y and the emitter is in emitter.rb. Racc builds the grammar and then its flowed into a new yaml4r.rb. I figured it was better to distribute the actual source I am working with rather than the generated files. > I like what I see, by the way. It's interesting to see how > you've done some things just like how Steve and I did it in our > original Ruby-emitter spikes. And feel free to make any comments on the API or to submit patches. I'm totally flexible and we can all get more done together. > And on yet another keyboard, here's a random idea. Why not > replace the things in basic.rb that look like this: > > def test_basic > # Check foo: > assert('foo'...) > > > # Check bar: > assert('bar'...) > end > > with this?: > > def test_foo > assert('foo'...) > end > > def test_bar > assert('bar'...) > end > > > The main reason I do it this way is that I've found that *Unit > test frameworks seem to like it better this way -- specifically, > they help you when a test fails: > 1. They keep going, and run the other tests, too. > 2. They tell you the name of which test method failed, which > can help debugging a bit. > > Iunno... you might know something I don't. =) Excellent suggestion. I believe I'll be moving to this technique inthe next few days. And if you want bleeding edge... I just checked in 0.15 with support for Regexp and better double-quoting. Also, the explicit implicit works now: integer: 12 also int: ! "12" string: !str 12 I allow currently allow maps to be explicitly typed as sequences and vice versa. - !seq test: one another: two Performs Hash#to_a: [ ['test', 'one'], ['another', 'two'] ] Whereas the opposite: - !map - test - one - another - two Performs Hash.[]: [ {'test' => 'one', 'another' => 'two'} ] While I'm making major changes each night, I won't be releasing all the minor versions. Sync up with CVS: cvs -d:pserver:ano...@cv...:/cvsroot/yaml4r login cvs -d:pserver:ano...@cv...:/cvsroot/yaml4r co yaml4r The best part is actually being able to use YAML with Ruby now! It rules! 8D _why |
From: Brian I. <in...@tt...> - 2002-07-14 22:31:13
|
On 09/07/02 00:31 -0600, why the lucky stiff wrote: > Ryan King (rk...@pa...) wrote: > > On 2002.07.08, yam...@wh... <yam...@wh...> wrote: > > > 2. Unit tests > > > [..] > > > perl: | > > > ['foo ' x 20] > > > ruby: | > > > ['foo ' * 20] > > > > Awesome. Beautiful. Perfect. Keep bugging Ingy until he caves > > in and does this. I love it. > > Yeah, this excites me too. Not only do the files function as unit tests, but they could > plausibly build a definitive YAML Cookbook. In other words, we could go for a structure > that includes brief descriptions. +1 I used to have a description field in these tests but took them out because I thought they were YAGNI. But it turns out they are YAAGNI (You actually ARE gonna need it). Ain't it always the way, rking! Steve and I talked a lot about doing this between our Perl and Python implementations. Now that Ruby is really cooking, I think it's a must. BTW, great job Why! Maybe I'll stop by your part of the world as I tour the country and we can pair up on our implementations. Need to stop by Neil's first to get that libyaml thingy wrapped up. :) Tommorrow I head off towards San Diego. Gonna be low on the radar for a while more. Peace to all of you. Cheers, Brian |
From: Brian I. <in...@tt...> - 2002-07-09 12:34:35
|
On 08/07/02 11:17 -0600, yam...@wh... wrote: > After a few weeks of distraction (camping, hiking, vaction, etc.), I > found some time this weekend to plug away at YAML4R. And great success > was had! The parser is working great and thanks to Racc (yacc for > Ruby), the parser took about 300 lines of code! I haven't done any > benchmarks, but I imagine it's quite slower than YAML.pm, as the > parser takes a couple passes to do its job. Still, it's not terribly > slow and its worth the clean code to me until I can hook into libyaml > someday. > > I don't know how Brian does it. I started writing a straight-forward > parser from the regular expressions in YAML.pm, but its a long and > winding road that I couldn't find the endurance to climb. (Thank the > 16 miles I hiked last week... It stole my stamina...) The parser is > rather elegant though, and I daresay it'll be useful if someone wants > to construct a parser with lex and yacc. My yaml.y could easily be > ported to C. Why, Great job. I'll be sure to publicize it at the O'Reilly Conference. YAMLers, I'm driving to Chicago today. My connectivity for the next several weeks will be spotty. NO SNEAKING IN CHANGES!! Just kidding. Peace and love, Brian |