Age | Commit message (Collapse) | Author |
|
etc.
Change-Id: I1548d60280ab4f74fe023d026435a05f7865b516
|
|
Change-Id: I214884e9ee1d49dcc4db71f8744513468b912691
|
|
Change-Id: I82113fcd4182f9557ba0e7258498b5d4e798bf03
|
|
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
|
|
Change-Id: I42bff46998b3d516161068af3d53bf92ee2f2b15
|
|
Change-Id: I012027c38a6d2b06a4bb0cb53743d350b124ccf4
|
|
Change-Id: Ic1c999ffdc391ea01be5711721e7c9e63179473e
|
|
..handling where possible.
Change-Id: I0b071988ed266cc2745a8ca9705c106a05edc557
Reviewed-on: https://gerrit.libreoffice.org/10020
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8e56137ad4422381adbf13b179e2ae6f04edea6e
|
|
Change-Id: I0eae089be1bde9db822a77bea482c10650c8a137
|
|
Change-Id: I4bdfb074b3cf6fcb49765322308dfa4b9ed67713
|
|
Change-Id: If7704edc5baa9759abc680b8d2040b9cdfe92317
|
|
Change-Id: I70e41f087dbe188f8fc455150480faeae2b426ed
|
|
...as flagged by -fsanitize=undefined. But is it really undefined?
[conv.double] "If the source value is between two adjacent destination values,
the result of the conversion is an implementation-defined choice of either of
those values." So if the double is between std::numeric_limits<float>::max()
and std::numeric_limits<float>::infinity()...
Change-Id: I6389c8ac4a922991e240638d231dd2a39e173882
|
|
remove obsoleted sal-module-internal custom STL allocator
The SAL module avoided the heavy dependency on the stlport4-libraries by using
a custom allocator for its internal STL containers. With stlport4 removed these
dependencies are gone and the SAL-internal custom allocator is obsoleted.
(cherry picked from commit c6e0325df6efce45dbb2616a32b7745c449c6c58)
Conflicts:
include/osl/diagnose.hxx
include/rtl/allocator.hxx
sal/osl/w32/procimpl.cxx
sal/qa/osl/process/osl_process.cxx
sal/rtl/bootstrap.cxx
sal/rtl/source/hash.cxx
sal/rtl/source/unload.cxx
Change-Id: I8515382828eda36aba1fec5f23e0f2a89aef7a33
|
|
Change-Id: I3e51a62710bb46c8255fd228d41d9300c90a1fb5
Reviewed-on: https://gerrit.libreoffice.org/9360
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: Id9cb4dbeb6b3313974b881efd6a7c43cb5e314ce
|
|
...which did not work e.g. for broken single-byte input 0x80.
Change-Id: I4dff41e4f18dfce376695b438004c2af853cf4fa
|
|
Change-Id: I8c37b9ec45836f9c0e2dc0cf232f96f23c7c36d3
|
|
Change-Id: Ifeee0632f6e163037bea9ba2ee8d19f050f9a212
|
|
Change-Id: Ie2a6b5e71f76ff2900ff078fcc098e66927458ef
|
|
Change-Id: Iaee3b73ceed5df9928514e55d00ac6292b8b2249
|
|
Change-Id: Ib36c2c5d55f86aff27081a0da554f6e8a81474ee
|
|
...which updates RFC 2396, removes the requirement that the base URI's path
starts with a slash, and clarifies how to treat excess "." and ".." segments.
This nicely allows handling of those odd vnd.sun.star.Package URLs as intended
now, so that making <foo> absolute relative to base URL
<vnd.sun.star.Package:Pictures/bar> yields <vnd.sun.star.Package:Pictures/foo>
instead of provoking a MalformedUriException.
Change-Id: Ice84303a57698a2c05d3a45541fe78b67450fa3c
|
|
Change-Id: Idf07c7d31c0a523f929aded9ff3183a3f01b16b9
Reviewed-on: https://gerrit.libreoffice.org/8297
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib46a64d8438dcaba37a234460d1a4113707e8c43
|
|
Change-Id: I248d002d2ed0e61f97a35ea0d329c64832252ad7
|
|
OpenCL devices require this else we would get a performance hit.
Change-Id: I6b1db6320fa84f933b6446022a0fd02ba267bf21
|
|
Change-Id: I939160ae72fecbe3d4a60ce755730bd4c38497fb
Reviewed-on: https://gerrit.libreoffice.org/8182
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
8f8bc0dcf3bc253ae49159d52db049767f476ced "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).
However, it would be advantageous to keep the stable URE interface as small as
possible. Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.
Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again. (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)
The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters. Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set. These
results appear to justify the change.
Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
|
|
Change-Id: I071a931660dafc1ee5950da527b042fb175255b8
|
|
This reverts commit 56ff07a795aca516106bfde80cb32860065690a6, the correct fix is
d19598b56c8bec688d1944cd167f32a369344100 "Adapt ImplicitBoolConversion to 32-bit
builds (where sal_Int32 is long)."
|
|
hashCode() seems to do sampling while creating the hash.
hashCode64() will not.
Change-Id: Id30f5a2a774cf5244dbc00da9649e95a532484be
|
|
Change-Id: I5ecaf73922c6a30add6e270b8abdfdb5c28fe4a5
|
|
Change-Id: Ie972599650620324fa7af5ed2b2843bfc1f34c43
|
|
Change-Id: I7ae2b02e435d21390843c6c56877a8ce3a73f9f2
|
|
3af99e4d59d89c343965a928681a30f36b1007d2 "convert equalsAsciiL calls to
startsWith calls" should rather have converted to oprator ==.
Change-Id: Id4a8836c5d6d570e54661c40be7214632e202b21
|
|
Change-Id: I46c30a62fb39c2223a369f91010a860372efc72f
|
|
Change-Id: I5150eec33228e18e274a8ae4effd3f185851b7f4
Reviewed-on: https://gerrit.libreoffice.org/7103
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ife8ebbb5e46704c5d2ff46cc345b4ed926e7dc12
|
|
Change-Id: I76be464200d486efef9c8a7e957c310c9adae3b8
|
|
A final pass through the code, converting code to use the new
OUString and OString methods that can detect string literals.
Change-Id: Ifa6382335e5650a1c67e52006b26354e0692c710
|
|
Convert code like:
aStr.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "ActiveConnection" ) )
to
aStr.startsWith( "ActiveConnection" )
which compiles down to the same machine code.
Change-Id: Id4b0c5e0f9afe716a468d3afc70374699848dc33
|
|
Change-Id: I391e027b2567c4239c1d02e132c6508b3f49d381
|
|
Change-Id: I5dd8f718cb96c4442e2fce08a8dc4130e934c68d
|
|
Change-Id: Id218a6123037bf624044a6297edaede924bd4a9a
|
|
Change-Id: Ibf04062ca86ed866202d748c3b62a210d30ed6ec
|
|
Document the "calling" macros for the strtmpl.cxx template file.
And remove unnecessary use of those macros in the calling file.
Change-Id: I20e0dd74150773363b9fb557884b84692ce22f11
Reviewed-on: https://gerrit.libreoffice.org/6504
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Id99ba394b898b7da0057d4a145ce8dce46122782
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I63c32289c7ac6a428c8c50e49650fbac98c8c5e3
|