splitted source (decl, def) gives compile errors byy use for test suite

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

splitted source (decl, def) gives compile errors byy use for test suite

Olaf Peter
Hello,

I run into a compiler error :

test/grammar_api.cpp: In function 'const string_literal_type&
string_literal()':
test/grammar_api.cpp:1291:9: error: 'string_literal' is not a member of
'parser'
   return parser::string_literal;
          ^~~~~~

using spirit x3 with these project organization:

* include/my/grammar.hpp:
----8<----
namespace parser {
         // Parser Rule IDs
         struct string_literal_class;
         ...
         // Parser Rule Types
         typedef x3::rule<string_literal_class> string_literal_type;
}
----8<----

* include/my/grammar_def.hpp:
----8<----
#include "my/grammar.hpp"
namespace parser {
         // Parser Declarations
         string_literal_type const string_literal { "string_literal" };
         // Parser Definition
         auto const string_literal_def =
         '"' > *graph > '"'
             ;
         // Definition
         BOOST_SPIRIT_DEFINE(string_literal)
}
----8<----

* include/my/config.hpp:
----8<----
namespace parser {
         typedef std::string::const_iterator iterator_type;
         typedef x3::unused_type context_type;
}
----8<----

* src/grammar.cpp:
----8<----
#include <eda/vhdl93/grammar_def.hpp>
#include <eda/vhdl93/parser_config.hpp>
namespace parser {
         BOOST_SPIRIT_INSTANTIATE(string_literal, iterator_type,
context_type);
}
----8<----

* test/grammar_api.h:
----8<----
#include "my/grammar.hpp"
// Grammar Test Bench API Definition
namespace parser {
         BOOST_SPIRIT_DECLARE(string_literal_type);
}
parser::string_literal_type const& string_literal();
----8<----

* test/grammar_api.cpp
----8<----
// Grammar Test Bench API Definition
#include "grammar_api.hpp"
parser::string_literal_type const& string_literal() {
     return parser::string_literal;
}
----8<----

* test/main.cpp
----8<----
// using the string_literal() parser, not yet here
----8<----


The idea is not to expose all parsers into the client code, but make
them exposed to the tests; inspired by test driven development.

How to organize it correct and avoid multiple instances? The grammar.hpp
self is missing the top/entry rule, e.g. program, since I start with
smaller production rules (bottom up design)

To fix the compiler error I have to include test/grammar_api.h in
grammar_def.hpp. I guess these increases compile time later on and
obviously shall be avoided.


Thanks,

Olaf



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: splitted source (decl, def) gives compile errors byy use for test suite

tomkulaga

I've had success using the method used in the calc examples:

https://github.com/boostorg/spirit/tree/develop/example/x3/calc/calc7

Have a
String_literal.hpp
String_literal_def.hpp
String_literal.cpp


On Thu., 2 Mar. 2017, 6:59 am Olaf Peter, <[hidden email]> wrote:
Hello,

I run into a compiler error :

test/grammar_api.cpp: In function 'const string_literal_type&
string_literal()':
test/grammar_api.cpp:1291:9: error: 'string_literal' is not a member of
'parser'
   return parser::string_literal;
          ^~~~~~

using spirit x3 with these project organization:

* include/my/grammar.hpp:
----8<----
namespace parser {
         // Parser Rule IDs
         struct string_literal_class;
         ...
         // Parser Rule Types
         typedef x3::rule<string_literal_class> string_literal_type;
}
----8<----

* include/my/grammar_def.hpp:
----8<----
#include "my/grammar.hpp"
namespace parser {
         // Parser Declarations
         string_literal_type const string_literal { "string_literal" };
         // Parser Definition
         auto const string_literal_def =
         '"' > *graph > '"'
             ;
         // Definition
         BOOST_SPIRIT_DEFINE(string_literal)
}
----8<----

* include/my/config.hpp:
----8<----
namespace parser {
         typedef std::string::const_iterator iterator_type;
         typedef x3::unused_type context_type;
}
----8<----

* src/grammar.cpp:
----8<----
#include <eda/vhdl93/grammar_def.hpp>
#include <eda/vhdl93/parser_config.hpp>
namespace parser {
         BOOST_SPIRIT_INSTANTIATE(string_literal, iterator_type,
context_type);
}
----8<----

* test/grammar_api.h:
----8<----
#include "my/grammar.hpp"
// Grammar Test Bench API Definition
namespace parser {
         BOOST_SPIRIT_DECLARE(string_literal_type);
}
parser::string_literal_type const& string_literal();
----8<----

* test/grammar_api.cpp
----8<----
// Grammar Test Bench API Definition
#include "grammar_api.hpp"
parser::string_literal_type const& string_literal() {
     return parser::string_literal;
}
----8<----

* test/main.cpp
----8<----
// using the string_literal() parser, not yet here
----8<----


The idea is not to expose all parsers into the client code, but make
them exposed to the tests; inspired by test driven development.

How to organize it correct and avoid multiple instances? The grammar.hpp
self is missing the top/entry rule, e.g. program, since I start with
smaller production rules (bottom up design)

To fix the compiler error I have to include test/grammar_api.h in
grammar_def.hpp. I guess these increases compile time later on and
obviously shall be avoided.


