You can subscribe to this list here.
2003 |
Jan
|
Feb
(101) |
Mar
(126) |
Apr
(262) |
May
(72) |
Jun
(76) |
Jul
(82) |
Aug
(92) |
Sep
(73) |
Oct
(70) |
Nov
(160) |
Dec
(107) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(95) |
Feb
(123) |
Mar
(24) |
Apr
(24) |
May
(133) |
Jun
(256) |
Jul
(108) |
Aug
(40) |
Sep
(112) |
Oct
(25) |
Nov
(69) |
Dec
(87) |
2005 |
Jan
(35) |
Feb
(38) |
Mar
(6) |
Apr
(1) |
May
(2) |
Jun
(12) |
Jul
(27) |
Aug
|
Sep
(16) |
Oct
(23) |
Nov
(22) |
Dec
(4) |
2006 |
Jan
(3) |
Feb
(12) |
Mar
(41) |
Apr
(122) |
May
(101) |
Jun
(37) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(21) |
Nov
(89) |
Dec
(12) |
2007 |
Jan
(19) |
Feb
(48) |
Mar
(30) |
Apr
(52) |
May
(31) |
Jun
(30) |
Jul
(6) |
Aug
(16) |
Sep
(16) |
Oct
(2) |
Nov
(4) |
Dec
|
2008 |
Jan
(26) |
Feb
(29) |
Mar
(6) |
Apr
(11) |
May
(5) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(86) |
Nov
(34) |
Dec
(33) |
2009 |
Jan
(59) |
Feb
(35) |
Mar
(73) |
Apr
(17) |
May
(15) |
Jun
(20) |
Jul
(9) |
Aug
(24) |
Sep
(11) |
Oct
(14) |
Nov
(18) |
Dec
(4) |
2010 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(9) |
May
(9) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
(17) |
Dec
(27) |
2011 |
Jan
(32) |
Feb
(14) |
Mar
(11) |
Apr
(7) |
May
(5) |
Jun
|
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
(29) |
Nov
(4) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(11) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
(2) |
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Fletcher, J. P <j.p...@as...> - 2012-07-02 07:48:50
|
Thomas Thank you for the information. Is it a simple patch you could post so that I can patch my installations of 1.49.0 and (presumably) 1.50.0? I had found phoenix::detail::expression::function_eval while searching the code and also the table at http://boost-sandbox.sourceforge.net/libs/phoenix/doc/html/phoenix/inside/rules.html so I thought it was supposed to exist. Thanks John ________________________________________ From: Thomas Heller [tho...@go...] Sent: 02 July 2012 07:32 To: Joel de Guzman Cc: Fletcher, John P; Spirit Development; Thomas Heller Subject: Re: Phoenix Example problem On 07/02/2012 01:56 AM, Joel de Guzman wrote: > On 7/1/2012 8:21 PM, Fletcher, John P wrote: >> Joel >> >> I am having a problem compiling the example container_actor.cpp which >> is in the Phoenix >> manual and also the examples. I have been compiling it with g++ >> 4.4.3 and also with >> clang 3.1 and neither works. The clang error messages look like this: > > I could repro the problem. Thomas, what is phoenix::expression::function? Thanks for bringing it to my attention. Fixed on trunk. phoenix::expression::function is supposed to be a struct responsible for creating expression template objects and calculating the expression template type for a phoenix function expression. Looks like i just forgot to alias it ... there was already a phoenix::detail::expression::function_eval which is part of the core, and used in a variety of places (for example bind). more information about these expression types can be found here: http://boost-sandbox.sourceforge.net/libs/phoenix/doc/html/phoenix/inside/expression.html and here: http://boost-sandbox.sourceforge.net/libs/phoenix/doc/html/phoenix/inside/rules.html > > Regards, |
From: Joel de G. <jo...@bo...> - 2012-07-02 00:25:15
|
On 7/1/2012 8:21 PM, Fletcher, John P wrote: > Joel > > I am having a problem compiling the example container_actor.cpp which is in the Phoenix > manual and also the examples. I have been compiling it with g++ 4.4.3 and also with > clang 3.1 and neither works. The clang error messages look like this: I could repro the problem. Thomas, what is phoenix::expression::function? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Fletcher, J. P <j.p...@as...> - 2012-07-01 12:36:43
|
Joel I am having a problem compiling the example container_actor.cpp which is in the Phoenix manual and also the examples. I have been compiling it with g++ 4.4.3 and also with clang 3.1 and neither works. The clang error messages look like this: phoenix_container_actor.cpp:58:35: error: no template named 'function' in namespace 'boost::phoenix::expression'; did you mean 'boost::phoenix::function'? typename phoenix::expression::function<phoenix::stl::begin, ... ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ boost::phoenix::function ./boost/phoenix/function/function.hpp:25:12: note: 'boost::phoenix::function' declared here struct function ^ phoenix_container_actor.cpp:58:35: error: too many template arguments for class template 'function' typename phoenix::expression::function<phoenix::stl::begin, that_type>... ^ ~~~~~~~~~~ ./boost/phoenix/function/function.hpp:25:12: note: template is declared here struct function ^ phoenix_container_actor.cpp:58:77: error: expected a qualified name after 'typename' ...that_type>::type const ^ phoenix_container_actor.cpp:58:81: error: expected ';' at end of declaration list ...that_type>::type const ^ ; 4 errors generated. make: *** [phoenix_container_actor_clang31] Error 1 I have looked through the phoenix headers and cannot find the namespace boost::phoenix::expression at all. Am I missing something? Best wishes John |
From: Joel de G. <jo...@bo...> - 2012-05-21 01:23:29
|
On 5/7/2012 9:05 AM, Joel de Guzman wrote: > On 5/5/2012 2:39 PM, Keshav Krity wrote: >> 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); } > > [..] > >> 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? > > Looks like a bug indeed. Unicode support has not been fully tested. > Would you care to provide some tests for them? This is fixed in Boost trunk, FWIW. I'd still welcome some tests if you care to provide some. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Hartmut K. <hk...@bo...> - 2012-05-15 11:31:26
|
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 > -----Original Message----- > From: Vitaly Budovski [mailto:vbu...@gm...] > Sent: Tuesday, May 15, 2012 1:55 AM > To: Spirit Development > Subject: Re: [Spirit-devel] RFC: Add support for parsing binary integers > of user specified lengths > > On 1 May 2012 21:22, Vitaly Budovski <vbu...@gm...> wrote: > > 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 > > Hi, > > Here is the updated version that works with and without predefined > terminals define. > > > Cheers, > > Vitaly |
From: Vitaly B. <vbu...@gm...> - 2012-05-15 06:55:12
|
On 1 May 2012 21:22, Vitaly Budovski <vbu...@gm...> wrote: > 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 Hi, Here is the updated version that works with and without predefined terminals define. Cheers, Vitaly |
From: Joel de G. <jo...@bo...> - 2012-05-11 09:44:15
|
On 5/11/2012 11:10 AM, Vitaly Budovski wrote: >> 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. >> > > 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. 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, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Vitaly B. <vbu...@gm...> - 2012-05-11 03:10:48
|
On 11 May 2012 11:30, Joel de Guzman <jo...@bo...> wrote: > 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. > 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. > (Aside: in spirit-3, BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT will > be the default behavior). > > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://boost-spirit.com 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 |
From: Joel de G. <jo...@bo...> - 2012-05-11 01:30:32
|
On 5/10/2012 3:00 PM, Vitaly Budovski wrote: > 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? 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, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Vitaly B. <vbu...@gm...> - 2012-05-10 07:00:30
|
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 |
From: Joel de G. <jo...@bo...> - 2012-05-07 01:05:50
|
On 5/5/2012 2:39 PM, Keshav Krity wrote: > 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); } [..] > 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? Looks like a bug indeed. Unicode support has not been fully tested. Would you care to provide some tests for them? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Keshav K. <kk...@ad...> - 2012-05-05 06:40:25
|
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 |
From: Joel de G. <jo...@bo...> - 2012-05-03 00:52:22
|
On 4/10/2012 2:34 AM, teajay wrote: > 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. patches applied. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Vitaly B. <vbu...@gm...> - 2012-05-01 11:23:00
|
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 |
From: teajay <th...@fa...> - 2012-04-09 18:40:15
|
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 |
From: Joel de G. <jo...@bo...> - 2011-11-19 11:55:18
|
On 11/8/2011 1:03 AM, Ryan Molden wrote: > 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. 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, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net |
From: Ryan M. <rya...@gm...> - 2011-11-07 17:04:06
|
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 |
From: Joel de G. <jo...@bo...> - 2011-11-04 20:10:28
|
On 11/2/2011 4:50 PM, Daniel James wrote: > 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. 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, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: Daniel J. <dn...@gm...> - 2011-11-02 08:50:53
|
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. |
From: Joel de G. <jo...@bo...> - 2011-10-27 01:22:04
|
On 10/27/2011 2:19 AM, TONGARI wrote: > 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 > Fixed. Thanks, TONGARI! Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com |
From: TONGARI <ton...@gm...> - 2011-10-26 18:19:31
|
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. |
From: Скуратович С. <ss...@ya...> - 2011-10-26 08:47:14
|
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. |
From: Hartmut K. <hk...@bo...> - 2011-10-25 00:41:27
|
> On 24 October 2011 13:21, Hartmut Kaiser <hk...@bo...> wrote: > > > > What's the policy now for documentation changes? I know I have to > > check in the qbk files, do I still need to generate the html files and > > put them somewhere? Or do you have an automated script running which > > does that on demand? > > I just run the script every few days (I don't have the resources for a > quick turnaround). You'll still need to generate the documentation > yourself to check that it's okay. If you want to, you could upload the > documentation to sourceforge yourself. I just rsync it, so it should be > okay. Ok, I'll just commit to the main SVN, then. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > The main problem is that it will overwrite the redirect file when you > generate the documentation yourself. Maybe it should build to one > directory by default (with an appropriate svn:ignore), and then when I > build the documentation I'll run it with a flag to put it in the right > place. I'm not sure exactly how to do that, maybe a docbook xsl parameter? > > -------------------------------------------------------------------------- > ---- > 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@Cisco Self-Assessment and learn about Cisco > certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Spirit-devel mailing list > Spi...@li... > https://lists.sourceforge.net/lists/listinfo/spirit-devel |
From: Daniel J. <dn...@gm...> - 2011-10-24 12:38:31
|
On 24 October 2011 13:21, Hartmut Kaiser <hk...@bo...> wrote: > > What's the policy now for documentation changes? I know I have to check in > the qbk files, do I still need to generate the html files and put them > somewhere? Or do you have an automated script running which does that on > demand? I just run the script every few days (I don't have the resources for a quick turnaround). You'll still need to generate the documentation yourself to check that it's okay. If you want to, you could upload the documentation to sourceforge yourself. I just rsync it, so it should be okay. The main problem is that it will overwrite the redirect file when you generate the documentation yourself. Maybe it should build to one directory by default (with an appropriate svn:ignore), and then when I build the documentation I'll run it with a flag to put it in the right place. I'm not sure exactly how to do that, maybe a docbook xsl parameter? |
From: Hartmut K. <hk...@bo...> - 2011-10-24 12:27:32
|
> On 16 October 2011 16:14, Joel de Guzman <jo...@bo...> > wrote: > > > > Please go ahead. Just make sure that all docs are available. > > Thanks, Daniel! > > > > BTW, please do the same for Phoenix too. > > OK, it's done on trunk, and I've rebuilt the trunk documentation including > phoenix and the spirit repository. Daniel, What's the policy now for documentation changes? I know I have to check in the qbk files, do I still need to generate the html files and put them somewhere? Or do you have an automated script running which does that on demand? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu |