| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
The LLURI::buildHTTP() overloads that take an LLSD 'path' accept 'undefined',
LLSD::String and (LLSD::Array of LLSD::String). A sequence of path components
passed in an Array is constructed into a slash-separated path. There are unit
tests in lluri_test.cpp to exercise that case.
To my amazement, there were NO unit tests covering the case of an LLSD::String
path. The code for that case escaped and appended the entire passed string.
While that might be fine for a 'path' consisting of a single undecorated path
component, the available documentation does not forbid one from passing a path
containing slashes as well. But this had the dubious effect of replacing every
slash with %2F.
In particular, decomposing a URL string with one LLURI instance and
constructing another like it using LLURI::buildHTTP() was not symmetrical.
Having consulted with Richard, I made the string-path logic a bit more nuanced:
- The passed path string is split on slashes. Every path component is
individually escaped, then recombined with slashes into the final path.
- Duplicate slashes are eliminated.
- The presence or absence of a trailing slash in the original path string is
carefully respected.
Now that we've nailed down how it ought to behave -- added unit tests to
ensure that it DOES behave that way!!
|
|
open root timer by default
|
|
|
|
cleaner implementation of llfasttimers...don't bother to share similarly named timers
just create multiple timers with same name...doesn't break anything
|
|
|
|
allow duplicate named fast timers again, refactored timer code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I recently tried to wade through llhandle.h and got somewhat perplexed. Armed
with an explanation from Richard, I've added notes to the file to try to make
it a bit less mysterious.
|
|
Leaving llhandle.h in llui restricts the set of viewer project directories
which could potentially use it, and there's nothing whatsoever UI-specific
about it.
|
|
|
|
cleaned up LLStat and removed unnecessary includes
|
|
removed unnecessary cache miss from fast timers
renamed llfasttimer_class back to llfasttimer
|
|
|
|
|
|
rather than fixing them; changing llcommon to be statically linked avoids the symbol issues with llcommon.dll
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We now specialize std::less<const std::type_info*> to use
std::type_info::before(), and on Windows and Mac that Just Works. It even
works on Linux when using gcc 4.4+: more recent implementations of gcc's
std::type_info::before() apparently do name()-string comparisons internally.
It doesn't work so well on Linux with gcc 4.1, though, and that's the compiler
we still use on our Linux build-farm machines. But rather than give up,
perform explicit name()-string comparison in that case.
|
|
Instead of forbidding std::map<const std::type_info*, ...> outright (which
includes LLRegistry<const std::type_info*, ...> and LLRegistrySingleton<const
std::type_info*, ...>), try to make it work by specializing std::less<const
std::type_info*> to use std::type_info::before().
Make LLRegistryDefaultComparator<T> use std::less<T> so it can capitalize on
that specialization.
|
|
|
|
The changeset above touched every consumer of the two LLRegistrySingletons
originally defined with std::type_info* as keys. Those two
LLRegistrySingletons were changed to use const char* as keys, then all
consumers were changed to pass std::type_info::name() instead of the plain
std::type_info* pointer -- to deal with the observed fact that on Linux, a
given type might produce different std::type_info* pointers in different load
modules. Since then, Richard turned up the fascinating fact that at least some
implementations of gcc's std::type_info::before() method already accommodate
this peculiarity. It seems worth backing out the (dismayingly pervasive)
change to see if properly using std::type_info::before() as the map comparator
will work just as well, with conceptually simpler source code.
This backout is transitional: we don't expect things to build/run properly
until we've cherry-picked certain other pertinent changes.
|
|
clean up of llstats stuff
|
|
boost::unordered_map<const char*, ...> does NOT, by default, "do the right
thing." Give it hash and equality functors that do.
|
|
Try to diagnose the cause of the misbehavior with a BOOST_STATIC_ASSERT.
|
|
|
|
Although LLRegistry and LLRegistrySingleton have always defined a COMPARATOR
template parameter, it wasn't used for the underlying map. Therefore every
type, including any pointer type, was being compared using std::less. This
happens to work most of the time -- but is tripping us up now.
Pass COMPARATOR to underlying std::map. Fix a couple minor bugs in
LLRegistryDefaultComparator (never before used!). Specialize for const char*.
Remove CompareTypeID and LLCompareTypeID because we now actively forbid using
LLRegistry<std::type_info*, ...>; remove only known reference
(LLWidgetNameRegistry definition).
|
|
Per discussion with Richard, accept the type key for insert() and find() as a
template parameter rather than as std::type_info*. This permits (e.g.) some
sort of compile-time prehashing for common types, without changing the API.
Eliminate iterators from the API altogether, thus avoiding costs associated
with transform_iterator.
Fix existing references in llinitparam.h.
|
|
Back out code that selects LLTypeInfoLookup for the underlying map
implementation when KEY = [const] std::type_info*, because LLTypeInfoLookup's
API is changing to become incompatible with std::map. Instead, fail with
STATIC_ASSERT when LLRegistry's KEY is [const] std::type_info*.
Fix all existing uses to use std::type_info::name() string instead.
|
|
Maybe it's failing to correctly handle overloaded transform() methods?
|
|
It seems MSVC doesn't like boost::make_transform_iterator() in the context I
was using it. Try directly invoking the iterator's constructor.
|
|
The original LLTypeInfoLookup implementation was based on two assumptions:
small overall container size, and infrequent normal-case lookup failures.
Those assumptions led to binary-searching a sorted vector, with linear search
as a fallback to cover the problem case of two different type_info* values for
the same type. As documented in the Jira, this turned out to be a problem. The
container size was larger than expected, and failed lookups turned out to be
far more common than expected.
The new implementation is based on a hash map of std::type_info::name()
strings, which should perform equally well in the success and failure cases:
no special-case fallback logic.
|
|
|
|
|
|
rather than fixing them; changing llcommon to be statically linked avoids the symbol issues with llcommon.dll
|
|
|
|
|
