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

Fri Aug 22 09:34:55 UTC 2008

On Fri, Aug 22, 2008 at 10:56 AM, Free Ekanayaka <free at 64studio.com> wrote:

>
>  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 :)

You're definitely not!

> Maybe some documentation on the
> web site would also help, I think your explanation below would be a
> good starting point.

http://augeas.net/page/Creating_a_lens_step_by_step 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.

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

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.

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

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.

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

I guess we could get to something like

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

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

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

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

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.

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

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!

Ciao

Raphaël

[0] http://augeas.net/page/Dealing_with_comments
[1] https://www.redhat.com/archives/augeas-devel/2008-July/msg00162.html
[2] https://www.redhat.com/archives/augeas-devel/2008-August/msg00002.html
[3] https://www.redhat.com/archives/augeas-devel/2008-July/msg00166.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20080822/020518ae/attachment.htm>