headers
Joel de Guzman | 2 Jan 04:11
Picon
Favicon

Re: Composite parse with action?

Max Pfingsthorn wrote:
> Dear list,
> 
> This is my first time with parsers and such, so I hope my question is
> not too stupid.
> 
> I would like to write a config file parser with Spirit. So far, that is
> not a problem, however, I would like to use the grammar from the
> calculator example as the parser for numeric expressions (so I can write
> 
> somevalue = 3*pi/2;
> 
> in my config file and somevalue will be 4.71239 instead of some string).
> 
> I have gotten as far as implementing the completely working calculator
> in a grammar<> subclass (it keeps a stack of values and actually
> performs the operations instead of just printing to stdout). Now, the
> only last thing I have left is how to attach an action to that grammar.
> Basically, I would like the action function to not care if it is
> attached to a real_parser or my calculator grammar. Is that possible?

Yes.

> What do I have to do to "return" a double value properly? I tried to
> read the code for real_parser, but I got lost...

If you are using "classic" spirit, then I think there's an example
doing that (see the calculators in the example/fundamental) directory.
Basically, a grammar is just another parser in the POV of Spirit.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ian eyberg | 2 Jan 20:41
Gravatar

[Spirit 2] semantic actions?

Hi,

  I am converting a set of Spirit Classic grammars
to their 2.0 counterparts and I have gotten confused
on how to pass captured text through a semantic action.

  In the past I used to have stuff like this:

    anynum = (millions | thousands | amount )[assign(self.seat.amount)];

  where seat was a struct that'd I'd pass into the parser and amount
  a member value of type string

  also I used assign_a like this:

    str_p("mucks")[assign_a(self.action.name, "fold")][assign_a(self.action.muck, "true")]

  what is the V2 way of performing that?

I've been trying to follow
http://www.boost.org/doc/libs/1_36_0/libs/spirit/doc/html/index.html
but sadly it is missing several pages of documentation.

On a side note, do the spirit maintainers not have control over the
site spirit.sf.net any more? It was rather hard to find documentation,
source to obtain the 2.0 branch.

Other than that, thanks a lot -- spirit has done wonders for a parser
I've been working on.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carl Barron | 2 Jan 22:40

Re: [Spirit 2] semantic actions?


On Jan 2, 2009, at 2:41 PM, ian eyberg wrote:

> Hi,
>
>  I am converting a set of Spirit Classic grammars
> to their 2.0 counterparts and I have gotten confused
> on how to pass captured text through a semantic action.
>
>  In the past I used to have stuff like this:
>
>    anynum = (millions | thousands | amount ) 
> [assign(self.seat.amount)];
>
>  where seat was a struct that'd I'd pass into the parser and amount
>  a member value of type string
>
>  also I used assign_a like this:
>
>    str_p("mucks")[assign_a(self.action.name, "fold")] 
> [assign_a(self.action.muck, "true")]
>
>  what is the V2 way of performing that?
>
> I've been trying to follow
> http://www.boost.org/doc/libs/1_36_0/libs/spirit/doc/html/index.html
> but sadly it is missing several pages of documentation.
>
> On a side note, do the spirit maintainers not have control over the
> site spirit.sf.net any more? It was rather hard to find documentation,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Zilian | 3 Jan 17:14
Picon
Picon

Re: Spirit2 and multi_pass for use with std::istream_iterator

>
Hello Hartmut,

> I'd appreciate it if in the meantime you could post some complete  
> (and possibly minimal) source
> code example exposing the problem.
>
> Regards Hartmut

Many thanks for your quick response! Please see the lines below that  
lead to the first compilation error message.
I checked the multi_pass-related test problems in libs/spirit/test but  
none of them compiled correctly. One reason
seems to be missing default values for policies in the multi_pass  
template definition. The other problem arises
from a missing 'distance_type' in 'struct  
boost::detail::iterator_traits'.

Again, my goal is to use a lexer tokenizing directly a std::cin stream  
for which the multi_pass iterator has been recommended.

Andreas.

/* test: multi_pass and lexer */

#include <iostream>

#include <boost/spirit/include/lex_lexer_lexertl.hpp>
#include <boost/spirit/include/support_multi_pass.hpp>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Menzel | 3 Jan 17:44
Picon

Re: lengthy newbie question about extracting values within predefined grammar

Am Montag, 29. Dezember 2008 03:06:08 schrieb OvermindDL1:

> For note, Spirit2(x) is a lot more simple then Classic Spirit.  If you
> intend to use Spirit2(x), do not learn Classic Spirit first, it will
> only make things more difficult.

Indeed, you are right with that one. I just had a look at the tutorials in the 
spirit2 docs and found them way better than the old docs. I think I'll go for 
spirit2 straight away then.
My use case even is a FAQ so I managed to do it quite easily. Now it looks 
like this:

struct results {

        boost::uint32_t  line_id;
        boost::uint16_t  line_ver;
        std::string      command;
        std::string      params;
};

BOOST_FUSION_ADAPT_STRUCT(
                results,
                (boost::uint32_t,    line_id)
                (boost::uint16_t,    line_ver)
                (std::string,        command)
                (std::string,        params)
                )

