[review queue] What to do about the library review queue?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
158 messages Options
123456 ... 8
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 15.03.2017 12:16, Niall Douglas via Boost wrote:
> If we at least could segment
> the bad libraries into a "bad Boost" distro, it would be a huge improvement.

Speaking of segmentation (I'm deliberately avoiding to comment on your
rant about flaws in specific libraries): I think it's a huge waste of
effort that the attempt to modularize Boost is stalled. It could be
really useful if pushed further, but in its current state is almost
useless to users as well as most developers.

Once Boost libraries are decoupled and autonomous, the "Boost branding"
would take on a different meaning, as users could more freely and
deliberately pick what Boost library they want as part of their
development (as well as runtime) platform.

Likewise, I still don't understand why build and test infrastructure
keeps being a central issue (in particular a "brand damaging" one, as
you state). Providing helpful tools for library developers to use is
certainly useful, but shouldn't be in any way constraining. And if
people strive for accelerated growth, trying to push for universal
policies and tools becomes an ever increasing problem.

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 15, 2017 at 5:16 PM, Niall Douglas via Boost
<[hidden email]> wrote:
> There are increasing problems with Boost.ASIO as it gets ever further
> away from ASIO.

Why is Boost Asio diverging from Asio?

--
Olaf

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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 14 March 2017 at 22:25, Robert Ramey via Boost <[hidden email]>
wrote:

> A much more interesting question: Why did you not submit a review
> yourself?  I think it would have been helpful to me as an author and to you
> in better understanding your own concerns.


Because I think the idea is flawed from the start.

int x = 2 * 2;

is wrong in principle, correct would be:

int64_t x = 2 * 2;

This is what happens in the CPU. C and C++ are wrong to allow multiplying
two ints and assign the result to an int (the cpu does not do that!). Then
of course there is the issue of two's-complement, clouding stuff even
further.

 If one wants to be safe, the only real option is to use bignums (GMP,
whatever). This is what implementations of languages like prolog and scheme
do (I'm thinking of SWI-Prolog and Racket f.e.). Shifts (left of right) get
a whole different meaning...

Reals (floats, doubles, quads) are already so broken in many ways, that I
wouldn't even like to comment. Even MPFR doesn't add much here, except
increased (but still relative) precision.

I'm of the opinion that the only real option (if one wants performance) is
to be very aware, learned and carefull regarding the issues, when dealing
with numbers in C or C++. And this is far from simple, signed zeros,
subnormal numbers, infinities, NaN's, roundings...

One of the review questions is: "would you use it?"

Sorry, no!

degski

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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2017 9:22, Andrzej Krzemienski via Boost wrote:
> 2017-03-14 13:01 GMT+01:00 Niall Douglas via Boost <[hidden email]>:
>
> Actually, I have a question to Joaquín Mª López Muñoz and Ion Gaztañaga.
> What does it mean that the library in the queue has a review manager, but
> does not have any time slot scheduled?

Just that Joaquín and I didn't agree on a date. But it could start
before May.

Best,

Ion

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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/15/17 12:24 PM, degski via Boost wrote:

> On 14 March 2017 at 22:25, Robert Ramey via Boost <[hidden email]>
> wrote:
>
>> A much more interesting question: Why did you not submit a review
>> yourself?  I think it would have been helpful to me as an author and to you
>> in better understanding your own concerns.
>
>
> Because I think the idea is flawed from the start.
>
> int x = 2 * 2;
>
> is wrong in principle, correct would be:
>
> int64_t x = 2 * 2;

Hmmm so what's flawed?  The C++ standard? This particular program? or ?

right - It's the whole purpose of the safe numerics library to detect
these sort of problems.

>
> This is what happens in the CPU.

Not all CPUs

> C and C++ are wrong to allow multiplying

> two ints and assign the result to an int (the cpu does not do that!).

Hmmm - but's ok to multiply two 64 bit ints and store it an a 64 result?

> Then
> of course there is the issue of two's-complement, clouding stuff even
> further.
>
>  If one wants to be safe, the only real option is to use bignums (GMP,
> whatever). This is what implementations of languages like prolog and scheme
> do (I'm thinking of SWI-Prolog and Racket f.e.). Shifts (left of right) get
> a whole different meaning...

Right

> Reals (floats, doubles, quads) are already so broken in many ways, that I
> wouldn't even like to comment. Even MPFR doesn't add much here, except
> increased (but still relative) precision.
>
> I'm of the opinion that the only real option (if one wants performance) is
> to be very aware, learned and carefull regarding the issues, when dealing
> with numbers in C or C++. And this is far from simple, signed zeros,
> subnormal numbers, infinities, NaN's, roundings...

I maintain that this library is helpful, even essential, in
accomplishing the above task.  Actually, I don't think it's possible to
do what you want without such a library as this.

It seems to me you're arguing the case FOR using the library rather than
against it!  Of course you might be arguing that since it doesn't
address the whole issue - including floats that it's not at all useful.
But it's hard for me to tell.

> One of the review questions is: "would you use it?"
>
> Sorry, no!
LOL - sure it's free country.

Thanks for your comments, I think they are quite illuminating.

Robert Ramey

PS my original question was: "Why not submit a review yourself?"
There's no reason why you couldn't have submitted your concerns during
the review period.  I've always felt that reviews would benefit from
more user feedback - even if I think it's misguided.  It can smoke out
other users who have similar concerns and also it can draw to the
surface mis-understandings which can result in clarification of
confusing points in the documentation.  One of the things that we're
most proud of here at boost is the generally high level of discourse
where people can feel free to raise their legitimate concerns and
discuss them in a professional way.  I'm happy to see you've been able
to note them here, and I would have been even happier to see then during
review period.
>
> degski
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/14/17 2:53 PM, Robert Ramey via Boost wrote:
> All correct.  This suggestion has been floating around since at least
> 2010.  I think it's time to implement it.  I propose the following text
> to be placed in the appropriate place.
>
> "Only those who have managed a boost review can expect their library
> submissions to be to be reviewed."
>
> This clearly states the rule and allows for some exceptions.

OK - I've endorsed one of Naill's ideas in the form of the above
suggestion.

a) I think it's simple to implement.
b) if it doesn't work it's simple to retract.
c) We've had the normal back and forth about it - with the usual number
of tangents and side tracts and I don't see a strong argument against at
least trying it out.

