Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.1.1 2024-04-29T04:56:09Z 2024-04-29T04:56:09Z Andrey Lihatskiy alihatskiy@productengine.com 2024-04-29T04:43:28Z urn:sha1:1b68f71348ecf3983b76b40d7940da8377f049b7 2022-06-21T18:46:59Z Nat Goodspeed nat@lindenlab.com 2022-06-21T18:46:59Z urn:sha1:490de3ab6e3a2b9dd8668c2093e265f36324f82e 2022-06-18T15:57:10Z Nat Goodspeed nat@lindenlab.com 2022-06-18T15:57:10Z urn:sha1:af4fbc1f8a99a3c5370cb6db45435e67f9ce92d2 LazyEventAPI is a registrar that implicitly instantiates some particular LLEventAPI subclass on demand: that is, when LLEventPumps::obtain() tries to find an LLEventPump by the registered name. This leverages the new LLEventPumps::registerPumpFactory() machinery. Fix registerPumpFactory() to adapt the passed PumpFactory to accept TypeFactory parameters (two of which it ignores). Supplement it with unregisterPumpFactory() to support LazyEventAPI instances with lifespans shorter than the process -- which may be mostly test programs, but still a hole worth closing. Similarly, add unregisterTypeFactory(). A LazyEventAPI subclass takes over responsibility for specifying the LLEventAPI's name, desc, field, plus whatever add() calls will be needed to register the LLEventAPI's operations. This is so we can (later) enhance LLLeapListener to consult LazyEventAPI instances for not-yet-instantiated LLEventAPI metadata, as well as enumerating existing LLEventAPI instances. The trickiest part of this is capturing calls to the various LLEventDispatcher::add() overloads in such a way that, when the LLEventAPI subclass is eventually instantiated, we can replay them in the new instance. LLEventAPI acquires a new protected constructor specifically for use by a subclass registered by a companion LazyEventAPI. It accepts a const reference to LazyEventAPIParams, intended to be opaque to the LLEventAPI subclass; the subclass must declare a constructor that accepts and forwards the parameter block to the new LLEventAPI constructor. The implementation delegates to the existing LLEventAPI constructor, plus it runs deferred add() calls. LLDispatchListener now derives from LLEventStream instead of containing it as a data member. The reason is that if LLEventPumps::obtain() implicitly instantiates it, LLEventPumps's destructor will try to destroy it by deleting the LLEventPump*. If the LLEventPump returned by the factory function is a data member of an outer class, that won't work so well. But if LLDispatchListener (and by implication, LLEventAPI and any subclass) is derived from LLEventPump, then the virtual destructor will Do The Right Thing. Change LLDispatchListener to *not* allow tweaking the LLEventPump name. Since the overwhelming use case for LLDispatchListener is LLEventAPI, accepting but silently renaming an LLEventAPI subclass would ensure nobody could reach it. Change LLEventDispatcher's use of std::enable_if to control the set of add() overloads available for the intended use cases. Apparently this formulation is just as functional at the method declaration point, while avoiding the need to restate the whole enable_if expression at the method definition point. Add lazyeventapi_test.cpp to exercise. 2022-06-16T00:04:34Z Nat Goodspeed nat@lindenlab.com 2022-04-07T01:49:03Z urn:sha1:f134eace911eca8a231a7c1d556d7d891e8b21ca Previously, LLEventAPI intentionally hid all but one of the many add() overloads supported by its LLEventDispatcher base class. The reason was that certain of the add() methods take an optional fourth parameter that's an LLSD::Map describing the expected parameter structure, while others take a fourth templated parameter that's an instance getter callable. This led to ambiguity, especially when passed an LLSDMap instance that's convertible to LLSD but isn't literally LLSD. At the time, it was simpler to constrain the add() methods inherited from LLEventDispatcher. But by adding new std::enable_if constraints to certain LLEventDispatcher add() methods, we've resolved the ambiguities, so LLEventAPI subclasses can now use any add() overload (as claimed on the relevant Confluence page). LLEventDispatcher comments have always loftily claimed that an instance getter callable may return either a pointer or a reference, doesn't matter. But it does when trying to pass the getter's result to boost::fusion::push_back(): a reference must be wrapped with std::ref() while a pointer cannot be. std::ref(pointer) produces errors. Introduce LLEventDispatcher::invoker:: bindable() overloads to Do The Right Thing whether passed a pointer or a reference. (cherry picked from commit 743f487c2e123171c9fc6d5b84d768f1d856d569) 2015-11-10T14:48:56Z Oz Linden oz@lindenlab.com 2015-11-10T14:48:56Z urn:sha1:c8726aba303bcf1207b730a344536e25491420bc 2013-05-09T21:10:45Z simon none@none 2013-05-09T21:10:45Z urn:sha1:ee2fce8790b69d61845cc32fbf7cdce8a33b0dab 2013-04-24T16:35:38Z simon none@none 2013-04-24T16:35:38Z urn:sha1:87ba85eaabbfd5fd7ad8ca8136f4783b1d932264 2013-03-29T14:50:08Z Graham Madarasz graham@lindenlab.com 2013-03-29T14:50:08Z urn:sha1:bf6182daa8b4d7cea79310547f71d7a3155e17b0 2013-02-28T23:35:14Z Graham Madarasz (Graham) graham@lindenlab.com 2013-02-28T23:35:14Z urn:sha1:93eaccae6fe6e8442a3c6e5a2d40a408aa44df77 2011-09-08T14:46:04Z Andrew A. de Laix alain@lindenlab.com 2011-09-08T14:46:04Z urn:sha1:2d19a2002501d44ce18080b6f26ceaf2dbf796e9