Rather than directly using the blocks from mtv.

Change-Id: I215e38ad406f8edc5d15c9f011dde649fce1d671

Change-Id: Id2b9ca7b6e24edc0da4735c01798ab580fba910d

Change-Id: I3c4f255469b48cfd6f132503ff695e347d8ae912

Change-Id: Ieb169d5ef8700067fbf011bbfc18fca6b40c03b8

And move the value compare code to somewhere public.  I'll be using it
from the ScMatrix internal.

This change requires mdds 0.9.1 which is yet to be released.

Change-Id: I942133c85b614b3404006fa38af111ace9361fd4

Change-Id: I0c02204d08c73668b2564360486f843e5e7b69d0

This one is accelerated for a single cell calculation case only.

Change-Id: I1f66fc6bb20f08f45d47ae596fb201b838b17408

The test now passes.

Change-Id: I84e98e326be9cab175ecb95dbb4db4c535bca6d2

Change-Id: I503fc26ccc0f117c626e78a8a1dd07ff32a06432

Change-Id: I3d6e3bceda23255a138340dcea3d847481216e73

For now it only works when the range starts with string cell.  With this,
the test now passes.

Change-Id: I6f79415ce11233648cdb20c8075f500b8c3d2f76

Change-Id: I9c48f340a0349e5f1ba772fcd783924c79b07616

This currently fails rightly.

Change-Id: Ic4d8d3d720b2ee879f963d1871dd8779461f352f

Change-Id: If2f47a7d98a4cbc9e09dc98c1bb0e11f8f889265

This is achieved by storing two physical arrays in each vector
reference array.

Change-Id: Iafb9e57b86e57e75eed8ff692a6d882c2049f710

Change-Id: I4a1ad9da56f39a21d8a392fdb92704cc4311c84c

Change-Id: I2b60de0a11948ad1cab29931ac09b0aa1fe9adee

Change-Id: I9cf5b9b0913e7bf4a59c3ec98157ce6d0661f408
Reviewed-on: https://gerrit.libreoffice.org/6310Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: Id6023dc3751fe70984f489682be17d1ab1855f71

i.e. due to d07e7d69
"wait until we know the UI language before initializing gtk"
we need to have uno working earlier

Change-Id: I77dbea78113c1c95b622a2367472a0111d0d32d1

Change-Id: I0a04798a38288eaa0cd4bc729303f8549ce4081a

Change-Id: I38dcca9d513e9122ffca81f448ad3181fd7a9817

Change-Id: I47265cf0be9785e8be4b4be0b13d40cda206f349

Change-Id: I85170f2d65dd17e0a04a261b0680f693e2917131

These functions have been introduced with Excel 2010, but were not
supported yet in calc.
COVARIANCE.P (population) replaces the COVAR function, but the COVAR
function remains present (in Excel as well as in calc).
COVARIANCE.S (sample) is a new function.

Change-Id: If5501b4090fb716adfb3d121c7898528fd1b7ad4
Reviewed-on: https://gerrit.libreoffice.org/6135Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

No mark at all happens when creating a new document, in which
case the selection pattern is empty (created of GetPool())
anyway (hence there was a debug warning "SelectionPattern Null"
from ScDocument::CreateSelectionPattern()) and nothing needs to
be applied.

Change-Id: I9df338063baf27581f258f6c2fd0737b95804509

Change-Id: I1c4a45c3f19d79b4da8cc96304e0e1802f92dff2
Reviewed-on: https://gerrit.libreoffice.org/6320Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: Ia29725295613faf875a688b3917b144a5f05bbe3

Change-Id: I142f9c4e73585272c3028880e40c20f4a056f3c3

Change-Id: I694d81d17fac5fbd964937dc654ebd764af90842

Change-Id: I9db663dbcb432cbfe380e1272d6daaed3e6f4221

What we want here is *all* the scripts in the range, that's the whole point of
using SCRIPTTYPE. We use this to determine the font to show in the fontbox. If
it's an exclusive script then we can show the font that that script, and if
there are multiple scripts we know to set it empty.

With the other intermediate bugs out of the way, this now appears to work
correctly.

Change-Id: I58426123602d70c151bd878e96fa5cbab7d3fd3e

Change-Id: I5da9114a3fd8330df2b63dc9187323765d305791

Only in editengine could we have this fiasco.

There are two ImpEditEngine::GetScriptType's

a) sal_uInt16 ImpEditEngine::GetScriptType(const EditPaM& rPaM, sal_uInt16* pEndPos) const
this one returns i18n::ScriptType

b) sal_uInt16 ImpEditEngine::GetScriptType(const EditSelection& rSel) const
this one returns SCRIPTTYPE

Could there be a better way to ensure that mistakes will be made.

Anyway, within variant b, with an empty edit engine
ImpEditEngine::GetScriptType calls GetI18NScriptTypeOfLanguage but *that*
returns i18n::ScriptType's not SCRIPTTYPEs but when there is content then a
SCRIPTTYPE is truly returned.

Change-Id: I3a4a7c8746728e0fdfb25d961004c8339a24c93d

