As
commit a545badd65
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Thu Feb 16 18:15:04 2012 +0100
Work around macro redefinition warning
already did for pyuno/source/module/pyuno_dlopenwrapper.c ,
also include the <Python.h> header first
in more pyuno source files.
Quoting from the Python/C API reference manual about include
files [1]:
> Note: Since Python may define some pre-processor definitions
> which affect the standard headers on some systems, you must
> include Python.h before any standard headers are included.
This avoids build errors like the following otherwise seen
on Debian testing after a glibc update from 2.42-17 to 2.43-3:
In file included from /home/michi/development/git/libreoffice/pyuno/source/module/pyuno_struct.cxx:28:
In file included from /home/michi/development/git/libreoffice/pyuno/source/module/pyuno_impl.hxx:26:
In file included from /home/michi/development/git/libreoffice/workdir/UnpackedTarball/python3/Include/Python.h:14:
/home/michi/development/git/libreoffice/workdir/UnpackedTarball/python3/pyconfig.h:1985:9: error: '_POSIX_C_SOURCE' macro redefined [-Werror,-Wmacro-redefined]
1985 | #define _POSIX_C_SOURCE 200809L
| ^
/usr/include/features.h:319:10: note: previous definition is here
319 | # define _POSIX_C_SOURCE 202405L
| ^
[1] https://docs.python.org/3/c-api/intro.html#include-files
Change-Id: I4ae90cfc9b92b559181d3884cdc8d51ee11f922d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209871
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
If an object implements XInvocation then the Invocation service will
directly return the object instead of creating its own invocation
wrapper. In that case the object isn’t guaranteed to also implement
XInvocation2. Previously, this was making pyuno just throw an exception
whenever it encounters one of these objects.
The only case where XInvocation2 is actually used is the implementation
of the __dir__ method. I don’t think this method is used very often so
it’s probably OK to just make it return an empty list if XInvocation2
isn’t supported. That way we can just store a reference to XInvocation
instead of XInvocation2.
This change makes it possible to use objects that implement XInvocation
from Python, for example ooo.vba.excel.Application.
Change-Id: I822c4ffa760f52d6488b9c1009435d059fc19fdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209086
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Many implementations of XInvocation for internal objects return null for
the getIntrospection method. In pyuno this method is only used in one
place to try and catch the case where the wrapped object is already a
PyUNO adapter. Let’s check for null in that case and assume the object
isn’t an adapter so that it won’t crash when handling objects that
implement XInvocation.
Change-Id: I26576a1a9fec92c679373d9ab47824d992065041
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209085
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
PyUNOStruct_dir is an almost exact copy of PyUNO_dir. This deletes the
first one and makes the struct code instead directly use PyUNO_dir. The
object version has the small advantage that it pre-allocates the Python
list to the right size so the struct code can now take advantage of that
too.
This will make it easier to modify the dir implementation for both use
cases in a later patch.
Change-Id: I7ebe2e6d547fd27c228842effd534e8d71d634ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209084
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
During local LODE builds on macOS, the test framework sets UNO_PATH
to `instdir/program`. While this works for Linux and Windows, macOS
builds generate a native application bundle, placing the executable
at `instdir/LibreOfficeDev.app/Contents/MacOS/soffice`.
This caused `subprocess.Popen` to throw a `FileNotFoundError` during
execution of targets like `PythonTest_pyuno_pytests_testofficehelper`.
This patch intercepts the macOS path in `bootstrap()` and dynamically
routes it to the correct LibreOfficeDev App Bundle location if the
default Linux-style path does not exist.
Additionally, this adds a standard Python 3 shebang to the file and
fixes a missing newline at EOF.
Change-Id: Ie92415941c24e0777087d51a999dcbeae6c06223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208052
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
When any2PyObject is given an interface which is actually an adapter for
a Python object, it now returns the original Python object instead of a
new wrapper for the object. This means that calling methods on the
returned object will be faster because they won’t involve UNO bridging.
It also means that Python implementations of UNO interfaces can detect
when they are given Python objects as a parameter and take advantage of
any internal private data attached to the object.
Change-Id: Ie13d0612f48e70973bd523e68710ec33a7875a16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207507
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
On macOS a hard-coded path is used for the soffice binary. It probably
makes sense to avoid doing this if the UNO_PATH environment variable is
set.
Change-Id: I160bbec8a7ddffbb7032b55a61a3004e9d42bf18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206263
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Instead of calling os.path.join with an empty string when UNO_PATH is
not set, it is now only called when UNO_PATH is set.
Change-Id: I8ebf99d1849e62634860686c0bb4c9d0c2a9c0d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206262
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
subprocess.Popen can take an array argument with the arguments. If we do
this instead of trying to build up a single argument to pass to the
shell then we can let Python handle quoting the arguments on Windows.
This also means the executable path could contain spaces on platforms
other than Windows too.
Change-Id: I7779c5bab431b65cf4a602047c184fe78d802d77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206260
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
officehelper processes remain active in memory unless scripters
intentionally stop them.
A new SessionMgr Python context manager is now taking care of
bootstraping a Libreoffice service as well as stopping it
automatically.
Change-Id: Icbc5886be371ad2aa8d8277e2476f5d89955d955
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206225
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
That function was added in Python 3.9. Even though the LibreOffice
README says the baseline is 3.11, the configure script actually lets you
build with 3.3. I tested with Python 3.5 and it does work apart from
that function call and the fact that desktop-translate.py is using
f-strings. The call to PyObject_CallOneArg was added in the patch below
after the 26.2 branch point so it hasn’t been battle-tested in a release
version yet. Seeing as it’s easy to use an alternative let’s do that in
case someone is using a really old version of Python with pyuno for some
reason.
commit 45d2412c78
Author: Neil Roberts <bpeeluk@yahoo.co.uk>
Date: Wed Feb 11 16:40:48 2026 +0100
tdf#171122 pyuno: Add class getter methods for singletons
Change-Id: Ic6f7cf8d0005f59e8cbfd1f9703d393b7e30dabe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206333
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Building with clang 21.1.8 and --enable-werror fails because glibc 2.43
adopted the C23 behavior for strrchr(), where it now returns const char*
when its input is const char*. Assigning the result to a plain char*
discards the const qualifier, which clang rejects as an error since the flag is passed.
Change-Id: Ib8eecd603bedb4a69c8f7bd93e49f01e8eba28d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199863
Tested-by: Jenkins
Reviewed-by: Neil Roberts <bpeeluk@yahoo.co.uk>
Makes it possible to import the name of a singleton into a Python script
as a class and then retrieve it with a getter method. Eg, instead of:
desktop = ctx.getValueByName(
"/singletons/com.sun.star.frame.theDesktop")
you can now do:
from com.sun.star.frame import theDesktop
desktop = theDesktop.get(ctx)
Change-Id: I009bd2e890cde52aa6273e462621157fc1f63661
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
This makes it so that services can be imported in Python with code like
this:
from com.sun.star.resource import StringResourceWithLocation
And then an instance of the service can be constructed using any of its
constructors as a class method like this:
res = StringResourceWithLocation.create(ctx, root_url, True, locale,
dlg, '', None)
This has the advantage that the number of arguments can be checked
properly and a more useful error message can be reported if they are not
correct. Because pyuno knows what types the arguments are supposed to
be, it can also do a better job of coercing them to the right ones. For
example in the example above it is possible to pass None for an
interface argument even though that normally represents the void type.
This idea evolved out of the discussion for tdf#169229.
Change-Id: I9b542178f1c101d58dcbbd241d4ecbc9fe38bc2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199104
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Previously when creating a callable object for an attribute on an
object (ie, a method), it would mark it with a special mode to disallow
passing a pyuno.Any as an argument. There doesn’t seem to be a good
reason to do this and it makes it difficult to use an explicit type when
calling a method that can take an Any. This patch instead just removes
the mode parameter from pyobject2Any entirely.
The example in the bug report is trying to call
createInstanceWithArgumentsAndContext which takes a Sequence of Anys as
an argument. Without this patch it is difficult to pass a null interface
as one of the arguments.
Change-Id: I8756bdc2821ebf247ff67a66f071263ac00e3890
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195452
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...for cases where one operand is a PyUNO Adapter of the other (i.e., one
operand is a Python object that got passed out and back in again, and the other
operand is that same Python object). This fixes the second "TODO" from
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest".
Change-Id: I0fc938db5c464ed56adee3b428537925fff0fc81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195392
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
That
> // the exception base functions want to have an "args" tuple,
> // which contains the message
code is there ever since e80bdbafeb "initial
checkin for the pyuno-0.9.2 release" for reasons that are not clear to me, but
at least in the "TODO" scenarios from 3320b5fe2e
"Add exhaustive testing of PyUNO type mapping based on embindtest" and
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" (which are hereby fixed), that
PyObject_SetAttrString would cause a Python exception, cf.
> info:pyuno.runtime:1489432:1489432:pyuno/source/module/pyuno_runtime.cxx:533: setting exception args raised Python exception <class 'AttributeError'>: AttributeError('args')
so at least catch that. (And maybe that code is obsolete anyway it would make
even more sense to drop it altogether.)
Change-Id: Ic651d106f34e0b316cba59ae66d2402b8f86b0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195340
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(Stumbled over this when while preparing
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" I accidentally forgot the
> from org.libreoffice.embindtest import Exception
in pyuno/qa/pytests/embindtest.py and thus PythonTest_pyuno_pytests_embindtest
would SIGABRT with
> sal/rtl/strtmpl.hxx:122: auto rtl::str::Copy(sal_Unicode *, const char *, sal_Int32)::(anonymous class)::operator()(char) const: Assertion `rtl::isAscii(static_cast<unsigned char>(c))' failed.
from pyuno::lcl_ExceptionMessage (with reprString being "('error', None,
-123456, 100.5, 'hä')") while trying to report
> uno.com.sun.star.uno.RuntimeException: Couldn't convert ('error', None, -123456, 100.5, 'hä') to a UNO type; caught exception: <class 'AttributeError'>: 'Exception' object has no attribute 'getTypes', traceback follows
.)
Change-Id: I4581061dbfa190266fef98dc670a058d6c98eaaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195304
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
...by implementing all the getAny... variants that were left out of
5f05929fd1498e418618d7570192877055de2c80 "Add exhaustive testing of PyUNO type
mapping based on embindtest".
Which revealed that the code in Adapter::invoke (in
pyuno/source/module/pyuno_adapter.cxx) was apparently broken, and would cause
the C++ call in doExecuteTest (in unotest/source/embindtest/embindtest.cxx) of
the Python
> def getAnyByte(self):
> return uno.Any('byte', -12)
(in pyuno/qa/pytests/embindtest.py) to fail with a nonsensical
> uno.com.sun.star.uno.RuntimeException: uno.Any instance not accepted during method call, use uno.invoke instead at pyuno/source/module/pyuno_runtime.cxx:785 at stoc/source/invocation_adapterfactory/iafactory.cxx:203
In addition, there's two new places marked with TODO comments:
For one, executing C++
> bool const ok = test->isAnyException(val);
would cause an odd
> python.bin: Objects/typeobject.c:4745: PyObject *_PyType_Lookup(PyTypeObject *, PyObject *): Assertion `!PyErr_Occurred()' failed.
failure that needs further investigation.
And for another, executing Python
> return value == self
would always return false. It appears that PyUNO_cmp (in
pyuno/source/module/pyuno.cxx isn't yet prepared to be called with `that` being
a native Python UNO-implemenation object (`class Test(unohelper.Base, XTest)`)
instead of a proxy for a binary/C++ UNO object.
Change-Id: I0289e1f5ee6dab53b589af783c0c53302989394c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195287
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
The goal is to make the script more readable. The format is done with
command:
black --line-length 120 <filename>
No manual modification to these files.
Change-Id: I8ebbac936924277308fc011b20cba60849fa9c45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179438
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
As Clang supports that warning now too, lots of occurrences have meanwhile been
cleaned up for good (0c29c417ef "Avoid
-Werror,-Wcast-function-type-mismatch", 1344e6261a
"Avoid -Werror,-Wcast-function-type-mismatch",
85a2bb9f52 "Avoid
-Werror,-Wcast-function-type-mismatch", etc.), so
ce99754e9b "Globally disable -Wcast-function-type
new with upcoming GCC 8" in solenv/gbuild/platform/com_GCC_defs.mk should no
longer be necessary.
One remaining issue I encountered was dae7304df6
"Silence Clang 19 trunk -Werror,-Wcast-function-type-mismatch", where GCC needs
a different way for silencing the warnings in pyuno/source/module/ than had been
used there for Clang.
Change-Id: I5d0404b957d798114051209c31e022a898cf91f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173623
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
The problem was that running UITest_xmlsecurity_gpg changed the files in
test/signing-keys/ ... prevent that by copying the directory in that
test, which is more complicated than initially expected.
Change-Id: Ie3be922e0b2e9dae49f9a70e35ad5270c90b4fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171322
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Andrea Gelmini