| Age | Commit message (Collapse) | Author |
|---|
|
Each test<n>() method invokes a function from earlier in the source. It's much
better if each of those functions immediately precedes the test that invokes it.
|
|
lleventcoro_test.cpp runs clean (as modified for new API), and all the rest
builds clean, but the resulting viewer is as yet untested.
|
|
|
|
Changing the queue-of-callables implementation to boost::signals2::signal,
which is noncopyable, means that LLPounceable itself should be noncopyable.
|
|
Vir points out that "queue of callables" is pretty much exactly what a signal
does.
Add unit tests to verify chronological order, also queue reset when fired.
|
|
LLMuteList, an LLSingleton, overrides its getInstance() method to intercept
control every time a consumer wants LLMuteList. This "polling" is to notice
when gMessageSystem becomes non-NULL, and register a couple callbacks on it.
Unfortunately there are a couple ways to request the LLMuteList instance
without specifically calling the subclass getInstance(), which would bypass
that logic. Moreover, the polling feels a bit dubious to start with.
LLPounceable<T*> presents an idiom in which you can callWhenReady(callable) on
the LLPounceable instance. If the T* is already non-NULL, it calls the
callable immediately; otherwise it enqueues it for when the T* is set
non-NULL. (This lets you "pounce" on the T* as soon as it becomes available,
hence the name.) So if gMessageSystem were an LLPounceable<LLMessageSystem*>,
LLMuteList's constructor could simply call gMessageSystem.callWhenReady() and
relax: the callbacks would be registered either on LLMuteList construction or
LLMessageSystem initialization, whichever comes later.
LLPounceable comes with its very own set of unit tests. However, as of this
commit it is not yet used in actual viewer code.
|
|
Remove evil getIfExists() method, used by no one.
Remove evil destroyed() method, used in exactly three places -- one of which
is a test. Replace with equally evil instanceExists() method, which is used
EVERYWHERE -- sigh.
|
|
The new toolchain may (!) have fixed a longstanding bug in LLLeap / APR when
we try to pump large volumes of data through a Windows named pipe using APR
nonblocking I/O. This used to fail pretty consistently because the APR
nonblocking write call would sometimes spuriously return "would block" when in
fact the data buffer was completely written; the caller would later retry,
which of course would duplicate some of the data in the pipe. Preliminary
experiments with VS 2013 suggest this may have been resolved. This changeset
is to propagate the experiment to a wider range of Windows systems; we may
need to revert it if in fact the bug persists.
|
|
|
|
ms_sleep() calls and adjust expectations accordingly
|
|
We use boost::phoenix::placeholders::arg1 to imply a whole lambda expression,
replacing boost::lambda. But to bind a plain function in a more
straightforward way, seems classic boost::bind() works while
boost::phoenix::bind() does not.
|
|
It's very irritating that Visual Studio produces a warning for unrecognized
#pragmas, which we then merrily turn into an error -- #pragma is inherently
compiler-specific!
|
|
https://svn.boost.org/trac/boost/ticket/10864
I've used boost::lambda with boost::function in a number of creative ways over
the years. But the clang 6 shipped with Xcode 6 seems to have somehow broken
lambda + function in Boost 1.57. boost::phoenix is a partial workaround.
Sadly, lambda's comma-operator overload doesn't seem to be supported,
necessitating a couple ugly workarounds.
With real lambdas now supported by current compilers, I'm sure the Boost
community has little incentive to repair the lambda + function problem.
Presumably we'll be able to use such features ourselves Real Soon Now...
|
|
These were of the form ensure(std::string, something convertible to bool). Not
sure what the ambiguity was, but ensure(std::string, bool(something)) works
better.
|
|
|
|
|
|
|
|
Hopefully this is temporary until we figure out the real problem!
|
|
The new TUT library build eliminates the ambiguity about ensure_equals(const
char*, ...) versus ensure_equals(const std::string&, ...). Now it's all based
on const std::string&. Remove pointless const char* overloads and ambiguous
forwarding templates.
With clang in Xcode 6, any new datatypes we intend to use with ensure_equals()
must have operator<<(std::ostream&, datatype) declared BEFORE lltut.h
#includes tut.hpp. Reorder code in certain test source files to guarantee that
visibility.
|
|
in: 'cout << a() << b()' the order of evaluation of a() and b() is undefined.
|
|
|
|
|
|
|
|
now - operator << issues on clang
|
|
trigger clang warnings
|
|
|
|
|
|
error reporting that is not properly cleaned up.
|
|
reporting that is not properly cleaned up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
further optimizations for codegen
|
|
changed unit declarations macros to make a lot more sense
|
|
macro in llunit
|
|
|
|
forced unit conversion code to inline
unit conversion now no longer converts all the way to base and back, but tries
to find equivalent units as early as possible
fixed another llinfos instance
scene monitor now outputs n/a for invalid samples
|
|
|
|
|
