- Jan 05, 2020
-
-
Rye Mutt authored
-
- Dec 12, 2019
-
-
Rye Mutt authored
default many constructors and destructors
-
- Sep 29, 2019
-
-
¡Cinder! ㊝ authored
-
- Sep 26, 2019
-
-
¡Cinder! ㊝ authored
-
- Jul 28, 2019
-
-
¡Cinder! ㊝ authored
-
- Oct 30, 2018
-
-
Mnikolenko ProductEngine authored
-
- Apr 15, 2018
-
-
Oz Linden authored
-
- Apr 13, 2018
-
-
Oz Linden authored
-
- Jun 27, 2017
-
-
Drake Arconis authored
-
- Jun 30, 2017
-
-
andreykproductengine authored
-
- May 24, 2017
-
-
Cinder authored
- Fix member init order - Use override specifier everywhere - Add required typename and template keywords - Replace smart pointer ctors with make functions where available - Replace 0 and NULL in pointer context with nullptr
-
- Mar 13, 2017
-
-
Oz Linden authored
-
- Mar 08, 2017
-
-
Oz Linden authored
-
- Mar 01, 2017
-
-
Oz Linden authored
-
- Oct 03, 2016
-
-
Luminous Luminos authored
These functions are deleting an iterator which invalidates the reference to the shared pointer that was passed in causing a use after free.
-
- Sep 28, 2016
-
-
Drake Arconis authored
-
- Sep 15, 2016
-
-
Nat Goodspeed authored
A shocking number of LLSingleton subclasses had public constructors -- and in several instances, were being explicitly instantiated independently of the LLSingleton machinery. This breaks the new LLSingleton dependency-tracking machinery. It seems only fair that if you say you want an LLSingleton, there should only be ONE INSTANCE! Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the friend class LLSingleton<whatevah>; and explicitly declare a private nullary constructor. To try to enforce the LLSINGLETON() convention, introduce a new pure virtual LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might suspect, defined by the macro. If you declare an LLSingleton subclass without using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro() implementation -- which will hopefully remind the coder. Trawl through ALL LLSingleton subclass definitions, sprinkling in LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit constructor declarations, public or private, along with relevant 'friend class LLSingleton<myself>' declarations. Where destructors are declared, move them into private section as well. Where the constructor was inline but nontrivial, move out of class body. Fix several LLSingleton abuses revealed by making ctors/dtors private: LLGlobalEconomy was both an LLSingleton and the base class for LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance contained another instance of the LLGlobalEconomy "singleton.") Extract LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that. LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy. LLToolGrab, an LLSingleton, was also explicitly instantiated by LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated, with trivial subclass LLToolGrab, the LLSingleton instance. (WARNING: LLToolGrabBase methods have an unnerving tendency to go after LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship between the instance in LLToolCompGun and the LLToolGrab singleton instance.) LLGridManager declared a variant constructor accepting (const std::string&), with the comment: // initialize with an explicity grid file for testing. As there is no evidence of this being called from anywhere, delete it. LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD parameter wasn't used, and as there is no evidence of it being passed from anywhere, delete the parameter. LLViewerWindow::shutdownViews() was checking LLNavigationBar:: instanceExists(), then deleting its getInstance() pointer -- leaving a dangling LLSingleton instance pointer, a land mine if any subsequent code should attempt to reference it. Use deleteSingleton() instead. ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the LLSingleton instance pointer pointing to an allocated-but-destroyed instance. Use deleteSingleton() instead.
-
- Jul 23, 2016
-
-
Cinder authored
-
- Jul 18, 2016
-
-
Drake Arconis authored
-
- Mar 22, 2016
-
-
Oz Linden authored
-
- Mar 07, 2016
-
-
Rider Linden authored
MAINT-6172: Send the render and mic devices to a session when they are dirty, not just in Tuning mode.
-
- Feb 24, 2016
-
-
Rider Linden authored
MAINT-6096: For non-spacial voice chats update the volume of participants. Rename "sendPositionalUpdate" to reflect volume changes.
-
- Jan 26, 2016
-
-
Rider Linden authored
MAINT-6086: Fixed an issue with management of sessionStates (was removing one before it was added in certain cases.) Also changed the calls to LL_ERRS to LL_WARNS (LL_ERRS is a "HaltCatchFire" command and will crash the viewer and nothing in voice should ever bring down the viewer.
-
- Jan 25, 2016
-
-
Rider Linden authored
MAINT-6086: Reworked how sessions were being tracked and recovered. A case was occurring where a session was being created and then destroyed, but had never been added to the session tracking map.
-
- Jan 11, 2016
-
-
Rider Linden authored
MAINT-6044: Throttle positional updates to no more than two a second. Compare angle between avatar rotations if trivially small do not trigger update.
-
- Jan 08, 2016
-
-
Rider Linden authored
MAINT-5978: Remove vestigial state machine code. Convert over to smart pointers for state information structures.
-
- Jan 07, 2016
-
-
Rider Linden authored
-
- Jan 06, 2016
-
-
Rider Linden authored
-
Rider Linden authored
MAINT-5978: Remove move of the residual state machine. Send initial positional update upon joining channel.
-
- Dec 17, 2015
-
-
Rider Linden authored
-
- Dec 11, 2015
-
-
Rider Linden authored
Remove some of the dead code. 1:1 chat is working but group chat fails now. Need to reexamine the entire flow.
-
- Dec 10, 2015
-
-
Rider Linden authored
-
- Dec 09, 2015
-
-
Rider Linden authored
-
- Dec 08, 2015
-
-
Rider Linden authored
-
- Dec 04, 2015
-
-
Rider Linden authored
-
Rider Linden authored
Initial changes for Vivox/Azumarill merge. Lots of temporary code and conditional compile switches. Begin switch from statemachine to coroutine.
-
- Nov 10, 2015
-
-
Oz Linden authored
-
- Jul 10, 2015
-
-
Nat Goodspeed authored
-
- Jul 07, 2015
-
-
Rider Linden authored
-
- Jul 01, 2015
-
-
Nat Goodspeed authored
lleventcoro_test.cpp runs clean (as modified for new API), and all the rest builds clean, but the resulting viewer is as yet untested.
-