It can happen the algorithm doesn't converge the values towards
the solution in the timeframe and number of generations it has
available (slow execution, high cpu load, bad luck) so for now
don't assert the expected value in the test, but still run it
so we know the algorithm does end eventually and doesn't cause
any seg. faults.
Change-Id: Ic889ad1618bf057ac7b281c15bce735f8ec5e13c
Reviewed-on: https://gerrit.libreoffice.org/50500
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This way, it is possible to have all the strings translated in dialogs even
when different users use different languages. [It was already possible
to have different languages previously, but not everything in the dialog has
switched - like the buttons at the bottom of the dialogs etc.]
Change-Id: I29a5ae6d31a370eec60397884200b684ec1bf5b9
Reviewed-on: https://gerrit.libreoffice.org/46417
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/46979
Tested-by: Jenkins <ci@libreoffice.org>
Hopefully the last such commit, now that the in-gerrit verification is
in place and also a warning is printed locally for those who push
directly.
Change-Id: Ib80cbca0b29dc7f71cbb182a38ad6839a659ff41
Reviewed-on: https://gerrit.libreoffice.org/45002
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...at least for my local one, with
> /data/sbergman/lo-san/core/sccomp/qa/unit/SwarmSolverTest.cxx:387:(anonymous namespace)::SwarmSolverTest::testMultipleVariables
> double equality assertion failed
> - Expected: 0
> - Actual : 1
> - Delta : 1e-05
so disable that part unconditionally for now.
Change-Id: Id8c091781baf4381696e2a8f0501df1f3f83724f
Reviewed-on: https://gerrit.libreoffice.org/44977
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
swarmsolver now compiles after the license issue was corrected, so
no need to have a special case for iOS.
Change-Id: Icae81c2b5769af9c8fd53068d69cbb6e608c7e69
This is a new, simple non-linear solver that uses a swarm
(population) to do global optimization. It uses two algoritms -
Particle Swarm Optimization (PSO) or Differential Evolution (DE)
to find a (non-optimal) solution.
It is experimental as not all functions are implemented and it
needs a lot more testing so that it performs well.
Change-Id: If55dad7eda17394851a9d178ad892de771eca7c9
Reviewed-on: https://gerrit.libreoffice.org/44382
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
and the vast majority of translations is to the ui language so default
ctor with that arg
and now drop OModuleResourceClient
Change-Id: I3b85a560ffdfe5f019c2271ac56a5fe4a361522b
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
This changes the lpsolver test to explicitly test the available
linear solvers we have - either CoinMP, LpSolver or both. This
prevents that a newly added solver will be automatically tested
as it can have a different behaviour for the tested input values.
Change-Id: I0c4d2f9c561d1e834ca51196b7b5ecf7d89ba550
Reviewed-on: https://gerrit.libreoffice.org/34813
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block
Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625
Reviewed-on: https://gerrit.libreoffice.org/33749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
...the code had been like this ever since it got introduced with
6d492447a37ec268fb5924e7fc5631c29c67325d "118160: Use CoinMP as replacement for
lp_solve," but it looks more plausible that the return values should be checked
rather than be ignored. At least, CppunitTest_sccomp_lpsolver keeps succeeding
after the change (with --enable-coinmp).
Change-Id: If450827ae034079c9ee69b4e49c55b480ac0de06
This required some changes to the framework:
* Init-/DeInitVCL is no longer done per individual test in BootstrapFixture, but
once per CppunitTest invocation in a new vclbootstrapprotector (similarly to
the exisiting unobootstrapprotector). CppunitTests that need VCL now need to
declare gb_CppunitTest_use_vcl.
* For things to work properly, the UNO component context needs to be disposed
from within DeInitVCL (cf. Desktop's Application::DeInit called from
DeInitVCL). The easiest solution was to introduce an
Application::setDeInitHook (where the hook is called from DeInitVCL)
specifically for vclbootstrapprotector to call.
* PythonTests don't (yet) call DeInitVCL; they still hook into
BootstrapFixture's original test_init functionality (to call InitVCL), and do
not make use of the vclbootstrapprotector.
Change-Id: I4f3a3c75db30b58c1cd49d81c51db14902ed68b2
Tomaž Vajngerl