Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)

Subject: Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2015-08-22 19:43:37

Hartmut Kaiser wrote:
> Niall Douglas wrote:
>> Please do feel free to ask for any clarifications. I have sprinked
>> cautions and notes around the AFIO documentation to explain how the
>> presented AFIO is expected to differ from final AFIO after Monad is
>> reviewed, and indeed there is also a dedicated section listing the
>> expected differences in the release notes.
>
> How can you submit a library for review for which you already _know_ it will
> change?

Hartmut makes a good point. Niall, please correct me if my
understanding is lacking here:
- You are presenting this library with interface version A
- You plan to implement interface version B while also providing A for
backward compatibility
- Once B is implemented, all documentation will only ever mention B
because it is superior
- The benefits of B make it superior in every way to A

Sounds like A pales in comparison to B. So what does B require? More
investment in AFIO? C++17 to be ratified? If the latter, then I don't
think anybody cares about B in the context of this review. What may or
may not happen in C++1y will not influence acceptance of a library
today. If the former, then you are better off waiting to submit AFIO
for review when you complete that new interface. Especially if it
makes a difference to reviewers: i.e. you can't expect people to
accept AFIO on the promise of a better API later. Right?

>> The library being presented today is very well tested, and should
>> *not* *lose* *you* *data* which is the most important quality in an
>> i/o library. Even if performance - as you will see in the tutorial's
>> benchmarks - is a bit poor in the current engine in some use cases.

I'm interested in an asynchronous file I/O library being part of Boost
for performance (portably). As long as it is no less reliable than
using the native filesystem APIs, reliability isn't a concern or a big
selling point for me. Am I to understand that by design, AFIO's
implementation implies lower performance than an alternative? (even if
that alternative is something like libuv, which has its own flaws)

Glen

On Sat, Aug 22, 2015 at 5:39 PM, Hartmut Kaiser
<hartmut.kaiser_at_[hidden]> wrote:
>> > On Sat, Aug 22, 2015 at 9:21 AM, Niall Douglas wrote:
>> > > If you want to get started, everything is ready at the usual places
>> > > and the CI dashboard is all green on all supported platforms and
>> > > targets (the one fail was a timeout due to me pushing the CI too
>> > > hard, it's not important).
>> >
>> > In my opinion- I don't think you will need to worry about the tests
>> > being all green for a review.
>>
>> I'm a perfectionist. I wouldn't have considered it ready for review
>> until it was all green across the board on all 60 of its per-commit
>> tested targets. I spent four hours on Friday coaxing wandbox to
>> compile AFIO again so you'd have a working C++ browser playpen you
>> can go play with AFIO in. Little details are important.
>>
>> > > Today I'll be spending swapping my dev workstation hard drive as I
>> > > killed the poor thing this week during testing the AFIO tutorial
>> > > workshop examples. I'll then press on with finishing the final
>> > > key-value store example which is described in detail in the tutorial
>> > > but is currently without code nor benchmarks. That new code won't be
>> > > part of this review, but I can link to it here with benchmarks when
>> > > it's ready.
>> >
>> > One question: Are reviewers also reviewing the  "Monad" and "APIBind"
>> > libraries? (I see them consumed as sub-modules in the AFIO
>> > repository).
>>
>> Well I asked here about that a few months ago, and I was told that
>> there is precedent for this situation. Apparently historically you
>> review the library being presented for review only, mentioning only
>> the internal sublibraries if there is something catastrophically
>> worrying about them. One then expects the internal sublibraries to be
>> spun out into additional Boost libraries presented for review later
>> if that is appropriate.
>>
>> I can tell you that I personally would not be comfortable sending
>> AFIO into the main Boost distribution until after Monad has been
>> reviewed here, so even if there is a universal unconditional
>> acceptance of AFIO by everyone here, I will personally guarantee I
>> won't send in a final AFIO until after Monad is reviewed here.
>>
>> I think this only fair. Do note I walk you through monad<T> in the
>> tutorial with everything you need to know. And if you find bugs in
>> Monad not already in the Monad issue tracker, please do file them. I
>> know of at least half a dozen myself.
>
> This underlines what I said before. It appears, you submitted a library for
> review which depends on another (unrelated) library which is not ready yet.
> How can AFIO be ready for review if Monad is not? Didn't you say you're a
> perfectionist?
>
>> Does this sound reasonable?
>
> Not at all. Not to me at least.
>
>> Please do feel free to ask for any clarifications. I have sprinked
>> cautions and notes around the AFIO documentation to explain how the
>> presented AFIO is expected to differ from final AFIO after Monad is
>> reviewed, and indeed there is also a dedicated section listing the
>> expected differences in the release notes.
>
> How can you submit a library for review for which you already _know_ it will
> change?
>
> What will happen if AFIO gets accepted now (god forbids!) and Monad later
> will not be accepted? Will you turn Monad into an implementation detail, in
> this case? Is that what the community wants? Or is Monad an implementation
> detail today?
>
>> I would *emphasise* very little is expected to change in the public
>> API presented here, indeed I expect all the unit tests and tutorial
>> examples to compile as-is. You or anyone else can base your review on
>> the library as presented. The only real changes in final AFIO are the
>> simplification of some tutorial examples thanks to C++ 1z coroutines,
>> and better performance.
>
> But Monad and APIBind are part of the API, aren't they?
>
>> The library being presented today is very well tested, and should
>> *not* *lose* *you* *data* which is the most important quality in an
>> i/o library. Even if performance - as you will see in the tutorial's
>> benchmarks - is a bit poor in the current engine in some use cases.
>
> My baffling increases with every word you're saying!
> All of this sounds like from the old quote 'If you can't dazzle them with
> your brilliance - baffle them with your bullshit!'
>
> Wasn't your whole discussion over months praising your super-duper future
> design only about exceptional performance? Wasn't I asking for performance
> benchmarks all along and you told me to hold my breath as I would see it
> shining once you're done developing? And now you're telling us that your
> performance is sub-par!
>
> Would you have the decency to stop conveying/implying things which are
> half-truths, at least on this list, please?
>
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost