[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] CUPS backend -- move to its own directory?
From:       Robert Krawitz <rlk () alum ! mit ! edu>
Date:       2019-06-02 21:18:10
Message-ID: 20190602211810.6C119141480 () localhost
[Download RAW message or body]

On Sat, 1 Jun 2019 22:13:40 -0400, Solomon Peachy wrote:
> On Fri, May 24, 2019 at 07:26:13PM -0400, Robert Krawitz wrote:
>> That's a lot better.  Can your test use the rotor setup (see the CUPS
>> and run-testpattern-2 tests to see how that works), so jobs can be
>> farmed off to different machines?  Currently it's split 5 ways.
>
> The tests implement a similar mechanism but the script does its own 
> forking.  I'll see about pulling that out so a specific rotor number can 
> be invoked arbitrarily..

As long as it uses the same environment variable interface
(STP_PARALLEL, STP_TEST_ROTOR, STP_TEST_ROTOR_CIRCUMFERENCE), the
implementation doesn't matter.

It should also handle STP_TEST_PROFILE, which is full, fast, valgrind,
checksums, minimal, valgrind_minimal, and valgrind_fast.  Any profile
that doesn't make sense (e. g. checksums) you should return status 77
from your script (that's what the GNU test framework uses to mean
skipped).  Figure on the minimal suites shouldn't take more than 1-2
minutes of CPU time, the fast ones should be in the 5 minute range,
and full can be whatever you want (within reason).

>> Would it be useful to have an option emit printer data streams, or
>> are those simply the unprocessed data from the driver with some out
>> of band protocol that can't be captured as a data stream?  That
>> would allow saving checksums from these tests like we do from the
>> run-testpattern-2 tests.
>
> I don't think so; most of the time the data going out is
> substantially similar to what goes in, but the backend has to do a
> bunch of interactive stuff to make sure it's okay to send the raster
> data and handle errors that inevitably pop up.

Yes, that makes sense...

> That said, emulating the printer would be substantially usful, but it's 
> really hard to justify that level of effort.  :)

That would indeed be a lot of effort.
-- 
Robert Krawitz                                     <rlk@alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
[prev in list] [next in list] [prev in thread] [next in thread]