headers
Hartmut Kaiser | 1 Nov 02:09
Picon
Gravatar

Re: Upcoming Boost V1.41 release

> I'd very much like to help in the rewrite. The largest part of the
> library is the AnyScalar type which essentially has an equivelent in
> boost. Where does one begin converting a grammar written in spirit
> classic to the new Qi grammar styles?

What about starting with the porting guide here: http://tinyurl.com/lk8r43?
This is really just a rough overview but should get you going.

Regards Hartmut

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Permalink | Reply | 4 comments |
headers
OvermindDL1 | 1 Nov 03:25
Picon

Re: Spirit Scripting Language

On Sat, Oct 31, 2009 at 1:27 AM, Taliesinnz <taliesin.nz <at> gmail.com> wrote:
>
> I am planning on writing a scripting language using Spirit. Im just wondering
> for advice on the best way to proceed. Using Syntemic Actions or attributes,
> How to build a AST? and parse form Spirit etc.
>
> I know there are already scripting languages out there, but I am doing this
> project to learn more about c++ and CPU's.

I have Spirit build a tree, mostly of variant's, then use visitors to
'execute' it, runs very fast then and keeps similar code in the same
place.  :)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Permalink | Reply | 0 comments |
headers
OvermindDL1 | 1 Nov 03:47
Picon

Re: Upcoming Boost V1.41 release

On Sat, Oct 31, 2009 at 7:09 PM, Hartmut Kaiser
<hartmut.kaiser <at> gmail.com> wrote:
>> I'd very much like to help in the rewrite. The largest part of the
>> library is the AnyScalar type which essentially has an equivelent in
>> boost. Where does one begin converting a grammar written in spirit
>> classic to the new Qi grammar styles?
>
> What about starting with the porting guide here: http://tinyurl.com/lk8r43?
> This is really just a rough overview but should get you going.

I did not really like some of the code I saw anyway, not very
Spirit2-friendly, I would just rewrite it based on the language
definition.  :)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Permalink | Reply | 3 comments |
headers
OvermindDL1 | 1 Nov 03:51
Picon

Boost.Lex and Boost.Qi reasons

I am curious, I have yet to see something in Boost.Lex that Boost.Qi
could not do and execute faster with directly.  Why use Boost.Lex to
parse into a token stream then parse that into your data, why not just
do it all at once, and much faster to boot, by just using Boost.Qi
itself only?  I just do not see the reasons to Lex something first, so
I am just trying to understand.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Permalink | Reply | 12 comments |
headers
Hartmut Kaiser | 1 Nov 03:54
Picon
Gravatar

Re: Spirit.lex Iteratorrequirements

> I am certainly not expecting you to me answer right away ... or even at
> all
> for that matter ;-)
> I do, however, very much appreciate your efforts and your patience !
> 
> I had looked at spirit a few years ago for a project and at the time
> decided
> to stick with flex/bison. I just recently found out about spirit 2.X
> and I
> have to say I am impressed. That said, even if the library is well
> designed
> and much better documented than most, the learning curve is steep.

I'm fully aware the Lex docs being not complete yet. But the examples should
give you some insights of what's possible. Generally we tried to make
everything available to replace flex. Please don't hesitate to ask if you're
stuck or if you don't know how to implement a specific feature.

> I can live with having to read a file into a string before lexing.
> I do think that supporting istream_iterator in some way is
> important ... after all, lexing/parser a file character stream is
> very a common task. One should not need to allocate 1 Gb of memory to
> lex a 1 Gb file.

I know. Support for lesser underlying iterators is high on my todo list.

> > Currently the lexer requires a random_access_iterator for accessing
> the
> > underlying input data.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel de Guzman | 1 Nov 04:35
Picon
Favicon

Spirit site upgrade (Beta)

Hi,

Here's a link to the new Spirit site (beta):
http://spirit.sourceforge.net/home/

- Finally settled on WordPress. It does the job wonderfully,
   with minimum fuss, and it has great support.

- The new docs are uploaded. The search box should be
   available once Google starts to index the new site
   (I already submitted a sitemap) for the Google Custom
   Search.

I'd like to hear your comments.

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joel de Guzman | 1 Nov 04:42
Picon
Favicon

Re: Boost.Lex and Boost.Qi reasons

