- Jan 07, 2021
-
-
Rye Mutt authored
-
- Oct 20, 2020
-
-
Rye Mutt authored
-
- Oct 03, 2020
- Sep 28, 2020
-
-
Rye Mutt authored
-
- Sep 10, 2020
-
-
Rye Mutt authored
-
- Sep 09, 2020
-
-
Rye Mutt authored
-
- Sep 04, 2020
-
-
Andrey Lihatskiy authored
-
- Aug 02, 2020
-
-
Rye Mutt authored
-
- Jul 28, 2020
-
-
Liru Faers authored
-
- Jul 26, 2020
-
-
Rye Mutt authored
-
- Jun 23, 2020
-
-
Rye Mutt authored
-
- Mar 25, 2020
-
-
Nat Goodspeed authored
This changeset is meant to exemplify how to convert a "namespace" class whose methods are static -- and whose data are module-static -- to an LLSingleton. LLVersionInfo has no initClass() or cleanupClass() methods, but the general idea is the same. * Derive the class from LLSingleton<T>: class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... }; * Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as described in indra/llcommon/llsingleton.h. * Move module-scope data in the .cpp file to non-static class members. Change any sVariableName to mVariableName to avoid being outright misleading. * Make static class methods non-static. Remove '//static' comments from method definitions as needed. * For LLVersionInfo specifically, the 'const std::string&' return type was replaced with 'std::string'. Returning a reference to a static or a member, const or otherwise, is an anti-pattern: the interface constrains the implementation, prohibiting possibly later returning a temporary (an expression). * For LLVersionInfo specifically, 'const S32' return type was replaced with simple 'S32'. 'const' is just noise in that usage. * Simple member initialization (e.g. the original initializer expressions for static variables) can be done with member{ value } initializers (no examples here though). * Delete initClass() method. * LLSingleton's forté is of course lazy initialization. It might work to simply delete any calls to initClass(). But if there are side effects that must happen at that moment, replace LLSomeSingleton::initClass() with (void)LLSomeSingleton::instance(); * Most initClass() initialization can be done in the constructor, as would normally be the case. * Initialization that might cause a circular LLSingleton reference should be moved to initSingleton(). Override 'void initSingleton();' should be private. * For LLVersionInfo specifically, certain initialization that used to be lazily performed was made unconditional, due to its low cost. * For LLVersionInfo specifically, certain initialization involved calling methods that have become non-static. This was moved to initSingleton() because, in a constructor body, 'this' does not yet point to the enclosing class. * Delete cleanupClass() method. * There is already a generic LLSingletonBase::deleteAll() call in LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned up with all the rest. But if there are side effects that must happen at that moment, replace LLSomeSingleton::cleanupClass() with LLSomeSingleton::deleteSingleton(). That said, much of the benefit of converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton dependencies will be properly honored: we're trying to migrate the code base away from the present fragile manual cleanup sequence. * Most cleanupClass() cleanup can be done in the destructor, as would normally be the case. * Cleanup that might throw an exception should be moved to cleanupSingleton(). Override 'void cleanupSingleton();' should be private. * Within LLSomeSingleton methods, remove any existing LLSomeSingleton::methodName() qualification: simple methodName() is better. * In the rest of the code base, convert most LLSomeSingleton::methodName() references to LLSomeSingleton::instance().methodName(). (Prefer instance() to getInstance() because a reference does not admit the possibility of NULL.) * Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged. In general, for many successive references to an LLSingleton instance, it can be useful to capture the instance() as in: auto& versionInfo{LLVersionInfo::instance()}; // ... versionInfo.getVersion() ... We did not do that here only to simplify the code review. The STRINGIZE(expression) macro encapsulates: std::ostringstream out; out << expression; return out.str(); We used that in a couple places. For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a couple specific static methods. It's harder to dummy out LLSingleton::instance() references, so we add the real class to that test.
-
- Mar 10, 2020
-
-
Rye Mutt authored
-
- Jan 08, 2020
-
-
andreykproductengine authored
-
- Aug 12, 2019
-
-
Nat Goodspeed authored
-
- Aug 10, 2019
-
-
Nat Goodspeed authored
Use them in place of awkward try/catch test boilerplate.
-
- Aug 09, 2019
-
-
andreykproductengine authored
-
- Aug 28, 2018
-
- Aug 24, 2018
-
-
Rider Linden authored
-
Rider Linden authored
-
- May 24, 2018
-
-
Anchor Linden authored
-
- May 23, 2018
- May 22, 2018
-
-
Rider Linden authored
-
- May 17, 2018
-
-
Nat Goodspeed authored
Also use existing LL_TO_STRING() macro to stringize LL_VIEWER_CHANNEL in llversioninfo.cpp and its tests.
-
- Jun 13, 2018
-
-
Mnikolenko ProductEngine authored
-
- Apr 10, 2018
-
-
andreykproductengine authored
-
andreykproductengine authored
-
- Aug 24, 2017
-
-
Oz Linden authored
MAINT-7594: add platform name string and address size to login request for crash stats (and add request parameter logging at DEBUG)
-
- Aug 22, 2017
-
-
Oz Linden authored
-
- Aug 14, 2017
-
-
Oz Linden authored
-
- Apr 14, 2017
-
-
Oz Linden authored
-
Oz Linden authored
Id rather than sha1 hash, since that is rarely used in modern certs. The previous form was storing trusted certs using an empty sha1 hash value as the key, which meant most certificates matched... not good. Modify the LLCertException to pass certificate information back as LLSD rather than an LLPointer<LLCertificate>, because when the exception is being thown from the certificate constructor that results in one of a couple of other exceptions (even refcounting won't save you when the problem is that the thing you're pointing to never finished coming into being properly). Update the certificates in the llsechandler_basic_test to modern conventions, and extend the classes to allow for an optional validation date so that the test can use a fixed date. Also make all the certificates include the plain text form for ease of reference.
-
- Mar 02, 2017
-
-
Brad Payne (Vir Linden) authored
-
- Feb 27, 2017
-
-
Brad Payne (Vir Linden) authored
-
- Dec 07, 2016
-
-
Nat Goodspeed authored
This is the function in indra/llmessage/tests/testrunner.py that iterates through ports in a specified range, looking for an available one. Other platforms understand a specification of port 0 to mean: "You pick one. I'll just use whichever one you picked."
-
Nat Goodspeed authored
Instead of having testrunner.run()'s caller pass a Thread object on which to run the caller's server instance's serve_forever() method, just pass the server instance. testrunner.run() now constructs the Thread. This API change allows run() to also call shutdown() on the server instance when done, and then join() the Thread. The hope is that this will avoid the Python runtime forcing the process termination code to 1 due to forcibly killing the daemon thread still running serve_forever(). While at it, eliminate calls to testrunner.freeport() -- just make the runtime pick a suitable port instead.
-
- Nov 30, 2016
-
-
Nat Goodspeed authored
Evidently the LL_VIEWER_CHANNEL macro (defined on the compiler command line) used to contain enclosing double quotes. Something changed (newer CMake version?) so that the macro now expands as Second Life Release rather than as "Second Life Release". That leads to syntax errors when it's used. Add C++ preprocessor trickery to stringize the value of the macro.
-
- Mar 06, 2017
-
-
Glenn Glazer authored
-