| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
GCC doesn't allow to init non-constant references with temporary objects
|
|
|
|
|
|
It appears that the LLTrans machinery, or at least the way it's used in this
program, is buggy: linux-updater.bin has been crashing. Tracebacks and
experimentation identify LLTrans as the culprit, so replace it with baked-in
string constants copied from strings.xml. (linux-updater.bin was already
producing English-only messages because the update_install shell script that
calls it was specifically passing the English version of strings.xml.)
|
|
|
|
|
|
|
|
|
|
|
|
on and off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HTTP when all objects loading are done.
|
|
|
|
|
|
|
|
|
|
|
|
As a viewer architect, I would like to understand how fast each of the components of the texture pipeline can run in isolation
|
|
disconnect.
Added checks for LLViewerRegion pointer in LLViewerObject being invalid.
|
|
Mindful that some autobuild packages populate only packages/lib/release
(rather than packages/lib/debug), Linking.cmake always appends
packages/lib/release to CMake's link_directories() directive. But since CMake
always appends CMAKE_BUILD_TYPE to those directories, we end up with a phantom
packages/lib/release/Release directory on the search path. This would be
harmless except that the Mac's 'ld' command produces a warning. These warnings
quickly make TC's "Important Messages" output useless. Try appending
packages/lib/release only when the build type isn't already Release.
|
|
the logs when passing
WOLF-363: (partial) correct ordering of cleaning build dir vs running
'autobuild install'
|
|
removed a couple more unnecessary string copies from unfortunate LLSD behavior.
reviewed with simon, post review from Richard.
|
|
|
|
|
|
|
|
removed unnecessary string copies from chat message handling
|
|
This handles the case when the target file doesn't exist, just as APR_TRUNCATE
handles the case when it does.
Strengthen error checks concerning downloaded installer file from
ll_apr_warn_status() to ll_apr_assert_status(). Failing to recognize (e.g.)
failure to open that file only leads to mysterious crashes down the road; this
removes the mystery.
|
|
|
|
Reviewed by Ted.
|
|
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In
that case, CreateProcess() passes NO handles -- even the files you've
explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO
struct! Remove LLProcess code to tweak bInheritHandles; we should also remove
the corresponding (useless) APR extension.
Instead, given that the Windows file-locking problem we've observed is
specific to the viewer installer .exe file downloaded by the background
updater logic, use APR file I/O for that specific file. Empirically, both
llofstream and std::ofstream seem to make the open file handle inheritable;
but apr_file_open() documentation says: "By default, the returned file
descriptor will not be inherited by child processes created by
apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
|
|
|
|
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.
|
|
|
|
|
|
|
