Re: Spirit rocks!

Henry Tan wrote:
> In general I agree with it. It has some learning-curve to get into it, 
> especially with Spirit 2.1 where suddenly you are bombarded with all 
> sorts of fancy programming concept,ideas: phoenix, lambda expression, 
> fusion, bind, variants, etc. It took me 3 x 24 hours to mentally consume 
> those docs and try to understand the whole new concepts which were new 
> to me.

Actually, that is fast! Learning new paradigms in that short a
time, IMO, is amazing. Either you are a very fast learner, or
you already have some background, or the Spirit libraries are
sufficiently intuitive, or all of the above 

Of course, the general recommendation is to digest all these
in small manageable pieces. Start small and gradually work
your way upwards.

> Luckily I have people on the threads always being very 
> helpful,especially Hartmut and Joel. So, I think after 1 week crash 
> course I think it feels much much better and I am in a good shape with 
> it. Not an expert yet but for the most practical things I wan to do with 
> it, defining grammar, creating my parse tree, I think I get the most of 
> it now.
>  
> Having said that, one of the biggest issue using boost lib in general is 
> the almost unreadable compile error/warning message. It gives you hints 
> of the issue but it does not tell exactly where it happened. I often 
> have to scratch my head for 25 mins doing divide and conquer to narrow 
> down where the errors happen. I hope that this will get addressed, as it 
> is really FRUSTATING and it could be nullifyng the time efficiency gain 

Re: Spirit rocks!

On Tue, Dec 1, 2009 at 10:59 AM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
>
> Yeah, we intend to have lots and lots of examples. More to come.
> Do check out the site every once in a while. We'll have more tips
> and stuff there.
>

Joel, you don't need lots of examples, you just need a few good ones,
as mentioned before:

1. Update the employee parser to do something more substantial

2. Provide a full blown expression parser equivalent to STX, (this is a must)

3. Provide a FIX parser, the "Parsing a List of Key-Value Pairs Using
Spirit.Qi" doesn't go far enough, what if a semi-colon was to be apart
of the value section, what is the correct syntax to "escape" certain
chars (you could probably write a whole article on doing that
properly), how can i provide a list of key's that I'm interested in
such that only they are parsed and everything else is skipped?.

Darid

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: changing a character returned by char_

Joel de Guzman <joel <at> boost-consulting.com> writes:

> How about:
> 
>      +char_("01") >> *('#' >> attr('0'))
> 
> ?
> 
> The '#' will force it to not have an attribute (same as lit('#'))
> while the attr('0') will give it the attribute back.
> 
> Regards,

qi::rule<Iterator, std::string()> uinteger2;
uinteger2 = raw[+char_("01") >> *('#' >> attr('0'))] ;

Session with debug(uinteger2):

