| Age | Commit message (Collapse) | Author |
|---|
|
DRTVWR-489-emoji-PR
|
|
|
|
|
|
Drtvwr 489 emoji
|
|
|
|
Xcode 14.1
|
|
|
|
working, the flag was introduced to warn (and therefore error out) when a virtual override was not marked with the 'override' keyword. Fixing this up involved a large number of changes and this commit represents just those changes - nothing specially from the DRTVWR-489 viewer
(Cherry pick of 3 commits from Callum to declutter the emoji PR: 3185bdea27b19e155c2ccc03c80624e113d312a6,
923733e591eb547ad5dfec395ce7d3e8f0468c16 and 6f31fabbc2d082b77c8f09bce30234ec9c506e33)
|
|
|
|
|
|
|
|
|
|
|
|
DRTVWR-489-emoji
|
|
This makes no sense, trying to add a glyph now will have no width or height set, neither character width or heigh, yet release viewer does that. Fixed code to match release and set width and height despite char width not being up to date.
|
|
following promotion of DRTVWR-570
|
|
This reverts commit 4d429b7ea31f51f653e0e2ad6b5799a515e28334.
|
|
Rebuilt locally with tests and confirmed it works now
|
|
|
|
to Python3 so that it builds on macOS in TeamCity
|
|
macOS build forwards
|
|
no-tabs coding policy caught it and failed the build
|
|
working, the flag was introduced to warn (and therefore error out) when a virtual override was not marked with the 'override' keyword. Fixing this up involved a large number of changes and this commit represents just those changes - nothing specially from the DRTVWR-489 viewer
|
|
|
|
- Link against ICU4C
- Font files were only copied on Windows builds
- Replace missing variable
|
|
therefore an error) but only on 32bit Windows builds - 64bit is fine. I don't know why that's the case (should be both surely) but in any case, I think the variable should be declared as a size_t
|
|
with access to TeramCity - with all the ICU4C DLLs removed, the viewer builds fine which does suggest a size/disk space issue. Trying with the (porposed) minimum set to see if this helps. Likely it won't because the main one (icudt48.dll) is much, much bigger than the others combined - but we shall see
|
|
with access to TeramCity - one theory is that the extra size of these DLLs consumes too much disk space and results in the NSIS internal compiler error we observe - removing these tempoorarily to see what difference that makes
|
|
builds fail because of 'compiler error' in NSIS - wondering if this warning triggers the error (it doesn't locally) - yes, grasphing at straws
|
|
dlls in the right place for the Windows builds
|
|
the right place in Windows builds
|
|
'missing' Tweenmoji SVG font
|
|
copies over the Windows DLLs as part of the build process
|
|
|
|
2017 like everything else. The work to do this is large and we are switching soon to VS 2022 so this will do for now
|
|
3p library changes for steps 1-5 (boost, colladom, googlemock, nanosvg, viewer-fonts) - final 3p change (ICU4C) coming later
|
|
Links can be drag and dropped so they should be movable via 'cut' as well
|
|
|
|
branches (#47)
Revert part of "DRTVWR-575: Address review comments on Xcode 14.1 type tweaks."
Crash was reproduced when assigning areastr to llsd, but likely present in other cases of assigning ui strings to llsd (instead of going for lluistring's result directly copy constructor was engaged and either copy or original crashed due to invalid pointers, copy shouldn't have been created).
|
|
This reverts commit d6f5e5bc9424b9d45f6eeeca5d894d46dc91b279.
|
|
|
|
|
|
user is in DND mode
Revert of commit for SL-15401. Messages are supposed to handle 'mute' on their own.
|
|
|
|
One could argue that passing a negative index to an LLSD array should do
something other than shrug and reference element [0], but as that's legacy
behavior, it seems all too likely that the viewer sometimes relies on it.
This specific problem arises if the index passed to operator[]() is negative
-- either with the previous Integer parameter or with size_t (which of course
reinterprets the negative index as hugely positive). The non-const
ImplArray::ref() overload checks parameter 'i' and, if it appears negative,
sets internal 'index' to 0.
But in the next stanza, if (index >= existing size()), it calls resize() to
scale the internal array up to one more than the requested index. The trouble
is that it passed resize(i + 1), not the adjusted resize(index + 1).
With a requested index of exactly -1, that would pass resize(0), which would
result in the ensuing array[0] reference being invalid.
With a requested index less than -1, that would pass resize(hugely positive)
-- since, whether operator[]() accepts signed LLSD::Integer or size_t,
resize() accepts std::vector::size_type. Given that the footprint of an LLSD
array element is at least a pointer, the number of bytes required for
resize(hugely positive) is likely to exceed available heap storage.
Passing the adjusted resize(index + 1) should defend against that case.
|
|
LLFloaterLandHoldings::postBuild() was constructing an LLSD structure by
assigning each map entry and array element one at a time. Chorazinallen
identified a crash bug possibly caused by destroying that LLSD structure.
Diagnostically try building it using nested llsd::map() and llsd::array()
calls instead to see if that improves matters.
|
|
The compiler was deducing an unsigned type for the difference (U64 desired
microseconds - half KERNEL_SLEEP_INTERVAL_US). When the desired sleep was less
than that constant, the difference went hugely positive, resulting in a very
long snooze.
Amusingly, forcing that U64 result into an S32 num_sleep_intervals worked only
*because* of integer truncation: the high-order bits were discarded, resulting
in a negative result as intended.
Ensuring that both integer operands are signed at the outset, though, produces
a more formally correct result.
|
|
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
|
|
Server sends updates in bulk now, so notify per agent instead of per update
|
|
Affects accent keys for diacritical marks
|
