"Christian Henning" <chhenning@gmail.com> wrote in message news:AANLkTinMFAmw77CL=7LP86o2RjKJ4a76E1i3Kcv9KRvb@mail.gmail.com...
We should definitely "sit down" after the review and see what should be the next step. I hope you're committed to walk the next few miles.
What's a few more miles ;)
I think in the end I was more committed into getting more image formats read, like bit_aligned images which I find a very important use case.
Of course, ability to read for example 1 bit images w/o them taking about 8 times the required RAM is a valuable addition (if I assume correctly what your bit_aligned image can do), which, as mentioned earlier should probably enter into the core GIL.
Mhmm, not sure what to take from this comment. When do you consider inlining appropriate and when not. As far as I know the Spirit lib practically lives from inlining. Are you saying they overdo it, as well.
I don't where to draw the line and rather have the compiler do its work.
And that (inlining done by the compiler) is what I was referring to...when you compile for speed the compiler will inline more functions, and without profile guided optimizations and precise information on the target CPU it cannot know what will actually be the optimum amount of inlining...thus resulting in some cases in the reverse effect because the extra generated code blows the instruction cache...And 'unnecessarily bloated' code is more prone to this effect than 'lean written' code...
I try to reuse code that can be shared between backends. I don't understand your point. Can you point out what is inflexible?
I know you do, however there are still some areas that are hampered by the chosen design...for example, in a CRTP based design the implementation/backend wrapper would only need to specify the supported pixel formats (like with an MPL typelist) and the switch, based on the input format, could then be done in a single place in the CRTP base class which would then invoke a template member function of the derived class specifying to it, through template parameters, the exact source and target types... But yes, the word 'inflexible' is an incorrect term for the issue I tried to point out here...maybe 'cumbersome' or 'duplication prone'...
Back to negativity. Yes there was a bug back in September. I fixed it, not much more I can do about that.
Christian, please do not take my comments personally :) IMO, in a review process, 'dry'/objective/rational comments demonstrated with straightforward arguments with as clear as possible (black-or-white / 'good'-or-'bad') conclusions get the job done in the shortest amount of time. Sure, this type of discourse can leave the author of the library being reviewed feeling as if there is little appreciation of the work he or she has done but, as it often is with feelings, this need not be true. Please note that I have remarked several times that you've done a massive piece of work ;-) The only comment that had a personal tone to it was the one in the beginning of my first post in the "[gil] New IO release" thread (the one that had a bit of an 'I told you so' overtone)...but it is important that we now have an overall open and friendly discussion and willingness to work together for a common cause... ;)
I hope you realize that providing a IO extension is more of a can of worms.
Of course, it's a 'truly massive' piece of work ;)
I'm not sure if sharing properties across backends makes sense. They all provide their own set. Even if they provide some matching properties ( like image height ) these properties might have different data types.
I meant sharing across backends that support the same types of images (i.e. having to use one set of properties with the LibPNG backend and an entirely different on with a LodePNG backend would not make much sense)...
I actually think GIL should move specific pixel types into a separate extension. I understand GIL as some sort of meta-library without the knowledge of rgb or cymk.
Or it can be done that way too...as long as they are all in one place...
Thanks again for your long review. I think I lost some nerves along the way but I very much appreciate your efforts.
I'm sorry for the lost nerves...somehow I've come to accept this as normal in these discussions with all the 'Parksinon's bicycle shed', 'straw man', 'ignored argument' and related 'syndromes' inherent in human (vanity tarred) communication... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman