<div dir="ltr">On Fri, Aug 22, 2008 at 10:56 AM, Free Ekanayaka <span dir="ltr"><<a href="mailto:free@64studio.com">free@64studio.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
  RP> Yes, lens debugging messages are quite hard to understand. I banged my head<br>
  RP> with them too, and I think they are definitely something that could be<br>
  RP> improved.<br>
<br>
Oh, nice to hear that I'm not alone :)</blockquote><div><br>You're definitely not!<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Maybe some documentation on the<br>
web site would also help, I think your explanation below would be a<br>
good starting point.</blockquote><div><br><a href="http://augeas.net/page/Creating_a_lens_step_by_step">http://augeas.net/page/Creating_a_lens_step_by_step</a> has a few explanations already, but I agree that a whole page on debugging could help. I'm only beginning to understand all this myself.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So if understand correctly this is a problem of the "put" direction,<br>

rather than of the "get" one. I was reasoning only in terms of the<br>
"get" direction, and I didn't see why<br>
<br>
mapping # whatever<br>
<br>
mapping<br>
    # whatever<br>
<br>
should be ambiguous, because if we define mapping like:<br>
<div class="Ih2E3d"><br>
let mapping = [ type "mapping" . (comment|eol) . (option|comment|empty)* ]<br>
<br>
</div>I guess the the first configuration can be matched only by<br>
<br>
type "mapping" . comment<br>
<br>
and the second only by<br>
<br>
type "mapping" . eol . comment<br>
<br>
and I don't see any other possibility when parsing in the "get"<br>
direction.<br>
<br>
On the other hand now I see that in the "put" direction there is no<br>
way to decide how to write:<br>
<br>
{ "mapping"<br>
    { "#comment" = "whatever" } }<br>
<br>
I hope I'm understanding it write..</blockquote><div><br>Yes this is it. I don't understand why the error in on tree concatenation instead of union.put. I guess the tree concatenation is checked before put, and raised an error in this case.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Another question, what does the term "split" in the message<br>
<div class="Ih2E3d"><br>
 '#comment/' can be split into<br>
<br>
</div>exactly mean?</blockquote><div><br><br>I tend to think of 'split' as 'parsed' in this case, as in '#comment/' can be parsed in two different ways. I think the term 'split' is initially mostly used for parsing, which makes sense since the lens 'splits' the input string into nodes and values.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> RP> This assumes that there is at least one mandatory option (not sure this is<br>

  RP> the case).<br>
<br>
Yes, this is the case for the mapping stanza, which requires at least<br>
the "script" option, and the solution you suggest works perfectly in<br>
that case thanks.<br>
<br>
Unfortunately in the iface stanza options are not mandatory, and you<br>
can have:<br>
<br>
iface eth0 inet dhcp<br>
<br>
and<br>
<br>
iface eth0 inet static<br>
<div class="Ih2E3d">      address <a href="http://192.168.1.1" target="_blank">192.168.1.1</a><br>
<br>
</div>I'm now thinking on how to solve this.<br>
</blockquote><div><br>I guess we could get to something like<br><br><div style="margin-left: 40px;">let mapping = [ type "mapping" .<br>                     ( eol | ((eol . empty*)? . comment) ) .<br>
                      empty* .<br>                      option . <br>                      (option|comment|empty)* ]<br></div><br><div style="margin-left: 40px;">let iface   = [ type "iface" . entry "family" . entry "method" .<br>
                  ( eol | ((eol . empty*)? . comment) ) . <br>                  empty* .<br>                  ( option . (option | comment | empty)* )? ]<br></div><br><br>This is getting ugly... and will probably require quite a few comments in the lens for further readers ;)<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">RP> Another option would be to give up on comments and ignore them altogether for this<br>

  RP> lens (but I really think comments in trees are a nice addition :) ).<br>
<br>
Yes I do also agree that having comments is nice, and in real-life I<br>
think that you would sometime want to uncomment some entries, or<br>
insert some entries after certain comments.<br>
</blockquote><div><br><br>Mapping comments can be tricky. Commenting/Uncommenting values is hard. I suggest you read [0] and the thread on [1]. I've been thinking about commenting/uncommenting for quite some time now. aug_mv was introduced in the API partly for this purpose, and we yet have to code the /augeas/tree/last_created node [2], and a non-disjoint union operation to begin implementing this in real-life lenses.<br>
<br>* [0] should tell you why we needed aug_mv, since most other options to map commented values are either error prone for the user, or too tricky to implement.<br>* The /augeas/tree/last_created node is required for the insert part of the commenting action. As you can see in [3], it is required to insert a node before moving the old node in order to comment/uncomment, otherwise the order of nodes can be modified. "ins" doesn't return the path to the newly created node, hence the need for /augeas/tree/last_created.<br>
* Finally, the non-disjoint operation is not absolutly necessary but would be highly useful. It would also be useful for your current code on interfaces.aug. This operation ( "||" ) would allow for a union of lenses that can conflict, with a priority on one of the lenses. In 'comment | entry', you have to make sure that 'entry' cannot conflict with 'comment', but in 'comment || entry', both could match the same regexp, and comment would then win the game. I guess the "simple" example from [1] is enough to show the complexity of writing disjoint commented values lenses even for very simple cases.<br>
<br><br>I'm looking forward to being able to comment/uncomment values in augeas though, and I find that this is probably one of the most exciting features to come!<br><br><br>Ciao<br><br><br>Raphaël<br><br><br><br>[0] <a href="http://augeas.net/page/Dealing_with_comments">http://augeas.net/page/Dealing_with_comments</a><br>
[1] <a href="https://www.redhat.com/archives/augeas-devel/2008-July/msg00162.html">https://www.redhat.com/archives/augeas-devel/2008-July/msg00162.html</a><br>[2] <a href="https://www.redhat.com/archives/augeas-devel/2008-August/msg00002.html">https://www.redhat.com/archives/augeas-devel/2008-August/msg00002.html</a><br>
[3] <a href="https://www.redhat.com/archives/augeas-devel/2008-July/msg00166.html">https://www.redhat.com/archives/augeas-devel/2008-July/msg00166.html</a><br><br></div></div><br></div>