headers
Mark Loftis | 1 Oct 02:59
Picon
Favicon

Re: trouble updating to spirit classic

Hartmut Kaiser wrote:
>> I'm having some trouble bringing an application up-to-date with the
>> latest version of boost/spirit. The current version used by the app is
>> 1.8.5 and I'm looking to make the switch over to 2.1/1.41 (r56475 from
>> the boost SVN trunk). So far, I've simply changed the include's and
>> namespace references from this:
>>
>>     #include <boost/spirit/trees/ast.hpp>
>>     using namespace boost::spirit;
>>
>> To this:
>>
>>     #include <boost/spirit/include/classic_ast.hpp>
>>     using namespace boost::spirit::classic;
>>     
>
> That's the right way to handle things.
>
>   
>> in the relevant application source files. When I compile the app (using
>> VS2008 / WinXP, both up-to-date) I end up with this error several times
>> :
>>     error C2039: 'trees' : is not a member of
>> 'boost::spirit::classic::match<boost::spirit::classic::nil_t>'
>> ...\boost\spirit\home\classic\tree\common.hpp    1478
>>     
>
> This error tells you that you're using a 'normal' spirit::match object
> instead of a spirit::tree_match, which is probably the result of a
> misspelled policy. But it's difficult to tell from here as long as you can't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hartmut Kaiser | 1 Oct 02:16
Picon
Gravatar

[Karma] What's the correct behavior?


Hi all,

What's the correct behavior for generators like

    *lit(' ')

i.e. a kleene for a self-contained generator, not requiring an attribute?

We have two possibilities

a) infinite loop, generating spaces until the memory is exhausted
b) no output at all

a) makes somehow sense as it could be something like:

    int i = 10;
    *(eps(--phx::ref(i) > 0) << '*')

which naturally limits the output to 9 characters. OTOH

b) makes sense in order to avoid infinite loops and generating no output at
all is a valid outcome of a kleene expression.

Qi relies completely on the programmer to avoid infinite loops while using
kleene, so option a) seems to be the matching choice. At the same time Karma
usually does the opposite of Qi, making b) the preferable option. So I'm not
sure.

What do you think?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Caisse | 1 Oct 03:53

Re: [Karma] What's the correct behavior?

Hartmut Kaiser wrote:
> Hi all,
>
> What's the correct behavior for generators like
>
>     *lit(' ')
>
> i.e. a kleene for a self-contained generator, not requiring an attribute?
>
> We have two possibilities
>
> a) infinite loop, generating spaces until the memory is exhausted
> b) no output at all
>
> a) makes somehow sense as it could be something like:
>
>     int i = 10;
>     *(eps(--phx::ref(i) > 0) << '*')
>
> which naturally limits the output to 9 characters. OTOH
>
> b) makes sense in order to avoid infinite loops and generating no output at
> all is a valid outcome of a kleene expression.
>
>
> Qi relies completely on the programmer to avoid infinite loops while using
> kleene, so option a) seems to be the matching choice. At the same time Karma
> usually does the opposite of Qi, making b) the preferable option. So I'm not
> sure.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hartmut Kaiser | 1 Oct 04:24
Picon
Gravatar

Re: ]karma] outputing local vars.

>   how do I get a pair of strings to output the ( second_member , index)
> 
> that is  { ("a,"b"),("c","d") )  -> ( "b",0) ("d",1)
> 
> how do I get a variable local to the generator to be output?
> struct Struct
> {
>      typedef std::vector<std::pair<std::string,std::string> >
> member_type;
>      std::string name;
>      member_type members;
> }
> 
>   basically the generator is fed a pair<std::string,std::string> and
> wants to produce
> 
>   a '(' << '" <<  input.second << '"' << ',' << counter << ')'
> 
> pair(a,b) ->  ("b",0)
> pair(c,d) ->  ("d",1)
> etc.

After thinking about this back and forth I believe the simplest solution is
still the best:

    eps(ref(i) = 0) 
    << *(omit[string] << string << ',' << lit(++ref(i)))

i.e initialize a counter before the loop, then omit the first element of the
pair, while printing the second one. The lit() should actually figure out on
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carl Barron | 1 Oct 04:44

Re: [Karma] What's the correct behavior?


On Sep 30, 2009, at 8:16 PM, Hartmut Kaiser wrote:

>
> Hi all,
>
> What's the correct behavior for generators like
>
>    *lit(' ')
>
> i.e. a kleene for a self-contained generator, not requiring an  
> attribute?
>
> We have two possibilities
>
> a) infinite loop, generating spaces until the memory is exhausted
> b) no output at all
>
> a) makes somehow sense as it could be something like:
>
>    int i = 10;
>    *(eps(--phx::ref(i) > 0) << '*')
>
> which naturally limits the output to 9 characters. OTOH
>
> b) makes sense in order to avoid infinite loops and generating no  
> output at
> all is a valid outcome of a kleene expression.
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl Barron | 1 Oct 04:51

Re: ]karma] outputing local vars.


On Sep 30, 2009, at 10:24 PM, Hartmut Kaiser wrote:

