| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- Changed level of output logs
- Cleaned up comments
|
|
|
|
This allows the login-page server to respond to any sourceid= associated with
the create_account_url, which (we happen to know) varies by skin -- e.g. for
the Steam viewer.
|
|
Previous logic constructed a std::ostringstream, directly messing with '?' vs.
'&', ugly libcurl escape calls etc. Now we can deconstruct the LLGridManager::
getLoginPage() URL, supplement the params map as needed and then rebuild a new
URL using LLURI::buildHTTP().
|
|
The LLURI::buildHTTP() overloads that take an LLSD 'path' accept 'undefined',
LLSD::String and (LLSD::Array of LLSD::String). A sequence of path components
passed in an Array is constructed into a slash-separated path. There are unit
tests in lluri_test.cpp to exercise that case.
To my amazement, there were NO unit tests covering the case of an LLSD::String
path. The code for that case escaped and appended the entire passed string.
While that might be fine for a 'path' consisting of a single undecorated path
component, the available documentation does not forbid one from passing a path
containing slashes as well. But this had the dubious effect of replacing every
slash with %2F.
In particular, decomposing a URL string with one LLURI instance and
constructing another like it using LLURI::buildHTTP() was not symmetrical.
Having consulted with Richard, I made the string-path logic a bit more nuanced:
- The passed path string is split on slashes. Every path component is
individually escaped, then recombined with slashes into the final path.
- Duplicate slashes are eliminated.
- The presence or absence of a trailing slash in the original path string is
carefully respected.
Now that we've nailed down how it ought to behave -- added unit tests to
ensure that it DOES behave that way!!
|
|
obsolete files
|
|
obsolete files
|
|
reporting raw GL strings in viewer stats instead of GPU table labels to make future GPU table overhauls more effective.
|
|
|
|
all, split up NVIDIA GT(X) 6xx series into mobile/desktop.
|
|
|
|
|
|
Reviewed by me. (Bao created)
|
|
|
|
|
|
shadows by default where appropriate.
|
|
comparison to the previous angular velocity.
|
|
the empty string is entered.
|
|
angular velocity is set to zero.
|
|
|
|
|
|
fitting to 1024 width screens.
|
|
MAINT-1444 complains that with all optional login-panel controls enabled, the
login panel is wider than 1024 pixels: at that width, the new "Start now"
button is pushed completely off the right edge of the window. Richard told me
how to tweak the layout so that the controls can squeeze together in an
overlapping way, enabling all controls to be visible even at 1024 width.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This doesn't really address 3325 directly but it is the result of research
done while hunting it down. First, this is a thread safety improvement for
canceled requests that have gone into resource wait state. I don't think
we've seen a failure there but there was a window. It also cleans the
resource wait queue earlier which lets us do less work and get requests
more quickly into llcorehttp by bypassing the resource wait state. With
this, I finally feel comfortable about rundown of requests.
|
|
|
|
|
|
A/B comparison with original code showed the newer issuing lower-priority
requests of the cache reader and some other minor changes. Brought them
into agreement (this is cargo-cult programming). Made the HTTP resource
semaphore an atomic int for rigorous correctness across threads. I
swear I'm going to tear down this code someday.
|
|
angular velocity.
|
|
Guard for the typical case of a missing setting with a bracketing
gSavedSettings.controlExists() call.
|
|
Dropped an argument during integration which made the total byte count read
lower than expected. Everything else is fine, however.
|
|
|
|
trace functionality
llcorehttp implements a nice trace facility but it hasn't been attached to
an external control to date. This hands over control to a *non-persistent*
setting that can be used for QA or field diagnostics.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
