- Mar 01, 2012
-
-
Nat Goodspeed authored
Of course, given the way the log machinery works, it's really "everything at that level or stronger."
-
Nat Goodspeed authored
This arises, for instance, if you want to be able to create a temporary Python module you can import from test scripts. The Python module file MUST have the .py extension.
-
Nat Goodspeed authored
All known callers were using ensure(! withMessage(...).empty()). Centralize that logic. Make failure message report the string being sought and the log messages in which it wasn't found. In case someone does want to permit the search to fail, add an optional 'required' parameter, default true. Leverage new functionality in llprocess_test.cpp.
-
Nat Goodspeed authored
We were using uniform macro to report the APR function and its C++ parameter expressions. But specifically for apr_proc_create() failure, better to report the command we're attempting to execute.
-
Nat Goodspeed authored
Giving more unit tests the ability to capture and examine log output is generally useful. Renaming the class just makes it less ambiguous: what's a TestRecorder? Something that records tests?
-
- Feb 29, 2012
-
-
Nat Goodspeed authored
We can't count on every child process reading everything we try to write to it. And if the child terminates with WritePipe data still pending, unless we explicitly suppress it, Posix will hit us with SIGPIPE. That would terminate the calling process, boom. "Ignoring" it means APR gets the correct errno, passes it back to us, we log it, etc.
-
Nat Goodspeed authored
Previously one might get process-terminated notification but still have to wait for the child process's final data to arrive on one or more ReadPipes. That required complex consumer timing logic to handle incomplete pending ReadPipe data, e.g. a partial last line with no terminating newline. New code guarantees that by the time LLProcess sends process-terminated notification, all pending pipe data will have been buffered in ReadPipes. Document LLProcess::ReadPipe::getPump() notification event; add "eof" key. Add LLProcess::ReadPipe::getline() and read() convenience methods. Add static LLProcess::getline() and basename() convenience methods, publishing logic already present elsewhere. Use ReadPipe::getline() and read() in unit tests. Add unit test for "eof" event on ReadPipe::getPump(). Add unit test verifying that final data have been buffered by termination notification event.
-
- Feb 27, 2012
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
We want to verify the sequence: LLInstanceTracker constructor adds instance to underlying container Subclass constructor throws exception LLInstanceTracker destructor removes instance from underlying container.
-
Nat Goodspeed authored
For the T* specialization (no string, or whatever, key), the original getInstance() method simply returned the passed-in T* value. It was defined, as the comments noted, for completeness of the analogy with the keyed LLInstanceTracker specialization. It turns out, though, that getInstance(T*) can still be useful to ask whether the T* you have in hand still references a valid T instance. Support that usage.
-
- Feb 26, 2012
-
-
Nat Goodspeed authored
Lacking time to properly test new LLStringUtil::getTokens() against the present (different!) command-line scanners in LLExternalEditor::tokenize() and LLCommandLineParser::parseCommandLineString(), just annotate as future work the goal of unifying them... SIGH.
-
Nat Goodspeed authored
This is an important differentiator between getTokens() and the present LLCommandLineParser::parseCommandLineString() logic: you cannot currently --set SomeVar to an empty string value because parseCommandLineString() discards empty strings.
-
- Feb 24, 2012
-
-
Nat Goodspeed authored
run_build_test.py already has the capability to set environment variables, and we may as well direct it to set PYTHON to the running Python interpreter. That completely eliminates one level of process wrapper.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
Nat Goodspeed authored
We didn't have any tokenizer suitable for scanning something like a bash command line. We do have a couple hacks, e.g. LLExternalEditor::tokenize() and LLCommandLineParser::parseCommandLineString(). Both try to work around boost::tokenizer limitations; but existing boost::tokenizer support just doesn't address this case. Neither of the above is available as a general scanner anyway, and parseCommandLineString() fails outright when passed "". New getTokens() also distinguishes between "drop delimiters" (e.g. space, return, newline) to be discarded from the token stream, versus "keep delimiters" (e.g. "+-*/") to be returned as tokens in their own right. There's an overload that honors escapes and a more efficient one that doesn't; each has a convenience overload that returns the scanned string vector rather than requiring a separate declaration. Tweak and comment older getTokens() implementation. Add unit tests for both old and new getTokens() implementations. Break out StringVec and std::ostream << StringVec from indra/llcommon/tests/listener.h to StringVec.h: that's coming in handy for a number of different TUT test sources.
-
- Feb 23, 2012
-
-
Nat Goodspeed authored
Clarify wording in some of the doc comments; be a bit more explicit about some of the parameter fields. Make some query methods 'const'. Change default LLProcess::ReadPipe::getLimit() value to 0: don't post any incoming data with notification event unless caller requests it. But do post pertinent FILESLOT in case caller reuses same listener for both stdout and stderr. Use more idiomatic, readable syntax for accessing LLProcess::Params data.
-
- Feb 20, 2012
-
-
Nat Goodspeed authored
If caller runs (e.g.) a Python script, it's not very helpful to a human log reader to keep seeing LLProcess instances logged as /pathname/to/python (pid). If caller is aware, the code can at least use the script name as the desc -- or maybe even a hint as to the script's purpose. If caller doesn't explicitly pass a desc, at least shorten to just the basename of the executable.
-
Nat Goodspeed authored
This way a caller need not spin on isRunning(); we can just listen for the requested termination event. Post a similar event containing error message if for any reason LLProcess::create() failed to launch the child. Add unit tests for both cases.
-
- Feb 18, 2012
-
-
Nat Goodspeed authored
That is, trying to instantiate a ReadPipeImpl while another already existed would throw an LLEventPump::DupPumpName exception. Fortunately this behavior is easily bypassed.
-
- Feb 16, 2012
-
-
Nat Goodspeed authored
The typos didn't make for invalid tests, but they made a few tests redundant while leaving other (subtly different) cases untested.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
Add unit tests for peek() with substring args, reimplemented contains(), various forms of find(). (yay unit tests)
-
Nat Goodspeed authored
-
Nat Goodspeed authored
If it's useful to have contains() to tell you whether incoming data contains a particular substring, and if it's useful for contains() and peek() to accept an offset within that data, then it's useful to allow you to get the offset of a desired substring within that data. But of course a find() returning offset needs something like std::string::npos for "not found"; borrow that convention. Support both find(const std::string&) and find(char); the latter permits a more efficient implementation. In fact, make find(string) recognize a string of length 1 and leverage the find(char) implementation. Given that, reimplement contains(mumble) as shorthand for find(mumble) != npos. Implement find() overloads using std::search() and std::find() on boost::asio::streambuf character iterators, rather than copying to std::string and then using string search like previous contains() implementation. Reimplement WritePipeImpl::tick() and ReadPipeImpl::tick() to write/read directly from/to boost::asio::streambuf data, instead of copying to/from a temporary flat buffer. As long as ReadPipeImpl::tick() keeps successfully filling buffers, keep reading. Previous implementation would only handle a long child write over successive tick() calls. Stop on read error or when we come up short.
-
- Feb 15, 2012
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
These are all very well when we just want to dump the output to a log, or whatever, but in a unit-test context it matters for comparison.
-
Nat Goodspeed authored
Also add "len" key to event data on LLProcess::getPump(). If you've used setLimit(), event["data"].length() may not reflect the length of the accumulated data in the ReadPipe. Add unit test with stdin/stdout handshake with child process.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
In the course of re-enabling the indra/test tests last year, Log generalized a workaround I'd introduced in llsdmessage_test.cpp. In Linux viewer land, a test program trying to catch an expected exception can't seem to catch it by its specific class (across the libllcommon.so boundary), but must instead catch std::runtime_error and validate the typeid().name() string. Log added a macro for this idiom in llevents_tut.cpp. Generalize that macro further for normal-case processing as well, move it to a header file of its own and use it in all known places -- plus the new exception-catching tests in llprocess_test.cpp.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
Add LLProcess::FileParam to specify how to construct each child's standard file slot, with lots of comments about features designed but not yet implemented. The point is to design it with enough flexibility to be able to extend to foreseeable use cases. Add LLProcess::Params::files to collect up to 3 FileParam items. Naturally this extends the accepted LLSD syntax as well. Implement type="" (child inherits parent file descriptor) and "pipe" (parent constructs anonymous pipe to pass to child). Add LLProcess::FILESLOT enum, plus methods: getReadPipe(FILESLOT), getOptReadPipe(FILESLOT) getWritePipe(), getOptWritePipe() getPipeName(FILESLOT): placeholder implementation for now Add LLProcess::ReadPipe and WritePipe classes, as returned by get*Pipe(). WritePipe supports get_ostream() method for streaming to child stdin. ReadPipe supports get_istream() method for reading from child stdout/stderr. It also provides getPump() returning LLEventPump& so interested parties can listen for arrival of new data on the aforementioned std::istream. For "pipe" slots, instantiate appropriate *Pipe class. ReadPipe and WritePipe classes are pure virtual bases for ReadPipeImpl and WritePipeImpl, respectively: all implementation data are hidden in the latter classes, visible only in llprocess.cpp. In fact each *PipeImpl class registers itself for "mainloop" ticks, attempting nonblocking I/O to the underlying apr_file_t on each tick. Data are buffered in a boost::asio::streambuf, which bridges between std::[io]stream and the APR I/O calls. Sanity-test ReadPipeImpl by using a pipe to absorb the Python "SyntaxError" output from the successful syntax_error test, rather than alarming the user. Add first few unit tests for validating FileParam. More tests coming!
-
- Feb 13, 2012
-
-
Nat Goodspeed authored
When we reimplemented LLProcess on APR, necessitating APR's funny callback mechanism to sense child-process status, every isRunning() or getStatus() call called the APR poll function that calls ALL registered LLProcess callbacks. In other words, every time any consumer called any LLProcess::isRunning() method, all LLProcess callbacks were redundantly fired. Change that so that the single APR poll function is called once per frame, courtesy of the "mainloop" LLEventPump. Once per viewer frame should be well within the realtime duration in which it's reasonable to expect child-process status to change. In effect, this changes LLProcess's public API to introduce a dependency on "mainloop" ticks. Add such ticks to llprocess_test.cpp as well.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Feb 12, 2012
-
- Feb 11, 2012
-
- Feb 10, 2012
-
-
Nat Goodspeed authored
Turns out that some (many?) wildcard LLManifest.path(wildcard) calls are "just in case": sweep up any (e.g.) "*.tga" files there may be, but no problem if there are none. Change path() logic so it tries the next tree (source, artwork, build) if either a specific (non-wildcard) filename doesn't exist, as now, OR if a wildcard matches 0 files in the current tree. This continues to support "just in case" wildcards, while permitting wildcards to work in the artwork and build trees as well as the source tree. Use a more specific exception than ManifestError for missing file. Only in that case should we try the next tree. Any other ManifestError should propagate.
-