From: Donnal W. <don...@ya...> - 2002-07-16 01:32:57
|
Okay, I am working on understanding sequences. Can someone provide the YAML equivalent for the following XML: <Problem> <name> pneumonia </name> <med-list> <Med> <name> ampicillin </name> <dose> 340 </dose> <units> mg </units> <route> IV </route> <interval> 8 </interval> </Med> <Med> <name> gentamicin </name> <dose> 8.6 </dose> <units> mg </units> <route> IV </route> <interval> 12 </interval> </Med> </med-list> </Problem> For example, is the following legal YAML? med-list: - Med name: ampicillin dose: 340 units: mg route: IV interval: 8 - Med name: gentamicin dose: 8.6 units: mg route: IV interval: 12 or... - Med: name: gentamicin dose: 8.6 or... - !Med name: gentamicin dose: 8.6 "Med" here is a user-defined type, but not all items in the "med-list" object need be of this type. For example, the user might use "Med" for medications in general, but define specific types for frequently used drugs... med-list: - !Ampicillin dose: 340 route: IV interval: 8 Thanks. ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com |
From: why t. l. s. <yam...@wh...> - 2002-07-16 03:00:12
|
Donnal Walter (don...@ya...) wrote: > Okay, I am working on understanding sequences. Can someone provide > the YAML equivalent for the following XML: > > <Problem> > <name> > pneumonia > </name> > <med-list> > <Med> > <name> > ampicillin > </name> > <dose> > 340 > </dose> > <units> > mg > </units> > <route> > IV > </route> > <interval> > 8 > </interval> > </Med> ... > </med-list> > </Problem> > or... > - !Med > name: gentamicin > dose: 8.6 It appears that you're looking for a transfer method, so the above is correct. Though you'll probably want to use a private ("!!Med") or a domain type ("!hospital.com/Med"), since the single exclamation syntax is for YAML builtin types. You could use prefixing to shorten the domain type: --- #YAML:1.0 !hospital.com/^Problem name: med list: - !^Med name: ampicillin dose: 340 units: mg route: IV interval: 8 - !^Med name: gentamicin dose: 8.6 # .. and so on > > "Med" here is a user-defined type, but not all items in the > "med-list" object need be of this type. For example, the user might > use "Med" for medications in general, but define specific types for > frequently used drugs... > > med-list: > - !Ampicillin > dose: 340 > route: IV > interval: 8 Yeah, exactly. The list of medications will unserialize into a set of Med/Ampicillin/etc object instances or structures. _why |
From: Clark C . E. <cc...@cl...> - 2002-07-16 13:40:37
|
On Mon, Jul 15, 2002 at 06:32:56PM -0700, Donnal Walter wrote: | Okay, I am working on understanding sequences. Can someone provide | the YAML equivalent for the following XML: Ok. The primary difference between XML and YAML is that YAML uses maps and lists, while XML uses a hybrid "named list". Your med-list is where you want the list it seems, and thus the "Med" name for each item in the list isn't needed. | <Problem> | <name> | pneumonia | </name> | <med-list> | <Med> | <name> | ampicillin | </name> Since in YAML you don't have the named-map thingy, you could merge "med-list" and "Med" and rename it to something intutitive, like "medication". In general, it is good practice to use singular words (even when you have a list) beacuse using plurals gets complicated quickly; and in YAML since it is clear that "medication" is a list, you don't need the -list idiom. | med-list: | - Med | name: ampicillin | dose: 340 | units: mg | route: IV | interval: 8 | - Med | name: gentamicin | dose: 8.6 | units: mg | route: IV | interval: 12 Close. All you need to do is drop the "Med" part as it is just redundant. name: pneumonia medication: - name: ampicillin dose: 340 units: mg route: IV interval: 8 - name: gentamicin dose: 8.6 units: mg route: IV interval: 12 Note that if you wanted to get tricky, you could consider the "units" as part of the dose... - name: ampicillin dose: amount: 340 units: mg route: IV This may be a better way to do units. Alternatively, you could use the "flow" syntax form for this. - name: ampicillin dose: { amount: 340, units: mg } route: IV | - !Med | name: gentamicin | dose: 8.6 Yes, something like this will work as well, !http://yourdomain/Med. Although your application probably doesn't need to use the type feature. | "Med" here is a user-defined type, but not all items in the | "med-list" object need be of this type. For example, the user might | use "Med" for medications in general, but define specific types for | frequently used drugs... | | med-list: | - !Ampicillin | dose: 340 | route: IV | interval: 8 This is probably a bad idea for a few reasons: (a) it makes a set of equivalences, the above would be equivalent to "name: ampicillin" or something like that... right?, (b) in the query language coming up types will be a bit harder to work with than regular "simple" content, I expect types to be the 10% usage category. Its there beacuse it is needed for arbitrary serialization; but in your use case, since you have a specific application reading/writing, this isn't so much a problem. BTW, according to the XML binding proposal, the first example could be written in XML as... <arbitrarly-named-root-node> <name>pneumonia</name> <medication> <_> <name>amicillin</name> <dose>340</dose> <units>mg</units> <route>IV</route> <interval>8</interval> </_> <_> <name>gentamicin</name> <dose>8.6</dose> <units>mg</units> <route>IV</route> <interval>12</interval> </_> </medication> </arbitrarly-named-root-node> When I get time to formalize it, the above will be the canonical XML representation of the YAML data first shown above. Note that the element name _ is used for list entries... no point in giving them a name as "medication" is more than adequate. Note that this named/list thingy came from the document world rather than the data world so it doesn't quite work, and the med-list/Med pair is the uglyness that results. Even if you stick with XML, I'd change your schema to use "medication" plus "_". The XML "experts" will hate you for it, but it is legal XML and it is damn clear. You don't have to guess if it is "MedList" or "Med-list" or "Med" or "med" or "medication" or "item", the pattern is easy to remember: For the list name use the singular form of the noun and use _ for each occurance. I hope this helps! Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Donnal W. <don...@ya...> - 2002-07-16 15:52:49
|
Thank you _why and Clark. Your responses were quite helpful. [Clark C . Evans]: > [Donnal Walter]: > | Okay, I am working on understanding sequences. Can someone > | provide the YAML equivalent for the following XML: > > Ok. The primary difference between XML and YAML is that YAML > uses maps and lists, while XML uses a hybrid "named list". > Your med-list is where you want the list it seems, and thus > the "Med" name for each item in the list isn't needed. Actually, I feel that I do need the "Med" name because when I read it back, I will use it to determine the "type" of the item. If ALL items were exactly the same type, this would not be necessary, of course, but for some meds I want to be able to "specialize" the type to something like "Ampicillin", and so on. See below. BTW, YAML's use of maps and lists fits my application's information model extremely well. > [snip] > Since in YAML you don't have the named-map thingy, you > could merge "med-list" and "Med" and rename it to something > intutitive, like "medication". In general, it is good > practice to use singular words (even when you have a list) > beacuse using plurals gets complicated quickly; and in YAML > since it is clear that "medication" is a list, you don't > need the -list idiom. Granted. Maybe something like" medication: - !!General name: ampicillin dose: amount: 340 units: mg route: IV interval: 8 - !!Gentamicin name: gentamicin dose: amount: 8.6 units: mg route: IV interval: 12 > | [snip] > Note that if you wanted to get tricky, you could consider > the "units" as part of the dose... > > - name: ampicillin > dose: > amount: 340 > units: mg > route: IV Yes, I had already been thinking of something similar, and it is nice to have the idea confirmed. Thanks. > This may be a better way to do units. Alternatively, you > could use the "flow" syntax form for this. > > - name: ampicillin > dose: { amount: 340, units: mg } > route: IV I like how it reads, but I am thinking that I may not implement flow syntax, at least initially. > Yes, something like this will work as well, > !http://yourdomain/Med. > Although your application probably doesn't need to use the type > feature. > > | "Med" here is a user-defined type, but not all items in the > | "med-list" object need be of this type. For example, the user > | might use "Med" for medications in general, but define > | specific types for frequently used drugs... > | > | med-list: > | - !Ampicillin > | dose: 340 > | route: IV > | interval: 8 > > This is probably a bad idea for a few reasons: (a) it makes a set > of equivalences, the above would be equivalent to "name: > ampicillin" or something like that... right?, (b) in the query > language coming up types will be a bit harder to work with than > regular "simple" content, I expect types to be the 10% usage > category. Its there beacuse it is needed for arbitrary > serialization; but in your use case, since you have a specific > application reading/writing, this isn't so much a problem. Yes, you are right that my example of leaving out two of the attributes ('name' and 'units') was a bad idea. In my original version, all of the attributes were the same, but 'name' and 'units' were "class" not "instance" attributes of the specialty class Ampicillin. The medication example may not be the best to demonstrate what I am thinking about, but there will be many cases where I will need a simple/general type for ad hoc (unexpected) situations and special types for situations that are exected. Since my application reads what only it writes, all I need is the type name (the namespace is built-in to the list) to reconstruct the native object. > [snip] > > When I get time to formalize it, the above will be the > canonical XML representation of the YAML data first shown > above. Note that the element name _ is used for list > entries... no point in giving them a name as "medication" > is more than adequate. Note that this named/list thingy > came from the document world rather than the data world > so it doesn't quite work, and the med-list/Med pair is > the uglyness that results. Even if you stick with XML, > I'd change your schema to use "medication" plus "_". The > XML "experts" will hate you for it, but it is legal XML and > it is damn clear. You don't have to guess if it is "MedList" > or "Med-list" or "Med" or "med" or "medication" or "item", > the pattern is easy to remember: For the list name use > the singular form of the noun and use _ for each occurance. > > I hope this helps! Yes, of course! :-) It helps a lot. Perhaps I will rethink my whole approach of allowing specialized types for the lists, but part of my goal is to allow the developer to build into the application as much domain knowledge as desired. An inheritance hierarchy seems one way to do this in an elegant manner. ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com |
From: Donnal W. <don...@ya...> - 2002-07-16 16:47:20
|
[Donnal Walter] > Thank you _why and Clark. Your responses were quite helpful. > > [Clark C . Evans]: > | Since in YAML you don't have the named-map thingy, you > | could merge "med-list" and "Med" and rename it to something > | intutitive, like "medication". In general, it is good > | practice to use singular words (even when you have a list) > | beacuse using plurals gets complicated quickly; and in YAML > | since it is clear that "medication" is a list, you don't > | need the -list idiom. > > Granted. Maybe something like this: > > medication: > - !!General > name: ampicillin > dose: > amount: 340 > units: mg > route: IV > interval: 8 > - !!Gentamicin > name: gentamicin > dose: > amount: 8.6 > units: mg > route: IV > interval: 12 Another possible syntax that would probably work for me is: medication: - type: General name: ampicillin dose: amount: 340 units: mg route: IV interval: 8 - type: Gentamicin name: gentamicin dose: amount: 8.6 units: mg route: IV interval: 12 where the 'ampicillin' object is an ad hoc (unexpected) type/class and 'gentamicin' is an instance of the Gentamicin class (with built-in dosage ranges and so on). ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com |
From: Steve H. <sh...@zi...> - 2002-07-16 16:55:38
|
I wonder if it makes sense to consolidate source control for YAML projects on to the perforce server. It might facilitate code reuse, particular with test suites. For example, Why has recently mentioned the idea of perl, ruby, and python all sharing the same tests. 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. |
From: why t. l. s. <yam...@wh...> - 2002-07-16 20:26:11
|
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. 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 ] This is a basic idea, so feel free to rip it apart. I'm just trying to get the discussion rolling. 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. 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 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. 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. _why |
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.) |
From: why t. l. s. <yam...@wh...> - 2002-07-17 17:22:02
|
Steve Howell (sh...@zi...) wrote: > > 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. Yeah, definitely. The tests should be comprised of implicit sequences and mappings. I've even wondered if document parsing is a bit much for starters. I didn't add document parsing until version 0.19. Then, again I guess it's not too difficult in most languages to split the file based on the '---' and handle each test individually. We should also put a limit on the character set used in the unquoted strings. Many new parsers may not be able to handle: --- name: YAML Specification 1.0: URI Escaping I'd say that if we want to use such characters, we have to put it in a block. > 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. If we do use it, I'm going to keep with 'round trip' over 'no round trip' for these reasons: 1) New authors wouldn't have to go through and add every test they can't round trip, which is bound to be most. 2) When you get round tripping working, you get the satisfaction of adding the line into the test. ;) I'm joking. Sorry. 3) For me, round tripping is an exception. I don't plan on being able to round trip all of the tests. I would simply have to store too much parsing data in the structures returned to the user. Perhaps we could just flag tests that are intended to be round tripped. For example, Clark (in the discussion about an ID element) mentioned that anchors and aliases are not designed to be round-trip-able. The spec says: "An alias node only exists in the syntax and serial models. When converted to the generic model, an alias node becomes a second occurrence of the anchored node." So, examples with anchors and aliases shouldn't round trip. Conversely, I'd find it very interesting to see which implementations can round trip private types and domain types. I mean to see how the different implementations handle this, along with whether they can both dump and load a domain type would be quite cool. > 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. This is a very good point. I think you're right about the round trip aspect being orthogonal to the parsing. I definitely think there are implementations which could skip the round trip altogether. I'd want the tests to be useable for someone who is just writing a simple YAML parser. I think the whole idea of the round trip field is just for interest factor. Just like the 'brief' field, it's a bit of extra information that seems worthy of belonging in our central file cabinet. > > 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. Yeah, sounds good. > > 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.) Also, agreed. _why |
From: Steve H. <sh...@zi...> - 2002-07-17 17:36:49
|
----- Original Message ----- From: "why the lucky stiff" <yam...@wh...> > Steve Howell (sh...@zi...) wrote: > > We should also put a limit on the character set used in the unquoted strings. > Many new parsers may not be able to handle: > > --- > name: YAML Specification 1.0: URI Escaping > > I'd say that if we want to use such characters, we have to put it in a > block. Agreed. > If we do use it, I'm going to keep with 'round trip' over 'no round trip' for > these reasons: > > 1) New authors wouldn't have to go through and add every test they can't round > trip, which is bound to be most. Yep, that makes sense. On the other hand, you would tend to add the new tests for your language one test at a time, so you could just make the round trips pass as you add them. If they don't round trip, and you're not able to fix it immediately, or you know that there's a good reason for it not to round trip, then you can add the "no_round_trip" exception indicator. > 2) When you get round tripping working, you get the satisfaction of adding > the line into the test. ;) I'm joking. Sorry. :) > 3) For me, round tripping is an exception. I don't plan on being able to > round trip all of the tests. I would simply have to store too much parsing data > in the structures returned to the user. > I think this goes into the whole interpretation of round tripping. If by round tripping, you mean Ruby->YAML-Ruby, then I would hope you round trip most things. If by round tripping, you mean YAML->Ruby->YAML, then you're gonna round trip a lot less. Maybe we need to define the two round tripping styles: round-trip serializable -- Ruby can dump to YAML, read it right back in, data doesn't change (requirement for most applications) round-trippale YAML - Ruby can parse YAML, and if it doesn't manipulate the structure at all, then it emits the exact same YAML (very challenging to do for all YAML, but gotten for free for canonical YAML) > Perhaps we could just flag tests that are intended to be round tripped. For > example, Clark (in the discussion about an ID element) mentioned that anchors > and aliases are not designed to be round-trip-able. > > The spec says: > "An alias node only exists in the syntax and serial models. When converted to > the generic model, an alias node becomes a second occurrence of the anchored > node." > > So, examples with anchors and aliases shouldn't round trip. Conversely, I'd > find it very interesting to see which implementations can round trip private > types and domain types. I mean to see how the different implementations > handle this, along with whether they can both dump and load a domain type would > be quite cool. > Yes, aliases and domain types pose challenges even for what I call "round trip serializable." |
From: why t. l. s. <yam...@wh...> - 2002-07-17 19:09:32
|
Steve Howell (sh...@zi...) wrote: > I think this goes into the whole interpretation of round tripping. If by > round tripping, you mean Ruby->YAML-Ruby, then I would hope you round trip > most things. If by round tripping, you mean YAML->Ruby->YAML, then you're > gonna round trip a lot less. Maybe we need to define the two round tripping > styles: > > round-trip serializable -- Ruby can dump to YAML, read it right back in, data > doesn't change (requirement for most applications) > > round-trippale YAML - Ruby can parse YAML, and if it doesn't manipulate the > structure at all, then it emits the exact same YAML (very challenging to do > for all YAML, but gotten for free for canonical YAML) Yeah, right on. I was talking about your "round-trippable YAML", as that's how I have my unit tests set up. Yeah, now I can see where you're coming from. Having round-trippable YAML is likely less useful to know about, as we don't really care if it can do it perfectly, character for character. I'd say we go with round-trip serializable, test your export against your parser. The reason being: it gives a clear indication of how the emitter works for each implementation. Whereas the round-trippable YAML gives an indication of how the parser and emitter work together to keep document integrity. Which is also a useful statistic, though too much to ask for when we're just starting these tests. Now that we're on the same page, I could lean either way on the syntax for this in the test files. The 'no round trip' is sounding better all the time, as I envision that many implementations will quickly make their way to 100% compatibility. I've only been working on my implementation for three or four weeks and I feel like I'm approaching it quickly. I've also got a page up on Wiki.. http://wiki.yaml.org/yamlwiki/YamlTestingSuite ..summarizing our discussion so far. Not sure where to link it. On the FrontPage or YamlImplementations? _why |
From: Steve H. <sh...@zi...> - 2002-07-17 19:26:27
|
----- Original Message ----- From: "why the lucky stiff" <yam...@wh...> > [...] > I've also got a page up on Wiki.. > > http://wiki.yaml.org/yamlwiki/YamlTestingSuite > > ..summarizing our discussion so far. Not sure where to link it. On the > FrontPage or YamlImplementations? > I added a link from the FrontPage. |
From: why t. l. s. <yam...@wh...> - 2002-07-17 21:35:18
|
Neil Watkiss (neilw@ActiveState.com) wrote: > 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. > > No problem; email me to set up an account for you. You can also email me an > ssh public key. It's better than me emailing out your password :) > > You can ask Steve, Clark, Ingy or I instructions about Perforce any time you > want. For a primer, read all about it at http://www.perforce.com. > > Later, > Neil Ingy got me set up! The latest source is now checked into the depot under yaml/YamlForRuby. It's nice to check out the other implementations. I had no clue libyaml was so far along. Is there a public interface for anonymously checking out source from Perforce? _why |
From: Neil W. <neilw@ActiveState.com> - 2002-07-17 21:48:42
|
why the lucky stiff [17/07/02 15:43 -0600]: > Is there a public interface for anonymously checking out source from > Perforce? No. We can set it up like the publich Perl repository, which also uses Perforce. If you want to have access to the depot, you send a username and SSH public key, and your account is set up with access to Perforce. Then you log in, forwarding the appropriate ports using SSH. You can then synch your local working copy with the depot copy. Those with sufficient privileges can also submit their changes for other developers. Instructions for accessing the Perl repository can be found here: http://www.daimi.au.dk/Manuals/perl/Porting/repository.html This is also Porting/repository.pod in the Perl source distribution. Later, Neil |
From: Rolf V. <rol...@he...> - 2002-07-18 06:30:58
|
Neil Watkiss wrote: > why the lucky stiff [17/07/02 15:43 -0600]: > >>Is there a public interface for anonymously checking out source from >>Perforce? > > > No. We can set it up like the publich Perl repository, which also uses Using the SourceForge CVS at sf.net/projects/yaml is also a possibility. It has web visibility and can be integrated well with the yaml.org website. Of course, that is for those who tolerate CVS and don't want to setup their own project at SF (which is also really easy). Cheers. Rolf. |
From: Steve H. <sh...@zi...> - 2002-07-18 15:16:54
|
----- Original Message ----- From: "Neil Watkiss" <neilw@ActiveState.com> > why the lucky stiff [17/07/02 15:43 -0600]: > > Is there a public interface for anonymously checking out source from > > Perforce? > > No. We can set it up like the publich Perl repository, which also uses > Perforce. If you want to have access to the depot, you send a username and > SSH public key, and your account is set up with access to Perforce. Then you > log in, forwarding the appropriate ports using SSH. You can then synch your > local working copy with the depot copy. Those with sufficient privileges can > also submit their changes for other developers. > > Instructions for accessing the Perl repository can be found here: > > http://www.daimi.au.dk/Manuals/perl/Porting/repository.html > > This is also Porting/repository.pod in the Perl source distribution. > It sounds like this approach would require folks to go through quite a bit of hassle just to browse the sources, including having to wait for Neil to respond to an email. Correct me if I'm wrong. It might be worth having some sort of public area where folks can download YAML tarballs. I would think we would want to segment the tarballs a little bit--maybe have a tarball for each implementation. We could let the authors decide when they want to make tarballs, and then we'd need a common place to put them, I'd think. Any thoughts on this? |
From: why t. l. s. <yam...@wh...> - 2002-07-18 16:19:32
|
Steve Howell (sh...@zi...) wrote: > ----- Original Message ----- > From: "Neil Watkiss" <neilw@ActiveState.com> > > No. We can set it up like the publich Perl repository, which also uses > > Perforce. If you want to have access to the depot, you send a username and > > SSH public key, and your account is set up with access to Perforce. Then > > you log in, forwarding the appropriate ports using SSH. You can then synch your > > local working copy with the depot copy. Those with sufficient privileges > > can also submit their changes for other developers. > > > > Instructions for accessing the Perl repository can be found here: > > > > http://www.daimi.au.dk/Manuals/perl/Porting/repository.html > > > > This is also Porting/repository.pod in the Perl source distribution. > > > > It sounds like this approach would require folks to go through quite a bit of > hassle just to browse the sources, including having to wait for Neil to > respond to an email. Correct me if I'm wrong. > > It might be worth having some sort of public area where folks can download > YAML tarballs. I would think we would want to segment the tarballs a little > bit--maybe have a tarball for each implementation. We could let the authors > decide when they want to make tarballs, and then we'd need a common place to > put them, I'd think. > > Any thoughts on this? I was originally using CVS, so I wrote a little script to update both the Perforce and CVS repositories. As long as I don't change my directory setup much, I should be fine. I will consider the Perforce server my main repository and if it becomes too much trouble to keep CVS in sync, then I'll likely drop it for a daily tarball. _why |