Age | Commit message (Collapse) | Author |
|
|
|
|
|
# Conflicts:
# indra/newview/llfloatermodelpreview.cpp
|
|
|
|
new lldiskcache implementation
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llfloaterconversationpreview.cpp
# indra/newview/llinventorypanel.h
# indra/newview/llmeshrepository.h
# indra/newview/llvoicevivox.cpp
|
|
|
|
|
|
llcache but @henri's suggestion that that doesn't reflect the other files in the same place and it should be llfilesystem is a good one so I changed it over
|
|
scripts to use a different name - lldiskcache - since that more closely resembles what it is (or will be) now that the VFA is no more
|
|
changes to remove LLVFS and LLVFSThread classes along with the associated source files. The existing llvfs folder is renamed to llcache. Also includes changes to CMake script in many places to reflect changes. Eventually, llvfile source file and class will be renamed but that is not in this change.
|
|
This reverts commit 92499ce1b43fd60ce7aad71d12f9eef0cef04f7f.
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
# indra/newview/llinventorypanel.h
|
|
Callstack is clearly broken since it points to LLNotifications::instance().clear(); after 'Goodbye!', my suspicion is that something reinitialized singleton so I fixed cleanup and added some logging to see if there is a dupplicate init
|
|
|
|
|
|
# Conflicts:
# indra/cmake/DirectX.cmake
# indra/newview/llviewerparcelmedia.cpp
# indra/newview/viewer_manifest.py
|
|
|
|
Get rid of that ugly '#pragma clang diagnostic ignored "-Wdelete-incomplete"' by making sure the delete always happens inside llview.cpp, where the type of LLView is known.
|
|
This is not correct, as clang is available on all 3 platforms. The correct way to check for this is via __clang__ (https://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros)
|
|
# Conflicts:
# autobuild.xml
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llimprocessing.cpp
|
|
# Conflicts:
# indra/llcommon/llkeybind.cpp
# indra/llcommon/llkeybind.h
|
|
Changes were moved to DRTVWR-514
|
|
"SpellCheck" is FALSE
|
|
|
|
|
|
|
|
# Conflicts:
# indra/llxml/llcontrolgroupreader.h
# indra/newview/llviewerkeyboard.cpp
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
# indra/newview/lltexturectrl.cpp
# indra/newview/skins/default/xui/de/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/es/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/fr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/it/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ja/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/pt/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ru/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/tr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/zh/floater_texture_ctrl.xml
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/llmath/llquaternion.h
# indra/newview/lldrawpoolwater.cpp
# indra/newview/lljoystickbutton.cpp
# indra/newview/llvosky.cpp
# indra/newview/skins/default/textures/textures.xml
|
|
|
|
# Conflicts:
# indra/newview/app_settings/shaders/class1/objects/previewV.glsl
# indra/newview/lldynamictexture.cpp
# indra/newview/llfloatermodelpreview.cpp
|
|
# Conflicts:
# indra/newview/pipeline.cpp
|
|
|
|
|
|
|
|
|
|
LLEventDetail::visit_and_connect() promised special treatment for the
specific case when an LLEventPump::listen() listener was composed of (possibly
nested) boost::bind() objects storing boost::weak_ptr values -- specifically
boost::bind() rather than std::bind or lambdas, specifically boost::weak_ptr
rather than std::weak_ptr.
Outside of self-tests, it does not appear that anyone actually uses that
support.
There is good reason not to: it's a silent side effect of a complicated
compile-time inspection that could be silently derailed by use of std::bind()
or a lambda or a std::weak_ptr. Can you be sure you've engaged that promise?
How?
A more robust guarantee can be achieved by storing an LLTempBoundConnection in
the transient object itself. When the object is destroyed, the listener is
disconnected. Normal C++ rules around object destruction guarantee it. This
idiom is widely used.
There are a couple good reasons to remove the visit_and_connect() machinery:
* boost::bind() and boost::weak_ptr do not constitute the wave of the future.
Preferring those constructs to lambdas and std::weak_ptr penalizes new code,
whether by silently failing or by discouraging use of modern idioms.
* The visit_and_connect() machinery was always complicated, and apparently
never very robust. Most of its promised features have been commented out
over the years. Making the code base simpler, clearer and more maintainable
is always a useful effect.
LLEventDetail::visit_and_connect() was also used by the four
LLNotificationChannelBase::connectMumble() methods. Streamline those as well.
Of course, remove related test code.
|