| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The new close(void) method simply acquires the logic from
~LLCoprocedureManager() (which now calls close()). It's useful, even if only
in test programs, to be able to shut down all existing LLCoprocedurePools
without having to name them individually -- and without having to destroy the
LLCoprocedureManager singleton instance. Deleting an LLSingleton should be
done only once per process, whereas test programs want to reset the
LLCoprocedureManager after each test.
|
|
Use new Sync class to make the driving logic wait for the coprocedure to run.
|
|
|
|
|
|
|
|
LLCoprocedureManager
|
|
|
|
been fulfilled.
|
|
|
|
|
|
Use them in place of awkward try/catch test boilerplate.
|
|
Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.
Use LLFile::tmpdir() instead of getenv("TEMP").
As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!
|
|
|
|
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."
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
A level of preprocessor indirection lets us later change the implementation if
desired.
|
|
|
|
|
|
This also introduces LLContinueError for exceptions which should interrupt
some part of viewer processing (e.g. the current coroutine) but should attempt
to let the viewer session proceed.
Derive all existing viewer exception classes from LLException rather than from
std::runtime_error or std::logic_error.
Use BOOST_THROW_EXCEPTION() rather than plain 'throw' to enrich the thrown
exception with source file, line number and containing function.
|
|
|
|
|
|
|
|
This will permit other subsystems to use gMessageSystem.callWhenReady() to (e.g.)
register callbacks as soon as gMessageSystem is fully initialized.
|
|
Partial conversion of group manager
clean up some debug code in web profiles.
|
|
and use it for existing LLSomeClass::cleanupClass() calls.
This logs the fact of making the call, as well as making it.
|
|
|
|
A skip() stating that we don't yet understand why the test fails is implicitly
an open action item. This one isn't open. Save future developers the research.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bounces once per second
SH-4346 FIX: Interesting: some integer Statistics are displayed as floating point after crossing region boundary
made llerrs/infos/etc properly variadic wrt tags
LL_INFOS("A", "B", "C") works, for example
fixed unit tests
remove llsimplestat
|
|
|
|
|
|
|
|
|
|
|