So let's try this out.

The only thing is I don't have any idea who has the authority to
implement this.  The Review Wizard could just start implementing it on
his own - though I'm not sure he'd be comfortable with that.  So I'll
guess that its the steering committee.  I'll send them a copy.

Robert Ramey



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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
degski wrote:

> Because I think the idea is flawed from the start.
>
> int x = 2 * 2;
>
> is wrong in principle, correct would be:
>
> int64_t x = 2 * 2;

That's what the library does (in 'automatic' promotion mode, which should be
only mode in my opinion.) When you multiply two integers, one having range
[0, M] and the other having range [0,N], you get an integer with range [0,
M*N]. So safe<uint32_t> * safe<uint32_t> gives safe<uint64_t> (almost).


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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 15, 2017 at 10:24 PM, degski via Boost
<[hidden email]> wrote:
>
> int x = 2 * 2;
>
> is wrong in principle, correct would be:
>
> int64_t x = 2 * 2;
>
> This is what happens in the CPU.

Actually, no. Truncating multiplication is also quite common, and at
least in case of x86 is faster than the widening. Some architectures
(e.g. SPARC) don't even have a widening multiply instruction, so the
operation would have to be emulated. Given that most of the time
overflows are not a concern, I'd say truncating multiplication has the
right to exist. Of course, the widening variant would also be a
welcome option in the language, but hardly it should be the default.

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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 15 March 2017 at 17:06, Andrey Semashev <[hidden email]>
wrote:

> > This is what happens in the CPU.
>
> Actually, no.
>

http://support.amd.com/TechDocs/25112.PDF (I didn't go through the 5
manuals to find a better quote, but they are there!)

Chapter 3, Page 61.

"Using 64-bit registers, the entire product
can be produced with only one instruction:
; Multiply RAX by RBX. The 128-bit product is stored in RDX:RAX.
00000000 48 F7 EB imul rb"

That you can't get at it (the full result) without some (inline) assembler
is another issue. RAX is what's returned (as far as I remember) from a
function, your truncating multiplication, the higher bits are waiting for
you in RDX.

I don't have a SPARC to my disposal, so cannot comment.

degski

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

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 15.03.2017 20:32, degski via Boost wrote:
> On 15 March 2017 at 17:06, Andrey Semashev <[hidden email]>
> wrote:
>
>>> This is what happens in the CPU.
>> Actually, no.

[....]

Would you mind continuing this discussion in a different thread ? It's
way off-topic, in case you haven't noticed.

Thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Glen Fernandes
Glen Fernandes wrote:

> peterkochlarsen wrote:
> > Also an unmaintained library should be marked as such as should
> > libraries that are deprecated, replaced by standard C++ features
> > (shared_ptr comes to mind)
>
> shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is
> not deprecated.
>
> It actually has been evolving past the C++11 std::shared_ptr.
> For example, boost::shared_ptr supported array forms in 1.53 and this was
> eventually added to C++ in C++17.

And, since we managed to not get the array form of make_shared into C++17,
boost::make_shared will remain relevant a few more years.

This reminds me of the saying "looking for the lost keys under the street
light." We have a problem, what can we do? I know, let's deprecate and
remove boost::shared_ptr!


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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 2017-03-16 01:56, Peter Dimov via Boost wrote:

> Glen Fernandes wrote:
>> peterkochlarsen wrote:
>> > Also an unmaintained library should be marked as such as should > libraries that are deprecated, replaced by standard C++ features > (shared_ptr comes to mind)
>>
>> shared_ptr (or Boost.SmartPointers in general) is not unmaintained,
>> and is not deprecated.
>>
>> It actually has been evolving past the C++11 std::shared_ptr.
>> For example, boost::shared_ptr supported array forms in 1.53 and this
>> was eventually added to C++ in C++17.
>
> And, since we managed to not get the array form of make_shared into
> C++17, boost::make_shared will remain relevant a few more years.
>
> This reminds me of the saying "looking for the lost keys under the
> street light." We have a problem, what can we do? I know, let's
> deprecate and remove boost::shared_ptr!


Hi,

I doubt that sarcasm will help solve the severe interoperability issues
between the very close boost and std versions.
I sometimes wish those libraries got never adopted for this reason.

Best,
Oswin

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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

peterkochlarsen
In reply to this post by Glen Fernandes
Glen Fernandes wrote
peterkochlarsen wrote:
> Also an unmaintained library should be marked as such as should
> libraries that are deprecated, replaced by standard C++ features
> (shared_ptr comes to mind)

shared_ptr (or Boost.SmartPointers in general) is not unmaintained,
and is not deprecated.

It actually has been evolving past the C++11 std::shared_ptr.
For example, boost::shared_ptr supported array forms in 1.53 and this
was eventually added to C++ in C++17.

(Interesting aside: That functionality above was even, and still is
used, in certain Microsoft projects, where boost::shared_ptr is used
instead of std::shared_ptr).

The same goes for other Boost libraries like Boost.Thread. They:
- May have features not in the C++ standard library equivalent
- May be evolving past the current C++ standard
- Are in use by actual projects and shouldn't be removed

Glen
I am not talking about removal, just a note that there is a standard replacement and a brief cap on their differences. Most people should prefer using the standard library, reconsidering if they really need the array-version of shared_ptr. By the way, I am a happy user of boost::thread, and have not taken the time to move to std::thread yet.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partly OT] Re: [review queue] What to do about the library review queue?

peterkochlarsen
In reply to this post by Boost - Dev mailing list
Boost - Dev mailing list wrote
Glen Fernandes wrote:
> peterkochlarsen wrote:
> > Also an unmaintained library should be marked as such as should
> > libraries that are deprecated, replaced by standard C++ features
> > (shared_ptr comes to mind)
>
> shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is
> not deprecated.
>
> It actually has been evolving past the C++11 std::shared_ptr.
> For example, boost::shared_ptr supported array forms in 1.53 and this was
> eventually added to C++ in C++17.

And, since we managed to not get the array form of make_shared into C++17,
boost::make_shared will remain relevant a few more years.

This reminds me of the saying "looking for the lost keys under the street
light." We have a problem, what can we do? I know, let's deprecate and
remove boost::shared_ptr!
I did not intend to imply that boost::shared_ptr was a problematic part of boost. I just expect that for most of us, we should prefer std::shared_ptr. Thus, a note should be put in the documentation that there is also a standard shared_ptr.

I just took a few minutes to look at the documentation and see that this information is already present, so shared_ptr has no problems in that regard. I just would prefer if this documentation was put at a more prominent position.

For shared_ptr, there is another problem, however. I went to the track list and found a number of open bugs. Not, I guess, because shared_ptr is buggy, but because the bugs are not maintained. As an example, the newest bug #12604 is still marked as open: I guess it should not be. The same is the case for the second bug I examined (8485). Also bugs such as 6829 (slow in MSVC) should not be marked as such. If a function is slower than it could be it should be marked as an enhancement/feature request, not as a bug. Except, of course, if the function is so slow that it is absolutely useless.

/Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Oswin Krause wrote:
> Hi,
>
> I doubt that sarcasm will help solve the severe interoperability issues
> between the very close boost and std versions.

What severe interoperability issues?

> I sometimes wish those libraries got never adopted for this reason.

By the standard? This would surely have cured the interoperability issues.


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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by peterkochlarsen
On Thu, Mar 16, 2017 at 3:20 AM, peterkochlarsen via wrote:
> For shared_ptr, there is another problem, however. I went to the track list
> and found a number of open bugs. Not, I guess, because shared_ptr is buggy,
> but because the bugs are not maintained.
>
> #12604 is still marked as open: I guess it should not be.
> The same is the case for the second bug I examined (8485).

