summaryrefslogtreecommitdiff
path: root/indra/llcommon/tests/llsdserialize_test.cpp
AgeCommit message (Collapse)Author
2018-12-14SL-10153: Review and rationalize fetching paths from environment.Nat Goodspeed
Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will be used as a pathname. Use LLFile::tmpdir() instead of getenv("TEMP"). As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz directories that have been accumulating every time we run a local build!
2018-05-22MAINT-2338 Unit testsAndrey Kleshchev
2017-02-23DRTVWR-418: Fix a round of compile errors surfaced by -std=c++11.Nat Goodspeed
These are mostly things that were in fact erroneous, but accepted by older compilers. This changeset has not yet been built with Visual Studio 2013 or Linux gcc, even with -std=c++11. This changeset has not been built *without* -std=c++11. It should be used in conjunction with a corresponding change to LL_BUILD_DARWIN_BASE_SWITCHES in viewer-build-variables/variables. This is a work in progress. We do not assert that this changeset completes the work needed to turn on -std=c++11, even on the Mac.
2016-07-20MAINT=6585: fix llsdserialize_testGlenn Glazer
2015-11-10remove execute permission from many files that should not have itOz Linden
2014-12-16For one use case, boost::bind() better than boost::phoenix::bind().Nat Goodspeed
We use boost::phoenix::placeholders::arg1 to imply a whole lambda expression, replacing boost::lambda. But to bind a plain function in a more straightforward way, seems classic boost::bind() works while boost::phoenix::bind() does not.
2014-12-12Eliminate use of boost::lambda with boost::function (Trac #10864).Nat Goodspeed
https://svn.boost.org/trac/boost/ticket/10864 I've used boost::lambda with boost::function in a number of creative ways over the years. But the clang 6 shipped with Xcode 6 seems to have somehow broken lambda + function in Boost 1.57. boost::phoenix is a partial workaround. Sadly, lambda's comma-operator overload doesn't seem to be supported, necessitating a couple ugly workarounds. With real lambdas now supported by current compilers, I'm sure the Boost community has little incentive to repair the lambda + function problem. Presumably we'll be able to use such features ourselves Real Soon Now...
2013-08-23BUILDFIX: fix for crashes in unit tests on mac and linuxRichard Linden
2013-08-22BUILDFIX: accidental checkin of infinite loop in llsdserialize testRichard Linden
2013-08-22BUILDFIX: attempted fix for crash on exit in llsdserialize testRichard Linden
2013-08-12SH-4399 FIX: Interesting: Texture console MB Bound 0/384 and texture queue ↵Richard Linden
bounces once per second SH-4346 FIX: Interesting: some integer Statistics are displayed as floating point after crossing region boundary made llerrs/infos/etc properly variadic wrt tags LL_INFOS("A", "B", "C") works, for example fixed unit tests remove llsimplestat
2013-04-25Merge 3.5.1 into MaterialsGraham Madarasz
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2013-03-01remove use of system llbase module in integration tests; always use the one ↵Oz Linden
from this tree
2012-01-21Convert LLProcess consumers from LLSD to LLProcess::Params block.Nat Goodspeed
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-20Per Richard, replace LLProcessLauncher with LLProcess.Nat Goodspeed
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-13Extract APR and temp-fixture-file helper code to indra/test.Nat Goodspeed
Specifically: Introduce ManageAPR class in indra/test/manageapr.h. This is useful for a simple test program without lots of static constructors. Extract NamedTempFile from llsdserialize_test.cpp to indra/test/ namedtempfile.h. Refactor to use APR file operations rather than platform- dependent APIs. Use NamedTempFile for llprocesslauncher_test.cpp.
2011-07-19More FormatMessage compile errors, try again to fixNat Goodspeed
2011-07-19Fix copy/paste error in swiped FormatMessage() example code.Nat Goodspeed
2011-07-19Per Josh's comments in http://codereview.lindenlab.com/6510035/Nat Goodspeed
Instead of low-level open(O_CREAT | O_EXCL) loop on all platforms, use GetTempFileName() on Windows and mkstemp() elsewhere. Don't append a final newline to NamedTempFile: use caller's data literally. Tweak a couple comments.
2011-07-16Use raw-string syntax for other Windows pathnames inserted to Python.Nat Goodspeed
2011-07-16Use raw-string syntax for Python string containing Windows pathname.Nat Goodspeed
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.
2011-07-15Use C++ __FILE__ rather than Python __file__ to find indra work area.Nat Goodspeed
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.
2011-07-15If we're going to need indra.base.llsd, have to munge sys.path.Nat Goodspeed
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.
2011-07-15Not all TC agents have llbase.llsd, fall back to indra.base.llsdNat Goodspeed
2011-07-15Try again to pacify VS fatal warning.Nat Goodspeed
2011-07-15Muzzle VS warningNat Goodspeed
2011-07-15Add test to verify Python-to-C++ LLSD notation sequence.Nat Goodspeed
Verify that an LLSD::String containing newlines works; verify that newlines between items are accepted.
2011-07-15Add test to verify C++-to-Python LLSD notation sequence.Nat Goodspeed
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.
2011-07-15Change NamedTempScript to NamedTempFile; allow streaming to it.Nat Goodspeed
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.
2011-07-14Pacify Linux gcc more thoroughly.Nat Goodspeed
2011-07-14#include correct headers for Windows _open() et al.Nat Goodspeed
Also mollify Linux build, which gets alarmed when you implicitly ignore write()'s return value. Ignore it explicitly.
2011-07-14Avoid Boost.Filesystem: Boost package improperly built on Windows?Nat Goodspeed
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."
2011-07-14wstring_to_utf8str() accepts LLWString rather than std::wstring.Nat Goodspeed
2011-07-14Use Linden wstring-to-string conversion, not boost::filesystem's.Nat Goodspeed
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.
2011-07-14Attempt to fix minor build errors on Windows.Nat Goodspeed
2011-07-14Eliminate use of PATH_MAX, which is bogus anyway.Nat Goodspeed
2011-07-14Work around broken Windows command-line processing.Nat Goodspeed
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.
2011-07-13Still trying to fix Windows header-file-order problem.Nat Goodspeed
2011-07-13Attempt to fix confusing header-file-order problems on Windows.Nat Goodspeed
2011-07-13Introduce support for C++ integration tests running Python scripts.Nat Goodspeed
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.
2011-02-04fix linking to llqtwebkit.Alain Linden
2010-08-24standardizing test suite names as class name under testAaron Terrell (Enus)
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-10-19mergeSteve Bennetts
2009-10-16merge from latest svn/viewer-2-0 to hg/viewer-2-0Mark Palange (Mani)
2009-10-16DEV-41080 more automated testing love - minor comment fixing.Adam Moss
2009-10-12DEV-41174 more automated testing loveAdam Moss
* turn llnamevalue_tut into a llmessage unit test * turn llsdserialize_tut into a llcommon integration test * re-enable the (quite slow) llsdserialize test on win32 now that it doesn't have to run on every recompile * re-enable all llmessage unit tests on linux viewer builds