Jörg Becker | 1 Jul 14:40
Picon

lexeme_scanner

Hi,

I'm wondering how to use the lexeme_scanner.

I defined the following rule:

foo = *spirit::anychar_p;
spirit::rule < typename spirit::lexeme_scanner< scanner_t >::type > foo;

Everything is fine. But if I use foo in my grammar, I get the following 
compiler error:

../boost/boost/spirit/core/non_terminal/impl/rule.ipp:189: error: no matching 
function for call 
to 'boost::spirit::impl::abstract_parser<boost::spirit::scanner<const 
wchar_t*,

boost::spirit::scanner_policies<boost::spirit::no_skipper_iteration_policy<boost::spirit::skipper_iteration_policy<boost::spirit::iteration_policy> 
>, boost::spirit::match_policy, boost::spirit::action_policy> >, 
boost::spirit::nil_t>::do_parse_virtual(const boost::spirit::scanner<const 
wchar_t*,

boost::spirit::scanner_policies<boost::spirit::skipper_iteration_policy<boost::spirit::iteration_policy>, 
boost::spirit::match_policy, boost::spirit::action_policy> >&)'

../boost/boost/spirit/core/non_terminal/impl/rule.ipp:213: note: candidates 
are: typename boost::spirit::match_result<ScannerT, AttrT>::type 
boost::spirit::impl::abstract_parser<ScannerT, AttrT>::do_parse_virtual(const 
ScannerT&) const [with ScannerT = boost::spirit::scanner<const wchar_t*,

(Continue reading)

Joel de Guzman | 1 Jul 14:43
Picon
Favicon

Re: lexeme_scanner

Jörg Becker wrote:
> Hi,
> 
> I'm wondering how to use the lexeme_scanner.
> 
> I defined the following rule:
> 
> foo = *spirit::anychar_p;
> spirit::rule < typename spirit::lexeme_scanner< scanner_t >::type > foo;
> 
> Everything is fine. But if I use foo in my grammar, I get the following 
> compiler error:

As always, please post some minimal (but complete) code that
we can try.

> Thanks for any help

Regards,
--

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
(Continue reading)

Jörg Becker | 1 Jul 17:57
Picon

Re: lexeme_scanner [SOLVED]

On Tuesday, 1. July 2008 14:40:54 Jörg Becker wrote:
> Hi,
>
> I'm wondering how to use the lexeme_scanner.
>
> I defined the following rule:
>
> foo = *spirit::anychar_p;
> spirit::rule < typename spirit::lexeme_scanner< scanner_t >::type > foo;
>
> Everything is fine. But if I use foo in my grammar, I get the following
> compiler error:
>

Seems like I missed an important docu page /example.

http://www.boost.org/doc/libs/1_35_0/libs/spirit/example/techniques/multiple_scanners.cpp
http://www.boost.org/doc/libs/1_35_0/libs/spirit/doc/techniques.html#multiple_scanner_support

defining         

typedef spirit::scanner_list <
  scanner_t, typename spirit::lexeme_scanner< scanner_t >::type
> scanners;

and using it like this:

spirit::rule< scanners > foo;

makes everything working fine.
(Continue reading)

Jörg Becker | 2 Jul 11:08
Picon

lexeme and leading spaces

Hello,

I'm wondering how to keep leading spaces in a 'lexeme rule'. 

Background: my grammar is composed of literal and expression parts. The 
literal parts should keep all spaces, the expression parts should overread 
all spaces. My approach (see example below) was to use a space_p skip parser 
for my grammar and parsing the literal parts with a lexeme directive. This 
works fine except for the leading spaces of my literals.

Obviously the skip parser is called before every rule. Is there a possibility 
to change or skip the skip parsers before my literal rule?

Thanks for any suggestions

Jörg

#include <boost/spirit/attribute.hpp>
#include <boost/spirit/core.hpp>
#include <boost/spirit/phoenix/functions.hpp>

#include <iostream>

using namespace boost::spirit;
using namespace phoenix;

struct my_closure : boost::spirit::closure< my_closure, std::wstring > {
  member1 str;
};

(Continue reading)

Nafi Diallo | 2 Jul 20:19
Picon
Favicon

tag.hpp missing under libs/spirit/example/intermediate/simple_xml

Hi,
I am trying to test the "simple_xml" example and it cannot find anywhere tag.hpp
Can you please update it?
Thanks, Fina
 

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Spirit-general mailing list
Spirit-general <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-general
Joe Pitt | 3 Jul 13:29
Picon
Picon

problem with tree parser

Hello guys!

I'm pretty new to parser generation and I'm having trouble building a tree parser :(
What I want to do is "translate" some source code to another pretty much similar source code.

My first approach was to use semantic actions to convert some symbols that are different. it worked good,
until i came to this expression:

term
     =    (
            '(' >> term >> ')')
        |    value    >>   
            !(   
                ('*' >> term)
                |    ('+' >> term)
                |    ('-' >> term)
                |    ('^' >> term)
                |    ('.' >> term)
            )

        ;

now the order of my string got mixed up, when I used a semantic action on e.g. ('+' >> term) trying to replace
the '+' by 'plus'

so I figured using a tree parser would be nicer, since I can first build the tree and then traverse it in the
right order. which is perfect, since I want to translate the same source to a different target language afterwards.

But now I'm having problems building my tree.
Does anyone have a very very simple example for such a parser with maybe just a single rule, so I can extend
that for my purpose?
I tried to extend the calc example, but failed.

Thanks in advance,
Joe
--

-- 
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Jan Swoboda | 3 Jul 18:24
Picon

Re: lexeme and leading spaces

Jörg Becker <news <at> elke-joerg.de> writes:

> 
> Hello,
> 
> I'm wondering how to keep leading spaces in a 'lexeme rule'. 
> 
> Background: my grammar is composed of literal and expression parts. The 
> literal parts should keep all spaces, the expression parts should overread 
> all spaces. My approach (see example below) was to use a space_p skip parser 
> for my grammar and parsing the literal parts with a lexeme directive. This 
> works fine except for the leading spaces of my literals.
> 
> Obviously the skip parser is called before every rule. Is there a possibility 
> to change or skip the skip parsers before my literal rule?
> 
> Thanks for any suggestions
> 
> Jörg

Looks like you don't want to skip initially, so I'd rephrase the kill_spaces
rule to do its own skipping. Suggested changes are below.

A cleaner version would be if you could specify a skipper for the kill_spaces
rule only, but I don't know if that's possible.

Regards, Jan

#include <boost/spirit/attribute.hpp>
#include <boost/spirit/core.hpp>
#include <boost/spirit/phoenix/functions.hpp>

#include <iostream>

using namespace boost::spirit;
using namespace phoenix;

struct my_closure : boost::spirit::closure< my_closure, std::wstring > {
  member1 str;
};

struct my_grammar : grammar< my_grammar, my_closure::context_t > {
  template < typename scanner_t >
  struct definition {
    definition ( my_grammar const& self ) {
      lit =
// lexeme_d not needed, replaced with:
        ( *( anychar_p - ch_p( '#' ) ) )
        [ lit.str = construct_< std::wstring >( arg1, arg2 ) ]
        ;

      kill_spaces =
        ch_p( '#' ) [ kill_spaces.str = '#' ]
// do your own skipping, insert space_p in between:
        >> *space_p
        >> *( ( anychar_p - ch_p( '#' ) - space_p ) 
        [ kill_spaces.str += construct_< std::wstring >( arg1, arg2 ) ]
        >> *space_p )
        >> ch_p( '#' ) [ kill_spaces.str += '#' ]
        ;

      top =
        lit [ self.str = phoenix::arg1 ]
        >> kill_spaces [ self.str += phoenix::arg1 ]
        >> lit [ self.str += phoenix::arg1 ]
        ;
    }

    typedef rule< scanner_t, my_closure::context_t > rule_t;
    rule_t kill_spaces, lit, top;
    rule_t const& start() const { return top; }
  };
};

int
main () {
  my_grammar g;
  std::wstring ret;
  parse_info< wchar_t const * > info;
  info = parse(
           L"  I want to see all (also leading) spaces in the first part   "
           L"#  I don't want to see any spaces in the second part.   #"
           L"   Here I want to see all (also leading) spaces again.   ",
// no skipper:
           g [ phoenix::var( ret ) = phoenix::arg1 ] );
  assert( info.full );
  std::wcout << L"parser returned: '" << ret << L"'." << std::endl;
  return 0;
}

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Spirit-general mailing list
Spirit-general <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-general
Jörg Becker | 4 Jul 11:21
Picon

Re: lexeme and leading spaces

On Thursday, 3. July 2008 18:24:19 Jan Swoboda wrote:
> Looks like you don't want to skip initially, so I'd rephrase the
> kill_spaces rule to do its own skipping. Suggested changes are below.

Thanks for your suggestion. But this is exactly what I want to avoid.
This solution is fine for the example, but in the real grammar I have one 
literal rule and many kill spaces rules (skip spaces between keywords, 
variable names, around brackets, ...). Therefore manually skiping spaces is 
error-prone and hard to test.

>
> A cleaner version would be if you could specify a skipper for the
> kill_spaces rule only, but I don't know if that's possible.
Yes, changing or toggling the skip parser on rule level would be nice. I 
thought the latter is done by the lexeme directive, but I was wrong, because 
the skip parser is called before the rule using the lexeme directive.

I found a solution for all but the first literal. Using the the lexeme 
directive for the top rule avoids calling the skip space parser between the 
rules on top level. But still loosing the leading spaces. Obviously the skip 
parser is called before the first rule (top). I think the skip parser should 
not be called before lexeme rules.

#define BOOST_SPIRIT_RULE_SCANNERTYPE_LIMIT 2

#include <boost/spirit/attribute.hpp>
#include <boost/spirit/core.hpp>
#include <boost/spirit/phoenix/functions.hpp>

#include <iostream>

using namespace boost::spirit;
using namespace phoenix;

struct my_closure : boost::spirit::closure< my_closure, std::wstring > {
  member1 str;
};

struct my_grammar : grammar< my_grammar, my_closure::context_t > {
  template < typename scanner_t >
  struct definition {
    definition ( my_grammar const& self ) {
      lit =
        lexeme_d[ *( anychar_p - ch_p( '#' ) ) ]
        [ lit.str = construct_< std::wstring >( arg1, arg2 ) ]
        ;

      kill_spaces =
        ch_p( '#' ) [ kill_spaces.str = '#' ]
        >> *( anychar_p - ch_p( '#' ) )
        [ kill_spaces.str += construct_< std::wstring >( arg1, arg2 ) ]
        >> ch_p( '#' ) [ kill_spaces.str += '#' ]
        ;

      top = lexeme_d[
              lit [ self.str = phoenix::arg1 ]
              >> kill_spaces [ self.str += phoenix::arg1 ]
              >> lit [ self.str += phoenix::arg1 ]
            ]
            ;
    }

    typedef scanner_list <
    scanner_t, typename lexeme_scanner< scanner_t >::type
    > scanners;

    typedef rule< scanners, my_closure::context_t > rule_t;
    rule_t kill_spaces, lit, top;
    rule_t const& start() const { return top; }
  };
};

int
main () {
  my_grammar g;
  std::wstring ret;
  parse_info< wchar_t const * > info;
  info = parse(
           L"  I want to see all (also leading) spaces in the first part   "
           "#  I don't want to see any spaces in the second part.   #"
           "   Here I want to see all (also leading) spaces again.   ",
           g [ phoenix::var( ret ) = phoenix::arg1 ],
           space_p );
  assert( info.full );
  std::wcout << L"parser returned: '" << ret << L"'." << std::endl;
  return 0;
}

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Carl Barron | 8 Jul 07:19

Re: lexeme and leading spaces


On Jul 4, 2008, at 5:21 AM, Jörg Becker wrote:

> On Thursday, 3. July 2008 18:24:19 Jan Swoboda wrote:
>> Looks like you don't want to skip initially, so I'd rephrase the
>> kill_spaces rule to do its own skipping. Suggested changes are below.
>
> Thanks for your suggestion. But this is exactly what I want to avoid.
> This solution is fine for the example, but in the real grammar I  
> have one
> literal rule and many kill spaces rules (skip spaces between keywords,
> variable names, around brackets, ...). Therefore manually skiping  
> spaces is
> error-prone and hard to test.
>
>>
>> A cleaner version would be if you could specify a skipper for the
>> kill_spaces rule only, but I don't know if that's possible.
> Yes, changing or toggling the skip parser on rule level would be  
> nice. I
> thought the latter is done by the lexeme directive, but I was wrong,  
> because
> the skip parser is called before the rule using the lexeme directive.
>
> I found a solution for all but the first literal. Using the the lexeme
> directive for the top rule avoids calling the skip space parser  
> between the
> rules on top level. But still loosing the leading spaces. Obviously  
> the skip
> parser is called before the first rule (top). I think the skip  
> parser should
> not be called before lexeme rules.
>

NOT TESTED but something like
    the simplest is a tuneable parser for your skipper
    struct my_skipper_inpl.
    {
	bool flag;
         my_skipper():flag(true){}
         typedef boost::spirfit::nil_t result_t;
	template <class Scan>
	std::ptrdirr_t operator () (const Scan &s,result_t &)
	{
		if(flag)
			return -1;	// a skipper that always fails is a non-skipper!!
		else
		{
			//parse one white space easiest is a switch
			if(!scan.at_end())
			{
				switch(*scan)
				{
				case ' ':
				case '\t:
					// etc.   fhw charss to skip if skipper is active.
					return 1;
				defautl:
					return -1;
			}
		}
		else
		{
			// end of data
			return -1;
		}
	}
};

typedef boost::spirit::functor_parser<my_skipper_impl>  my_skiipper;

struct your_grammar:boost::spirit::grammar<your_grammar,....>
{
	my_skipper *p_skipper;
	yout_grammar(my_skipper *p):p_skipper){}
	template <class Scan>
	struct definition
	{
		definition(const your_grammar &self)
		{
			//  tuen skipper on// off with an eps_p parser with the action to
			// change   self.p_sklipper->flag
		}
	}
};

int main()
{
	my_skipper skipper;
	\yiur_grammar gram(&skipper);
	// ...
	if( parse( input, gram,skipper).full)
	{
		// ...
	}
	else
	{
		// ...
	}
}

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Jan van Dijk | 8 Jul 10:32
Picon
Picon
Gravatar

trac ticket #1997

	Dear developers,

May I humbly draw your attention to:

	http://svn.boost.org/trac/boost/ticket/1997 ?

That was filed 4 weeks ago, it should not take more than a second to fix (just 
add an '#include <cstring>'). 

This would allow me to use an unpatched boost SVN trunk on the various 
machines where my projects are being built. Thanks in advance!

With kind regards,

	Jan van Dijk.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Gmane