Releasing an early beta of automake 1.12? (was: Re: TAP support in automake)

2012-04-01 Thread Stefano Lattarini 
On 04/01/2012 03:10 AM, Bob Friesenhahn wrote:
> On Sat, 31 Mar 2012, Russ Allbery wrote:
> 
>> Bob Friesenhahn  writes:
>>
>>> Ok, now I hear that there are still log files similar to parallel-tests
>>> (presumably using the identical facility).  It does not seem that Russ's
>>> C TAP Harness offers this quite wonderful feature since the instructions
>>> advise to re-run just the one test to see more verbose output (similar
>>> to what I have experienced from perl).
>>
>> Correct; my harness program doesn't currently have a way of storing log
>> files.  (Added to TODO.)
> 
> Regardless, I will likely use your 'runtests' test driver as a way to
> explore converting some of my test scripts to TAP since Automake 1.12
> is not released yet.
>
In case you feel like experimenting, I could release an early beta for it.
Automake 1.12 is anyway planned to be released in month or so (hopefully
before), and the code in the master branch should be in near-releasable
state (in fact, Jim has been using it to bootstrap coreutils' official
distribution already).

> I will start with tests which have little need for log files.
> 
>> Viewed in that light, TAP doesn't really reduce parallelism.  prove, the
>> Perl driver, supports running all the TAP tests in parallel, for example.
> 
> Automake already has support for parallelism.  The quality of the
> parallelism depends on how "lumpy" the various TAP tests become.
> If some are very fast and others take a very long time, then the
> slowest tests will tend to dominate the time.  Listing the slowests
> tests first helps.
> 
Right; that's what automake does in its own testsuite (mostly).

Regards,
  Stefano

Re: TAP support in automake

2012-04-01 Thread Stefano Lattarini 
On 04/01/2012 02:50 AM, Bob Friesenhahn wrote:
> On Sun, 1 Apr 2012, Stefano Lattarini wrote:
> 
>> On 03/31/2012 11:47 PM, Bob Friesenhahn wrote:
>>>
>>> how does one re-execute just one test in order to see the details
>>> of how it failed?
>>>
>> With Automake, one shouldn't -- he should write his test to be verbose
>> enough so that a perusing of the logs is sufficient to reveal the reason
>> of the failure.
> 
> Ok, now I hear that there are still log files similar to parallel-tests
> (presumably using the identical facility).
>
Yes.  And also (newly-introduced) "trs" (Test ReSults) files that store
some metadata about the tests' runs (note however that the format of
these files is still highly exeprimental and subject to change).

> It does not seem that Russ's C TAP Harness offers this quite wonderful
> feature since the instructions advise to re-run just the one test to
> see more verbose output (similar to what I have experienced from perl).
> 
>> You mean running only a given test case in a given TAP test script, or all
>> the test cases in a given TAP test script?  Currently, there is no 
>> transparent
>> way way to do the former (which is hardly surprising), but for the latter,
>> you would use the same interface you use for "simple" tests:
>>
>>  make check TESTS=granular.tap
>>
>> or even:
>>
>>  make check TEST_LOGS=granular.log
> 
> So Automake TAP still supports the same parallel-tests facility but
> treats files with the ".tap" extension as being TAP test scripts?
>
Not by default; you must declare which extensions should use the TAP
driver, with the definition of a proper "_LOG_DRIVER" variable.

For example, if your testsuite contains "simple tests" written as shell
script (and having a '.sh' extension) and TAP tests written as perl
scripts (and having a '.pl' extension), your Makefile.am might look
like this:

  # Tell which program should run the .sh scripts.
  SH_LOG_COMPILER = $(SHELL) -ex
  # Tell which program should run the .pl scripts
  PL_LOG_COMPILER = $(PERL) -MTAP::More -w
  # Tell which program should interpret the outcomes for the .pl scripts
  PL_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \
  $(top_srcdir)/build-aux/tap-driver.sh

In the next Automake version, I hope to be able to refine the above
to something like this:

  SH_LOG_COMPILER = $(SHELL) -ex
  PL_LOG_COMPILER = $(PERL) -MTAP::More -w
  PL_LOG_PROTOCOL = tap

