| Age | Commit message (Collapse) | Author |
|---|
|
Consider this pathname for llsdserialize_test.cpp:
C:\nats\indra\llcommon\tests\llsdserialize_test.cpp
Embed that in a Python string literal:
'C:\nats\indra\llcommon\tests\llsdserialize_test.cpp'
and you get a string containing:
C:
ats\indra\llcommon ests\llsdserialize_test.cpp
where the \n became a newline and the \t became a tab character.
Hopefully Python raw-string syntax r'C:\etc\etc' works better.
|
|
In this case, the Python code in question is being written from a C++ string
literal to a temp script file in a platform-dependent temp directory -- so the
Python __file__ value tells you nothing about the location of the repository
checkout. Embedding __FILE__ from the containing C++ source file works better.
|
|
|
|
And at that point, the Python logic needed to bring in the llsd module is big
enough to warrant capturing it in a separate string variable common to
multiple tests.
|
|
|
|
|
|
|
|
|
|
Verify that an LLSD::String containing newlines works; verify that newlines
between items are accepted.
|
|
Write a sequence of LLSDSerialize::toNotation() calls separated by newlines to
a data file, then read lines and parse using llbase.llsd.parse(). Verify that
this produces expected data even when one item is a string containing newlines.
Generalize python() helper function to allow using any of the NamedTempFile
constructor forms.
Allow specifying expected Python rc (default 0) and use this to verify an
intentional sys.exit(17). This is better than previous sys.exit(0) test
because when, at one point, NamedTempFile failed to write file data, running
Python on an empty script file still terminates with rc 0. A nonzero rc
verifies that we've written the file, that Python is running it and that we're
retrieving its rc.
|
|
The only thing about NamedTempScript that was specific to script files was the
hardcoded ".py" extension. Renaming it to NamedTempFile with an explicit
extension argument addresses that.
Allow constructing NamedTempFile with either a std::string, as before, or an
expression of the form (lambda::_1 << some << stuff). If Linden's Boost
package included the Boost.Iostreams lib, we could even stream such an
expression directly to an ostream constructed around the fd. But oh well.
|
|
|
|
Also mollify Linux build, which gets alarmed when you implicitly ignore
write()'s return value. Ignore it explicitly.
|
|
Seems Linden's Boost package and the viewer build might use different
settings of the /Zc:wchar_t switch.
Anyway, this implementation using open(O_CREAT | O_EXCL) should be more
robust. I'm surprised Boost.Filesystem doesn't seem to offer "create a unique
file"; all I found was "generate a random filename fairly likely to be unique."
|
|
|
|
On Windows, calling boost::filesystem::path::string() implicitly requests
code conversion between std::wstring (the boost::filesystem::path::string_type
selected on Windows) and std::string. At least for integration-test program,
that produces link errors. Use Linden's wstring_to_utf8str() instead.
|
|
|
|
|
|
That, in turn, needs Boost.System library.
|
|
It's wonderful that the Python interpreter will accept a whole multi-line
script as a composite -c argument... but because Windows command-line
processing is fundamentally flawed, we simply can't count on it for Windows.
Instead, accept script text, write a temporary script file in a system-
dependent temp directory, ask Python to run that script and delete the file.
Also, on Windows, use _spawnl(), much simpler than adding bizarre Windows wait
logic to LLProcessLauncher. Use LLProcessLauncher only on Mac & Linux, with
waitpid() to capture rc.
|
|
|
|
|
|
This is in its infancy; tested on Mac; needs to be ironed out on Windows and
Linux. Goal is to test at least some cross-language LLSD serialization.
|
|
(per Monty code review)
The notion of storing LLMemoryInfo data both as an LLSD::Map and an
LLSD::Array of pair arrays arose from a (possibly misguided) desire to
continue producing stats output into the viewer log in the same order it
always used to be produced. There is no evidence that anyone cares about the
order of those stats in the log; there is no other use case for preserving
order. At Monty's recommendation, eliminate generating and storing the
array-of-pair-arrays form: directly store LLSD::Map.
|
|
|
|
cleanups to the crash reporters, and the ability to use --set GroupName.SettingName to set parameters outside of the (default) Global settings group.
|
|
(per Monty code review)
Explain why we intentionally don't suppress exceptions from boost::regex
objects constructed with string literals. Catch std::runtime_error from
boost::regex_search() and boost::regex_match(); log and return false.
|
|
(per Monty code review)
Other platforms return -1 anyway, so don't need to call load methods.
|
|
On Mac, where LLMemoryInfo relies on a child process rather than any sort of
internal system API, try to produce more informative LL_WARNS output if
popen() fails to run vm_stat, or if vm_stat terminates with nonzero rc.
|
|
For postprocessing these stats, we'll want the time at which they were
captured. We'll want the current framerate too, but handle that at a higher
level.
|
|
|
|
|
|
|
|
GetProcessMemoryInfo() is prototyped with PROCESS_MEMORY_COUNTERS*, so to
accept PROCESS_MEMORY_COUNTERS_EX* as documented, have to cast.
|
|
Remove <kfuncs.h>, documented header file for GetCurrentProcess().
|
|
Introduce StatsArray helper class to facilitate accumulating stats in the
array-of-pair-arrays form cached internally by LLMemoryInfo.
|
|
|
|
So far we've only been querying GlobalMemoryStatusEx(), but
GetPerformanceInfo() delivers a bunch more memory-related stats that may be
pertinent. Try capturing those too. May not yet compile on Windows...
|
|
|
|
Recast stream() to display data from LLSD array rather than reinvoking OS
operations used to capture it.
Make refresh() cache LLSD data in map form as well as array; fetch items from
that in a few places to avoid going back to OS.
|
|
Handle conversion errors (boost::bad_lexical_cast).
Glean additional LLSD statistics from vm_stat output.
|
|
|
|
This is known not to compile on Mac yet; checking in to concurrently work on
Linux-specific code.
|
|
Previous code deliberately flowed the different lines from MEMINFO_FILE
together on a single line, which seems pointless to me, since we want to be
able to grep the viewer log to recognize individual stats.
Also replace classic-C LLFILE* machinery used to read MEMINFO_FILE with
std::ifstream and std::getline().
|
|
The trouble with remembering the slowest-ever framerate is that framerate
drops dramatically on login, then typically bounces back to something
reasonable during the session. So the session-normal framerate has to drop
pretty dramatically before it falls below the original login framerate. To
address this, only remember the last ~10 minutes of framerates, and log memory
stats every time a new framerate is slower than the previous 10 minutes.
|
|
|
|
Introduce FrameWatcher, a static object that hooks into the LLEventPump named
"mainloop" to get a call every frame. Track framerate over a defined sample
time (20 seconds atm); track minimum and log LLMemoryInfo every time we hit a
new minimum.
|
|
|
|
|
|
code to match
|
