headers
Michael Caisse | 1 Mar 2010 01:07

Re: [Review] ITL review extended until March 7th

Hartmut Kaiser wrote:
> Hey all,
>
> After getting the approval from our review wizards we decided to extend the
> review period of Joachim Faulhabers ITL library until March 7th, 2010. That
> should give everybody some more time to finish their reviews.
>
> Regards Hartmut
>
> ---------------
> Meet me at BoostCon
> www.boostcon.com
>
>
>   

I want to thank the review wizards, Hartmut and Joachim
for extending the period. My work schedule will not allow
me to submit a review until later this week.

I have been using ITL since November and will provide
feedback on my experience by the 7th.

thanks -
michael

--

-- 

----------------------------------
Michael Caisse
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthias Walter | 1 Mar 2010 01:08

Re: [BGL] Testing a graph for bipartiteness

> If possible, I would tar or zip the submission and then send a link to the
> mailing list. If you don't have a convenient place to put it online, then
> you upload it to the Boost Vault. I'd put it the Algorithms/graph directory.
> 
> After posting that, I'll review it and the documentation and then merge it
> into the trunk. It will probably take a couple of days once you have
> everything together.

I've uploaded the bipartiteness stuff onto boost vault, as you recommended:

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bipartite.zip&directory=Algorithms/graph&

The documentation is in the same manner as the other algorithms,
the example creates two graphs, tests them and prints the partitition
(1st graph) and the odd-cycle (2nd graph), while the test code calls all
implemented interfaces and verifies the certificates. The test code uses
boost/test/minimal.hpp structure.

Matthias Walter
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 10 comments |
headers
vicente.botet | 1 Mar 2010 01:31
Picon

Re: [Review] ITL review starts today, February 18th


----- Original Message ----- 
From: "Joachim Faulhaber" <afojgo <at> googlemail.com>
To: <boost <at> lists.boost.org>
Sent: Monday, March 01, 2010 12:23 AM
Subject: Re: [boost] [Review] ITL review starts today, February 18th

> 
> Hi Barend,
> 
> thank you again for all the effort and diligence that you invested to
> investigate my library :)
> 
> I am going to address the issues you raised piecemeal in a sequence of
> importance that I consider for them. Generalized addition, subtraction and
> intersection operators are at the heart of the library. So I'll begin here:
> 
> 5) OPERATORS and FUNCTIONS
> 
>> During the review period I had a discussion on the list with Joachim about
>> the operators and the naming of functions. However, I thought that the +=
>> and |= were both doing a pure union, but it appears that they are doing a
>> union PLUS a (sometimes mathematic) addition.
> 
> 
> this is correct.
> 
> As I have outlined in the documentation, all Sets and Maps of the ITL are
> Addable and Subtractable. Addability is more fundamental than
> Subtractability. Addability in the sense I have in mind could also be called
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikolay Mladenov | 1 Mar 2010 03:10
Picon

Re: [Serialization] extended_type_info.hpp

Hello Mr Ramey,

export.hpp includes itself with the comment

// for guid_defined only
(see the diff below)

but guid_defined is in extended_type_info.hpp

so I assume this is a typo

And without the inclusion of extended_type_info.hpp
export.hpp *really* specializes the  undefined template guid_defined, as
the error message posted from Fabien shows.

Regards,

Nikolay Mladenov

$ svn diff -r HEAD  export.hpp
Index: export.hpp
===================================================================
--- export.hpp  (revision 59992)
+++ export.hpp  (working copy)
 <at>  <at>  -34,7 +34,7  <at>  <at> 
 #include <boost/mpl/not.hpp>
 #include <boost/mpl/bool.hpp>

-#include <boost/serialization/export.hpp> // for guid_defined only
+#include <boost/serialization/extended_type_info.hpp> // for guid_defined only
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gennadiy Rozental | 1 Mar 2010 05:20
Picon
Gravatar

Re: is review system in place is extremely slow? (was Re:[rfc] rcpp)

Vicente Botet wrote:
> Hi Gennadiy,

>> * Some libraries come up without proper substantiation leading to review 
>> process and only being rejected by "lack of interest" argument
> 
> 
> The author and the review manager should start already a review only if they have checked that the library
has enough interest..

More formal procedure for people to second/support the submission would 
be helpful

>> * Some libraries comes not being ready for review. There is 
>> automatically checked list of requirements before scheduling the review.
> 
> This should be checked already by the review manager.

I guess. I was after a script that can perform basis automatic checks.