Of course, the use of "_LOG_DRIVER" variables will still be
supported, to allow developers to define their own drivers if they
want to (e.g., if they want to support a protocol like SubUnit that
is not supported by default by Automake).

> That sounds like a useful approach.
>
I'm glad to hear this.

> An issue with using the TAP facility to reduce the number of tests
> (to fix command line length issues) is that it reduces the amount
> of available test parallelism.
>
That's a risk if TAP is over-used or abused; it's up to the developer
to strike a balance.  You can take a look at the TAP usage in the
automake's own testsuite for few examples.

Regards,
  Stefano

Re: TAP support in automake

2012-03-31 Thread Bob Friesenhahn 

On Sat, 31 Mar 2012, Russ Allbery wrote:


Bob Friesenhahn  writes:


Ok, now I hear that there are still log files similar to parallel-tests
(presumably using the identical facility).  It does not seem that Russ's
C TAP Harness offers this quite wonderful feature since the instructions
advise to re-run just the one test to see more verbose output (similar
to what I have experienced from perl).


Correct; my harness program doesn't currently have a way of storing log
files.  (Added to TODO.)


Regardless, I will likely use your 'runtests' test driver as a way to 
explore converting some of my test scripts to TAP since Automake 1.12 
is not released yet.  I will start with tests which have little need 
for log files.



Viewed in that light, TAP doesn't really reduce parallelism.  prove, the
Perl driver, supports running all the TAP tests in parallel, for example.


Automake already has support for parallelism.  The quality of the 
parallelism depends on how "lumpy" the various TAP tests become.  If 
some are very fast and others take a very long time, then the slowest 
tests will tend to dominate the time.  Listing the slowests tests 
first helps.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: TAP support in automake

2012-03-31 Thread Russ Allbery 
Bob Friesenhahn  writes:

> Ok, now I hear that there are still log files similar to parallel-tests
> (presumably using the identical facility).  It does not seem that Russ's
> C TAP Harness offers this quite wonderful feature since the instructions
> advise to re-run just the one test to see more verbose output (similar
> to what I have experienced from perl).

Correct; my harness program doesn't currently have a way of storing log
files.  (Added to TODO.)

> An issue with using the TAP facility to reduce the number of tests (to
> fix command line length issues) is that it reduces the amount of
> available test parallelism.

Well, sort of.  TAP has the concept of multiple tests per executable, and
of course it's hard to run those in parallel without a lot of work.  But
usually what I see happen when someone converts from the more traditional
PASS/FAIL test executable test layout to TAP is not that a lot of those
tests are combined into a single test program, but rather that TAP now
allows them to report far more internal test detail about exactly what is
passing or failing in a PASS/FAIL test instead of just one status.

Viewed in that light, TAP doesn't really reduce parallelism.  prove, the
Perl driver, supports running all the TAP tests in parallel, for example.

I've not tried to support parallelism in my simple TAP driver, though, for
a few reasons: most of my packages (i.e., my personal itch) can't use much
parallelism because they have network components that create local network
sockets and would conflict with each other, none of my personal test
suites take more than 10-15 seconds to run, and implementing parallelism
in a C test harness with the portability requirements of C TAP Harness is
hard.  (For example, it's mostly impossible to use select portably without
requiring Autoconf or something similar, since the header files you have
to include vary by platform and include some mandatory header files on
some platforms that don't exist on other platforms.)  But it's a nice
feature to have, and the TAP protocol supports it and it sounds like the
Automake support for it will be there.

-- 
Russ Allbery (r...@stanford.edu)

Re: TAP support in automake

2012-03-31 Thread Bob Friesenhahn 

On Sun, 1 Apr 2012, Stefano Lattarini wrote:


On 03/31/2012 11:47 PM, Bob Friesenhahn wrote:


how does one re-execute just one test in order to see the details
of how it failed?


With Automake, one shouldn't -- he should write his test to be verbose
enough so that a perusing of the logs is sufficient to reveal the reason
of the failure.


Ok, now I hear that there are still log files similar to 
parallel-tests (presumably using the identical facility).  It does not 
seem that Russ's C TAP Harness offers this quite wonderful feature 
since the instructions advise to re-run just the one test to see more 
verbose output (similar to what I have experienced from perl).



You mean running only a given test case in a given TAP test script, or all
the test cases in a given TAP test script?  Currently, there is no transparent
way way to do the former (which is hardly surprising), but for the latter,
you would use the same interface you use for "simple" tests:

 make check TESTS=granular.tap

or even:

 make check TEST_LOGS=granular.log


So Automake TAP still supports the same parallel-tests facility but 
treats files with the ".tap" extension as being TAP test scripts? 
That sounds like a useful approach.


An issue with using the TAP facility to reduce the number of tests (to 
fix command line length issues) is that it reduces the amount of 
available test parallelism.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: TAP support in automake

2012-03-31 Thread Russ Allbery 
Stefano Lattarini  writes:

> Consider that the whole point of the TAP support in Automake is that the
> testsuite harness present in Automake-generated makefiles (the one that
> gets launched by "make check") will act as TAP consumer itself.  Thus
> the "harness" part of Russ' package is likely of little or no use in
> conjunction with the newer Automake test harness -- but of course you
> can reuse the part of his project that provide a TAP *producer* for C
> and/or Shell programs.

Indeed.  The purpose of the C TAP Harness project is to provide sort of a
toolkit and you can mix and match whatever pieces you want.  I personally
use the harness included there just because I wrote it and therefore it
does everything the way that I like having it done, although at some point
I want to look at the TAP support directly in Automake and see if it can
now do everything it does.

But the libraries are more directly useful to anyone doing something with
TAP, and reflect about 10 years of accumulated experience with all the
various weird things that one ends up needing to do in a project that also
uses Automake.  They don't just handle the test stream; there are also
functions for handling the special cases that come up in finding
supporting test data with srcdir != builddir builds and things along those
lines.  And the C library takes care of a bunch of annoying bookkeeping
for you and provides some wrapper functions around memory allocation that
call bail() on failure for clean failure of tests in low-memory
conditions.

I know of several other people who are using the libraries but just using
prove as the test suite driver.

Incidentally, for anyone doing a lot with TAP, you may also want to look
at the TAP add-ons that are part of my general C utility collection:

http://www.eyrie.org/~eagle/software/rra-c-util/

C TAP Harness is developed under a strict requirement that it not need to
use Autoconf, so it only uses completely standard C functions.  The
rra-c-util add-ons are allowed to depend on a broader portability
framework (I use mine, but gnulib would presumably work as well) and
therefore include TAP add-ons that do things like wrap asprintf() to test
for success, to fork a subprocess and check its output, and to run an
external program to do setup at the start of a test.  (Sometimes it's a
lot easier to do your test setup in shell or some other scripting language
rather than C, while the core test code has to be written in C because of
what it's testing.)

-- 
Russ Allbery (r...@stanford.edu)

Re: TAP support in automake

2012-03-31 Thread Stefano Lattarini 
On 03/31/2012 11:47 PM, Bob Friesenhahn wrote:
>
> how does one re-execute just one test in order to see the details
> of how it failed?
>
With Automake, one shouldn't -- he should write his test to be verbose
enough so that a perusing of the logs is sufficient to reveal the reason
of the failure.

But of course, you might want now to ask this fully legitimate question
instead:

  How does one re-execute just one test?

question which is answered below.

> In Automake I do this like
> 
>   make TESTS=mytest
>
I guess you actually do like this:

   make check TESTS=mytest

> Using Perl's test driver I can execute one test like
> 
>   make TEST_VERBOSE=1 TEST_FILES=t/mytest.t test
> 
> How will the Automake 1.12 TAP driver handle this common
> special case?
>
You mean running only a given test case in a given TAP test script, or all
the test cases in a given TAP test script?  Currently, there is no transparent
way way to do the former (which is hardly surprising), but for the latter,
you would use the same interface you use for "simple" tests:

  make check TESTS=granular.tap

or even:

  make check TEST_LOGS=granular.log

Regards,
  Stefano

Re: TAP support in automake

2012-03-31 Thread Stefano Lattarini 
On 03/31/2012 10:23 PM, Bob Friesenhahn wrote:
> On Sat, 31 Mar 2012, Stefano Lattarini wrote:
>>>
>> Well, automake being automake, it only depends on portable awk[1] ;-)
>> OK, portable "nawk" actually (as found by the autoconf builtin macro
>> AC_PROG_AWK), but I don't know of any non-museum machine lacking that.
> 
> Good.
> 
>> The new feature is already documented in the automake manual on the
>> 'master' branch; and this documentation should be release-quality
>> already.  But maybe I should make this new feature more visible before
>> the 1.12 release?  If yes, how do you suggest to do so?
> 
> Certainly mentioning and discussing it again on the 'automake' list 
> (happening now) is useful.
>
Let's continue the discussion then :-)

> The previous discussion I found was from almost a year ago before
> development of the feature was started.
> 
Communication failure on my part then :-(  The feature's development was
basically complete by the end of August 2011 (as mandated by the GSoC
deadlines).  And Automake has been happily using TAP in its own testsuite
since then!

>> As for the implementation quality, there's still an annoying glitch in
>> that you need to *manually* copy the automake-provided 'tap-driver.sh'
>> script yourself into your package[2] -- "automake --add-missing" won't
>> work -- and define some variables by hand; all of this is documented
>> in the manual, and should hopefully be fixed for automake 1.12.1.
> 
> This does not seem like a big problem.
> 
> Russ Allbery's C TAP Harness looks reasonable as well.  It also
> requires adding a single file (.c) to the source tree and a rule
> to build it as a test program.
>
Consider that the whole point of the TAP support in Automake is that the
testsuite harness present in Automake-generated makefiles (the one that
gets launched by "make check") will act as TAP consumer itself.  Thus
the "harness" part of Russ' package is likely of little or no use in
conjunction with the newer Automake test harness -- but of course you
can reuse the part of his project that provide a TAP *producer* for C
and/or Shell programs.

> The philosophy of TAP is rather different than Automake's existing
> test suite.
>
Yes, but not too radically IMHO; in fact, the TAP consumer implemented by
Automake reuses most of the code and interfaces of the 'parallel-tests'
test harness (that was an early design choice, and so far I have been very
happy with it).

> These differences may prove challenging when switching from Automake
> tests to TAP:
>
Note that you don't need any "flag day switch" for a conversion to TAP: "simple
tests" (whose outcome is purely based on their exit status) and TAP tests can
happily co-exists (as they currently do in the Automake's own testsuite).  This
too is an early, deliberate design choice.

>   * Every TAP test needs to somehow know its unique test number (so it
> can print a result "ok 35").
>
Actually, not really:

  $ cat foo.sh
  #!/bin/sh
  echo 1..3
  echo 'ok'
  echo 'ok # SKIP'
  echo 'not ok # TODO'

  $ prove ./foo.sh
  ./foo.sh .. ok
  All tests successful.
  Files=1, Tests=3,  1 wallclock secs ( 0.04 usr +  0.00 sys =  0.04 CPU)
  Result: PASS

But as it's reasonable, if you provide a test number, that must be correct
(this should be undeniably recognized as a feature IMO); see:

  $ cat bar.sh
  #!/bin/sh
  echo 1..3
  echo 'ok 4'
  echo 'ok # SKIP'
  echo 'not ok # TODO'

  $ prove ./bar.sh
  ./bar.sh .. All 3 subtests passed
  (less 1 skipped subtest: 2 okay)
  Test Summary Report
  ---
  ./bar.sh (Wstat: 0 Tests: 3 Failed: 0)
Parse errors: Tests out of sequence.  Found (4) but expected (1)
  Files=1, Tests=3,  0 wallclock secs ( 0.04 usr +  0.00 sys =  0.04 CPU)
  Result: FAIL

> If the tests are all in the same
> module then they can simply increment an integer but if they are
> not then there is a problem (or they can always plan for one
> test).
>
Apart from the fact that I'd advise against writing your TAP stream by
hand (you should use a small but higher-level module or library or set
of functions to do so), the situation you describe shouldn't be a problem
in any case: Automake-produced Makefiles fire off a *new* TAP-parsing
process for each TAP-based test script in $(TESTS) [1], so that you would
only need to worry about the ordering/numbering of the test cases in the
script you are modifying.

 [1] This is also extremely important in order to preserve the ability
 to run tests in parallel -- one of the major selling points of the
 Automake testsuite harness.

>   * TAP tests need to know if they are expected to pass or fail.
> 
> A major feature of how GraphicsMagick is using the Automake tests
> framework is that it determines which tests are XFAIL based on what
> features were configured into the software.  The list of tests which
> are expected to fail is produced based on Automake conditionals.
> It is useful for the user to see tests XFAIL as a remind

Re: TAP support in automake

2012-03-31 Thread Russ Allbery 
Bob Friesenhahn  writes:

> The numbers are useful.  TAP is documented to support reporting the number
> of tests at the end of the test run rather than at the beginning.

Yes, that of course works as well.  With the basic C TAP library, you can
use plan_lazy() instead of plan() and the library will then figure out the
number of tests for you.

> Using your TAP test driver, and under the umbrella of Automake, how does
> one re-execute just one test in order to see the details of how it
> failed?  The sample tests in your test harness expect that SOURCE and
> BUILD have already been set in the environment by Automake so just
> running via the suggested 'runtests -o' results in a failed test.

SOURCE and BUILD are only not set when you're building the C TAP Harness
source out of its distribution tarball, since that creates a generic
runtests binary.  When incorporating the test framework into another
package, you would do (from README):

check_PROGRAMS = tests/runtests
tests_runtests_CPPFLAGS = -DSOURCE='"$(abs_top_srcdir)/tests"' \
-DBUILD='"$(abs_top_builddir)/tests"'

which will take care of defining SOURCE and BUILD, and then tests/runtests
-o  will work as expected.

-- 
Russ Allbery (r...@stanford.edu)

Re: TAP support in automake

2012-03-31 Thread Bob Friesenhahn 

On Sat, 31 Mar 2012, Russ Allbery wrote:

This isn't the case if you have a sufficiently new version of the TAP
driver.  The TAP protocol allows the tests to not be numbered.  You lose
some robustness, since you then potentially don't know if a test was
skipped silently, but it's supported by C TAP Harness in the runtests.c
driver.  (The basic C TAP library doesn't support generating that style of
output, but that's because the library takes care of the counting for you,
so you don't need to keep track of test numbers.)


The numbers are useful.  TAP is documented to support reporting the 
number of tests at the end of the test run rather than at the 
beginning.


Using your TAP test driver, and under the umbrella of Automake, how 
does one re-execute just one test in order to see the details of how 
it failed?  The sample tests in your test harness expect that SOURCE 
and BUILD have already been set in the environment by Automake so just 
running via the suggested 'runtests -o' results in a failed test.


In Automake I do this like

  make TESTS=mytest

Using Perl's test driver I can execute one test like

  make TEST_VERBOSE=1 TEST_FILES=t/mytest.t test

How will the Automake 1.12 TAP driver handle this common special case?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: TAP support in automake

2012-03-31 Thread Russ Allbery 
Bob Friesenhahn  writes:

> The philosophy of TAP is rather different than Automake's existing test
> suite.  These differences may prove challenging when switching from
> Automake tests to TAP:

>   * Every TAP test needs to somehow know its unique test number (so it
> can print a result "ok 35").  If the tests are all in the same
> module then they can simply increment an integer but if they are
> not then there is a problem (or they can always plan for one
> test).

This isn't the case if you have a sufficiently new version of the TAP
driver.  The TAP protocol allows the tests to not be numbered.  You lose
some robustness, since you then potentially don't know if a test was
skipped silently, but it's supported by C TAP Harness in the runtests.c
driver.  (The basic C TAP library doesn't support generating that style of
output, but that's because the library takes care of the counting for you,
so you don't need to keep track of test numbers.)

>   * TAP tests need to know if they are expected to pass or fail.

This is true, and there isn't support for supplying that information
outside of the test program itself.  I'd be happy to implement a TAP
extension to allow this for my test driver, though, since it seems
obviously useful.  But I think your particular use case may have a better
solution.

> A major feature of how GraphicsMagick is using the Automake tests
> framework is that it determines which tests are XFAIL based on what
> features were configured into the software.  The list of tests which are
> expected to fail is produced based on Automake conditionals.  It is
> useful for the user to see tests XFAIL as a reminder that the
> configuration may be missing something they wanted.  How is this best
> handled for TAP tests?

What I do for similar situations in my packages is that I test at the
start of a test program that relies on optional features whether those
features are available and, if not, call skip_all.  (The TAP protocol
representation being an initial "1..0 # skip ..." plan line.)  That will
result in that test being marked as skipped, which is *sort of* like
XFAIL.

You then get output like:

Running all tests listed in TESTS.  If any tests fail, run the failing
test program with runtests -o to see more details.

kafs/basic..skipped (AFS not available)
kafs/haspag.skipped (AFS not available)
pam-util/args...ok   
pam-util/fakepamok   
pam-util/loggingok   
pam-util/optionsok 
pam-util/vector.ok   
portable/asprintf...ok   
portable/daemon.ok 
portable/getaddrinfook   
portable/getnameinfook   
portable/getopt.ok   
portable/inet_aton..ok   
portable/inet_ntoa..ok 
portable/inet_ntop..ok   
portable/mkstempok   
portable/setenv.ok 
portable/snprintf...ok   
portable/strlcatok   
portable/strlcpyok   
portable/strndupok 
util/buffer.ok   
util/concat.ok   
util/fdflag.ok 
util/messages...ok   
util/messages-krb5..ok   
util/networkok 
util/vector.ok 
util/xmallocskipped (xmalloc tests only run for maintainer)
util/xwrite.ok   

All tests successful, 3 tests skipped.
Files=30,  Tests=2110,  5.13 seconds (0.00 usr + 0.00 sys = 0.00 CPU)

where the first two are a missing system feature and the last is a test
case that I only run if a particular environment variable is set.  You can
do similar things for any other missing feature, and of course skip only
part of the tests in a particular case case if you want (although
currently, with the C TAP Harness harness, the latter doesn't tell you the
reason why the test was skipped the way that ones skipped with skip_all
do).

-- 
Russ Allbery (r...@stanford.edu)

Re: TAP support in automake (was: Re: automake 1.11.3 check-TESTS and command line length)

2012-03-31 Thread Bob Friesenhahn 

On Sat, 31 Mar 2012, Stefano Lattarini wrote:



Well, automake being automake, it only depends on portable awk[1] ;-)
OK, portable "nawk" actually (as found by the autoconf builtin macro
AC_PROG_AWK), but I don't know of any non-museum machine lacking that.


Good.


The new feature is already documented in the automake manual on the
'master' branch; and this documentation should be release-quality
already.  But maybe I should make this new feature more visible before
the 1.12 release?  If yes, how do you suggest to do so?


Certainly mentioning and discussing it again on the 'automake' list 
(happening now) is useful.  The previous discussion I found was from 
almost a year ago before development of the feature was started.



As for the implementation quality, there's still an annoying glitch in
that you need to *manually* copy the automake-provided 'tap-driver.sh'
script yourself into your package[2] -- "automake --add-missing" won't
work -- and define some variables by hand; all of this is documented
in the manual, and should hopefully be fixed for automake 1.12.1.


This does not seem like a big problem.

Russ Allbery's C TAP Harness looks reasonable as well.  It also 
requires adding a single file (.c) to the source tree and a rule to 
build it as a test program.


The philosophy of TAP is rather different than Automake's existing 
test suite.  These differences may prove challenging when switching 
from Automake tests to TAP:


  * Every TAP test needs to somehow know its unique test number (so it
can print a result "ok 35").  If the tests are all in the same
module then they can simply increment an integer but if they are
not then there is a problem (or they can always plan for one
test).

  * TAP tests need to know if they are expected to pass or fail.

A major feature of how GraphicsMagick is using the Automake tests 
framework is that it determines which tests are XFAIL based on what 
features were configured into the software.  The list of tests which 
are expected to fail is produced based on Automake conditionals.  It 
is useful for the user to see tests XFAIL as a reminder that the 
configuration may be missing something they wanted.  How is this best 
handled for TAP tests?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/