| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Instead of low-level open(O_CREAT | O_EXCL) loop on all platforms, use
GetTempFileName() on Windows and mkstemp() elsewhere.
Don't append a final newline to NamedTempFile: use caller's data literally.
Tweak a couple comments.
|
|
|
|
Consider this pathname for llsdserialize_test.cpp:
C:\nats\indra\llcommon\tests\llsdserialize_test.cpp
Embed that in a Python string literal:
'C:\nats\indra\llcommon\tests\llsdserialize_test.cpp'
and you get a string containing:
C:
ats\indra\llcommon ests\llsdserialize_test.cpp
where the \n became a newline and the \t became a tab character.
Hopefully Python raw-string syntax r'C:\etc\etc' works better.
|
|
In this case, the Python code in question is being written from a C++ string
literal to a temp script file in a platform-dependent temp directory -- so the
Python __file__ value tells you nothing about the location of the repository
checkout. Embedding __FILE__ from the containing C++ source file works better.
|
|
And at that point, the Python logic needed to bring in the llsd module is big
enough to warrant capturing it in a separate string variable common to
multiple tests.
|
|
|
|
|
|
|
|
Verify that an LLSD::String containing newlines works; verify that newlines
between items are accepted.
|
|
Write a sequence of LLSDSerialize::toNotation() calls separated by newlines to
a data file, then read lines and parse using llbase.llsd.parse(). Verify that
this produces expected data even when one item is a string containing newlines.
Generalize python() helper function to allow using any of the NamedTempFile
constructor forms.
Allow specifying expected Python rc (default 0) and use this to verify an
intentional sys.exit(17). This is better than previous sys.exit(0) test
because when, at one point, NamedTempFile failed to write file data, running
Python on an empty script file still terminates with rc 0. A nonzero rc
verifies that we've written the file, that Python is running it and that we're
retrieving its rc.
|
|
The only thing about NamedTempScript that was specific to script files was the
hardcoded ".py" extension. Renaming it to NamedTempFile with an explicit
extension argument addresses that.
Allow constructing NamedTempFile with either a std::string, as before, or an
expression of the form (lambda::_1 << some << stuff). If Linden's Boost
package included the Boost.Iostreams lib, we could even stream such an
expression directly to an ostream constructed around the fd. But oh well.
|
|
|
|
Also mollify Linux build, which gets alarmed when you implicitly ignore
write()'s return value. Ignore it explicitly.
|
|
Seems Linden's Boost package and the viewer build might use different
settings of the /Zc:wchar_t switch.
Anyway, this implementation using open(O_CREAT | O_EXCL) should be more
robust. I'm surprised Boost.Filesystem doesn't seem to offer "create a unique
file"; all I found was "generate a random filename fairly likely to be unique."
|
|
|
|
On Windows, calling boost::filesystem::path::string() implicitly requests
code conversion between std::wstring (the boost::filesystem::path::string_type
selected on Windows) and std::string. At least for integration-test program,
that produces link errors. Use Linden's wstring_to_utf8str() instead.
|
|
|
|
|
|
It's wonderful that the Python interpreter will accept a whole multi-line
script as a composite -c argument... but because Windows command-line
processing is fundamentally flawed, we simply can't count on it for Windows.
Instead, accept script text, write a temporary script file in a system-
dependent temp directory, ask Python to run that script and delete the file.
Also, on Windows, use _spawnl(), much simpler than adding bizarre Windows wait
logic to LLProcessLauncher. Use LLProcessLauncher only on Mac & Linux, with
waitpid() to capture rc.
|
|
|
|
|
|
This is in its infancy; tested on Mac; needs to be ironed out on Windows and
Linux. Goal is to test at least some cross-language LLSD serialization.
|
|
|
|
|
|
Test also passes overlong arrays and maps with extraneous keys; in all cases
we expect the same set of values to be passed to the registered functions.
|
|
We'd introduced FunctionsTriple to associate a pair of registered function
names with the Vars* on which those functions should operate. But with more
different tests coming up, it became clear that restating the Vars* every time
a given function name appeared in any such context was redundant.
Instead, extended addf() to accept and store the relevant Vars* for each
registered function, be it the global Vars for the free functions and static
methods or the stack Vars for the non-static methods.
Added varsfor() function to retrieve and validate the Vars* for a given
function name.
Eliminated array_funcs() function, restating aggregates of names to test as
LLSD collections. Where before these were coerced into a separate LLSD map
with ["a"] and ["b"] keys, that map can now be part of the original structure.
|
|
An array-registered function has no param names, so you can only pass an
array: a map would be meaningless. Initial implementation of map-registered
functions assumed that since you CAN pass a map, you MUST pass a map. But in
fact it's meaningful to pass an array as well -- for whatever reason -- and
easy to implement, so there you are. Tests to follow.
|
|
LLSDParam<const char*> is coded to pass NULL for an isUndefined() LLSD value,
so event-based caller can choose whether to pass NULL, "" or whatever string
value to such a parameter. Ensure this behavior.
|
|
One operation we often use is to take an LLSD array of param names, a
corresponding LLSD array of values, and create from them a name=value LLSD
map. Instead of doing that "by hand" every time, use a function.
|
|
Streamline a bit more redundancy from the code in that test.
|
|
Following the C++ convention of having two distinct somethigna, somethingb
names, initially we introduced paramsa, paramsb LLSD arrays, following that
convention all the way down the line. This led to two distinct loops every
time we wanted to walk both arrays, since we didn't want to assume that they
were both the same size. But leveraging the fact that distinct LLSD arrays
stored in the same LLSD container can in fact be of different lengths,
refactored all the pairs of vars into top-level LLSD maps keyed by ["a"] and
["b"]. That lets us perform nested loops rather than duplicating the logic,
making test code much less messy.
|
|
Naively storing a const char* param in a const char* data member ignores the
fact that once the caller's done, the string data referenced by that pointer
will probably be freed. Store the referenced string in a std::string instead.
|
|
|
|
|
|
A certain popular-but-dumb compiler seems to think that initializing a
std::vector from a pair of iterators requires assignment. A struct containing
a reference cannot be assigned. Pointers get us past this issue.
|
|
We want to break out a couple different test methods that both need the same
data. While we could define a std::vector<FunctionsTriple> in the
lleventdispatcher_data class and initialize it using a classic {} initializer
as in array_funcs(), using a separate function puts it closer to the tests
consuming that data, and helps reduce clutter in the central data class.
Either way, it's cool that BOOST_FOREACH() handles the gory details of
iterating over a std::vector vs. a classic-C array.
|
|
|
|
You can't directly write:
BOOST_FOREACH(LLSD item, someLLSDarray) { ... }
because LLSD has two distinct iteration mechanisms, one for arrays and one for
maps, neither using the standard [const_]iterator typedefs or begin()/end()
methods. But with these helpers, you can write:
BOOST_FOREACH(LLSD item, llsd::inArray(someLLSDarray)) { ... }
or
BOOST_FOREACH(const llsd::MapEntry& pair, llsd::inMap(someLLSDmap)) { ... }
These are in namespace llsd instead of being (e.g.) llsd_inMap because with a
namespace at least your .cpp file can have a local 'using':
using namespace llsd;
BOOST_FOREACH(LLSD item, inArray(someLLSDarray)) { ... }
It's namespace llsd rather than LLSD because LLSD can't be both a namespace
and a class name.
|
|
Also, finally got sick of hand-writing the official iterator-loop idiom and
dragged in BOOST_FOREACH(). Because LLSD has two completely different
iteration styles, added inArray and inMap helper classes to be able to write:
BOOST_FOREACH(LLSD item, inArray(someArray)) { ... }
|
|
|
|
|
|
|
|
Previous tests involved a small handful of functions with only a couple
different parameter types. Now we exhaustively invoke every registration case,
plus every metadata query case. Call cases still pending.
|
|
|
|
Until now, LLEventAPI has only been able to register functions specifically
accepting(const LLSD&). Typically you add a wrapper method to your LLEventAPI
subclass, register that, have it extract desired params from the incoming LLSD
and then call the actual function of interest.
With help from Alain, added new LLEventAPI::add() methods capable of
registering functions/methods with arbitrary parameter signatures. The code
uses boost::fusion magic to implicitly match incoming LLSD arguments to the
function's formal parameter list, bypassing the need for an explicit helper
method.
New add() methods caused an ambiguity with a previous convenience overload.
Removed that overload and fixed the one existing usage.
Replaced LLEventDispatcher::get() with try_call() -- it's no longer easy to
return a Callable for caller to call directly. But the one known use of that
feature simply used it to avoid fatal LL_ERRS on unknown function-name string,
hence the try_call() approach actually addresses that case more directly.
Added indra/common/lleventdispatcher_test.cpp to exercise new functionality.
|
|
|
|
|
|
|
