gmane.comp.parsers.spirit.devel

Re: [spirit] get_script method

Joel de Guzman — 2012-05-21T01:23:01

This is fixed in Boost trunk, FWIW. I'd still welcome some tests if you
care to provide some.

Regards,

Re: RFC: Add support for parsing binary integersofuser specified lengths

Hartmut Kaiser — 2012-05-15T11:31:02

Vitaly,

You're not ignored, I just have too many things on my plate currently to give sensible feedback on this. Others may have an opinion, though.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: RFC: Add support for parsing binary integers ofuser specified lengths

Vitaly Budovski — 2012-05-15T06:55:03

Hi,

Here is the updated version that works with and without predefined
terminals define.


Cheers,

Vitaly
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Feature request - attribute type should not be altered for terminal rules

Joel de Guzman — 2012-05-11T09:43:47


I see your point.

Perhaps a way to fix this is to introduce the concept of fixed attributes.
I.e. some parsers (e.g. word or even rule) have fixed attributes and
can therefore prevent attribute replacement. If int_ becomes a parser
with a fixed attribute, then it's attribute will always be int. Same for
word; same for rule<I, T()>; or grammar.

Thoughts?

I still have to think this through...

Regards,

Re: Feature request - attribute type should not be altered for terminal rules

Vitaly Budovski — 2012-05-11T03:10:39

Perhaps there is a way to introduce a step 2a, which checks
compatibility between the parsed result (bignum) and output result
(int) and issues a warning.
I guess what I'm saying is that Spirit should determine compatibility
between AA and DA.
If the user does the conversion manually to a compatible type e.g.
parse(f, l, _val = bignum_p[if_else_(_1 > 1e200, 5, 6)], int) there
will not be an issue.
Both 5 and 6 are convertible to int without overflow.



That is exactly why I have enabled it.
On the subject of spirit-3, perhaps you could write up a brief article
on what you see as the main shortcomings of v2 and what you hope to
achieve in v3.


Cheers,

Vitaly

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Feature request - attribute type should not be altered for terminal rules

Joel de Guzman — 2012-05-11T01:30:08

I probably did not communicate well on IRC. Let me try again.
So, what is the attribute of the int_ parser? By default, it is
int. However, if the user passes in his own attribute, the int_
parser uses its type and it becomes its attribute. Basically, for
any parser P, we have:

  1) DA: the default attribute type of P (for int_ it is int)
  2) AA: The actual attribute of P (the one that the user actually provides)

Essentially, P is not tied to its DD (default attribute type). For as long as
AA (The actual attribute) is 'compatible with' the parser P. It will be
accepted. For example, your AA can be short for parser int_. That is OK.
int_ will try to parse as much as it can, but report an error when the
short overflows. For that matter, it should also be possible to pass in
user defined types such as bignum for int_. When passed a bignum, the int_
parser will use it, parse the input, and compute the result (compile the
bignum).

Semantic actions use the AA attribute when you #define
BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT. That way, if you pass in a
bignum, your SA will get the bignum that int_ parsed for you.

(In your case, you are getting the warning because you passed in
an int which the word parser takes in as its AA and passes that to
your SA as _1 and you compare to an unsigned)

Now, imagine if we force int_ to always pass _1 with type int.
If you passed a bignum, that will be lossy!

  1) the int_ parser parses a big number, say
     "1234567890123456789012345678901234567"
  2) compiles that into a bignum
  3) converts it to an int (oops)
  4) passes it to your SA

Step no. 3 is problematic. The bignum will be downsized to an int.
Step no. 4 is also problematic because now, there is no way to get
the actual bignum result that was parsed.

(Aside: in spirit-3, BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT will
be the default behavior).

Regards,

Feature request - attribute type should not bealtered for terminal rules

Vitaly Budovski — 2012-05-10T07:00:21

Hi all,

I've discussed this with Joel on IRC, but am posting this to the list
so others can comment.
Currently code such as this results in unexpected behaviour (for me).

#define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT

int result;
parse(first, last, word[_val = if_else_(_1 > 1000u, -1, 5)], result);

This results in a warning about comparison between signed and unsigned
types (_1 > 1000u).
This is because the attribute type is converted to int to match the
type of the result variable, even though the type returned by word is
unsigned.

I would like to request a change in the behaviour for terminal rules,
if possible, so that this no-longer occurs. The type of _1 would now
be unsigned, and the comparison would happen without warnings. The two
possible branches output a type that is compatible with the type of
the output variable and so it succeeds.

The code below, however, should result in a warning or error:

int result;
parse(first, last, dword, result); // Difference in sign

or

unsigned result;
parse(first, last, qword, result); // Might overflow

Is this feasible?


Regards,

Vitaly

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [spirit] get_script method

Joel de Guzman — 2012-05-07T01:05:26

[..]


Looks like a bug indeed. Unicode support has not been fully tested.
Would you care to provide some tests for them?

Regards,

[spirit] get_script method

Keshav Krity — 2012-05-05T06:39:09

I am trying to get the script name for a given Unicode value. This is the method I am calling.

http://www.boost.org/doc/libs/1_49_0/boost/spirit/home/support/char_encoding/unicode/query.hpp

inline properties::script get_script(::boost::uint32_t ch)
{
     return static_cast<properties::script>(detail::script_lookup(ch) & 0x3F);
}


enum script

