Hi Phil, good to hear from you. On Fri, Dec 3, 2010 at 1:54 PM, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Hi Christian, Mateusz and others
Mateusz Loskot <mateusz@loskot.net> wrote:
According to the Boost Formal Review Schedule [1], review of Christian Henning's extensions to the Boost Generic Image Library (Boost.GIL, [2]), it is: * Boost.GIL.IO * Boost.GIL.Toolbox starts on December 1st and lasts until December 10th, 2010.
The boost_review.zip is about 20MB due to its extensive collection of test images. They are part of the test suite to make sure that different variations of each image format is read and written correctly.
It looks like these test images are not included in your Google Code repository, which is not unreasonable; how do you plan to handle this in the Boost repository, if accepted? Are there any precedents elsewhere in Boost?
Yeah, I separated them for the time being. I don't think it's big deal to add a bunch of test images to the boost source tree. It isn't really that big after all. When running the test suite I write out a lot of pictures which amounts to 5MB. But this is only done once since the files are being overridden at the next run. If there is resistance to add 20MB in test images I would have to resort to images in memory ( std::stringstream ). I cannot recommend such approach. The biggest problem I can see is the configuration of the test suite. There are some manual steps involved, as they are described in the readme.txt. I need to talk to the boost build guys to get the configuration done automatically. But that's for after the review.
Also, can you point out which images and tests exercise the error paths that we discussed at length (e.g. setjmp/longjmp) a few months ago?
Every time you read/write a jpeg or a png you use the setjmp/longjmp combination. I have tested it on my own machine and it works pretty well. There are no tests that are targeted specifically at setjmp/longjmp. Does that answer your question? Regards, Christian