| Age | Commit message (Collapse) | Author |
|---|
|
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)) { ... }
|
|
|
|
|
|
|
|
On Windows, unlike on Mac or Linux, boost::ptr_map<> started insisting on this
concept of clonability. In other words, it wants to own a unique instance of
the pointee; if you copy a value_type -- even to dereference an iterator! --
it wants to construct a whole new instance of the mapped_type. That's nuts. A
std::map<..., boost::shared_ptr<>> has the property I want (the mapped_type
goes away when the entry is erased), plus it's willing to pass around the
shared_ptr to the same instance of the mapped_type. This change also permits
simplifying a couple awkward kludges I'd already had to make to accommodate
ptr_map's idiosyncracies.
|
|
Newer C++ compilers produce a (fatal) warning when you try to initialize a
(non-const) char* variable with a string literal: you're supposed to capture
such data in a const char*. But as this module is resolving external
references declared in ancient message-system headers, we don't have the
option to fix the original declaration. Instead use
char* _PREHASH_Foo = const_cast<char*>("string literal"); // sigh
|
|
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.
|
|
The shortcut way to construct an LLSD array of size n is to assign LLSD() to
array[n-1]. That's fine -- as long as you remember not to do it for n == 0.
|
|
A free function or static method accepting(const LLSD&) was being intercepted
by the free-function-with-arbitrary-parameters overload instead of the
original Callable overload. Added an overload that specifically redirects that
case.
Documented limit of ~6 arbitrary parameters for directly-called functions (5
for methods). Beyond that many, you have to write a Callable wrapper function
and unpack the parameters from the LLSD by hand.
|
|
Nested LLSDArray expressions, e.g.:
LLSD array_of_arrays(LLSDArray(LLSDArray(17)(34))
(LLSDArray("x")("y")));
would quietly produce bad results because the outermost LLSDArray was being
constructed with the compiler's implicit LLSDArray(const LLSDArray&) rather
than LLSDArray(const LLSD&) as the reader assumes. Fixed with an explicit copy
constructor to Do The Right Thing.
Generalized LLSDParam<float> specialization into a macro to resolve similar
conversion ambiguities for float, LLUUID, LLDate, LLURI and LLSD::Binary.
Added optional bits= argument to llsd_equals() to permit comparing embedded
Real values using is_approx_equal_fraction() rather than strictly bitwise.
Omitting bits= retains current bitwise-comparison behavior.
|
|
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.
|
|
LLSDArray is a helper to construct an LLSD::Array value inline.
LLSDMap is a helper to construct an LLSD::Map value inline.
LLSDParam is a customization point, a way for generic code to support
unforseen parameter types as conversion targets for LLSD values.
|
|
|
|
|
|
|
|
|
|
|
|
restrictive filtering.
Stored filter sub-string comparison with new string failed because of non-matching register of compared strings. Transforming the new search term to uppercase before comparing it with previous one allows to determine if filter became more or less restrictive and not to restart the search over.
Used patch provided by Satomi Ahn.
|
|
|
|
|
|
limit the number of object cache files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Viewer attempting to load precached images in file types that are not being used.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
