Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.3 2016-08-18T20:05:30Z 2016-08-18T20:05:30Z Glenn Glazer coyot@lindenlab.com 2016-08-18T20:05:30Z urn:sha1:c8c143e7741d2b93b589d770b64c265228293564 2015-11-10T14:48:56Z Oz Linden oz@lindenlab.com 2015-11-10T14:48:56Z urn:sha1:c8726aba303bcf1207b730a344536e25491420bc 2013-04-19T18:42:56Z Oz Linden oz@lindenlab.com 2013-04-19T18:42:56Z urn:sha1:3bb708d70636188b91a6e8476a3b899441de0468 2013-03-29T14:50:08Z Graham Madarasz graham@lindenlab.com 2013-03-29T14:50:08Z urn:sha1:bf6182daa8b4d7cea79310547f71d7a3155e17b0 2013-02-21T21:47:52Z Oz Linden oz@lindenlab.com 2013-02-21T21:47:52Z urn:sha1:cf1019859def2af4414def7991e95a9020b0688f 2012-01-21T16:45:15Z Nat Goodspeed nat@lindenlab.com 2012-01-21T16:45:15Z urn:sha1:47d94757075e338c480ba4d7d24948242a85a9bb Using a Params block gives compile-time checking against attribute typos. One might inadvertently set myLLSD["autofill"] = false and only discover it when things behave strangely at runtime; but trying to set myParams.autofill will produce a compile error. However, it's excellent that the same LLProcess::create() method can accept either LLProcess::Params or a properly-constructed LLSD block. 2012-01-20T23:10:40Z Nat Goodspeed nat@lindenlab.com 2012-01-20T23:10:40Z urn:sha1:f0dbb878337082d3f581874c12e6df2f4659a464 LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating parameters with which to launch a child process and (2) sometimes tracking the lifespan of the ensuing child process. But a valid LLProcessLauncher object might or might not have ever been associated with an actual child process. LLProcess specifically tracks a child process. In effect, it's a fairly thin wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with lifespan management thrown in. A static LLProcess::create() method launches a new child; create() accepts an LLSD bundle with child parameters. So building up a parameter bundle is deferred to LLSD rather than conflated with the process management object. Reconcile all known LLProcessLauncher consumers in the viewer code base, notably the class unit tests. 2012-01-17T23:55:42Z Nat Goodspeed nat@lindenlab.com 2012-01-17T23:55:42Z urn:sha1:c0731c1c05cafe508c91c5f583301234ba3b8403 On a Posix platform (vfork()/execv() implementation), if for any reason the execv() failed (e.g. executable not on PATH), the viewer would never know, nor the user: the vfork() child produced no output, and terminated with rc 0! Add logging, make child terminate with nonzero rc. Remove pointless addArgument(const char*) overload: this does nothing for you that the compiler won't do implicitly. In llupdateinstaller.cpp, remove pointless c_str() call in addArgument() arg: we were starting with a std::string, then extracting its c_str(), only to construct a whole new std::string from it! 2010-12-29T18:23:02Z Loren Shih seraph@lindenlab.com 2010-12-29T18:23:02Z urn:sha1:5f99331f4a9ed5ed78af7b47bdad152949e63ec4 2010-12-20T18:38:36Z Andrew A. de Laix alain@lindenlab.com 2010-12-20T18:38:36Z urn:sha1:2c68cb2c69348522ebb648aa4abd2ca7e4038b80