From: Oren Ben-K. <or...@ri...> - 2002-07-03 05:52:37
|
Steve Howell [mailto:sh...@zi...] wrote: > Okay, since it's your use case, I won't argue any more. I'm glad it worked out in the end :-) > Let's document it better. Seems so. Clark has written: > New lines inside paragraphs are of folded. > New lines between paragraphs follow the N-1 rule > All other new lines are significant That's exactly what's in the spec today. In fact, if you follow the productions, you'll see they directly reflect this. So, in the interest of enhanced clarity: - We should change the name "folded_text_line" to "folded_paragraph" and "folded_text" to "folded_text_line". - We should re-word of section 4.6.6. Anyone wants to take a stab at it? I think this would resolve the issue. > I like the technique of showing the same data in both representations. > Showing things in YAML goes a lot further than describing them in English. Yes. We should probably use this in other places as well. > The spec might also talk about the use case a little more. > Clearly, YAML's folding format will be optimized for the > one-newline-between-paragraphs internal format. > That's reasonable. Right. > > I've already conceded that carriage returns surrounding indented > > blocks should be significant; which is IMHO, a great idea... > > Examples of that would be good too. There's one such example in the spec already (the final example in section 4.6.7). Have fun, Oren Ben-Kiki |
From: Steve H. <sh...@zi...> - 2002-07-03 14:06:24
|
I just lost 15 minutes of my life waiting for perforce to download all our obsolete specs from the yaml.org checkout. I didn't even get the pleasure of smoking a pack of cigarettes. Why in the world are we keeping around all these old specs? Does anybody actually read them? If so, is that a good thing? Can we cut a CD with all the old specs, then remove all the files from perforce, then remove them from the web site, then throw the CD into the Potomac River, and move on to the future? Thanks, Steve |
From: Clark C . E. <cc...@cl...> - 2002-07-03 14:16:48
|
| I just lost 15 minutes of my life waiting for | perforce to download all our obsolete specs | from the yaml.org checkout. Two answers: You already downloaded them, so your pain is over... Or... if you are willing to put-in some work... 1. rename the very first version you find as "spec.html" and check it in using the date for the comment. 2. check it out, and replace it with the very next version, submit changes with the date from the file as the comment. 3. repeat #2 for every one there except for the one that is a .zip (for that one you could if you have time turn it into a single document using MIME...) 4. remove all of the files in the /spec directory except for the new "spec" 5. I'll keep all the old versions checked-out on the website (but you are right, no reason to keep them separate in perforce) |
From: Steve H. <sh...@zi...> - 2002-07-03 14:29:18
|
----- Original Message ----- From: "Clark C . Evans" <cc...@cl...> > | I just lost 15 minutes of my life waiting for > | perforce to download all our obsolete specs > | from the yaml.org checkout. > > Two answers: > > You already downloaded them, so your pain > is over... Correct. You only pay the price once. > Or... if you are willing to put-in some work... > > 1. rename the very first version you find as > "spec.html" and check it in using the date > for the comment. > 2. check it out, and replace it with the very > next version, submit changes with the date > from the file as the comment. > [...] I guess I don't understand why we need to keep all the history around in perforce. Just because perforce could let us keep the whole history around doesn't mean we should. Perhaps we don't want to put links to old versions of the spec on the front page of yaml.org. It seems like this will only lead to confusion. On a related note, I am wondering if we should maybe put some YAML on the front page. Perhaps we can lift something from Brian's slides. I like how "Recent News" shows that the YAML project is over a year old, and that YAML includes a mature implementation and spec, but perhaps we could get the same message across in a more YAMLesque way? Thanks, Steve |
From: Neil W. <neilw@ActiveState.com> - 2002-07-03 15:52:55
|
Rant follows. Steve Howell [03/07/02 10:28 -0400]: > I guess I don't understand why we need to keep all the history around in > perforce. This is source control. You're supposed to keep the history around forever. The problem is it's done totally wrong here. Sorry, Clark. When you've got a source code control system, you don't need version numbers in directories or filenames. If you need them, you're not using it properly. This is what 'p4 files //depot/yaml/yaml.org/spec/...' looks like: ttul:~$ p4 files //depot/yaml/yaml.org/spec/... //depot/yaml/yaml.org/spec/01aug2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/02oct2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/04nov2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/07apr2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/09dec2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/09jun2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/10dec2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/10feb2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/10mar2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/10nov2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/11nov2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/12aug2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/13jun2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/14jun2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/15may2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/16feb2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/16jun2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/17dec2001.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/18feb2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/18may2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/19jan2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/20feb2002.html#1 - add change 134 (text) //depot/yaml/yaml.org/spec/22jul2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/23jun2001.zip#1 - add change 134 (xbinary) //depot/yaml/yaml.org/spec/24may2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/25jun2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/26may2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/27jun2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/27may2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/28apr2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/30jun2002.html#1 - add change 476 (text) //depot/yaml/yaml.org/spec/31jul2001.html#1 - add change 134 (xtext) //depot/yaml/yaml.org/spec/index.html#2 - edit change 476 (text) //depot/yaml/yaml.org/spec/spug.html#1 - add change 134 (text) This is what it should look like: ttul:~$ p4 files //depot/yaml/yaml.org/spec/... //depot/yaml/yaml.org/spec/index.html#2 - edit change 476 (text) //depot/yaml/yaml.org/spec/spug.html#1 - add change 134 (text) If you want to see the spec as of 26may2002, do this: ttul:~$ p4 sync //depot/yaml/yaml.org/spec/...@2002/05/26 Now of course, our Perforce repository hasn't been around as long as yaml.org has, so we can't do that past 2002/04/11. But we can use labels. p4 help label p4 help labels p4 help labelsync p4 sync //depot/yaml/yaml.org/spec/...@<labelname> The basic idea is to avoid duplication. You don't have to download all the history at once -- Perforce keeps it in the server! That's the point! Later, Neil |
From: Neil W. <neilw@ActiveState.com> - 2002-07-03 15:56:38
|
Neil Watkiss [03/07/02 08:51 -0700]: > This is what it should look like: > > ttul:~$ p4 files //depot/yaml/yaml.org/spec/... > //depot/yaml/yaml.org/spec/index.html#2 - edit change 476 (text) > //depot/yaml/yaml.org/spec/spug.html#1 - add change 134 (text) Actually, isn't spug.html just another label of index.html? That's one fewer file needed. And index.html probably ought to be called something like "spec.html" instead. The name "index" isn't very informative. Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-07-03 16:06:05
|
Several months ago, Brian gave a talk at "spug", this is the version of the spec that he used; I'm not sure which version is syncs up with. Also, index.html is needed so that the canonical link, http://yaml.org/index.html works. It needn't be in perforce as it always a copy-of / link-to the most recent version of our spec; sorry it made it in the import. | Steve Howell [03/07/02 10:28 -0400]: | > I guess I don't understand why we need to keep all the history around in | > perforce. | | This is source control. You're supposed to keep the history around forever. | The problem is it's done totally wrong here. Sorry, Clark. | Oh, no offence taken. This numbering scheme is what we need for the website so that previous versions of the spec are accessable with a simple click. What we do in CVS is completely up to you.. I just checked the site in (rather blindly) cuz I was lazy. Best Clark |