Hello all, I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list. I would like to request to add Boost.Local to the review schedule and for any volunteer to be the review manager. Thank you! Boost.Local supports local functions, local blocks, and local exits for C++. For example: #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT(const bind& size, bind nums) { if (size && nums) delete[] nums; std::cout << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); // `add` as template parameter BOOST_LOCAL_BLOCK(const bind& sum) { assert(sum == 1975.0); // so far `sum` is 10*100+10*90.5+10*7=1975 std::cout << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; } Documentation: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html Source code: http://svn.boost.org/svn/boost/sandbox/local/ Release Notes for Version 0.2.0 (2011-05-14) 1. Replaced parenthesized syntax with variadic and sequencing macro syntaxes. 2. Profiled library performances against other approaches. 3. Replaced virtual functor trick with casting functor trick (for smaller run-time). 4. Optimized library run-time (rearranging code and not using casting functor trick on compilers that accept local classes as template parameters). 5. Added BOOST_LOCAL_FUNCTION_NAME(inline ...) and BOOST_LOCAL_FUNCTION_NAME(recursive ...). 6. Added BOOST_LOCAL_TYPEOF. 7. Added bind(type) to specify bind type explicitly (skipping Boost.Typeof type deduction). 8. Removed boost::local::function (use boost::function instead). 9. Added boost::local::function::overload to overload local functions (and functors in general). 10. Implemented support for nesting local functions, blocks, and exits into one another. Boost.Local was used by Gregory Crosswhite in one of his project: https://github.com/gcross/CodeSearch -- Lorenzo
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Hello all,
I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list.
<snip> Hi Lorenzo, I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment: 1) I suggest adding: #ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif #ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT. 2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation? Thanks, Mostafa
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local... However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#... Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local... Thanks! --Lorenzo
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sun, May 15, 2011 at 12:42 AM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here:
http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code.
I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
Boost will require this macro to be named BOOST_LOCAL_WITH_DEFAULT even if it is controlled by the BOOST_LOCAL_ENABLE_BOOST_LOCAL_[VARIADIC/SEQUENCING]_WITH_DEFAULT switch: http://www.boost.org/development/requirements.html#Design_and_Programming I found this macro names to be longer and less readable than ", default x" or ")(default x" so I decided not to add BOOST_LOCAL_WITH_DEFAULT to the library defined macros. I simply to suggest in the library docs that programmers can define this macro if they find it readable. If during the review also other programmers request to add BOOST_LOCAL_WITH_DEFAULT, I am happy to consider it. --Lorenzo
On Sun, 15 May 2011 11:47:12 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Boost will require this macro to be named BOOST_LOCAL_WITH_DEFAULT even if it is controlled by the BOOST_LOCAL_ENABLE_BOOST_LOCAL_[VARIADIC/SEQUENCING]_WITH_DEFAULT switch: http://www.boost.org/development/requirements.html#Design_and_Programming
Oh, ok, I now see what you're saying. Thanks for the clarification.
I found this macro names to be longer and less readable than ", default x" or ")(default x" so I decided not to add BOOST_LOCAL_WITH_DEFAULT to the library defined macros. I simply to suggest in the library docs that programmers can define this macro if they find it readable. If during the review also other programmers request to add BOOST_LOCAL_WITH_DEFAULT, I am happy to consider it.
Yes, given your earlier clarification, I agree with you on the readability issue. However, I still see a use case for it, not as is, rather, the case where clients would just alias to WITH_DEFAULT. So please consider this my request for such an addition, in case I forget/don't participate in the review. Thank you, Mostafa
Mostafa-6 wrote:
On Sun, 15 May 2011 11:47:12 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Boost will require this macro to be named BOOST_LOCAL_WITH_DEFAULT even if it is controlled by the BOOST_LOCAL_ENABLE_BOOST_LOCAL_[VARIADIC/SEQUENCING]_WITH_DEFAULT switch: http://www.boost.org/development/requirements.html#Design_and_Programming
Oh, ok, I now see what you're saying. Thanks for the clarification.
I found this macro names to be longer and less readable than ", default x" or ")(default x" so I decided not to add BOOST_LOCAL_WITH_DEFAULT to the library defined macros. I simply to suggest in the library docs that programmers can define this macro if they find it readable. If during the review also other programmers request to add BOOST_LOCAL_WITH_DEFAULT, I am happy to consider it.
Yes, given your earlier clarification, I agree with you on the readability issue. However, I still see a use case for it, not as is, rather, the case where clients would just alias to WITH_DEFAULT.
Even if defining macros as follow might "feel" strange to programmers because of the leading "," or ")(": #define WITH_DEFAULT , default // (1) or: #define WITH_DEFAULT )(default // (2) The leading ", default ..." and ")(default ..." is part of Boost.Local public API so I think that Boost.Local users should be expected to be familiar with it. Therefore, I don't see a need for aliasing WITH_DEFAULT to a pre-defined BOOST_LOCAL_WITH_DEFAULT macro: #define WITH_DEFAULT BOOST_LOCAL_WITH_DEFAULT // (3) I would just expect programmers to define (1) or (2) directly if they feel these are more readable than using ", default ..." or ")(default ..." (I personally find the WITH_DEFAULT macro not useful at all but I am very used to use the "default" syntax). BTW, based on our discussion, I will add (2) to the library docs for completeness (right now only (1) is mentioned).
So please consider this my request for such an addition, in case I forget/don't participate in the review.
Yes, let's discuss more during the review together with other people that will be experimenting with the library. Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3526206.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Sat, May 14, 2011 at 9:06 PM, Mostafa <mostafa_working_away@yahoo.com> wrote:
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <lorcaminiti@gmail.com> I just took a quick glance at the documentation to get an understanding of the library, and I have a suggestion/comment:
1) I suggest adding:
#ifdef ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT #define WITH_DEFAULT , default #endif
#ifdef ENABLE_BOOST_LOCAL_SEQUENCING_WITH_DEFAULT #define WITH_DEFAULT ) default #endif
to the library. I think it makes client code more readable if they define ENABLE_BOOST_LOCAL_VARIADIC_WITH_DEFAULT or its variant rather than just defining WITH_DEFAULT.
Something similar (at least for the variadic syntax) is suggest in one of the docs examples -- see last example here: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
However, Boost macro naming conventions will require this macro to be named BOOST_LOCAL_WITH_DEFAULT if the macro were to be added to Boost.Local. IMO, that name is too long defeating the increased readability benefit. Therefore, I'd leave it up to programmers to #define WITH_DEFAULT if they wish to do so as suggested by the above doc example.
Yes, it was from the documentation where I originally got my motivation from. Just to be clear, I'm not suggesting replacing WITH_DEFAULT with BOOST_LOCAL_WITH_DEFAULT, or with my equivalents. Rather I was suggesting a "standard" switch be available which, if defined by the client, would enable the WITH_DEFAULT macro. As to the name being too long, I envisioned it (BOOST_LOCAL_WITH_DEFAULT or its equivalents) to be defined only *once* by the clients in a common header file, and then they would use the subsequently available WITH_DEFAULT through out the rest of their code. I guess I'm just being super lazy, because if I were going to define WITH_DEFAULT myself, then I would have to explicitly add a comment that its for use with Boost.Local, else it would look like a very strangely defined macro that would require a grep to figure out what it's used for. (I like self documenting code, hence the suggested names.)
2) In you're email you mentioned that Boost.Local functions can be used with stl algorithms, is this noted in the web documentation?
Yes, it is mentioned in a few places starting at the very beginning of the Introduction section (3rd bullet point from the top): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html#...
Here is a sketch of how Boost.Local implements passing local classes as template parameters (normally not allowed in ISO C++): http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
Thanks, I don't how I missed that first mention of it.
Hi Lorenzo, I have received your message and have added the Local library to the review schedule, Best, Ron On May 14, 2011, at 3:38 PM, Lorenzo Caminiti wrote:
Hello all,
I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list.
I would like to request to add Boost.Local to the review schedule and for any volunteer to be the review manager. Thank you!
Boost.Local supports local functions, local blocks, and local exits for C++. For example:
#include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp>
#include <algorithm> #include <iostream> #include <cassert>
int main() { double sum = 0.0; int factor = 10;
void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0);
size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT(const bind& size, bind nums) { if (size && nums) delete[] nums; std::cout << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END
nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); // `add` as template parameter
BOOST_LOCAL_BLOCK(const bind& sum) { assert(sum == 1975.0); // so far `sum` is 10*100+10*90.5+10*7=1975 std::cout << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END
return 0; }
Documentation: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html Source code: http://svn.boost.org/svn/boost/sandbox/local/
Release Notes for Version 0.2.0 (2011-05-14) 1. Replaced parenthesized syntax with variadic and sequencing macro syntaxes. 2. Profiled library performances against other approaches. 3. Replaced virtual functor trick with casting functor trick (for smaller run-time). 4. Optimized library run-time (rearranging code and not using casting functor trick on compilers that accept local classes as template parameters). 5. Added BOOST_LOCAL_FUNCTION_NAME(inline ...) and BOOST_LOCAL_FUNCTION_NAME(recursive ...). 6. Added BOOST_LOCAL_TYPEOF. 7. Added bind(type) to specify bind type explicitly (skipping Boost.Typeof type deduction). 8. Removed boost::local::function (use boost::function instead). 9. Added boost::local::function::overload to overload local functions (and functors in general). 10. Implemented support for nesting local functions, blocks, and exits into one another.
Boost.Local was used by Gregory Crosswhite in one of his project: https://github.com/gcross/CodeSearch
-- Lorenzo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ronald Garcia-4 wrote:
Hi Lorenzo,
I have received your message and have added the Local library to the review schedule,
Best, Ron
On May 14, 2011, at 3:38 PM, Lorenzo Caminiti wrote:
Hello all,
I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list.
Thank you very much Ron. Is there any volunteer for Boost.Local Review Manager? Gregory Crosswhite wrote:
I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope
Greg once mentioned that he would be willing to be the Review Manager but I am not sure if that is still a valid offer :) --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3529059.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5/17/11 5:40 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope
Greg once mentioned that he would be willing to be the Review Manager but I am not sure if that is still a valid offer:)
--Lorenzo
My offer still stands, with the same caveats I mentioned before. :-) Cheers, Greg
Gregory Crosswhite wrote:
On 5/17/11 5:40 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
I would be happy to volunteer to be the review manager if one is
needed
to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope
Greg once mentioned that he would be willing to be the Review Manager but I am not sure if that is still a valid offer:)
My offer still stands, with the same caveats I mentioned before. :-)
Greg, on my part, I gladly accept your offer to be the Review Manager for Boost.Local. Thank you! From: 1) The guidelines at http://www.boost.org/community/reviews.html#Review_Manager "Before a library can be scheduled for formal review, an active boost member not connected with the library submission must volunteer to be the "Review Manager" for the library." 2) The brief discussions at http://boost.2283326.n4.nabble.com/introductions-tt3529868.html 3) The fact that no Booster raised concerns I don't think that the caveats you mentioned should be of concern. http://www.boost.org/community/reviews.html#Wizard Ron (as the Review Wizard), would you consider Greg's offer to the Boost.Local's Review Manager acceptable? If yes, is it possible to assign a date to the Boost.Local review? Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3536110.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hello Lorenzo, Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless, thanks a lot Gregory for volunteering. I expect that you will provide an informed and high-quality review for this library when the time comes. Best, Ron On May 19, 2011, at 11:34 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
On 5/17/11 5:40 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
I would be happy to volunteer to be the review manager if one is
needed
to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope
Greg once mentioned that he would be willing to be the Review Manager but I am not sure if that is still a valid offer:)
My offer still stands, with the same caveats I mentioned before. :-)
Greg, on my part, I gladly accept your offer to be the Review Manager for Boost.Local. Thank you!
From: 1) The guidelines at http://www.boost.org/community/reviews.html#Review_Manager "Before a library can be scheduled for formal review, an active boost member not connected with the library submission must volunteer to be the "Review Manager" for the library." 2) The brief discussions at http://boost.2283326.n4.nabble.com/introductions-tt3529868.html 3) The fact that no Booster raised concerns I don't think that the caveats you mentioned should be of concern.
http://www.boost.org/community/reviews.html#Wizard
Ron (as the Review Wizard), would you consider Greg's offer to the Boost.Local's Review Manager acceptable? If yes, is it possible to assign a date to the Boost.Local review?
Thanks, --Lorenzo
-- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3536110.ht... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ron, I just wanted to say again as I have said before that it has occurred to me that you all might feel this way and so I completely understand and have no hard feelings at all about your decision. :-) Best regards, Greg On 5/19/11 12:56 PM, Ronald Garcia wrote:
Hello Lorenzo,
Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless, thanks a lot Gregory for volunteering. I expect that you will provide an informed and high-quality review for this library when the time comes.
Best, Ron
On May 19, 2011, at 11:34 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
On 5/17/11 5:40 AM, lcaminiti wrote:
Gregory Crosswhite wrote:
I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope
Greg once mentioned that he would be willing to be the Review Manager but I am not sure if that is still a valid offer:) My offer still stands, with the same caveats I mentioned before. :-)
Greg, on my part, I gladly accept your offer to be the Review Manager for Boost.Local. Thank you!
From: 1) The guidelines at http://www.boost.org/community/reviews.html#Review_Manager "Before a library can be scheduled for formal review, an active boost member not connected with the library submission must volunteer to be the "Review Manager" for the library." 2) The brief discussions at http://boost.2283326.n4.nabble.com/introductions-tt3529868.html 3) The fact that no Booster raised concerns I don't think that the caveats you mentioned should be of concern.
http://www.boost.org/community/reviews.html#Wizard
Ron (as the Review Wizard), would you consider Greg's offer to the Boost.Local's Review Manager acceptable? If yes, is it possible to assign a date to the Boost.Local review?
Thanks, --Lorenzo
-- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3536110.ht... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, May 19, 2011 at 3:56 PM, Ronald Garcia <rxg@cs.cmu.edu> wrote:
Hello Lorenzo,
Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless, thanks a lot Gregory for volunteering. I expect that you will provide an informed and high-quality review for this library when the time comes.
OK Ron, I think both Greg and I understand your point. Many thanks again to Greg for his offer :) Anyone else that feels like volunteering to be the Review Manager for Boost.Local? Thanks, --Lorenzo
On Sat, May 21, 2011 at 7:46 AM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello Lorenzo,
Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless,
On Thu, May 19, 2011 at 3:56 PM, Ronald Garcia <rxg@cs.cmu.edu> wrote: thanks a lot Gregory for volunteering. I expect that you will provide an informed and high-quality review for this library when the time comes.
OK Ron, I think both Greg and I understand your point. Many thanks again to Greg for his offer :)
Anyone else that feels like volunteering to be the Review Manager for Boost.Local?
After some prodding from Mr. Stewart, I could volunteer to be Review Manager for proposed Boost.Local, if the Review Wizards deem it appropriate. Greg, if you would like to aid in managing the review, I'd be all for it if the Review Wizards allow it. If things go well, I would take the initiative to manage the reviews of several other libraries in the queue in the future. I'll wait to hear from the Review Wizards, and if their response is positive, then Lorenzo, I, and (possibly) Greg can work out a schedule. Lorenzo, I'd like to go through the library a bit more in-depth (and yours isn't the only one!), submit change suggestions, and give you time to respond appropriately before the official review happens. - Jeff
On Tue, May 24, 2011 at 8:51 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
On Sat, May 21, 2011 at 7:46 AM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello Lorenzo,
Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless, thanks a lot Gregory for volunteering. I expect that you will
On Thu, May 19, 2011 at 3:56 PM, Ronald Garcia <rxg@cs.cmu.edu> wrote: provide an informed and high-quality review for this library when the time comes.
OK Ron, I think both Greg and I understand your point. Many thanks again to Greg for his offer :)
Anyone else that feels like volunteering to be the Review Manager for Boost.Local?
After some prodding from Mr. Stewart, I could volunteer to be Review Manager for proposed Boost.Local, if the Review Wizards deem it appropriate. Greg, if you would like to aid in managing the review, I'd be all for it if the Review Wizards allow it.
If things go well, I would take the initiative to manage the reviews of several other libraries in the queue in the future.
I'll wait to hear from the Review Wizards, and if their response is positive, then Lorenzo, I, and (possibly) Greg can work out a schedule. Lorenzo, I'd like to go through the library a bit more in-depth (and yours isn't the only one!), submit change suggestions, and give you time to respond appropriately before the official review happens.
[I realize my last sentence above may have indicated that I was going to follow up with (more) pre-review comments before expecting any further responses, and that was not the intention.] At the risk of embarassing myself for missing this, I don't recall getting a response concerning my volunteering to be Review Manager from the Review Wizards, so :: ping ::. Assuming I get an "okay" from the RWs, would the next step be for us (= me, Lorenzo, and Greg) to submit a request to reserve a couple of weeks within the review calendar? Thanks, - Jeff
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Tue, May 24, 2011 at 8:51 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
On Sat, May 21, 2011 at 7:46 AM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello Lorenzo,
Given Gregory's recent entry into the Boost community and process, I am not comfortable having him as manager for you library review. Nonetheless, thanks a lot Gregory for volunteering. I expect that you will
On Thu, May 19, 2011 at 3:56 PM, Ronald Garcia <rxg@cs.cmu.edu> wrote: provide an informed and high-quality review for this library when the time comes.
OK Ron, I think both Greg and I understand your point. Many thanks again to Greg for his offer :)
Anyone else that feels like volunteering to be the Review Manager for Boost.Local?
After some prodding from Mr. Stewart, I could volunteer to be Review Manager for proposed Boost.Local, if the Review Wizards deem it appropriate. Greg, if you would like to aid in managing the review, I'd be all for it if the Review Wizards allow it.
If things go well, I would take the initiative to manage the reviews of several other libraries in the queue in the future.
I'll wait to hear from the Review Wizards, and if their response is positive, then Lorenzo, I, and (possibly) Greg can work out a schedule. Lorenzo, I'd like to go through the library a bit more in-depth (and yours isn't the only one!), submit change suggestions, and give you time to respond appropriately before the official review happens.
[I realize my last sentence above may have indicated that I was going to follow up with (more) pre-review comments before expecting any further responses, and that was not the intention.]
At the risk of embarassing myself for missing this, I don't recall getting a response concerning my volunteering to be Review Manager from the Review Wizards, so :: ping ::. Assuming I get an "okay" from the RWs, would the next step be for us (= me, Lorenzo, and Greg) to submit a request to reserve a couple of weeks within the review calendar?
Hello review wizards, Would you consider Jeff offer to be Boost.Local review manager acceptable? Regards, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/local-Review-request-tp3522996p3660937.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hello Lorenzo, On Jul 11, 2011, at 5:38 PM, lcaminiti wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Tue, May 24, 2011 at 8:51 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
After some prodding from Mr. Stewart, I could volunteer to be Review Manager for proposed Boost.Local, if the Review Wizards deem it appropriate. Greg, if you would like to aid in managing the review, I'd be all for it if the Review Wizards allow it.
Hello review wizards,
Would you consider Jeff offer to be Boost.Local review manager acceptable?
Yes. I will update the review schedule to reflect that Jeff will be your review manager. Best, Ron
On Fri, Jul 15, 2011 at 2:27 AM, Ronald Garcia <rxg@cs.cmu.edu> wrote:
Hello Lorenzo,
On Jul 11, 2011, at 5:38 PM, lcaminiti wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Tue, May 24, 2011 at 8:51 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
After some prodding from Mr. Stewart, I could volunteer to be Review Manager for proposed Boost.Local, if the Review Wizards deem it appropriate. Greg, if you would like to aid in managing the review,
I'd
be all for it if the Review Wizards allow it.
Hello review wizards,
Would you consider Jeff offer to be Boost.Local review manager acceptable?
Yes. I will update the review schedule to reflect that Jeff will be your review manager.
Best, Ron
Greg (co-manager), Lorenzo, and I have agreed to schedule October 24 - 30 (inclusive) for the review. If you can add those dates to the review table, and put the review in the calendar, we'd appreciate it. Thanks, - Jeff
Hi Jeffrey, Library reviews are typically scheduled for 10 days. If you can confirm that October 24 - November 2 will work, then I will schedule it as such. On Jul 18, 2011, at 7:25 AM, Jeffrey Lee Hellrung, Jr. wrote:
Greg (co-manager), Lorenzo, and I have agreed to schedule October 24 - 30 (inclusive) for the review. If you can add those dates to the review table, and put the review in the calendar, we'd appreciate it.
Thanks,
- Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jul 18, 2011 at 12:44 AM, Ronald Garcia <rxg@cs.cmu.edu> wrote:
Hi Jeffrey,
Library reviews are typically scheduled for 10 days. If you can confirm that October 24 - November 2 will work, then I will schedule it as such.
On Jul 18, 2011, at 7:25 AM, Jeffrey Lee Hellrung, Jr. wrote:
Greg (co-manager), Lorenzo, and I have agreed to schedule October 24 - 30 (inclusive) for the review. If you can add those dates to the review
table,
and put the review in the calendar, we'd appreciate it.
October 24 - November 2 it is, then! Thanks, - Jeff
participants (6)
-
Gregory Crosswhite -
Jeffrey Lee Hellrung, Jr. -
lcaminiti -
Lorenzo Caminiti
-
Mostafa -
Ronald Garcia