>>  how do I get a pair of strings to output the ( second_member ,  
>> index)
>>
>> that is  { ("a,"b"),("c","d") )  -> ( "b",0) ("d",1)
>>
>> how do I get a variable local to the generator to be output?
>> struct Struct
>> {
>>     typedef std::vector<std::pair<std::string,std::string> >
>> member_type;
>>     std::string name;
>>     member_type members;
>> }
>>
>>  basically the generator is fed a pair<std::string,std::string> and
>> wants to produce
>>
>>  a '(' << '" <<  input.second << '"' << ',' << counter << ')'
>>
>> pair(a,b) ->  ("b",0)
>> pair(c,d) ->  ("d",1)
>> etc.
>
> After thinking about this back and forth I believe the simplest  
> solution is
> still the best:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel de Guzman | 1 Oct 04:54
Picon
Favicon

Re: [Karma] What's the correct behavior?

Michael Caisse wrote:
> Hartmut Kaiser wrote:
>> Hi all,
>>
>> What's the correct behavior for generators like
>>
>>     *lit(' ')
>>
>> i.e. a kleene for a self-contained generator, not requiring an attribute?
>>
>> We have two possibilities
>>
>> a) infinite loop, generating spaces until the memory is exhausted
>> b) no output at all
>>
>> a) makes somehow sense as it could be something like:
>>
>>     int i = 10;
>>     *(eps(--phx::ref(i) > 0) << '*')
>>
>> which naturally limits the output to 9 characters. OTOH
>>
>> b) makes sense in order to avoid infinite loops and generating no output at
>> all is a valid outcome of a kleene expression.
>>
>>
>> Qi relies completely on the programmer to avoid infinite loops while using
>> kleene, so option a) seems to be the matching choice. At the same time Karma
>> usually does the opposite of Qi, making b) the preferable option. So I'm not
>> sure.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl Barron | 1 Oct 05:52

Re: ]karma] outputing local vars.


On Sep 30, 2009, at 10:51 PM, Carl Barron wrote:

>
> On Sep 30, 2009, at 10:24 PM, Hartmut Kaiser wrote:
>
>>> how do I get a pair of strings to output the ( second_member ,
>>> index)
>>>
>>> that is  { ("a,"b"),("c","d") )  -> ( "b",0) ("d",1)
>>>
>>> how do I get a variable local to the generator to be output?
>>> struct Struct
>>> {
>>>    typedef std::vector<std::pair<std::string,std::string> >
>>> member_type;
>>>    std::string name;
>>>    member_type members;
>>> }
>>>
>>> basically the generator is fed a pair<std::string,std::string> and
>>> wants to produce
>>>
>>> a '(' << '" <<  input.second << '"' << ',' << counter << ')'
>>>
>>> pair(a,b) ->  ("b",0)
>>> pair(c,d) ->  ("d",1)
>>> etc.
>>
>> After thinking about this back and forth I believe the simplest
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Caisse | 1 Oct 06:29

Re: [Qi] feature suggestion

Stephan Menzel wrote:
>
>> Works great, produced a smaller footprint
>> than the old solution, runs faster
>>     
>
> Runs faster? Sure?
>
>   
OK, you got me there. It "feels" faster but I'm really not sure
since I did zero testing of the speed for this latest conversion.
Most of the things I have been converting over are boost.regex based
ad-hoc parsers; however, recently (last week) I wrote a parser
for XML. I have been using Xerces-C forever but that causes some
issues with smaller embedded projects. I have my own abstraction
of an xml_node that I've been using longer than Xerces. I replaced
the Xerces-C based SAX reader with the Spirit 2.1 based one.

I ran a test of parsing 50,000 XML messages through each and the
numbers are consistent. The Spirit 2.1 based parser is 6.4x faster.

Granted, Xerces-C will do all kinds of things that my parser wont... but
that was the point. It was too bloated for most of my needs.

Thank you for challenging my assumption!

michael

--

--
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joel de Guzman | 1 Oct 07:02
Picon
Favicon

Re: [Qi] feature suggestion

Michael Caisse wrote:
> Stephan Menzel wrote:
>>> Works great, produced a smaller footprint
>>> than the old solution, runs faster
>>>     
>> Runs faster? Sure?
>>
>>   
> OK, you got me there. It "feels" faster but I'm really not sure
> since I did zero testing of the speed for this latest conversion.
> Most of the things I have been converting over are boost.regex based
> ad-hoc parsers; however, recently (last week) I wrote a parser
> for XML. I have been using Xerces-C forever but that causes some
> issues with smaller embedded projects. I have my own abstraction
> of an xml_node that I've been using longer than Xerces. I replaced
> the Xerces-C based SAX reader with the Spirit 2.1 based one.
> 
> I ran a test of parsing 50,000 XML messages through each and the
> numbers are consistent. The Spirit 2.1 based parser is 6.4x faster.
> 
> Granted, Xerces-C will do all kinds of things that my parser wont... but
> that was the point. It was too bloated for most of my needs.
> 
> Thank you for challenging my assumption!

Care to provide some benchmark code we can add to our
tests? I am trying to provide some comparisons or Qi versus
some other parsing means here:

     BOOST_ROOT\libs\spirit\benchmarks
(Continue reading)

Permalink | Reply | 4 comments |

Gmane