Change-Id: Id6eaba19e89236716db2a0db9f557216d9402c66

Change-Id: Id3854de1bcb8d5856d56e96895ff3bbf2e4aa666

Change-Id: I31c6bcb9a4b26653d439601f78d71fd94d938eeb

...as per #libreoffice-dev IRC:

Sep 19 10:32:24 <mst__> sberg, moggi  why the hell is that thing named
  "cppunit/cppunittester" and inside a subdir?  it's obstructing my attempt to
  put it in $(INSTDIR)/program
Sep 19 10:33:28 <mst__> (... and if you wonder "wtf does it have to do with
  INSTDIR" you have never heard of awesome LibreOffice_Test installset.... not
  that i would know who needs it :)
Sep 19 10:36:36 <sberg> mst__, it is in a subdir of solver/*/bin so that on
  Windows it would not accidentally have picked DLLs next to itself instead of
  the module-local DLLs it was supposed to test (back when we had module-local
  output trees)
Sep 19 10:37:02 <mst__> sberg, ahh hysteric reasons then, /me renames it
Sep 19 10:37:55 <tml> mst__, if nobody you know uses LibreOffice_Test, just kill
  it?
Sep 19 10:38:59 <sberg> mst__, tml, LibreOffice_Test was conceived by pmladek
  and/or kendy, IIRC
Sep 19 10:40:31 * kendy does not remember anything about it :-)
Sep 19 10:42:17 <sberg> wasn't that something so users (or QA people?) could
  easily run the smoketest against an installation, to see whether the
  installation is any good at all, by installing that LibreOffice_Test alongside
  the installation proper?
Sep 19 10:43:26 <sberg> mst__, ...and I'd unscientifically vote to kill it
Sep 19 11:34:23 <pmladek> mst__, sberg: I have created the LibreOffice_Test
  package for one QA guy. He does not longer work on LO. I am not sure if anyone
  else started to use it. So, I think that it can be killed.

Oct 17 18:18:07 <tml_> sberg: have you ever noticed that when you try to
  actually run instdir/unxmacxi/LibreOfficeDev.app , the system actually tries
  to run cppunittester inside the app bundle (it says so in the crash report)
  (it crashes because cppunittester requires a specialized DYLIB_LIBRARY_PATH
  apparently)
Oct 17 18:19:29 <tml_> I suspect that the system when cppunittester as part of
  the build process is run from inside instdir (i.e. inside an app bundle) the
  system "caches" this false knowledge, and thinks that the executable of the
  app bundle is cppunittester...
Oct 17 18:19:36 <sberg> tml_, no, never noticed; with "run
  instdir/unxmacxi/LibreOfficeDev.app" you mean calling "open
  instdir/unxmacxi/LibreOfficeDev.app"?  (I always call
  .app/Contenst/MacOS/program explicitly)
Oct 17 18:19:52 <tml_> yes, I mean "open instdir/..."
Oct 17 18:20:53 <tml_> some googling tells me that at least years ago, the
  CFBundleExecutable key in the Info.plist is ignored if it is manually changed,
  so I guess similar caching of mapping between an app bundle and which
  executable to actually run happens in this case
Oct 17 18:23:17 <tml_> and last year somebody even claims "And while on Mountain
  Lion, CFBundleExecutable seems to be a no-op", which would be odd, surely
  there must be widely used apps that have several executables inside the MacOS
  directory; how would the system know which one to run when the app is run?
Oct 17 18:24:38 <tml_> hmm, apparently the code that handles this might be open
  source even, http://www.opensource.apple.com/source/CF/CF-744.18/CFBundle.c
Oct 17 18:25:52 <tml_> some mention of "caches" there yes, my guesses might be
  right
Oct 17 18:27:05 <tml_> if I cp -R instdir/unxmacxi/LibreOffice.app foo.app and
  open foo.app, it works fine
Oct 17 18:28:33 <tml_> anyway, I guess it would be cleaner to have cppunittester
  somewhere else even without this problem
Oct 17 18:37:09 <sberg> tml_, yes, IIRC having cppunittester in instdir was a
  misguided mst decision, because that odd LibreOffice_Test product (that
  pmladek said nobody needs any longer anyway) includes it; I think consensus
  was to kill LibreOffice_Test and move cppunittester where all the other NONE
  executables are, but looks like nobody executed
Oct 17 18:37:55 <tml_> ah ok, so mst should know what needs to be done? good, no
  need for me to try to hack this now then
Oct 17 18:38:19 <sberg> tml_, I'll do the cleanup tomorrow, unless somebody
  beats me

This removes smoketest/losmoketest et al along with the *_Test product, as they
seem to not make sense without it anyway.  smoketest/Executable_libtest.mk
appears to be a test that could also be run during the build, and only ended up
in the *_Test product by accident, so I left it untouched for now.

Change-Id: I8024472c909fe0a885eb08ef4d3777f8a9e1f7c8

Change-Id: I4c688a4aeedcae56ed6404574bd1bb392d4190cb
Reviewed-on: https://gerrit.libreoffice.org/6311Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I66257ed063849fde997ff78b8b9a6fc2db939fde