| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
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'
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
missed a few spots: cleanup: get rid of the no-op 'mex' function in the shaders which was being used as a dummy replacement for 'mix'
|
|
cleanup: get rid of the no-op 'mex' function in the shaders which was being used as a dummy replacement for 'mix'
|
|
a bunch of trivial clean-ups and commentary.
|
|
Coalesced patchset.
|
|
|
|
simplifies llvoavatar and allows adding such tracking to classes that live outside the avatar lifetime
|
|
On Windows, Bad Things happen when apr_proc_create() is allowed to pass TRUE
to CreateProcess(bInheritHandles). For instance, the open handle for a new
installer executable file being downloaded by the background updater gets
inadvertently passed to a couple slplugin.exe instances. When the viewer
finishes downloading, closes the file and tries to remove it, Windows balks
because the file is still open by another process. Require an apr_suite
package that includes the new Linden apr_procattr_inherit_set() extension, and
call it to turn off CreateProcess(bInheritHandles).
|
|
Attempting to debug an observed LLFile::remove() failure, I was floored to
find that remove() made no attempt whatsoever to report its lack of success!
Add warnif() function to log errno text in platform-dependent way. Support the
notion that for some functions, certain errno values are acceptable -- e.g. we
expect stat() to frequently hit ENOENT -- and need not be logged.
Add commented-out Windows-specific logic to try to provide further information
in the case of EACCES ("Permission denied," e.g. another process has the file
open). To use, enable the code block, download handle.exe and turn on DEBUG
logging for LLFile. handle.exe can be obtained from:
http://technet.microsoft.com/en-us/sysinternals/bb896655
|
|
|
|
|
|
|
|
request from similator and display a notification
Reviewed by Simon
|
|
Incoming changes from two different project repos left viewer-development with
LLInventoryModel::removeItem() and removeCategory() plus free functions
remove_item() and remove_category() in llinventoryfunctions.cpp.
remove_category() was actually the better implementation; migrated its body
into LLInventoryModel::removeCategory(). Clearly the previous state of affairs
-- with LLInventoryModel::removeItem() plus a remove_category() free function
in a very different source file -- fooled two different developers into
overlooking the other of the pair. Unfortunately we each added different
"missing" functions, leaving us with a complete set of four.
Fix existing references to remove_item() and remove_category() free functions.
|
|
|
|
|
|
|
|
range for high res.
|
|
|
|
|
|
|
|
|
|
|
|
when the camera is still
|
|
that parameter
|
