[local] Review request

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[local] Review request

lcaminiti
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
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

lcaminiti
On Sat, May 14, 2011 at 9:06 PM, Mostafa <[hidden email]> wrote:

> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti <[hidden email]>
> 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/Tutorial.html#boost_local.Tutorial.default_parameters

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#boost_local.Introduction

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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks!

--Lorenzo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
In reply to this post by lcaminiti
On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti  
<[hidden email]> wrote:

> On Sat, May 14, 2011 at 9:06 PM, Mostafa  
> <[hidden email]> wrote:
>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti  
>> <[hidden email]>
>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>
> 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#boost_local.Introduction
>
> 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/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters

Thanks, I don't how I missed that first mention of it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

lcaminiti
In reply to this post by Mostafa-6
On Sun, May 15, 2011 at 12:42 AM, Mostafa
<[hidden email]> wrote:

> On Sat, 14 May 2011 18:24:36 -0700, Lorenzo Caminiti <[hidden email]>
> wrote:
>
>> On Sat, May 14, 2011 at 9:06 PM, Mostafa <[hidden email]>
>> wrote:
>>>
>>> On Sat, 14 May 2011 12:38:50 -0700, Lorenzo Caminiti
>>> <[hidden email]>
>>> 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/Tutorial.html#boost_local.Tutorial.default_parameters
>>
>> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Mostafa-6
On Sun, 15 May 2011 11:47:12 -0700, Lorenzo Caminiti  
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

lcaminiti
Mostafa-6 wrote
On Sun, 15 May 2011 11:47:12 -0700, Lorenzo Caminiti  
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Ron Garcia
In reply to this post by lcaminiti
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

lcaminiti
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
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Gregory Crosswhite
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

lcaminiti
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
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Ron Garcia
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.html
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [local] Review request

Gregory Crosswhite
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.html
>> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12