commit | 882174d8e7b7f6ed8216ee6b839dc6c15e0496c3 | [log] [tgz] |
---|---|---|
author | Václav Kubernát <kubernat@cesnet.cz> | Wed Mar 25 21:31:46 2020 +0100 |
committer | Václav Kubernát <kubernat@cesnet.cz> | Thu Mar 26 13:14:55 2020 +0100 |
tree | 8f37e7ab109e4daf9467016818bcb4cf94ffdfc6 | |
parent | 9ae8cc43710a9b4c67b91722b937e87725dda7cb [diff] |
Rework leaf_data The previous implementation of leaf_data used a grammar, where all of the leaf_data_* parsers were tried one after another and then in each of their on_success handlers, the type of leaf was checked against the attribute of the parser. This leads to two problems: 1) Ambiguity. Example: 1 can be parsed as any of the integral parsers. This can lead to a problems inside the parser (ambiguity is the reason the parser doesn't work in newer Boost versions). 2) Order of the alternatives. Because the alternative parser can only be defined at compile-time, there is no way to change the order of the alternatives. Right now, this isn't a problem, since a leaf can only have one type, but I'm going to need a way to reorder the parsers to implement unions. The new leaf_data parser is implemented by creating an entirely new type of parser. A parser (as far as Spirit is concerned) is a class that inherits from x3::parser and implements parse(), which returns whether the parser passed or not. In this method I have access to ParserContext. That means I can dynamically choose which parser is going to be used according to the return value of Schema::leafType. Another advantage is that now I don't need on_success handlers for basic types and I can use the elemental parsers directly. Types like enum need extra validation, so they keep their handlers. If I ever need extra validation on more types, I can easily add some of the handlers back. I also moved the createSetSuggestions handler to leaf_data.hpp since it's directly connected to leaf_data (even the rule is defined in this file). Side note: the parser could have been implemented by using an implementation of the lazy parser from here https://github.com/boostorg/spirit/issues/530. However, a Spirit developer suggested I just inherit from x3::parser and use that. Side note 2: all of the completion creators can be implemented in a similar way, and that brings some advantages too. Side note 3: the parser for paths can be rewritten in a similar way to this, but right now it's not needed. When Boost gets updated, the rewrite will happen then. Change-Id: Ia29c1895833b811a45873f8490da9c64fa4742eb
This program provides an interactive console for working with YANG data. It can connect to NETCONF servers, and also talk to sysrepo locally.
For building, one needs:
Use an exact commit of any dependencies as specified in submodules/dependencies/*
.
The build process uses CMake. A quick-and-dirty build with no fancy options can be as simple as mkdir build && cd build && cmake .. && make && make install
.
Issue reporting and feature requests are welcome via Taiga.io.
We are using Gerrit for patch submission, code review and Continuous Integration (CI). Development roadmap and planning happens over Taiga.io.
Copyright © CESNET, https://www.cesnet.cz/ . Portions copyright © Faculty of Information Technology, Czech Technical University in Prague, https://fit.cvut.cz/ . Most of the code was written by Václav Kubernát (CESNET, formerly FIT ČVUT) and Jan Kundrát (CESNET). The project is distributed under the terms of the Apache 2.0 license.