template <typename Iterator>
struct line_parser : boost::spirit::qi::grammar<Iterator, results(),
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Wilkinson | 3 Jan 21:31
Picon
Favicon

position_iterator always reporting error at line 1 column 1

With the following grammer position_iterator always reports an error to be at line 1 column 1:

    start_ = array_ | str_p( "bar" );

    array_ = ch_p('[') >> !elements_ >> ch_p(']') ;

    elements_ = ch_p('A')[ &debug ] >> *( ',' >> ch_p('A')[ &debug ] );

If I remove "str_p( "bar" )" or the second  ch_p(']') errors are reported correctly. The correct number of
'A's are always reported by the debug function. I would be grateful if anyone could tell me whether this is a
bug, expected behaviour and if there is a work-around.

I am using boost 1_37_0, Spirit classic, Visual C++ 2005.

Thanks
John

Full code:

#include "stdafx.h"
#include <iostream>
#include <boost/spirit/core.hpp>
#include <boost/spirit/iterator/position_iterator.hpp>
#include <boost/spirit/utility/escape_char.hpp>
#include <boost/spirit/utility/confix.hpp>

using namespace std;
using namespace boost;
using namespace boost::spirit;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carl Barron | 3 Jan 22:15

Re: lengthy newbie question about extracting values within predefined grammar


On Jan 3, 2009, at 11:44 AM, Stephan Menzel wrote:

>
> Nice. And thanks. However, there's a question left I couldn't manage  
> yet.
> After applying this I would have to tokenize the string params apart  
> and copy
> each token into a vector<string>. Would that be possible to achieve  
> with
> spirit2 in one go? Something like this:
>
> struct results {
>
>        boost::uint32_t          line_id;
>        boost::uint16_t          line_ver;
>        std::string              command;
>        std::vector<std::string> params;
> };

Easiest is
    strings %= *string;

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Fletcher, John P | 4 Jan 00:50
Picon
Picon
Favicon

[fusion] IO naming of manipulators.

I have been looking at the manipulators defined in boost/fusion/sequence/io/detail/manip.hpp

There is also documentation in http://www.boost.org/doc/libs/1_37_0/libs/fusion/doc/html/fusion/sequence/operator/i_o.html

In the documentation the output manipulators are 'tuple_open' etc and in the input example they are
'set_open' etc.

Looking at the source code in boost 1.35.0 they appear to be defined only as 'tuple_open' etc.

Also there is the following comment in the code:

//$$$ these should be part of the public API$$$
//$$$ rename tuple_open, tuple_close and tuple_delimiter to
//    open, close and delimeter and add these synonyms to the
//    TR1 tuple module.

What is the status of this comment?

It looks to me as though there is one set for both input and output which remains in effect once set.  Is that correct?
Is that on a program section basis or is it global behaviour?
Is there a simple means to restore the default behaviour?

Thanks

John Fletcher

------------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Joel de Guzman | 4 Jan 05:11
Picon
Favicon

Re: [fusion] IO naming of manipulators.

Fletcher, John P wrote:
> I have been looking at the manipulators defined in
> boost/fusion/sequence/io/detail/manip.hpp
> 
> There is also documentation in
> http://www.boost.org/doc/libs/1_37_0/libs/fusion/doc/html/fusion/sequence/operator/i_o.html
> 
> 
> In the documentation the output manipulators are 'tuple_open' etc and in the
> input example they are 'set_open' etc.
> 
> Looking at the source code in boost 1.35.0 they appear to be defined only as
> 'tuple_open' etc.
> 
> Also there is the following comment in the code:
> 
> //$$$ these should be part of the public API$$$ //$$$ rename tuple_open,
> tuple_close and tuple_delimiter to //    open, close and delimeter and add
> these synonyms to the //    TR1 tuple module.
> 
> 
> 
> What is the status of this comment?

I think it was largely forgotten :-( Thanks for bringing it
into attention.

> It looks to me as though there is one set for both input and output which
> remains in effect once set.  Is that correct?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel de Guzman | 4 Jan 06:23
Picon
Favicon

Re: position_iterator always reporting error at line 1 column 1

John Wilkinson wrote:
> With the following grammer position_iterator always reports an error to be at line 1 column 1:
> 
>     start_ = array_ | str_p( "bar" );
> 
>     array_ = ch_p('[') >> !elements_ >> ch_p(']') ;
> 
>     elements_ = ch_p('A')[ &debug ] >> *( ',' >> ch_p('A')[ &debug ] );
> 
> If I remove "str_p( "bar" )" or the second  ch_p(']') errors are reported correctly. The correct number of
'A's are always reported by the debug function. I would be grateful if anyone could tell me whether this is a
bug, expected behaviour and if there is a work-around.
> 
> I am using boost 1_37_0, Spirit classic, Visual C++ 2005.

The iterator is being re-wound when it gets to the topmost
parse call. It simply points to the outermost error. If you
want a more pinpoint error report, use this recipe:

     x | eps_p[error_report]

That is: try x, if it fails, call an error report handler. In your
example, this can be:

    element = ch_p('A') | eps_p[print_error]
    elements_ = element >> *( ',' >> element );

HTH. Oh my.. It would be so much wonderful with Spirit2! ;-)

Regards,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane