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

[Free Ekanayaka]

Hi Raphaël,

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

[...]

  >>I hope I'm understanding it write..

  RP> Yes this is it. I don't understand why the error in on tree concatenation
  RP> instead of union.put. I guess the tree concatenation is checked before put,
  RP> and raised an error in this case.

That was a bit confusing indeed.

  >>Another question, what does the term "split" in the message
  >>
  >>'#comment/' can be split into
  >>
  >>exactly mean?

  RP> I tend to think of 'split' as 'parsed' in this case, as in '#comment/' can
  RP> be parsed in two different ways. I think the term 'split' is initially
  RP> mostly used for parsing, which makes sense since the lens 'splits' the input
  RP> string into nodes and values.

Oh I see, it makes sense :)

  RP> I guess we could get to something like

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

  RP> let iface   = [ type "iface" . entry "family" . entry "method" .
  RP>                   ( eol | ((eol . empty*)? . comment) ) .
  RP>                   empty* .
  RP>                   ( option . (option | comment | empty)* )? ]

I works, you're a wizard! The lense is now acceptable, I'm sure there
are some corner cases which are not yet covered, but it should be fine
for most real-life cases.

  RP> This is getting ugly... and will probably require quite a few comments in
  RP> the lens for further readers ;)

Definitely. I was thinking to the possibility of nesting nodes of
trailing comments inside a values/options nodes, so that:

auto eth0 # Whatever

would generate:

{ "auto"
   { "1" = "eth0
       { "#comment" = "Whatever } } }

while:

auto eth0
# Whatever

would lead to:

{ "auto"
   { "1" = "eth0 } }
{ "#comment" = "Whatever }

I have the feeling that it would simplifiy things, but I'm not
sure.

  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.
  >>

  RP> Mapping comments can be tricky. Commenting/Uncommenting values is hard. I
  RP> suggest you read [0] and the thread on [1]. I've been thinking about
  RP> commenting/uncommenting for quite some time now. aug_mv was introduced in
  RP> the API partly for this purpose, and we yet have to code the
  RP> /augeas/tree/last_created node [2], and a non-disjoint union operation to
  RP> begin implementing this in real-life lenses.

  RP> * [0] should tell you why we needed aug_mv, since most other options to map
  RP> commented values are either error prone for the user, or too tricky to
  RP> implement.
  RP> * The /augeas/tree/last_created node is required for the insert part of the
  RP> commenting action. As you can see in [3], it is required to insert a node
  RP> before moving the old node in order to comment/uncomment, otherwise the
  RP> order of nodes can be modified. "ins" doesn't return the path to the newly
  RP> created node, hence the need for /augeas/tree/last_created.
  RP> * Finally, the non-disjoint operation is not absolutly necessary but would
  RP> be highly useful. It would also be useful for your current code on
  RP> interfaces.aug. This operation ( "||" ) would allow for a union of lenses
  RP> that can conflict, with a priority on one of the lenses. In 'comment |
  RP> entry', you have to make sure that 'entry' cannot conflict with 'comment',
  RP> but in 'comment || entry', both could match the same regexp, and comment
  RP> would then win the game. I guess the "simple" example from [1] is enough to
  RP> show the complexity of writing disjoint commented values lenses even for
  RP> very simple cases.

  RP> I'm looking forward to being able to comment/uncomment values in augeas
  RP> though, and I find that this is probably one of the most exciting features
  RP> to come!

Yes, that's very interesting ideed. I hope it can be done in a
reliable way without compromsing the roboustness of the program.

Ciao!

Free