Thanks,

Olaf



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: splitted source (decl, def) gives compile errors byy use for test suite

Olaf Peter
Hello Tom,

> I've had success using the method used in the calc examples:
>
> https://github.com/boostorg/spirit/tree/develop/example/x3/calc/calc7
>
> Have a
> String_literal.hpp
> String_literal_def.hpp
> String_literal.cpp

yes, I use this approach. The problem rise if I want to test each
production in a test suite. calc7 shows:

namespace client {
     ...
     namespace calculator_grammar {
         struct expression_class;
         typedef x3::rule<expression_class, ast::expression>
                expression_type;
         BOOST_SPIRIT_DECLARE(expression_type);
     }
     calculator_grammar::expression_type expression();
}

and expose the top rule, but for testing parts of the grammar a lot of
them are required.

The other question may be behind: How to clever write iterativ the rule
definitions to avoid drowning in compiler errors?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: splitted source (decl, def) gives compile errors byy use for test suite

tomkulaga

I've got an iterative rule set at home (at least if we're both thinking of iterative in the same sense, where rules compose up of other rules). I can send some snippets a little later.

As for the testing suite I'll take a look at what I have and see if it helps.


On Thu., 2 Mar. 2017, 6:07 pm Olaf Peter, <[hidden email]> wrote:
Hello Tom,

> I've had success using the method used in the calc examples:
>
> https://github.com/boostorg/spirit/tree/develop/example/x3/calc/calc7
>
> Have a
> String_literal.hpp
> String_literal_def.hpp
> String_literal.cpp

yes, I use this approach. The problem rise if I want to test each
production in a test suite. calc7 shows:

namespace client {
     ...
     namespace calculator_grammar {
         struct expression_class;
         typedef x3::rule<expression_class, ast::expression>
                expression_type;
         BOOST_SPIRIT_DECLARE(expression_type);
     }
     calculator_grammar::expression_type expression();
}

and expose the top rule, but for testing parts of the grammar a lot of
them are required.

The other question may be behind: How to clever write iterativ the rule
definitions to avoid drowning in compiler errors?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: splitted source (decl, def) gives compile errors byy use for test suite

tomkulaga
Hi Olaf,

here's what I use hope it helps:

SchematicFileGrammer_def.hpp http://pastebin.com/SUP0WAq3
SchematicFileGrammer.hpp http://pastebin.com/t5hwymCe
SchematicFileParserConfig.hpp http://pastebin.com/VgyrrAVQ
SchematicFileGrammer.cpp http://pastebin.com/sNkQtXuS

(There's also the AST define files but i've left them out)

I instatiante my parser at point of use like this

#include "KicadParser/SchematicFile/SchematicFileGrammar.hpp"
#include "KicadParser/SchematicFile/SchematicFileParserConfig.hpp"

    auto const schParser =
        // we pass our error handler to the parser so we can access
        // it later on in our on_error and on_sucess handlers
        boost::spirit::x3::with<client::KicadFileParser_grammar::error_handler_tag>(std::ref(error_handler))
        [
            client::schematicFile()
        ];



On Thu, 2 Mar 2017 at 19:29 Tom Kulaga <[hidden email]> wrote:

I've got an iterative rule set at home (at least if we're both thinking of iterative in the same sense, where rules compose up of other rules). I can send some snippets a little later.

As for the testing suite I'll take a look at what I have and see if it helps.


On Thu., 2 Mar. 2017, 6:07 pm Olaf Peter, <[hidden email]> wrote:
Hello Tom,

> I've had success using the method used in the calc examples:
>
> https://github.com/boostorg/spirit/tree/develop/example/x3/calc/calc7
>
> Have a
> String_literal.hpp
> String_literal_def.hpp
> String_literal.cpp

yes, I use this approach. The problem rise if I want to test each
production in a test suite. calc7 shows:

namespace client {
     ...
     namespace calculator_grammar {
         struct expression_class;
         typedef x3::rule<expression_class, ast::expression>
                expression_type;
         BOOST_SPIRIT_DECLARE(expression_type);
     }
     calculator_grammar::expression_type expression();
}

and expose the top rule, but for testing parts of the grammar a lot of
them are required.

The other question may be behind: How to clever write iterativ the rule
definitions to avoid drowning in compiler errors?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: splitted source (decl, def) gives compile errors byy use for test suite

Olaf Peter
Hello Tom,

> I instatiante my parser at point of use like this
>
> #include"KicadParser/SchematicFile/SchematicFileGrammar.hpp"
>
> #include"KicadParser/SchematicFile/SchematicFileParserConfig.hpp"
>
> autoconstschParser=
>
> //wepassourerrorhandlertotheparsersowecanaccess
>
> //itlateroninouron_errorandon_sucesshandlers
>
> boost::spirit::x3::with<client::KicadFileParser_grammar::error_handler_tag>(std::ref(error_handler))
>
> [
>
> client::schematicFile()
>
> ];

but how do you iterative develop the rules and use them by the tests
(suite), e.g. testing the production rule schematicDescription? I don't
know about the BNF of KiCAD's schematic, but I would assume that the
comment lines here would be optional etc. Even this format file
definition looks quite simple, there are test cases to be checked at
this rule.

Thank you,
Olaf


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general