> #b1#
<uinteger2>
  <try>1#</try>
  <success></success>
  <attributes>(1#)</attributes>
</uinteger2>
success

The leading #b is required but is consumed before uniteger2.

Is the raw[] directive doing something funky?

Re: Expectation operator

Let me ask the question differently. How would you implement the error
handling in this situation?
Both "alpha 1;" and "beta 2;" are valid input for the main grammar.
The use of sub-grammars is due to practical reasons: all in one header
grammar is not practical/possible  for any medium to high complexity
grammar. 

namespace client
{
	
	namespace qi = boost::spirit::qi;
	namespace ascii = boost::spirit::ascii;

	typedef std::string::const_iterator iterator;
	typedef qi::rule<iterator, void(), ascii::space_type> rule_type;
	typedef qi::grammar<iterator, void(), ascii::space_type> grammar_type;

	using qi::lit;
	

	struct sub_grammar1 : grammar_type 
        { 
                sub_grammar1() 
                        : sub_grammar1::base_type(start, "sub_grammar1") 
                { 
                        start 
                                =       lit ("alpha" ) 
                                        >       lit ("1" )

Re: getting started with phoenix

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

_______________________________________________
Spirit-general mailing list
Spirit-general <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-general

Re: Expectation operator

John Home wrote:
> 
> Let me ask the question differently. How would you implement the error
> handling in this situation?
> Both "alpha 1;" and "beta 2;" are valid input for the main grammar.
> The use of sub-grammars is due to practical reasons: all in one header
> grammar is not practical/possible  for any medium to high complexity
> grammar. 

Let's see... you have something like:

     a = lit("alpha") > lit("1");

then

     b = lit("beta") > lit("2");

Then the enclosing grammar:

     c = a | b;

In such case, you don't put expectation points in either a or b
because they are allowed to fail. Put the expectation point
only where it is not allowed to fail. In this case, it can be
in the enclosing grammar, c. E.g.:

    c = eps > a | b;

You'll get something like:

    Error, expecting a or b, but got xxx instead.

Remember, use expectation points *only* on hard errors where
you don't expect to back track.

Regards,
--

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

Meet me at BoostCon
http://www.boostcon.com/home
http://www.facebook.com/boostcon

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: getting started with phoenix

CR Koudella wrote:
> 
> sorry for the noise I am making, this is silly of me. I wasn't trying to 
> make any statements
> about spirit, which I know nothing about, but I have been trying to 
> figure out when phoenix
> 2 was released and why I was suggested that phoenix 1.2.1 was old. I 
> guess my point was
> that it wasn't old until recently. 

phoenix 1.2.1 is still relevant and will remain relevant. It's
been superceded by 2.x though so, just be aware. There are
major differences but shouldn't be a problem porting 1.x to
2.x. Time is fast. As we speak, Phoenix 3 is being written.
So, the question is: do you have to worry? I'd say no. The
interfaces are mostly kept intact. The differences are in the
infrastructure code mostly and the extension mechanisms (which
is only relevant if you do advanced Phoenix development). We
strive as much as we can for backward compatibility.

Regards,
--

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

Meet me at BoostCon
http://www.boostcon.com/home
http://www.facebook.com/boostcon

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: changing a character returned by char_

On Mon, Nov 30, 2009 at 5:20 PM, bytecolor <bytecolor <at> gmail.com> wrote:
> Joel de Guzman <joel <at> boost-consulting.com> writes:
>
>> How about:
>>
>>      +char_("01") >> *('#' >> attr('0'))
>>
>> ?
>>
>> The '#' will force it to not have an attribute (same as lit('#'))
>> while the attr('0') will give it the attribute back.
>>
>> Regards,
>
> qi::rule<Iterator, std::string()> uinteger2;
> uinteger2 = raw[+char_("01") >> *('#' >> attr('0'))] ;
>
> Session with debug(uinteger2):
>
>> #b1#
> <uinteger2>
>  <try>1#</try>
>  <success></success>
>  <attributes>(1#)</attributes>
> </uinteger2>
> success
>
> The leading #b is required but is consumed before uniteger2.
>
> Is the raw[] directive doing something funky?

The raw directive returns an iterator range into your input, so it is
not doing anything odd, you should just remove the raw part.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Spirit-general mailing list
Spirit-general <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-general

Re: Spirit rocks!

> > Yeah, we intend to have lots and lots of examples. More to come.
> > Do check out the site every once in a while. We'll have more tips
> > and stuff there.
> 
> Joel, you don't need lots of examples, you just need a few good ones,
> as mentioned before:
> 
> 1. Update the employee parser to do something more substantial
> 
> 2. Provide a full blown expression parser equivalent to STX, (this is a
> must)

Are you just interested to see how it's implemented or is this something you
would really like to have for your projects?

> 3. Provide a FIX parser, the "Parsing a List of Key-Value Pairs Using
> Spirit.Qi" doesn't go far enough, what if a semi-colon was to be apart
> of the value section, what is the correct syntax to "escape" certain
> chars (you could probably write a whole article on doing that
> properly), how can i provide a list of key's that I'm interested in
> such that only they are parsed and everything else is skipped?.

What's a FIX parser?

The article you're referring to was meant as an introduction to using Qi and
has to be seen in conjunction with its companion article "Output Generation
from a List of Key-Value Pairs Using Spirit.Karma"
(http://boost-spirit.com/home/?p=400). We intend to ramp up the complexity
of those examples but it's mainly a series implementing simple shrink
wrapped solutions for different everyday tasks. Frankly I prefer 20 well
written examples highlighting a subset of the functionality each over one
giant kitchen sink example showing everything at once.

Wrt your question 'what if a semi-colon was to be a part of the value
section?' - well, I started to answer this with another article: " Generate
Escaped String Output Using Spirit.Karma"
(http://boost-spirit.com/home/?page_id=626). There will be a corresponding
one for parsing this kind of structures soon, but it will be very much
orthogonal, obviously.

The "How can i provide a list of key's that I'm interested in such that only
they are parsed and everything else is skipped?" is a good question and I
might get back to that in yet another post. Thanks for the suggestion.

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Re: Expectation operator

On Mon, Nov 30, 2009 at 7:03 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> John Home wrote:
>>
>> Let me ask the question differently. How would you implement the error
>> handling in this situation?
>> Both "alpha 1;" and "beta 2;" are valid input for the main grammar.
>> The use of sub-grammars is due to practical reasons: all in one header
>> grammar is not practical/possible  for any medium to high complexity
>> grammar.
>
> Let's see... you have something like:
>
>     a = lit("alpha") > lit("1");
>
> then
>
>     b = lit("beta") > lit("2");
>
> Then the enclosing grammar:
>
>     c = a | b;
>
> In such case, you don't put expectation points in either a or b
> because they are allowed to fail. Put the expectation point
> only where it is not allowed to fail. In this case, it can be
> in the enclosing grammar, c. E.g.:
>
>    c = eps > a | b;
>
> You'll get something like:
>
>    Error, expecting a or b, but got xxx instead.
>
> Remember, use expectation points *only* on hard errors where
> you don't expect to back track.

Think of it this way, an expectation point basically means "NO
BACKTRACKING".  The | requires backtracking to work, so if you use an
expectation point, it cannot backtrack to try a different path (on
default on_error handling settings anyway).

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Spirit-general mailing list
Spirit-general <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-general