Age | Commit message (Collapse) | Author | |
---|---|---|---|
2019-09-11 | SL-11218 Update Avatar Texture Debugger to reflect new bake channels | andreykproductengine | |
2019-09-11 | Merged in default (pull request #948) | Andrey Lihatskiy | |
SL-11848 Fixed login crash (Face with no texture index references indexed texture draw info) Approved-by: Graham Madarasz | |||
2019-09-11 | SL-11918 [Mac] Wheel support (horizontal scroll) | Mnikolenko ProductEngine | |
2019-09-10 | Downstream merge from lindenlab/viewer-bear | AndreyL ProductEngine | |
2019-09-10 | Downstream merge from lindenlab/viewer-lynx | AndreyL ProductEngine | |
2019-09-10 | Merged in lindenlab/viewer-release | andreykproductengine | |
2019-09-10 | SL-11910 [Win] Horizontal scroll | andreykproductengine | |
2019-09-10 | Upstream merge from lindenlab/viewer-neko | AndreyL ProductEngine | |
2019-09-10 | Downstream merge from lindenlab/viewer-manul | AndreyL ProductEngine | |
2019-09-10 | increment viewer version to 6.3.2 | Nat Goodspeed | |
2019-09-10 | SL-11909 FIXED Crash in Second Life ↵ | maxim_productengine | |
Release!LLIMProcessing::requestOfflineMessagesCoro | |||
2019-09-06 | handle slvoice executable separately from the vivox libraries, and update ↵ | Oz Linden | |
mac slvoice package | |||
2019-09-06 | Upstream merge from viewer-neko | AndreyL ProductEngine | |
2019-09-06 | SL-11315 Build fix (removed not yet existing state) | andreykproductengine | |
2019-09-06 | SL-11883 FIXED Crash: SecondLifeViewer!update_statistics | maxim_productengine | |
2019-09-06 | Mac buildfix | AndreyL ProductEngine | |
2019-09-05 | SL-11848 Fixed login crash (Face with no texture index references indexed ↵ | AndreyL ProductEngine | |
texture draw info) | |||
2019-09-05 | Upstream merge from viewer-neko | AndreyL ProductEngine | |
2019-09-05 | Merged in lindenlab/viewer-manul | AndreyL ProductEngine | |
2019-09-05 | Merged in lindenlab/viewer-bear | AndreyL ProductEngine | |
2019-09-05 | Merged in lindenlab/viewer-lynx | AndreyL ProductEngine | |
2019-09-05 | SL-11315 Viewer asks to play media and retains selected choice | andreykproductengine | |
2019-09-09 | SL-11315 Fix paddings for checkbox | andreykproductengine | |
2019-09-09 | SL-11903 FIXED Crash in LLAppearanceMgr::slamCategoryLinks | maxim_productengine | |
2019-09-06 | SL-11894 FIXED Crash: SecondLifeViewer!LLPanelPlaces::onShowOnMapButtonClicked | maxim_productengine | |
2019-09-05 | SL-11315 Checkbox support for notifications | andreykproductengine | |
2019-09-05 | SL-11718 Another exit crash | andreykproductengine | |
2019-09-05 | SL-11867 FIXED [ES][FR][IT] The text “Unable to buy” goes beyond the ↵ | maxim_productengine | |
description area | |||
2019-09-04 | DRTVWR-493 Do not recreate proxy only to destroy it | andreykproductengine | |
2019-09-04 | SL-11868 Fix cache init after purge | andreykproductengine | |
2019-09-04 | SL-11217 Show confirmation when replacing skin,shape,eyes or hairbase with ↵ | maxim_productengine | |
item which doesn't match the type. | |||
2019-09-04 | SL-11866 [D493] Some startup elements can be executed twice, added protections | andreykproductengine | |
2019-09-04 | SL-11865 Fixed weird existance check | andreykproductengine | |
2019-09-03 | SL-11856 Backed out SL-11012 | AndreyL ProductEngine | |
changeset: 0d43d9754b79 | |||
2019-08-30 | SL-1171 [Dev tools] UI controls <-> settings connection issues | andreykproductengine | |
2019-08-29 | SL-11657 Further improvements | andreykproductengine | |
2019-08-29 | SL-10536 Crash in getPosRegionFromAgent | andreykproductengine | |
2019-08-29 | SL-11675 Don't show identical error messages more then once | maxim_productengine | |
2019-08-29 | Merge from lindenlab/viewer-release | andreykproductengine | |
2019-08-27 | SL-11782 FIXED Light is still visible when it's out of the draw distance | maxim_productengine | |
2019-08-26 | Merged in lindenlab/viewer-release | AndreyL ProductEngine | |
2019-08-26 | increment viewer version to 6.3.1 | Nat Goodspeed | |
2019-08-23 | SL-11736 FIXED "Stand" button disappears if "Restore down" UI button is ↵ | Mnikolenko Productengine | |
pressed while sitting. | |||
2019-08-21 | SL-11753 FIXED Group & Resident with the same name share chat history. | maxim_productengine | |
2019-08-20 | Automated merge with ssh://bitbucket.org/andreykproductengine/drtvwr-493 | Nat Goodspeed | |
2019-08-20 | DRTVWR-493: Clarify capturing LLError::getFatalFunction() in a var. | Nat Goodspeed | |
VS 2013 thought we were storing an initialization-list. | |||
2019-08-20 | DRTVWR-493: Defend LL[Param]Singleton against ctor/init exceptions. | Nat Goodspeed | |
An exception in the LLSingleton subclass constructor, or in its initSingleton() method, could leave the LLSingleton machinery in a bad state: the failing instance would remain in the MasterList, also on the stack of initializing LLSingletons. Catch exceptions in either and perform relevant cleanup. This problem is highlighted by test programs, in which LL_ERRS throws an exception rather than crashing the whole process. In the relevant catch clauses, clean up the initializing stack BEFORE logging. Otherwise we get tangled up recording bogus dependencies. Move capture_dependency() out of finishInitializing(): it must be called by every valid getInstance() call, both from LLSingleton and LLParamSingleton. Introduce new CONSTRUCTED EInitState value to distinguish "have called the constructor but not yet the initSingleton() method" from "currently within initSingleton() method." This is transient, but we execute the 'switch' on state within that moment. One could argue that the previous enum used INITIALIZING for current CONSTRUCTED, and INITIALIZED meant INITIALIZING too, but this is clearer. Introduce template LLSingletonBase::classname() helper methods to clarify verbose demangle(typeid(stuff).name()) calls. Similarly, introduce LLSingleton::pop_initializing() shorthand method. | |||
2019-08-19 | DRTVWR-493: Improve exception safety of LLSingleton initialization. | Nat Goodspeed | |
Add try/catch clauses to constructSingleton() (to catch exceptions in the subclass constructor) and finishInitializing() (to catch exceptions in the subclass initSingleton() method). Each of these catch clauses rethrows the exception -- they're for cleanup, not for ultimate handling. Introduce LLSingletonBase::reset_initializing(list_t::size_t). The idea is that since we can't know whether the exception happened before or after the push_initializing() call in LLSingletonBase's constructor, we can't just pop the stack. Instead, constructSingleton() captures the stack size before attempting to construct the new LLSingleton subclass. On exception, it calls reset_initializing() to restore the stack to that size. Naturally that requires a corresponding LLSingleton_manage_master method, whose MasterList specialization is a no-op. finishInitializing()'s exception handling is a bit simpler because it has a constructed LLSingleton subclass instance in hand, therefore push_initializing() has definitely been called, therefore it can call pop_initializing(). Break out new static capture_dependency() method from finishInitializing() because, in the previous LLSingleton::getInstance() implementation, the logic now wrapped in capture_dependency() was reached even in the INITIALIZED case. TODO: Add a new EInitState to differentiate "have been constructed, now calling initSingleton()" from "fully initialized, normal case" -- in the latter control path we should not be calling capture_dependency(). The LLSingleton_manage_master<LLSingletonBase::MasterList> specialization's get_initializing() function (which called get_initializing_from()) was potentially dangerous. get_initializing() is called by push_initializing(), which (in the general case) is called by LLSingletonBase's constructor. If somehow the MasterList's LLSingletonBase constructor ended up calling get_initializing(), it would have called get_initializing_from(), passing an LLSingletonBase which had not yet been constructed into the MasterList. In particular, its mInitializing map would not yet have been initialized at all. Since the MasterList must not, by design, depend on any other LLSingletons, LLSingleton_manage_master<LLSingletonBase::MasterList>::get_initializing() need not return a list from the official mInitializing map anyway. It can, and should, and now does, return a static dummy list. That obviates get_initializing_from(), which is removed. That in turn means we no longer need to pass get_initializing() an LLSingletonBase*. Remove that parameter. | |||
2019-08-19 | DRTVWR-493: When a test fails due to exception, display exception. | Nat Goodspeed | |
2019-08-15 | SL-11662 - apparently a race condition between image loading and material ↵ | Brad Payne (Vir Linden) | |
property setting |