{

.

.

.

common = 92,

unknown = 93

}



This api is not returning "common" script for characters such as space. The reason being the & operation with 0x3F. It restricts the return value to the range 0-63. Thus the values in the enum "script" greater that 63 will never be returned.

I fail to understand the logic behind this. Can somebody please explain the behavior, why the values are being restricted to top 64 only?

Thanks

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Keywords parser msvc 9.0 patch

Joel de Guzman — 2012-05-03T00:51:58

patches applied.

Regards,

RFC: Add support for parsing binary integers of userspecified lengths

Vitaly Budovski — 2012-05-01T11:22:54

Hi,

See the attached patch. Please not that it doesn't currently work
unless BOOST_SPIRIT_NO_PREDEFINED_TERMINALS is defined.
Can anyone suggest how I might fix this?


Regards,

Vitaly
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Keywords parser msvc 9.0 patch

teajay — 2012-04-09T18:34:47

Hello,

Here's a patch which fixes the issues I found with the last patch with 
msvc 9.0.

I also pushed the modifications on the ryppl git mirror of boost.

Regards,
Thomas Bernard
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Fields of type lex::char_

Joel de Guzman — 2011-11-19T11:51:20

Pardon the delay. The list is still active but is somehow superseded
by the Spirit IRC channel where dev related discussions happen.
I'll get back to you later. Right now, I'm typing this in a small
netbook and don't have access to the code.

Regards,

Fields of type lex::char_

Ryan Molden — 2011-11-07T17:03:56

Sorry if this is duplicated, I originally sent it two days ago but I never
saw it appear back in my inbox as a list message (I actually haven't seen
*any* messages to this list yet...is it still active?), nor have I seen any
follow-up, so I thought I would send it again in case I hadn't been
properly registered as one allowed to send mail when I sent it the first
time.

I am having some problems having fields on my lexer of type lex::char_,
specifically I get the following errors in Visual Studio 2010 SP1 with
Boost 1.47

C2146: syntax error : missing ';' before identifier 'simple'
C2886: 'boost::spirit::standard::char_' : symbol cannot be used in a member
using-declaration
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
C2146: syntax error : missing ';' before identifier 'simple'
C2886: 'boost::spirit::standard::char_' : symbol cannot be used in a member
using-declaration
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int

This is with the following simplified repro

#include <boost/spirit/include/lex_lexertl.hpp>

namespace lex = boost::spirit::lex;

template <typename Lexer>
struct lexer : lex::lexer<Lexer>
{
    lexer()
    {
        simple = lex::char_('.');
        this->self += simple;

        //This works, but I need/want to store the char_ object so I can
later reference its token ID from the parser level:
        //this->self += lex::char_('.');
        //
        //as does this (though in my real lexer I have LOTS of token_defs
and as I add more the compile time gets worse and worse):
        //
        //this->self += lex::token_def<>('.');
    }
    lex::char_ simple;
};

struct token_processor
{
    template <typename Token>
    bool operator()(Token const& t) const
    {
        return true;
    }
};

int main(int argc, char**argv[])
{
    std::string str (".");
    char const* first = str.c_str();
    char const* last = &first[str.size()];

     lexer<lex::lexertl::actor_lexer<> > l;
    bool r = lex::tokenize(first, last, l, token_processor());

    return 0;
}

Is this a Visual Studio 'issue' or something I am doing wrong?

Ryan
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Missing documentation file.

Joel de Guzman — 2011-11-04T20:10:02

TONGARI, could you please send me the latest patch for that?
I seem to have missed the one you sent me on the seek directive.
Thanks!

Regards,

Missing documentation file.

Daniel James — 2011-11-02T08:50:45

Hi,

The spirit repository doc build is failing at the moment, it looks
like 'libs/spirit/repository/doc/what_s_new.qbk' is missing in trunk.

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1

Patch for qi::seek[] doc

TONGARI — 2011-10-27T16:18:33

Hi list,

There's an issue I overlooked in qi::seek[], in conjunction with sequence
(i.e. a >> b) and skipping.

Consequently, I decided to change my seek.cpp example, adding one note to
the doc that guides the users to deal with the case.

The complexity section is also modified, I hope I get it right this time.


Thanks!
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: [website] Please fix the link to nabble.

Joel de Guzman — 2011-10-27T01:21:37

Fixed. Thanks, TONGARI!

Regards,

[website] Please fix the link to nabble.

TONGARI — 2011-10-26T18:19:23

Hi,

The nabble link in the support page:
http://boost-spirit.com/home/feedback-and-support/

is dead (http://old.nabble.com/The-Spirit-Parser-Library-f3430.html).

Please change to
http://boost.2283326.n4.nabble.com/The-Spirit-Parser-Library-f2672581.html

Thanks.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Strange behaviour of boost::spirit::get_current_line

Скуратович Сергей — 2011-10-26T08:47:04

Hello.

When content in range [current, upper_bound) contains multiple lines, get_current_line(lower_bound, current, upper_bound) returns iterator range, which includes all lines after current excluding last. Is this behaviour correct? I think,
the returning of only one current line is more expecting behaviour. The patch for that behaviour is attached.

Thanks.------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Re: Move generated spirit docs to the sandbox

Hartmut Kaiser — 2011-10-25T00:41:16

Ok, I'll just commit to the main SVN, then.

Thanks!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu



------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev