| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
names in other classes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In addition to its usual apr_sterror() function, APR defines a special
function specifically for errors relating to the apr_dso_*() functions.
Introduce ll_apr_warn_status() and ll_apr_assert_status() overloads accepting
apr_dso_handle_t* to call apr_dso_error() as well as apr_strerror() and log
its output. Use new ll_apr_warn_status() in LLAppViewer::loadEventHostModule()
for apr_dso_load() and apr_dso_sym() calls. Instead of shorthand
ll_apr_assert_status(), use with llassert_always() so check is still performed
even in Release build.
Add more lleventhost-related debugging output, e.g. full pathname of the DLL.
On Mac and Linux, call 'file' command to report nature of the DLL too.
|
|
|
|
|
|
|
|
|
|
|
|
--args which is 10.6 only. Also fix erroneous check in process launcher which was mistakenly reporting a failed execution of the new updater script.
|
|
|
|
|
|
|
|
|
|
The bundle ID is found in llversionviewer.h, Info-SecondLife.plist and
mac_updater.cpp. The latter two state it as "com.secondlife.indra.viewer".
llversionviewer.h stated it as "com.secondlife.snowglobe.viewer". Changing it
to "indra" to be consistent. For further discussion, please see the Jira.
|
|
The TextureFetch thread was still stalling out due to
a different path that determines whether there is work
or not in the thread (uses getPending()) and that had
to be harmonized with the changes to runCondition().
I'm not happy with this solution but a refactor of the
LLThread tree isn't in the cards right now.
|
|
|
|
|
|
|
|
metrics, will disable later.
|
|
|
|
|
|
|
|
|
|
|
|
The editor can be specified:
* via "ExternalEditor" setting in settings.xml
* via LL_SCRIPT_EDITOR variable
Removed obsolete XUIEditor setting in favor of the new one.
|
|
|
|
|
|
|
|
|
|
|
|
globals and magic strings, enforce naming conventions
|
