On Windows, when logged in with a non-ASCII username, every one of the three
documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
account for the fact that the oldest of these continues to work with the
release viewer and within a Python script (though not, curiously, from a
Python interactive session). With a non-ASCII username, they consistently fail
when called from an Alex Ivy viewer build: "The filename, directory name, or
volume label syntax is incorrect."
Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
where those are, yup, actual question marks.
Empirically, the VMP is able to successfully call SHGetFolderPath() to
retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
LLDir_Win32 retrieve those environment variables.
Make LLFile::mkdir() treat "directory already exists" as a success case. Every
single call fell into one of two categories: either it didn't check success at
all, or it tested specially to exempt errno == EEXIST. Migrate that test into
mkdir(); eliminate it from call sites.
Make LLDir::append() and add() convenience functions accept variadic
arguments. Replace add(add()...) constructs, as well as clumsy concatenations
of directory names and getDirDelimiter(), with simple variadic add() calls.
When std::istream::good() returns false, presumably we can no longer rely on
get() returning valid data. Certain streamtools tests were assuming that get()
would return the empty string at EOF, but in fact it appears that it left the
previous buffer contents unmodified.
The LLApp API used to consist of init(), mainLoop(), cleanup() methods. This
makes sense -- but on Mac that structure was being subverted. The method
called mainLoop() was in fact being called once per frame. There was
initialization code in the method, which (on Mac) needed to be skipped with an
already-initialized bool. There was a 'while' loop which (on Mac) needed to be
turned into an 'if' instead so the method would return after every frame.
Rename LLApp::mainLoop() to frame(). Propagate through subclasses LLAppViewer
and LLCrashLogger. Document the fact that frame() returns true to mean "done."
(This was always the case, but had to be inferred from the code.)
Rename the Mac Objective-C function mainLoop to oneFrame. Rename the C++ free
function it calls from runMainLoop() to pumpMainLoop(). Add comments to
llappdelegate-objc.mm explaining (inferred) control flow.
Change the Linux viewer main() and the Windows viewer WINMAIN() from a single
LLAppViewer::mainLoop() call to repeatedly call frame() until it returns true.
Move initialization code from the top of LLAppViewer::frame() to the init()
method, where it more properly belongs. Remove corresponding
mMainLoopInitialized flag (and all references) from LLAppViewer.
Remove 'while (! LLApp::isExiting())' (or on Mac, 'if (! LLApp::isExiting())')
from LLAppViewer::frame() -- thus unindenting the whole body of the 'while'
and causing many lines of apparent change. (Apologies to reviewers.)
There are four LLApp states: APP_STATUS_RUNNING, APP_STATUS_QUITTING,
APP_STATUS_STOPPED and APP_STATUS_ERROR. Change LLAppViewer::frame() return
value from (isExiting()) (QUITTING or ERROR) to (! isRunning()). I do not know
under what circumstances the state might transition to STOPPED during a
frame() call, but I'm quite sure that if it does, we don't want to call
frame() again. We only want a subsequent call if the state is RUNNING.
Also rename mainLoop() method in LLCrashLogger subclasses
LLCrashLoggerWindows, LLCrashLoggerMac, LLCrashLoggerLinux. Of course it's
completely up to the frame() method whether to yield control; none of those in
fact do. Honor protocol by returning true (frame() is done), even though each
one's main() caller ignores the return value.
In fact LLCrashLoggerWindows::mainLoop() wasn't using the return protocol
correctly anyway, returning wParam or 0 or 1 -- possibly because the return
protocol was never explicitly documented. It should always return true: "I'm
done, don't call me again."
Remove legacy udp script upload methods,
Refactor script runtime perms from three arrays to one struct array so we don't have to juggle array order anymore.
Apparently in Boost 1.57 with Xcode 6, the combination of Boost.Lambda and
Boost.Function is broken -- Trac ticket 10864:
https://svn.boost.org/trac/boost/ticket/10864
However, Boost.Phoenix provides an acceptable replacement.
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.
lltut.h declares a number of ensure_equals() overloads for various data types,
notably the types supported by LLSD. We expect these to be called by tut code.
But the tut code in question is in a template in tut.hpp -- which was
#included BEFORE the overloads were declared. Previous C++ compilers have
evidently made multiple passes, collecting the relevant overloads before
attempting to compile the template bodies. clang does not, complaining that
the overloads must be declared before the tut.hpp template code that
references them. Reordering parts of lltut.h seems to address that problem.
For similar reasons, test programs that use StringVec.h and its operator<<()
must #include StringVec.h before lltut.h.
Add ensure_equals(const std::string&, const LLSD::Binary&, const LLSD::Binary&)
overload. The sloppy mix of (const char*, ...) and (const std::string&, ...)
overloads bothers me, since for many of those ... types we seem to have to
duplicate them.
Oz Linden