From: Brian I. <in...@tt...> - 2001-10-29 04:47:53
|
Check out this site: www.fatport.com:8001 This is the actual data from my fledgling YAML testing system for YAML.pm. Feel free to add submissions. I need: submission: - description - yaml - Perl code I can generate the Data::Dumper output from the Perl code if it is properly formatted. This site will move soon. Cheers, Brian |
From: Brian I. <in...@tt...> - 2001-11-09 01:49:51
|
On 07/11/01 09:27 -0500, Clark C . Evans wrote: > Ok. Let's call our list construct a "sequence". Interesting. My friend Neil Watkiss suggested the same word yesterday. He knows Perl and Python inside out BTW. > > >From examination of your construct below, I think > "dunno" in Python could be the fabled tuple. The My other friend Neil Kandalgoankar said they are similar but not the same. To me, a Perl list is not a structure at all. It's not something we need to serialize in YAML. It's just a way of saying: "This bunch of things". My concatenation needs stem from this: I simply want to put any number of YAML nodes into a single document. They should actually be autonomous. References in one should be invalid in another. I don't want to wrap them with another data structure. And I want to be able to easily concatenate any group of YAML documents into a single document. And then be able to easily split them apart again. It seems that a separator-based syntax is the way to do it. If we can't do this, then let's just say: "One node per file. You can try to concatenate list node files, but you won't be able to split them out again". --- As for tuples, I just want to keep them as is. Python data structures serialized like this: tuple: !tuple - 1 - two Paul Prescod suggested a really cool way to round trip them through Perl. Instead of wrapping them with a hash which would make them hard to use, we can just bless an array with the string 'org.yaml.tuple'. That way we can use it as a normal Perl array. Cool huh. This actually has very big implications for other things. Yay. > | a scalar > > Hmm. Do we require scalars to be indented > just for good measure? > > a scalar I'd really like to be able to not indent single line scalars. I think we can avoid it. Remind me again why we can't. On 07/11/01 10:28 -0500, Clark C . Evans wrote: > A. Since list is used by Perl and Python to > mean two different things, we adopt "tuple" > from python and "array" from Perl. Let us > call these classes org.yaml.array (!array) > and org.yaml.tuple (!tuple). OK. For those specific structures. Like, empty: !array > > B. We call our sequential yaml construct (-) > a seq(uence). And we call our functional > construct (:) a map. Thus the word "list" > is no longer part of the YAML vocabulary > to reduce confusion. OK. I like the abbrev. > > C. The starting production is map xor seq. > A YAML text may not begin with a scalar, > however, a YAML text can begin with a > one-tuple... which is damn close. Don't like. > > D. The default class for a top level sequence > is a !tuple and the default class for > secondary and further indented sequences > is an !array. Huh? no thanks. tuples should just be rare python things. > E. Please note another whitespace option as motivated > by Python [3]. This solution allows mixing > of TAB and increments of 4 SPACES as follows: > 1) On parse, a tab is replaced (from left to right) > by four or eight spaces such that the total > number of characters up to and including the > replacement is a multiple of eight. > > 2) Each sequence of four spaces becomes an > indentation token. > > In this way, one can think of a TAB as a > double indent. On the down side, one must > either use all spaces or tabs and spaces. > One cannot exclusively use TABS with this > solution. More thought, no? This is one of the solutions I was going to propose, based on my talk with Paul. Another one that I'd really like to consider in full is using a single space indent. Please give it some serious thought before screaming bloody murder. On 08/11/01 11:15 +0200, Oren Ben-Kiki wrote: > As a part-time Perl programmer I've never noticed the difference between > list and array, and I *did* read the Camel book cover-to-cover. For example, > how does one declare a list variable? List isn't a type, it's a context. Almost every operation in Perl can have either a list or scalar context. I just want to be able to put more than one autonomous thingy into a YAML file. It's *not* the same as a YAML list. A YAML list (or whatever) *is* a type and that type gets parsed into a Perl or Python array. > About attaching descriptors to the top-level. That's covered in today's > spec: > > !typed > - top-level list > > !typed > top-level : map > > !typed \ > top-level scalar > > !typed top-level map key : with value > > No need for magical comments. Good. > Separators: I'm warming up towards the separator syntax. > > - It allows safe splitting: > > Note Splitting != Concatenation. Separators make *splitting* safe, in the > sense that it is always safe to textually cut a YAML document surrounded by > separators and feed it into a YAML system on its own. This is *not* true for > a top-level list entry, because it may contain references to nodes in > previous list entries. *Concatenating* is safe for both - you can always > attach another top-level list entry at the end, same as you can attach > another separated document. > > - It allows for concatenation even if there are top-level descriptors. > > --- !type1 > ... > --- !type2 > ... > --- > > - It allows us to *NOT* indent top level scalars: > > --- \ > Unindented top-level scalar, hurrah! > --- > > In fact I'd make the separator mandatory if there are top-level descriptors > or indicators (there's your place to add a YAML version if we ever need > one). I rather like this and I think that so would Brian. The beauty of it > that the above is almost exactly covered by the current spec. YAY! > > At any rate, I think the only valid options we have are tabs only or 4 > spaces only. Anything else is a mess. I don't care which one we choose, as > along as we inhume this vampire (chop off its head, put some dirt in its > moth, a stake through its heart, and bury it under a crossroad). Interestingly, Paul Prescod ( a huge Python bigot ) doesn't really even like indenting. He didn't really have any good suggesstions for us on that front. > but it would actually be three (A possibly unrelated fact is that really old > testament books were written without white space, which lends some credit to > Brian's opinion of where white space comes from :-) LOL > In short, I'm for keeping things as they are in the current draft. It is > better then we give it credit for. With minor changes: > > - indentation (maybe), > - changing 'list' to 'sequence' (and *maybe* adding list/tuple), > - going through the production to verify the above top-level > descriptors/indicators idea works, I sencond that for the most part. I'm still reading, but I like what I see. On 08/11/01 17:03 +0200, Oren Ben-Kiki wrote: > Or, for that matter, a '---' :-) Also note that using a '---' you wouldn't > need to indent the scalar! That's what I've been saying. I would still indent multilines so that long keys would not require lookahead. > Back references are not allowed to go across '---' for safe splitting. I completely agree. If they are important then wrap them in a sequence. On 08/11/01 10:24 -0500, Clark C . Evans wrote: > Ok. So a YAML document is a series of fragments. > And each fragment is a map, seq, or scalar? This > is a change to the information model... I'll go > with it if Brian agrees. I think we're coming together now. On 08/11/01 18:24 +0200, Oren Ben-Kiki wrote: > I prefer the current draft wording. A YAML stream is a series of YAML > documents, each document being a map, sequence or scalar. This leaves the > information model untouched. > > > | I'll go > > | with it if Brian agrees. Perfect. I'm not done reading the arguments, but I gotta run to make my call with clark. Cheers, Brian |
From: Mark C. <xs...@uk...> - 2003-08-16 10:55:10
|
>> What would be nice if someone would volunteer to produce binary ... >Have you tried suggestions from any of the following pages? ... Thanks for the tip. I'll give them a go, and report back if I can get them to work. It may be some time, though. _____________________________________________________________ Sign up for your very own email address from UKmail.com To-day !! |
From: Plamena D. <pl...@ya...> - 2009-01-17 19:39:17
|
Hello! I have a problem installing modules in Perl and I need help. First I downloaded and installed Perl on my computer and then I wanted to download some modules from http://www.cpan.org but I encountered a problem installing a module because as soon as I wrote in the dos prompt “perl Makefile.pl” I got a message error that yaml was not installed. But I do not know how to install yaml. Can you help me how to do it, please? Sincerely yours, Plamena |
From: Burt H. <Bur...@mi...> - 2009-02-05 22:45:29
|
I'd like to verify something. It came up testing my parser, and seems counter intuitive. Should --- ? a : b ... be a single mapping { a : b } nested mappings with an empty outer value { { a : b } : } ? http://www.yaml.org/ypaste seems to come up with the later. |
From: Ingy d. N. <in...@in...> - 2009-02-06 23:55:40
|
libyaml also produces the latter. I always trust libyaml :) On Thu, Feb 5, 2009 at 10:45 PM, Burt Harris <Bur...@mi...>wrote: > I'd like to verify something. It came up testing my parser, and seems > counter intuitive. Should > > > > --- > > ? a : b > > … > > > > be a single mapping { a : b } nested mappings with an empty outer value { > { a : b } : } ? > > > > http://www.yaml.org/ypaste seems to come up with the later. > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Kirill S. <xi...@ga...> - 2009-02-23 17:03:00
|
Hi Burt, > I’d like to verify something. It came up testing my parser, and seems > counter intuitive. Should > > --- > > ? a : b > > … > > > > be a single mapping { a : b } nested mappings with an empty outer value > { { a : b } : } ? The latter is valid. If you need the former, use ? a : b Also consider ? a: b c: d : e: f g: h It should produce {{a: b, c: d}: {e: f, g: h}} Thanks, Kirill |
From: ali m. <ali...@ya...> - 2012-04-02 13:20:38
|
<a href="http://sistemaimmobiliare.net/wp-content/uploads/castel_mella_via_paganini/02efpk.html"> http://sistemaimmobiliare.net/wp-content/uploads/castel_mella_via_paganini/02efpk.html</a> |
From: ali m. <ali...@ya...> - 2012-04-06 12:35:40
|
<a href="http://jenhocko.com/weblog.old/wp-content/plugins/podpress/optional_files/rmngl.html"> http://jenhocko.com/weblog.old/wp-content/plugins/podpress/optional_files/rmngl.html</a> |
From: ali m. <ali...@ya...> - 2012-04-10 22:23:31
|
http://tinewahl.com/images/fidmnrl.html?tuj=q.jpeg&cv=ofd.htm&fry=bomf |
From: ali m. <ali...@ya...> - 2012-04-11 09:31:50
|
http://wedding.jennandbryce.com/packages/theme_natural_essence/trud.php |
From: Peter M. <pet...@gm...> - 2012-04-12 02:06:36
|
On Wed, Apr 11, 2012 at 7:31 PM, ali mousa <ali...@ya...> wrote: > http://wedding.jennandbryce.com/packages/theme_natural_essence/trud.php > Could someone have Ali the asshole kicked off the list with extreme prejudice? Best regards, Peter -- Email: pet...@gm... WWW: http://www.pkmurphy.com.au/ |
From: dizzy c. <diz...@gm...> - 2012-08-16 00:06:11
|
From: Agnes M. <agn...@gm...> - 2019-01-21 09:06:34
|
From: Agnes M. <agn...@gm...> - 2019-01-21 09:27:23
|
From: Fred L. <fre...@gm...> - 2019-03-22 20:26:58
|
From: Masoud S. <mas...@gm...> - 2021-02-15 11:34:15
|
From: Đức T. P. <duc...@gm...> - 2021-02-20 11:54:11
|
From: adamlaska <ada...@gm...> - 2021-04-08 18:26:26
|
From: Reading O. <qa...@gm...> - 2021-12-19 18:03:55
|
From: yuqieang c. <yuq...@gm...> - 2022-04-03 00:06:26
|
-- 发自移动版 Gmail |
From: Saad H. <yas...@gm...> - 2022-10-09 21:24:17
|
saad hussien |
From: Saad H. <yas...@gm...> - 2022-10-20 20:28:08
|
saad hussien |
From: Saad H. <yas...@gm...> - 2022-12-27 03:45:18
|
saad hussien |
From: Melvin O. <mel...@gm...> - 2023-02-26 18:11:56
|