| Age | Commit message (Collapse) | Author | 
 | 
Apparently our TeamCity build machines are still not up to Python 2.6.
 | 
 | 
 | 
 | 
 | 
 | 
Instead of free python() and python_out() functions containing a local
temporary LLProcessLauncher instance, with a 'tweak' callback param to
"do stuff" to that inaccessible object, change to a PythonProcessLauncher
class that sets up a (public) LLProcessLauncher member, then allows you to
run() or run() and then readfile() the output. Now you can construct an
instance and tweak to your heart's content -- without funky callback syntax --
before running the script.
Move all such helpers from TUT fixture struct to namespace scope. While
fixture-struct methods can freely call one another, introducing a nested class
gets awkward: constructor must explicitly require and bind a fixture-struct
pointer or reference. Namespace scope solves this.
(Truthfully, I only put them in the fixture struct originally because I
thought it necessary for calling ensure() et al. But ensure() and friends are
free functions; need only qualify them with tut:: namespace.)
 | 
 | 
Run INTEGRATION_TEST_llprocesslauncher using setpython.py so we can find the
Python interpreter of interest.
Introduce python() function to run a Python script specified using
NamedTempFile conventions.
Introduce a convention by which we can read output from a Python script using
only the limited pre-January-2012 LLProcessLauncher API. Introduce
python_out() function to leverage that convention.
Exercise a couple of LLProcessLauncher methods using all the above.
 | 
 | 
Specifically:
Introduce ManageAPR class in indra/test/manageapr.h. This is useful for a
simple test program without lots of static constructors.
Extract NamedTempFile from llsdserialize_test.cpp to indra/test/
namedtempfile.h. Refactor to use APR file operations rather than platform-
dependent APIs.
Use NamedTempFile for llprocesslauncher_test.cpp.
 | 
 | 
 | 
 | 
Defend test against the ambiguous answer to that question by not recording, or
testing for, EOF history events.
Enrich output for history-verification failures: display whole history array.
 | 
 | 
 | 
 | 
Previous logic was vulnerable to the case in which both pipes reached EOF in
the same loop iteration. Now we use std::list instead of std::vector, allowing
us to iterate and delete with a single pass.
 | 
 | 
Otherwise the unreferenced declaration causes a fatal warning.
 | 
 | 
Quiet the temporary child_status_callback() output.
Add a bit of diagnostic info if apr_proc_wait() returns anything but
APR_CHILD_DONE.
 | 
 | 
At least on OS X 10.7, a call to apr_proc_wait(APR_NOWAIT) in fact seems to
block the caller. So instead of polling apr_proc_wait(), use APR callback
mechanism (apr_proc_other_child_register() et al.) and poll that using
apr_proc_other_child_refresh_all().
Evidently this polls the underlying system waitpid(), but the internal call
seems to better support nonblocking. On arrival in the
child_status_callback(APR_OC_REASON_DEATH) call, though, apr_proc_wait()
produces ECHILD: the child process in question has already been reaped.
The OS-encoded wait() status does get passed to the callback, but then we have
to use OS-dependent macros to tease apart voluntary termination vs. killed by
signal... a bit of a hole in APR's abstraction layer.
Wrap ensure_equals() calls with a macro to explain which comparison failed.
 | 
 | 
Fix EOL issues: "\r\n" vs. "\n".
On Windows, requesting a read in nonblocking mode can produce EAGAIN instead
of EWOULDBLOCK.
 | 
 | 
That is, where before we just flung stuff to stdout with the expectation that
a human user would verify, replace with assertions in the test code itself.
Quiet previous noise on stdout.
Introduce a temp script file that produces output on both stdout and stderr,
with sleep() calls so we predictably have to wait for it. Track and then
verify the history of our interaction with the child process, noting
especially EWOULDBLOCK attempts.
 | 
 | 
 | 
 | 
As always with llcommon, this is expressed as an "integration test" to
sidestep a circular dependency: the llcommon build depends on its unit tests,
but all our unit tests depend on llcommon.
Initial test code is more for human verification than automated verification:
does APR's child-process management in fact support nonblocking operations?
 |