| Age | Commit message (Collapse) | Author |
|---|
|
relying on hacked computation based on width / height.
|
|
|
|
read latency
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
changed stacking logic to attempt to stack against any floater that is cascade head
*or* in a cascade group
|
|
|
|
|
|
ssh://hg@bitbucket.org/stinson_linden/viewer-development-havokai.
|
|
Separating the viewer status messaging from the simulator status.
|
|
bad XUI
|
|
|
|
thicker.
|
|
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.
|
|
|
|
Sigh, the rejoicing was premature.
|
|
|
|
If in fact we've managed to fix the APR bug writing to a Windows named pipe,
it should no longer be necessary to try to work around it by testing with a
much smaller data volume on Windows!
|
|
|
|
Ideally we'd love to be able to nail the underlying bug, but log output
suggests it may actually go all the way down to the OS level. To move forward,
try to bypass it.
|
|
|
|
|
|
change from FROZEN to UNFROZEN state.
|
|
|
|
|
|
|
|
ssh://hg@bitbucket.org/stinson_linden/viewer-development-havokai.
|
|
|
|
We want to write a robust test that consistently works. On Windows, that
appears to require constraining the max message size. I, the coder, could try
submitting test runs of varying sizes to TC until I found a size that works...
but that could take quite a while. If I were clever, I might even use a manual
binary search. But computers are good at binary searching; there are even
prepackaged algorithms in the STL. If I were cleverer still, I could make the
test program itself search for size that works.
|
|
|
|
|
|
|
|
|
|
A static LLProcessPtr variable won't be destroyed until after procedural code
has shut down APR. The trouble is that LLProcess's destructor unregisters
itself from APR -- and, for an autokill LLProcess, attempts to kill the child
process. All that is ill-advised after APR shutdown.
Disable use of apr_pool_note_subprocess() mechanism. This should be another
viable way of coping with static autokill LLProcessPtr variables: when the
designated APR pool is cleaned up, APR promises to kill the child process. But
whether it's an APR bug or a calling error, the present (now disabled) call in
LLProcess results in OUR process, the viewer, getting SIGTERM when it asks to
clean up the global APR pool.
|
|
Apparently, at least on Mac, there are circumstances in which the very-large-
message test can take several times longer than normal, yet still complete
successfully. This is always the problem with timeouts: does timeout
expiration mean that the code in question is actually hung, or would it
complete if given a bit longer?
If very-large-message test fails, retry a few times with smaller sizes to try
to find a size at which the test runs reliably. The default size, ca 1MB, is
intended to be substantially larger than anything we'll encounter in the wild.
Is that "unreasonably" large? Is there a "reasonable" size at which the test
could consistently pass? Is that "reasonable" size still larger than what we
expect to encounter in practice? Need more information, hence this code.
|
|
Otherwise, a stuck child process could potentially hang the test, and thus the
whole viewer build.
|
|
|
|
ssh://hg@bitbucket.org/stinson_linden/viewer-development-havokai.
|
|
NavMesh update message.
|
|
|