>> That's said, here's how better procedure might look like IMO. This will 
>> require some initial investment in writing scripts for process 
>> automation, but in a long run we should be very well compensated.
>>
>> 1. Any library author interrested in submission of new library should 
>> come to the "Candidate" page and register. Once registered candidate gets:
>>    a) svn repository for the library
>>    b) standardized page on boost website (something like 
>> boost.org/candidate/≤candidate name>
>>    c) announcement post is sent automatically (with abstract and link
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Ramey | 1 Mar 2010 05:48

Re: [Serialization] extended_type_info.hpp

OK - I see it now. Done.

Robert Ramey

Nikolay Mladenov wrote:
> Hello Mr Ramey,
>
> export.hpp includes itself with the comment
>
> // for guid_defined only
> (see the diff below)
>
> but guid_defined is in extended_type_info.hpp
>
> so I assume this is a typo
>
> And without the inclusion of extended_type_info.hpp
> export.hpp *really* specializes the  undefined template guid_defined,
> as
> the error message posted from Fabien shows.
>
> Regards,
>
> Nikolay Mladenov
>
> $ svn diff -r HEAD  export.hpp
> Index: export.hpp
> ===================================================================
> --- export.hpp  (revision 59992)
> +++ export.hpp  (working copy)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gennadiy Rozental | 1 Mar 2010 05:52
Picon
Gravatar

Re: is review system in place is extremely slow? (was Re: [rfc] rcpp)

Andrey Semashev wrote:
> On 02/28/2010 07:24 PM, Gennadiy Rozental wrote:
>> Not really. The transition occurs almost automatically and
>> asynchronously. There is no any queue. If one library has bigger support
>> and interest in a community, it will go through the phases much faster.
> 
> Well, the current queue isn't really a queue, as reviews can happen in 
> any order.

Are they? Who is making the decision who comes first? Aside of lack of 
review manager?

>>>> 4. Review process.
>>>> The candidate review can start at any time by the review manager (no
>>>> queue) and should take at least 2-4 month. There can be any number of
>>>> reviewed being run concurrently. The "candidate review" page should
>>>> include abstract, review package, and some kind of review submission
>>>> mechanism (maybe boolean yes/no + an actual review). The review should
>>>> be per person and each reviewer should have an ability to modify the
>>>> review.
>>>> Review discussion mechanism can be web based on rely on mailing list or
>>>> some mixture of these.
>>>
>>> I disagree, in several points.
>>>
>>> * 2-4 months is a very long period.
>>
>> Somehow you are fine with C++ standard changes being reviewed for years,
>> but find 2-4 month for non-trivial C++ library too long?
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Vladimir Prus | 1 Mar 2010 07:13

Re: is review system in place is extremely slow? (was Re:[rfc] rcpp)

Robert Ramey wrote:

> Vladimir Prus wrote:
>> This is pretty straight-forward to implement:
>>
>> 1. Create a branch off the last release
>> 2. For each proposed library living in sandbox, add a couple of
>> svn:externals into the new branch.
>> 3. Modify status/Jamfile.v2 to only run the tests for the new
>> libraries.
>> 4. Have one, or more people run tests on the new branch.
>> 5. Adjust reporting process to produce one more set of tables.
>>
>> Of this, (1) and (2) is done in a matter of minutes. (3) requires
>> really minimal hacking. (4) requires a volunteer. I personally don't
>> know how to
>> do (5) but should not be hard either.
> 
> I think this is even simpler
> 
> 1) use the release branch
> 2) put the library to be tested into that branch - only on the local testing
> machine.
> 3) CD to boost/libs/newlib/test
> 4) run ../../../tools/src/library_test.sh (or bat) --toolset=msvc-7.1 (or
> whatever)
> 5) this will create a pair of  local html tables in boost/libs/newlib/test
> which
> show all test results.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
eg | 1 Mar 2010 07:39
Picon

Re: [iostreams] array and gzip_decompressor

On 2/23/2010 10:48 PM, Nikolay Mladenov wrote:
>
> Is there another way I should be creating gzipped stream into memory?
> Or maybe the arrays could be made peekable?
>

Perhaps you could read it into a stringstream.

namespace io = boost::iostreams;

io::filtering_istream in;
in.push(io::gzip_decompressor());
in.push(io::file_source(fileName.c_str(), std::ios_base::in | 
std::ios_base::binary));
std::stringstream	memStream;
memStream << in.rdbuf();
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Daniel Larimer | 1 Mar 2010 08:00
Picon

boost::optional<void>

I am writing some generic code and would like to handle "all values" the same way; however, I keep running
into the problem of return void return types that need "special treatment".  There is nothing I can do about
it most of the time except template specialization. 

That said, it would be helpful if boost::optional<void> could have some sensible default implementation
where it acts more or less like a boolean.   As it is, I will probably provide my own specialization of
boost::optional to simplify my templates.

Any thoughts on this?

Dan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |

Gmane