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: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-22 17:39:42

> > 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