OvermindDL1 wrote:
> I am curious, I have yet to see something in Boost.Lex that Boost.Qi
> could not do and execute faster with directly.  Why use Boost.Lex to
> parse into a token stream then parse that into your data, why not just
> do it all at once, and much faster to boot, by just using Boost.Qi
> itself only?  I just do not see the reasons to Lex something first, so
> I am just trying to understand.

In theory, the deterministic nature of Lex (using a DFA) makes it
faster than Qi, which is a backtracking recursive descent parser
with potentially quadratic worst-case performance (esp. with
poorly written code). This is especially true at the token level.

In practice... well... your mileage may vary. I really haven't
benchmarked specific applications.

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
(Continue reading)

Permalink | Reply | 2 comments |
headers
OvermindDL1 | 1 Nov 04:54
Picon

Re: Boost.Lex and Boost.Qi reasons

On Sat, Oct 31, 2009 at 9:42 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
> OvermindDL1 wrote:
>> I am curious, I have yet to see something in Boost.Lex that Boost.Qi
>> could not do and execute faster with directly.  Why use Boost.Lex to
>> parse into a token stream then parse that into your data, why not just
>> do it all at once, and much faster to boot, by just using Boost.Qi
>> itself only?  I just do not see the reasons to Lex something first, so
>> I am just trying to understand.
>
> In theory, the deterministic nature of Lex (using a DFA) makes it
> faster than Qi, which is a backtracking recursive descent parser
> with potentially quadratic worst-case performance (esp. with
> poorly written code). This is especially true at the token level.
>
> In practice... well... your mileage may vary. I really haven't
> benchmarked specific applications.

Hmm, I just instinctively thought it would be slower due to its use of
regex (not statically compiled) and the fact it is another pass you do
before running QI anyway to get your final parsed data.  I am curious,
we should do benchmarks...

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel de Guzman | 1 Nov 05:35
Picon
Favicon

Re: Boost.Lex and Boost.Qi reasons

OvermindDL1 wrote:
> On Sat, Oct 31, 2009 at 9:42 PM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> OvermindDL1 wrote:
>>> I am curious, I have yet to see something in Boost.Lex that Boost.Qi
>>> could not do and execute faster with directly.  Why use Boost.Lex to
>>> parse into a token stream then parse that into your data, why not just
>>> do it all at once, and much faster to boot, by just using Boost.Qi
>>> itself only?  I just do not see the reasons to Lex something first, so
>>> I am just trying to understand.
>> In theory, the deterministic nature of Lex (using a DFA) makes it
>> faster than Qi, which is a backtracking recursive descent parser
>> with potentially quadratic worst-case performance (esp. with
>> poorly written code). This is especially true at the token level.
>>
>> In practice... well... your mileage may vary. I really haven't
>> benchmarked specific applications.
> 
> Hmm, I just instinctively thought it would be slower due to its use of
> regex (not statically compiled) and the fact it is another pass you do
> before running QI anyway to get your final parsed data.  I am curious,
> we should do benchmarks...

You have a point. While the big-O complexity is, in theory, better than
RD, the hidden constants may be magnitudes apart. With RD, we have the
optimizer in our favor. With anything that's "interpreted", such as
DFAs, the limit of optimization goes as far as the implementation.
It makes me really curious now as to what the performance is vs. YACC,
for example. It blew me away when I saw benchmarks against ANTLR/PCCTS,
for example. LL(1) being another table based interpreter. I recall
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hartmut Kaiser | 1 Nov 14:06
Picon
Gravatar

Re: Boost.Lex and Boost.Qi reasons

> I am curious, I have yet to see something in Boost.Lex that Boost.Qi
> could not do and execute faster with directly.  Why use Boost.Lex to
> parse into a token stream then parse that into your data, why not just
> do it all at once, and much faster to boot, by just using Boost.Qi
> itself only?  I just do not see the reasons to Lex something first, so
> I am just trying to understand.

A lexer will be faster than a pure lexerless solution for grammars requiring
heavy backtracking. There lexing gives you 2 advantages

a) it avoids rescanning the input, this is done exactly once
b) it avoids re-converting input into token values, this is done once as
well

This is achieved by two means: the multi_pass iterator adaptor and some
clever lazy token value conversion which is executed only when first needed.

Regards Hartmut

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
(Continue reading)

Permalink | Reply | 7 comments |

Gmane