From: Jason D. <ja...@in...> - 2004-06-26 16:00:12
|
Should there be a line length limit in order to ease the processing of YAML files in typically buffer-challenged environments like C? I would suggest a nice round number like 1024 characters which is so large that humans will never hit it but still allowing for some wiggle room for applications that automatically generate YAML. This wouldn't be unheard of: RFC 2822, section 2.1.1 restricts line lengths in email messages:: There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. By the way, how's the new draft coming along? -- Jason |
From: Oren Ben-K. <or...@be...> - 2004-06-26 16:49:22
|
On Saturday 26 June 2004 18:58, Jason Diamond wrote: > Should there be a line length limit in order to ease the processing of > YAML files in typically buffer-challenged environments like C? > > I would suggest a nice round number like 1024 characters which is so > large that humans will never hit it but still allowing for some wiggle > room for applications that automatically generate YAML. There's a 1024 characters limit for simple keys, to prevent unbound lookahead in parsers. We _could_ replace this by having a 1024 characters line length limit, I suppose, though that is a much more pervasive restriction. > This wouldn't be unheard of: RFC 2822, section 2.1.1 restricts line > lengths in email messages:: > > There are two limits that this standard places on the number of > characters in a line. Each line of characters MUST be no more than > 998 characters, and SHOULD be no more than 78 characters, excluding > the CRLF. Hmmm. I don't have a strong opinion about this either way - Clark, Brian, what do you think? > By the way, how's the new draft coming along? Slowly ;-) Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-06-26 16:58:11
|
I like the limit of 1024 on simple keys (due to look-ahead concerns). However, I often use a 'simplified' single-line YAML that uses all double-quoted strings and in-line forms of mappings and sequences. It's not easy to read, but it is a cake walk to parse. Cheers! Clark On Sat, Jun 26, 2004 at 07:49:18PM +0300, Oren Ben-Kiki wrote: | On Saturday 26 June 2004 18:58, Jason Diamond wrote: | > Should there be a line length limit in order to ease the processing of | > YAML files in typically buffer-challenged environments like C? | > | > I would suggest a nice round number like 1024 characters which is so | > large that humans will never hit it but still allowing for some wiggle | > room for applications that automatically generate YAML. | | There's a 1024 characters limit for simple keys, to prevent unbound lookahead | in parsers. We _could_ replace this by having a 1024 characters line length | limit, I suppose, though that is a much more pervasive restriction. | | > This wouldn't be unheard of: RFC 2822, section 2.1.1 restricts line | > lengths in email messages:: | > | > There are two limits that this standard places on the number of | > characters in a line. Each line of characters MUST be no more than | > 998 characters, and SHOULD be no more than 78 characters, excluding | > the CRLF. | | Hmmm. I don't have a strong opinion about this either way - Clark, Brian, what | do you think? | | > By the way, how's the new draft coming along? | | Slowly ;-) | | Have fun, | | Oren Ben-Kiki | | | ------------------------------------------------------- | This SF.Net email sponsored by Black Hat Briefings & Training. | Attend Black Hat Briefings & Training, Las Vegas July 24-29 - | digital self defense, top technical experts, no vendor pitches, | unmatched networking opportunities. Visit www.blackhat.com | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: Jason D. <ja...@in...> - 2004-06-26 17:19:17
|
Clark C. Evans wrote: >I like the limit of 1024 on simple keys (due to look-ahead concerns). >However, I often use a 'simplified' single-line YAML that uses all >double-quoted strings and in-line forms of mappings and sequences. It's >not easy to read, but it is a cake walk to parse. > > Your entire document is on one line? Why do you find this necessary? -- Jason |
From: Oren Ben-K. <or...@be...> - 2004-06-26 18:44:05
|
On Saturday 26 June 2004 20:17, Jason Diamond wrote: > Your entire document is on one line? Why do you find this necessary? It isn't vital by any means, but Clark makes a good point. Forcing flow style collections to have line breaks is unnatural. Also, as someone who repeatedly tries to write a YAML parser in C, I don't see that a 1K line length limit is helpful (I just use a sliding window buffer). Since lookahead is bound (due to the 1k limit on simple keys), there's really no problem. Sure, you might report a single text chunk as multiple ("continuation") events/tokens, but that's true regardless of breaking text into lines. Have fun, Oren Ben-Kiki |
From: Rich M. <rd...@cf...> - 2004-06-26 21:03:58
|
The trend in most of the Perl community (as well as in the GNU suite) is toward taking away arbitrary restrictions. One of the things that made Boulder IO popular with geneticists, in fact, was the lack of a limit on line length. I also recall hearing a war story about folks running into a line-length limit in vi(1); it got in the way of the data entry folks who were typing in gene sequences (:-). So, my answer is an emphatic NO. If someone wants to work with a subset of YAML, that's not a problem. Just don't limit the rest of us to it! -r -- email: rd...@cf...; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series |
From: Brian I. <in...@tt...> - 2004-06-27 20:31:47
|
On 26/06/04 13:53 -0700, Rich Morin wrote: > The trend in most of the Perl community (as well as in the GNU suite) > is toward taking away arbitrary restrictions. One of the things that > made Boulder IO popular with geneticists, in fact, was the lack of a > limit on line length. I also recall hearing a war story about folks > running into a line-length limit in vi(1); it got in the way of the > data entry folks who were typing in gene sequences (:-). > > So, my answer is an emphatic NO. If someone wants to work with a > subset of YAML, that's not a problem. Just don't limit the rest of > us to it! Writing YAML parsers (even in dynamic languages like Perl) is a bitch if you have unbounded lookaheads. The problem isn't with buffer sizes, it's with context. You think that you're parsing a multiline value only to find out (after you've reported it) that it's a key of a new mapping. Whether or not this is a problem depends on the algorithm you are using and the environment you are working in. What we've decided is that it is *ok* for a YAML parser to throw an error if a *simple key* exceeds 1024 chars. This is not much of a usage restriction at all. Emitters should just quote mapping keys longer than 1024 to ensure that any parser can handle it. There is no such restrictions on mapping values, which is where you will normally find long data like those gene sequences. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-06-27 20:57:07
|
On Sunday 27 June 2004 23:29, Brian Ingerson wrote: > What we've decided is that it is *ok* for a YAML parser to throw an error > if a *simple key* exceeds 1024 chars. This is not much of a usage > restriction at all. Emitters should just quote mapping keys longer than > 1024 to ensure that any parser can handle it. Nit: It isn't quoting that does the trick; instead, you need to prefix the key with "? ". It can then be unquoted and as long as you like. The idea is for the parser to know this is a key _before_ it reads through 1GB of quoted/plain/whatever data to discover there's a ": " at the end. > There is no such restrictions on mapping values, which is where you will > normally find long data like those gene sequences. Right. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2004-06-27 21:17:12
|
On 27/06/04 23:57 +0300, Oren Ben-Kiki wrote: > On Sunday 27 June 2004 23:29, Brian Ingerson wrote: > > What we've decided is that it is *ok* for a YAML parser to throw an error > > if a *simple key* exceeds 1024 chars. This is not much of a usage > > restriction at all. Emitters should just quote mapping keys longer than > > 1024 to ensure that any parser can handle it. > > Nit: It isn't quoting that does the trick; instead, you need to prefix the key > with "? ". It can then be unquoted and as long as you like. The idea is for > the parser to know this is a key _before_ it reads through 1GB of > quoted/plain/whatever data to discover there's a ": " at the end. Haha. I knew I wasn't quite right, but I also *knew* Oren would correct me. Thanks. Cheers, Brian |