Re: [boost] [GIL] new IO extension review

Subject: Re: [boost] [GIL] new IO extension review
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-12-08 05:45:52

"Christian Henning" <chhenning_at_[hidden]> wrote in message
news:AANLkTinMFAmw77CL=7LP86o2RjKJ4a76E1i3Kcv9KRvb_at_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