summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-05-05upgrade to VMP package 505035, include Oz's logging changesGlenn Glazer
2017-05-04SL-617: upgrade to VMP package 504984coyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-04SL-617: use final_exe to create exe name in summary.jsoncoyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-03MAINT-6928: upgrade VMP package to 504954Glenn Glazer
2017-05-03MAINT-6928: upgrade VMP package to 504920 and rip out viewer-manifest ↵Glenn Glazer
changes for 2.6
2017-05-02SL-617: use the braces, Luke!coyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-01SL-617: fix registry pathcoyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-04-28SL-617: pass final_exe from viewer manifest to NSIS as VIEWER_EXEcoyot@coyot-sager-PC
2017-04-28SL-671: fix string substitutioncoyot@coyot-sager-PC
2017-04-28SL-671: make icon point to launcher, not viewercoyot@coyot-sager-PC
2017-04-24MAINT-6928: upgrade VMP package to 504558Glenn Glazer
2017-04-18MAINT-6928: upgrade VMP package to 504332Glenn Glazer
2017-04-17MAINT-6928: upgrade VMP package to 504317Glenn Glazer
2017-04-17SL-617: upgrade VMP package to 504305Glenn Glazer
2017-04-17SL-617: alter viewer manifest to write exe name to summary.json, upgrade VMP ↵Glenn Glazer
package to 504292 to read it
2017-04-17SL-617: upgrade VMP package to 504287Glenn Glazer
2017-04-15MAINT-6928: upgrade to VMP package 504240Glenn Glazer
2017-04-12MAINT-6928: upgrade to VMP package 504232Glenn Glazer
2017-04-11MAINT-6928: revert previous post-move strategy, rename via self.path insteadGlenn Glazer
2017-04-11MAINT-6928: guard shutil.move against retryGlenn Glazer
2017-04-11MAINT-6928: os,rename is retarded, use shutil.move insteadGlenn Glazer
2017-04-11MAINT-6928: upgrade to VMP package 504140, use renamed directory to walk ↵Glenn Glazer
around codesign bug; fix dullahan file copy code
2017-04-10MAINT-6928: Add in Python 2.6.6 modulesGlenn Glazer
2017-04-07SL-321: upgrade VMP package to 504101Glenn Glazer
2017-04-07MAINT-7282: add requests module and associated build machineryGlenn Glazer
2017-04-06SL-321: add Requests lib cmake fileGlenn Glazer
2017-04-06pull from gateGlenn Glazer
2017-04-06DRTVWR-418, MAINT-7242: Update viewer64 to KDU 7.9.1 build 504041.Nat Goodspeed
2017-04-05MAINT-6928: update VMP package 503733, add requests package 504010, ↵Glenn Glazer
associated viewer-manifest changes for new files
2017-04-03Automated merge with ssh://bitbucket.org/lindenlab/viewer64Nat Goodspeed
2017-03-31SL-321: sign *before* nsis grabs the EXEsGlenn Glazer
2017-03-30dummy commit to bump build (target for upgrade)Glenn Glazer
2017-03-30SL-321: upgrade VMP package 503815Glenn Glazer
2017-03-30DRTVWR-418: Eliminate reference to LLParcelSelection::sNullSelection.Nat Goodspeed
2017-03-30Automated merge with ssh://bitbucket.org/lindenlab/viewer64-xcode-8.3Nat Goodspeed
2017-03-30DRTVWR-418: Xcode 8.3 complains about LLSafeHandle<T> implementation.Nat Goodspeed
The previous LLSafeHandle<T> implementation declares a static data member of the template class but provides no (generic) definition, relying on particular specializations to provide the definition. The data member is a function pointer, which is called in one of the methods to produce a pointer to a "null" T instance: that is, a dummy instance to be dereferenced in case the wrapped T* is null. Xcode 8.3's version of clang is bothered by the call, in a generic method, through this (usually) uninitialized pointer. It happens that the only specializations of LLSafeHandle do both provide definitions. I don't know whether that's formally valid C++03 or not; but I agree with the compiler: I don't like it. Instead of declaring a public static function pointer which each specialization is required to define, add a protected static method to the template class. This protected static method simply returns a pointer to a function-static T instance. This is functionally similar to a static LLPointer<T> set on demand (as in the two specializations), including lazy instantiation. Unlike the previous implementation, this approach prohibits a given specialization from customizing the "null" instance function. Although there exist reasonable ways to support that (e.g. a related traits template), I decided not to complicate the LLSafeHandle implementation to make it more generally useful. I don't really approve of LLSafeHandle, and don't want to see it proliferate. It's not clear that unconditionally dereferencing LLSafeHandle<T> is in any way better than conditionally dereferencing LLPointer<T>. It doesn't even skip the runtime conditional test; it simply obscures it. (There exist hints in the code that at one time it might have immediately replaced any wrapped null pointer value with the pointer to the "null" instance, obviating the test at dereference time, but this is not the current functionality. Perhaps it was only ever wishful thinking.) Remove the corresponding functions and static LLPointers from the two classes that use LLSafeHandle.
2017-03-29DRTVWR-418: Instead of "Unknown", try be informative about platform.Nat Goodspeed
When a 'family' code isn't recognized, for instance, report the family code. That should at least clue us in to look up and add an entry for the relevant family code.
2017-03-21remove --quiet from xcodebuild (it hides too much)Oz Linden
2017-03-16merge CEF update and fixes from callumOz Linden
2017-03-15Next part of the 'SL-641 Update CEF -> cef-bin -> Dullahan -> ↵callum@lindenlab.com
p64_3p-Dullahan -> media_plugin_cef.cpp to current latest version' puzzle - fix @rpath/@executable paths for macOS
2017-03-14Fixed for MAINT-7201, MAINT-7202, MAINT-7203 (viewer-embeddedd browser ↵Callum Prentice
scheme handler was broken)
2017-03-14SL-641 - Update CEF -> cef-bin -> Dullahan -> p64_3p-Dullahan -> ↵Callum Prentice
media_plugin_cef.cpp to latest versionPull in p64_3p-dullahan that has the cef 2897/chrome 57
2017-03-14Tweak CEF plugin version to include Chrome equivalentCallum Prentice
2017-03-13Automated merge with ssh://bitbucket.org/lindenlab/viewer64Nat Goodspeed
2017-03-13Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2017-03-13Automated merge with tip of viewer-releaseCallum Prentice
2017-03-13increment viewer version to 5.0.4Oz Linden
2017-03-13Added tag 5.0.3-release for changeset 02c24e9f4f7dOz Linden
2017-03-13Automated merge with ssh://bitbucket.org/lindenlab/viewer64-maint-7177Nat Goodspeed
2017-03-13DRTVWR-418: Make LLEventPumps an LLHandleProvider for LLEventPump.Nat Goodspeed
LLEventPump's destructor was using LLEventPumps::instance() to unregister the LLEventPump instance from LLEventPumps. Evidently, though, there are lingering LLEventPump instances that persist even after the LLSingletonBase::deleteAll() call destroys the LLEventPumps LLSingleton instance. These were resurrecting LLEventPumps -- pointlessly, since a newly-resurrected LLEventPumps instance can have no knowledge of the LLEventPump instance! Unregistering is unnecessary! What we want is a reference we can bind into each LLEventPump instance that allows us to safely test whether the LLEventPumps instance still exists. LLHandle is exactly that. Make LLEventPumps an LLHandleProvider and bind its LLHandle in each LLEventPump's constructor; then the destructor can unregister only when LLEventPumps still exists.