[augeas-devel] Re: [Interfaces] Draft lense

[Free Ekanayaka]

Hi Raphaël,

|--==> On Fri, 22 Aug 2008 08:55:29 +0200, "Raphaël Pinson" <raphink at gmail.com> said:

[...]

  >>I'm getting another error:
  >>
  >>lenses/interfaces.aug:30.3-.71:Failed to compile mapping
  >>lenses/interfaces.aug:30.19-.69:exception: ambiguous tree concatenation
  >>'#comment/' can be split into
  >>'|=|#comment/'
  >>
  >>and
  >>'#comment/|=|'
  >>
  >>First lens: lenses/interfaces.aug:30.19-.49
  >>Second lens: lenses/interfaces.aug:30.52-.69
  >>
  >>and I can't figure out why.
  >>

  RP> Yes, lens debugging messages are quite hard to understand. I banged my head
  RP> with them too, and I think they are definitely something that could be
  RP> improved.

Oh, nice to hear that I'm not alone :) Maybe some documentation on the
web site would also help, I think your explanation below would be a
good starting point.

  RP> I'm going to try and explain what this means.

  >>
  >>Do the messages "ambiguous tree concatenation" and "ambiguous
  >>concatenation" actually differ?

  RP> In this case, the ambiguity is in the tree concatenation. The problem is not
  RP> met when parsing the input, but when generating the tree. "|=|" is the
  RP> position of the parser when the error is met.

  RP> The error says that the lens at interfaces.aug:30-3-.71 failed to compile
  RP> (i.e. line 30, position 3 to 71), which is the "mapping" lens. This lens is
  RP> defined as

  RP> let mapping = [ type "mapping" . (comment|eol) . (option|comment|empty)* ]

  RP> Now augeas says that in this lens, a tree with a '#comment/' node (the /
  RP> shows that we're talking about the tree, not about parsing) can be split
  RP> either before '#comment' ('|=|#comment/') or after ('#comment/|=|'). Let's
  RP> see... what is a '#comment/' node in the "mapping" lens?

  RP> { "mapping"
  RP>    { "comment" = "whatever" } }

  RP> This is a comment in a mapping node. What would this look like in the
  RP> conffile?

  RP> mapping # whatever

  RP> or maybe

  RP> mapping
  RP>     # whatever

  RP> Both these possiblity will lead to the same tree, which means that the tree
  RP> is not enough to determine how to create the conffile.

So if understand correctly this is a problem of the "put" direction,
rather than of the "get" one. I was reasoning only in terms of the
"get" direction, and I didn't see why 

mapping # whatever

mapping
    # whatever

should be ambiguous, because if we define mapping like: 

let mapping = [ type "mapping" . (comment|eol) . (option|comment|empty)* ]

I guess the the first configuration can be matched only by

type "mapping" . comment

and the second only by

type "mapping" . eol . comment

and I don't see any other possibility when parsing in the "get"
direction.

On the other hand now I see that in the "put" direction there is no
way to decide how to write:

{ "mapping"
    { "#comment" = "whatever" } }

I hope I'm understanding it write..

Another question, what does the term "split" in the message 

 '#comment/' can be split into

exactly mean?

  RP> I honestly had not
  RP> thought of this conflict when I suggested there could be comments right
  RP> after "mapping" or "iface" headers. I'm guessing this is one of the reasons
  RP> why David first chose to ignore comments: since the "official" parser is
  RP> (likely to be) imperative, it removes comments, empty lines and backslashes
  RP> before even looking at what's in the file, while we have to consider all
  RP> these in the regexp we write.

  RP> I don't really see how to easily solve this problem, since both positions
  RP> for the comment are possible (right after "mapping", or on the next line).
  RP> Quite obviously, the problem only appears if the first line met after
  RP> "mapping" is a comment. So... we could try something like this (I have no
  RP> idea if this will work properly):

  RP> let mapping = [ type "mapping" .
  RP>                      ( (eol . empty*) | ((eol . empty*)? . comment) ) .
  RP>                      option .
  RP>                      (option|comment|empty)* ]

  RP> This assumes that there is at least one mandatory option (not sure this is
  RP> the case).

Yes, this is the case for the mapping stanza, which requires at least
the "script" option, and the solution you suggest works perfectly in
that case thanks.

Unfortunately in the iface stanza options are not mandatory, and you
can have:

iface eth0 inet dhcp

and

iface eth0 inet static
      address 192.168.1.1

I'm now thinking on how to solve this.

  RP> Again, I have not tested and cannot garantee that it will work.

It did! :)

  RP> Another option would be to give up on comments and ignore them altogether for this
  RP> lens (but I really think comments in trees are a nice addition :) ).

Yes I do also agree that having comments is nice, and in real-life I
think that you would sometime want to uncomment some entries, or
insert some entries after certain comments.

Ciao!

Free