Skip to content
Snippets Groups Projects
  1. Jan 07, 2021
  2. Oct 20, 2020
  3. Oct 03, 2020
  4. Sep 28, 2020
  5. Sep 10, 2020
  6. Sep 09, 2020
  7. Sep 04, 2020
  8. Aug 02, 2020
  9. Jul 28, 2020
  10. Jul 26, 2020
  11. Jun 23, 2020
  12. Mar 25, 2020
    • Nat Goodspeed's avatar
      SL-11216: Convert LLVersionInfo to an LLSingleton. · 5a260e0c
      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.
      5a260e0c
  13. Mar 10, 2020
  14. Jan 08, 2020
  15. Aug 12, 2019
  16. Aug 10, 2019
  17. Aug 09, 2019
  18. Aug 28, 2018
  19. Aug 24, 2018
  20. May 24, 2018
  21. May 23, 2018
  22. May 22, 2018
  23. May 17, 2018
  24. Jun 13, 2018
  25. Apr 10, 2018
  26. Aug 24, 2017
  27. Aug 22, 2017
  28. Aug 14, 2017
  29. Apr 14, 2017
    • Oz Linden's avatar
      e07a60f6
    • Oz Linden's avatar
      Change certificate store infrastructure to key off of the Subject Key · fd3628ef
      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.
      fd3628ef
  30. Mar 02, 2017
  31. Feb 27, 2017
  32. Dec 07, 2016
    • Nat Goodspeed's avatar
      DRTVWR-418: Apparently (some) Windows hosts still need freeport(). · 5bb456d8
      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."
      5bb456d8
    • Nat Goodspeed's avatar
      DRTVWR-418: Revamp testrunner to shutdown server Thread at end. · a4ba22fe
      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.
      a4ba22fe
  33. Nov 30, 2016
    • Nat Goodspeed's avatar
      DRTVWR-418: Adjust for LL_VIEWER_CHANNEL coming in unquoted. · 222919be
      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.
      222919be
  34. Mar 06, 2017
Loading