Age | Commit message (Collapse) | Author |
|
New --leap switch takes a quoted command line likely to contain spaces. Sloppy
handling of quoted arguments definitely gets us into trouble. Fix that.
|
|
This code replaces the previous cleanup of DLLs loaded by APR.
|
|
Nuance of command-line processing: when there's exactly one --leap switch, the
resulting LLSD is a scalar string rather than an array with one entry. Fix
processing code to handle either case.
|
|
You can specify one or more instances of --leap 'command line'. Each such
command line is parsed using bash-like conventions, notably honoring double
quotes, e.g. --leap '"c:/Program Files/Something/something.exe" arg1 arg2'.
(Specifying such an argument in a Windows Command Prompt may be tricky.)
Such a program should read its stdin and write to its stdout using LLSD Event
API Plugin protocol: length:serialized_LLSD
where 'length' is the decimal integer count of bytes in serialized_LLSD,
':' is a literal colon character,
and 'serialized_LLSD' is notation-format LLSD.
A typical LLSD object is a map containing 'pump' and 'data' keys, where
'pump' is the name of the LLEventPump on which to send 'data' (or on which
'data' was received). In particular, the initial LLSD object on stdin mentions
the name of this plugin's reply LLEventPump: the LLEventPump that will send
every subsequent received event to the plugin's stdin.
Anything written to the plugin's stderr will be logged in the viewer log. In
addition to being generally useful, this helps debug problems with particular
plugins.
|
|
|
|
This separate commit is just to order the keys. Data are unchanged, as
established by:
$ hg cat -rtip cmd_line.xml >cmd_line.xml.tip
$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from llbase import llsd
>>> tipdata = llsd.parse(open("cmd_line.xml.tip").read())
>>> newdata = llsd.parse(open("cmd_line.xml").read())
>>> tipdata == newdata
True
|
|
|
|
|
|
|
|
Lacking time to properly test new LLStringUtil::getTokens() against the
present (different!) command-line scanners in LLExternalEditor::tokenize() and
LLCommandLineParser::parseCommandLineString(), just annotate as future work
the goal of unifying them... SIGH.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"InventoryOutboxLogging" debug flag.
|
|
|
|
viewer_manifest.py's Linux_i686Manifest class has contained directives to copy
library files with names like (e.g.) "libapr-1.so.0.4.2", which means that
every update to any such library requires messing with viewer_manifest.py.
But LLManifest.path() claims to support wildcards, and it's more robust to
specify "libapr-1.so*" instead.
Unfortunately LLManifest.path()'s wildcard support only used to work for files
in the source tree (vs. the artwork tree or the build tree). The logic in
path() tries each tree in turn, relying on an exception to make it try the
next tree. This exception was raised for a nonexistent specific filename --
but it never used to raise that exception for a wildcard matching 0 files.
Instead it would simply report "0 files" and proceed, producing an invalid
viewer install.
Raise that exception for a wildcard matching nothing. This forces path() to
consider the artwork tree and the build tree, permitting us to use wildcards
in library names.
Define an exception specific to LLManifest: ManifestException rather than the
generic Python RuntimeException. Make it a subclass of RuntimeException so any
existing callers expecting to catch RuntimeException will continue to work.
|
|
|
|
|
|
removed merchant outbox context menu
reviewed by Leslie
|
|
reviewed by Leslie
|
|
Use the new "Avatar Rez" debugging tag to see the output.
|
|
|
|
|
|
"CurlRequestTimeOut" for QA to test Curl.
|
|
concurrent requests instead of unreliable increments/decrements sprinkled around the code.
|
|
|
|
|
|
|
|
for alpha lighting of point lights not matching deferred lights.
|
|
|
|
regression bug in inventory late loading
|
|
fully fetch user inventory
|
|
|
|
the graphics code.
Reviewed by davep.
|
|
Outbox options can appear in invalid state when a valid folder is last selection
EXP-1834 FIX -- Right click context menus on Folders in Merchant Outbox and Library folders can show all inventory options including admin options
EXP-1835 FIX -- Right clicking on a folder and selecting New Folder creates folder under My Inventory not within selected folder
* Updated folder context menu building to build full options in one step or
trigger a load which will rebuild top-level context menu for all selected
items when complete. Previous code had an implicit assumption that the
selected folder was the only selection after background fetch.
|
|
|
|
|
|
|
|
|
|
This appears to close a long-pending action item, as it seems the original
LLProcessLauncher implementation was in fact cloned-and-edited from this logic
in LLVivoxVoiceClient::stateMachine().
In any case, leveraging LLProcess buys us:
- reduced redundancy; fewer maintenance points
- logging for both success and errors
- (possibly) better SLVoice.exe lifespan management.
|
|
Much as I dislike viewer log spam, seems to me starting a child process,
killing it and observing its termination are noteworthy events.
New logging makes LLExternalEditor launch message redundant; removed.
|
|
|
|
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.
|
|
|
|
Inventory
* Refactored LLFolderBridge::buildContextMenu fetch to clear and rebuild basic
context menu options after the fetch rather than trying to merge the two.
|
|
|
|
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.
|