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.
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.
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.
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
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
Nat Goodspeed