I do not believe this issue has been raised yet.
But for std.experimental.image (or at least to my intention) I will be needing a test suite for e.g. PNG file format loader/exporter.

To my knowledge we currently only support unittests for Phobos. What I need structure wise is similar to dmd's testsuite.

I do not know nor want to get into setting this up.

For example the PNG file format it should really be tested using separate programs to compare against load/export/load for the files[0].
This is quite crucial to ensure the correctness of the loader/exporter. It will help prevent and detect many bugs.

So, would anybody like to get a head start on it?

[0] http://www.schaik.com/pngsuite/

On 7/16/2015 4:39 AM, Rikki Cattermole wrote:
> I do not believe this issue has been raised yet.
> But for std.experimental.image (or at least to my intention) I will be needing a
> test suite for e.g. PNG file format loader/exporter.
>
> To my knowledge we currently only support unittests for Phobos. What I need
> structure wise is similar to dmd's testsuite.
>
> I do not know nor want to get into setting this up.
>
> For example the PNG file format it should really be tested using separate
> programs to compare against load/export/load for the files[0].
> This is quite crucial to ensure the correctness of the loader/exporter. It will
> help prevent and detect many bugs.
>
> So, would anybody like to get a head start on it?
>
> [0] http://www.schaik.com/pngsuite/

I haven't looked at your code, but for an image file reader, the D way is to separate file handling code from image handling code. This means that the image code can be tested not by handing it a file name, but handing it the data that can be inlined in a D source code file.

This makes testing much more straightforward.

On Thursday, 16 July 2015 at 17:32:04 UTC, Walter Bright wrote:
> On 7/16/2015 4:39 AM, Rikki Cattermole wrote:
>> I do not believe this issue has been raised yet.
>> But for std.experimental.image (or at least to my intention) I will be needing a
>> test suite for e.g. PNG file format loader/exporter.
>>
>> To my knowledge we currently only support unittests for Phobos. What I need
>> structure wise is similar to dmd's testsuite.
>>
>> I do not know nor want to get into setting this up.
>>
>> For example the PNG file format it should really be tested using separate
>> programs to compare against load/export/load for the files[0].
>> This is quite crucial to ensure the correctness of the loader/exporter. It will
>> help prevent and detect many bugs.
>>
>> So, would anybody like to get a head start on it?
>>
>> [0] http://www.schaik.com/pngsuite/
>
> I haven't looked at your code, but for an image file reader, the D way is to separate file handling code from image handling code. This means that the image code can be tested not by handing it a file name, but handing it the data that can be inlined in a D source code file.

Not an issue, takes an input range.

> This makes testing much more straightforward.

My concern is about getting access to the images to test against.
While embedding is valid, the test images I linked to only total a couple meg at most. We will need others added. Both large and small. I am concerned about file sizes and maintainability.
Especially for e.g. other file formats.

Worse case scenario I'll make sure something like bin2d[0] is part of the tools repo. To generate these files.
I just don't like this approach.

[0] https://github.com/rikkimax/Bin2D/blob/master/source/Bin2D.d

On Thursday, 16 July 2015 at 18:34:35 UTC, Rikki Cattermole wrote:
> ...
> 
> My concern is about getting access to the images to test against.
> While embedding is valid, the test images I linked to only total a couple meg at most. We will need others added. Both large and small. I am concerned about file sizes and maintainability.
> Especially for e.g. other file formats.
>
> Worse case scenario I'll make sure something like bin2d[0] is part of the tools repo. To generate these files.
> I just don't like this approach.
>
> [0] https://github.com/rikkimax/Bin2D/blob/master/source/Bin2D.d

Can't you do the old string import trick to import binary files? I dont know if phobos unittests are built with string imports enabled though.

On 17/07/2015 9:19 a.m., Tofu Ninja wrote:
> On Thursday, 16 July 2015 at 18:34:35 UTC, Rikki Cattermole wrote:
>> ...
>>
>> My concern is about getting access to the images to test against.
>> While embedding is valid, the test images I linked to only total a
>> couple meg at most. We will need others added. Both large and small. I
>> am concerned about file sizes and maintainability.
>> Especially for e.g. other file formats.
>>
>> Worse case scenario I'll make sure something like bin2d[0] is part of
>> the tools repo. To generate these files.
>> I just don't like this approach.
>>
>> [0] https://github.com/rikkimax/Bin2D/blob/master/source/Bin2D.d
>
> Can't you do the old string import trick to import binary files? I dont
> know if phobos unittests are built with string imports enabled though.

https://issues.dlang.org/show_bug.cgi?id=3420 https://issues.dlang.org/show_bug.cgi?id=6554 https://issues.dlang.org/show_bug.cgi?id=14349

That's why I'm not keen on it.

On Friday, 17 July 2015 at 03:17:08 UTC, Rikki Cattermole wrote:
> https://issues.dlang.org/show_bug.cgi?id=3420

I have always hated that sub directories were not allowed. A flat file directory simply sucks when you have a couple hundred string imports... why walter... why.... </3

On Friday, 17 July 2015 at 05:45:06 UTC, Tofu Ninja wrote:
> On Friday, 17 July 2015 at 03:17:08 UTC, Rikki Cattermole wrote:
>> https://issues.dlang.org/show_bug.cgi?id=3420
>
> I have always hated that sub directories were not allowed. A flat file directory simply sucks when you have a couple hundred string imports... why walter... why.... </3

I wonder if windows support can be added using PathCanonicalize and PathFileExists
seems about as "secure" as using realpath on posix

https://msdn.microsoft.com/en-us/library/windows/desktop/bb773569(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773584(v=vs.85).aspx