| Age | Commit message (Collapse) | Author |
|---|
|
|
|
removed bad assert
fixed precision issues during int->unsigned int conversions and vice
versa
|
|
added unit tests for lltrace
|
|
made getPrimaryAccumulator return a reference since it was an
always non-null pointer
changed unit conversion to perform lazy division in order to avoid truncation
of timer values
|
|
continued conversion to units system
made units perform type promotion correctly and preserve type in arithmetic
e.g. can now do LLVector3 in units
added typedefs for remaining common unit types, including implicits
|
|
added convenience types for units F32Seconds, etc.
|
|
point after crossing region boundary
fine-tuned heuristics for switching between mean and current values in stat bar display
added comments to LLUnits unit test
|
|
bounces once per second
SH-4346 FIX: Interesting: some integer Statistics are displayed as floating point after crossing region boundary
made llerrs/infos/etc properly variadic wrt tags
LL_INFOS("A", "B", "C") works, for example
fixed unit tests
remove llsimplestat
|
|
consolidated most indra-specific constants in llcommon under indra_constants.h
fixed issues with operations on mixed unit types (implicit and explicit)
made LL_INFOS() style macros variadic in order to subsume other logging methods
such as ll_infos
added optional tag output to error recorders
|
|
|
|
fast timer data now resets on login
|
|
|
|
removed implicit flushes on reads from recorders for better performance
made sure stack timers were updated on recorder deactivate
faster rendering and better ui for fast timer view
|
|
added getAs and setAs to LLUnit to make it clearer how you specify units
removed accidental 0-based indexing of periodicRecording history...
should now be consistently 1-based, with 0 accessing current active recording
removed per frame timer updates of all historical timer bars in fast timer display
added missing assignment operator to recordings
|
|
changed Units macros and argument order to make it more clear
optimized units for integer types
fixed merging of periodicrecordings...should eliminate duplicate entries in sceneloadmonitor history
|
|
|
|
|
|
|
|
Introduce LLCoros::setStackSize(), with a compile-time default value we hope
we never have to use. Make LLAppViewer call it with the value of the new
settings variable CoroutineStackSize as soon as we've read settings files.
(While we're at it, notify interested parties that we've read settings files.)
Give CoroutineStackSize a default value four times the previous default stack
size. Make LLCoros::launch() pass the saved stack size to each new coroutine
instance.
Re-enable lleventcoro integration test. Use LLSDMap() construct rather than
LLSD::insert(), which used to return the modified object but is now void.
|
|
|
|
|
|
dependencies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from this tree
|
|
In autobuild.xml, specify today's build of the Boost package that includes the
Boost.Context library, and whose boost::dcoroutines library uses Boost.Context
exclusively instead of its previous context-switching underpinnings (source of
the ucontext.h dependency).
Add BOOST_CONTEXT_LIBRARY to Boost.cmake and Copy3rdPartyLibs.cmake. Link it
with the viewer and with the lllogin.cpp test executable.
Track new Boost package convention that our (early, unofficial) Boost.Coroutine
library is now accessed as boost/dcoroutine/etc.h and boost::dcoroutines::etc.
Remove #include <boost/coroutine/coroutine.hpp> from
llviewerprecompiledheaders.h and lllogin.cpp: old rule that Boost.Coroutine
header must be #included before anything else that might use ucontext.h is
gone now that we no longer depend on ucontext.h. In fact remove
-D_XOPEN_SOURCE in 00-Common.cmake because that was inserted specifically to
work around a known problem with the ucontext.h facilities.
|
|
|
|
improved unit tests for LLUnit
renamed LLUnit to LLUnitImplicit with LLUnit being reserved for
explicit units
|
|
added unit tests for LLUnit
|
|
* Removed no longer used unpack_bufsize from bitpack_test.cpp
* Added llviewertexture_stub.cpp to the newview tests directory to fix llworldmap_test.cpp and llworldmipmap_test.cpp linker errors.
|
|
alignment issue in llAppearance.
|
|
|
|
|
|
|
|
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!!
|
|
Big delta was converting the new texture debugger support code
to the new library. Viewer manifest should probably get an eyeball
before release.
|
|
|
|
That is, when the underlying LLError::Settings object is destroyed -- possibly
at termination, possibly on LLError::restoreSettings() -- the passed Recorder*
is deleted.
There was much existing code that seemed as unaware of this alarming fact as I
was myself. Passing to addRecorder() a pointer to a stack object, or to a
member of some other object, is just Bad. It might be preferable to make
addRecorder() accept std::auto_ptr<Recorder> to make the ownership transfer
more explicit -- or even boost::shared_ptr<Recorder> instead, which would
allow the caller to either forget or retain the passed Recorder.
This preliminary pass retains the Recorder* dumb pointer API, but documents
the ownership issue, and eliminates known instances of passing pointers to
anything but a standalone heap Recorder subclass object.
|
|
This test must not be subject to spurious environmental failures, else some
kind soul will disable it entirely. We observe that APR specifies a hard-coded
buffer size of 64Kbytes for pipe creation -- use that and cross fingers.
|
|
Sigh, the rejoicing was premature.
|
|
If in fact we've managed to fix the APR bug writing to a Windows named pipe,
it should no longer be necessary to try to work around it by testing with a
much smaller data volume on Windows!
|
|
Ideally we'd love to be able to nail the underlying bug, but log output
suggests it may actually go all the way down to the OS level. To move forward,
try to bypass it.
|
|
We want to write a robust test that consistently works. On Windows, that
appears to require constraining the max message size. I, the coder, could try
submitting test runs of varying sizes to TC until I found a size that works...
but that could take quite a while. If I were clever, I might even use a manual
binary search. But computers are good at binary searching; there are even
prepackaged algorithms in the STL. If I were cleverer still, I could make the
test program itself search for size that works.
|
|
Apparently, at least on Mac, there are circumstances in which the very-large-
message test can take several times longer than normal, yet still complete
successfully. This is always the problem with timeouts: does timeout
expiration mean that the code in question is actually hung, or would it
complete if given a bit longer?
If very-large-message test fails, retry a few times with smaller sizes to try
to find a size at which the test runs reliably. The default size, ca 1MB, is
intended to be substantially larger than anything we'll encounter in the wild.
Is that "unreasonably" large? Is there a "reasonable" size at which the test
could consistently pass? Is that "reasonable" size still larger than what we
expect to encounter in practice? Need more information, hence this code.
|
|
Otherwise, a stuck child process could potentially hang the test, and thus the
whole viewer build.
|
