| Age | Commit message (Collapse) | Author |
|---|
|
|
|
cleaning up build
moved most includes of windows.h to llwin32headers.h to disable min/max macros, etc
streamlined Time class and consolidated functionality in BlockTimer class
llfasttimer is no longer included via llstring.h, so had to add it manually in several places
|
|
repository.
|
|
The change from LLProcessLauncher to LLProcess introduces the possibility of a
NULL (default-constructed) LLProcessPtr. Add certain static LLProcess methods
accepting LLProcessPtr, forwarding to nonstatic method when non-NULL but doing
something reasonable with NULL. Use these methods in LLPLuginProcessParent.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
message output pipe
by removing 's = s.substr()' type operations. The output string is now cleared via 's.clear()'
when its entire contents have been pumped and the beginning of the data is stored as an index
when necessary, rather than modifying the initial string.
Reviewed by davep.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
debugger to help content creators
Viewer side changes to enable Web debugger.
|
|
progress etc. to make debugging problems easier
|
|
|
|
|
|
|
|
clamp maximum framerate of slplugin to 100Hz
also added assert to catch cases where we're requesting infinite framerate
|
|
|
|
|
|
|
|
|
|
current state of the SL client, such as avatar location
|
|
|
|
orientation out to LLQtWebKit
|
|
current state of the SL client, such as avatar location
|
|
links in web profile
Also fixes SOCIAL-521 and SOCIAL-428
|
|
and Help if S3 content or web content is not available.
(Included refs to new LLQtWebKit that supports functionality)
|
|
|
|
|
|
minimal skin on Windows
made slplugin.exe start with correct working directory (llplugin)
|
|
|
|
|
|
current working
Reviewed by Richard - http://codereview.lindenlab.com/6011001/
|
|
accessed through the static LLThread::tldata().
Currently this object contains two (public) thread-local
objects: a LLAPRRootPool and a LLVolatileAPRPool.
The first is the general memory pool used by this thread
(and this thread alone), while the second is intended
for short lived memory allocations (needed for APR).
The advantages of not mixing those two is that the latter
is used most frequently, and as a result of it's nature
can be destroyed and reconstructed on a "regular" basis.
This patch adds LLAPRPool (completely replacing the old one),
which is a wrapper around apr_pool_t* and has complete
thread-safity checking.
Whenever an apr call requires memory for some resource,
a memory pool in the form of an LLAPRPool object can
be created with the same life-time as this resource;
assuring clean up of the memory no sooner, but also
not much later than the life-time of the resource
that needs the memory.
Many, many function calls and constructors had the
pool parameter simply removed (it is no longer the
concern of the developer, if you don't write code
that actually does an libapr call then you are no
longer bothered with memory pools at all).
However, I kept the notion of short-lived and
long-lived allocations alive (see my remark in
the jira here: https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356
which requires that the LLAPRFile API needs
to allow the user to specify how long they
think a file will stay open. By choosing
'short_lived' as default for the constructor
that immediately opens a file, the number of
instances where this needs to be specified is
drastically reduced however (obviously, any
automatic LLAPRFile is short lived).
***
Addressed Boroondas remarks in https://codereview.secondlife.com/r/99/
regarding (doxygen) comments. This patch effectively only changes comments.
Includes some 'merge' stuff that ended up in llvocache.cpp
(while starting as a bug fix, now only resulting in a cleanup).
***
Added comment 'The use of apr_pool_t is OK here'.
Added this comment on every line where apr_pool_t
is correctly being used.
This should make it easier to spot (future) errors
where someone started to use apr_pool_t; you can
just grep all sources for 'apr_pool_t' and immediately
see where it's being used while LLAPRPool should
have been used.
Note that merging this patch is very easy:
If there are no other uses of apr_pool_t in the code
(one grep) and it compiles, then it will work.
***
Second Merge (needed to remove 'delete mCreationMutex'
from LLImageDecodeThread::~LLImageDecodeThread).
***
Added back #include <apr_pools.h>.
Apparently that is needed on libapr version 1.2.8.,
the version used by Linden Lab, for calls to
apr_queue_*. This is a bug in libapr (we also
include <apr_queue.h>, that is fixed in (at least) 1.3.7.
Note that 1.2.8 is VERY old. Even 1.3.x is old.
***
License fixes (GPL -> LGPL). And typo in comments.
Addresses merov's comments on the review board.
***
Added Merov's compile fixes for windows.
|
|
|
|
|
|
Reviewed by Callum
|
|
Reviewed by Callum at http://codereview.lindenlab.com/5636001
|
|
If Qt and/or llqtwebkit is found in a non-standard place, you still
have to set LD_LIBRARY_PATH yourself (to $QTDIR/lib) before running
the viewer of course (or the webkit plugin will silently fail).
|