Yes, a lot of the bugs in Trac should be closed (marked as fixed).
I think we're more diligent in closing Github Issues than Trac Issues
lately. We can change that (until we truly move to Github Issues).

> Also bugs such as 6829 (slow in MSVC) should not be marked as such.

Word choice "bug" versus "feature" aside, that one was also fixed, a
long time ago.

Glen

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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost
<[hidden email]> wrote:
> ...until we truly move to Github Issues

What needs to be done in order to make this happen?

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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by peterkochlarsen
On Thu, Mar 16, 2017 at 3:09 AM, peterkochlarsen via Boost wrote:

> Glen Fernandes wrote
>> peterkochlarsen wrote:
>>> Also an unmaintained library should be marked as such as should
>>> libraries that are deprecated, replaced by standard C++ features
>>> (shared_ptr comes to mind)
>>
>> shared_ptr (or Boost.SmartPointers in general) is not unmaintained,
>> and is not deprecated.
>>
>> It actually has been evolving past the C++11 std::shared_ptr.
>> For example, boost::shared_ptr supported array forms in 1.53 and this
>> was eventually added to C++ in C++17.
>>
>> (Interesting aside: That functionality above was even, and still is
>> used, in certain Microsoft projects, where boost::shared_ptr is used
>> instead of std::shared_ptr).
>>
>> The same goes for other Boost libraries like Boost.Thread. They:
>> - May have features not in the C++ standard library equivalent
>> - May be evolving past the current C++ standard
>> - Are in use by actual projects and shouldn't be removed
>>
>> Glen
>
> I am not talking about removal, just a note that there is a standard
> replacement and a brief cap on their differences. Most people should prefer
> using the standard library, reconsidering if they really need the
> array-version of shared_ptr. By the way, I am a happy user of boost::thread,
> and have not taken the time to move to std::thread yet.

There is no "should" here. I let most people decide for themselves
what they prefer.
e.g. You may intend to move to std::thread, that's fine. Others may
choose to continue to use boost::thread and boost::shared_ptr
because they may not want to keep switching between std and boost
for whatever reason(s).

(In some cases, those reasons could be as simple as wanting newer
features in Boost libraries that evolve faster. In other cases,
it might be as simple as their organization updates Boost versions
faster than they migrate to new compiler versions).

As for documenting that there exists a standard version and describing
the differences, sure: I can see the value in that.

Glen

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

Re: [partly OT] Re: [review queue] What to do about the library review queue?

peterkochlarsen
In reply to this post by Boost - Dev mailing list
Boost - Dev mailing list wrote
On Thu, Mar 16, 2017 at 3:20 AM, peterkochlarsen via wrote:
> #12604 is still marked as open: I guess it should not be.
> The same is the case for the second bug I examined (8485).

Yes, a lot of the bugs in Trac should be closed (marked as fixed).
I think we're more diligent in closing Github Issues than Trac Issues
lately. We can change that (until we truly move to Github Issues).

> Also bugs such as 6829 (slow in MSVC) should not be marked as such.

Word choice "bug" versus "feature" aside, that one was also fixed, a
long time ago.

Glen
I believe many people are frightened by this, so it would be nice if we could fix this situation. If trac is dying, I would propose that you closed public access to the database or made it obvious for potential boosters that the status of the issues are not to be trusted. Refer to github instead.

/Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partly OT] Re: [review queue] What to do about the library review queue?

peterkochlarsen
In reply to this post by Boost - Dev mailing list
Boost - Dev mailing list wrote
On Thu, Mar 16, 2017 at 3:09 AM, peterkochlarsen via Boost wrote:
> Glen Fernandes wrote
>> peterkochlarsen wrote:
> Most people should prefer
> using the standard library, reconsidering if they really need the
> array-version of shared_ptr. By the way, I am a happy user of boost::thread,
> and have not taken the time to move to std::thread yet.

There is no "should" here. I let most people decide for themselves
what they prefer.
e.g. You may intend to move to std::thread, that's fine. Others may
choose to continue to use boost::thread and boost::shared_ptr
because they may not want to keep switching between std and boost
for whatever reason(s).

(In some cases, those reasons could be as simple as wanting newer
features in Boost libraries that evolve faster. In other cases,
it might be as simple as their organization updates Boost versions
faster than they migrate to new compiler versions).

As for documenting that there exists a standard version and describing
the differences, sure: I can see the value in that.

Glen
Agreed. I probably meant to write "Most people would". And this is an opinion where you have given good reasons as to why some might prefer not to switch.

/Peter
123456 ... 8
Loading...