Age | Commit message (Collapse) | Author | Files | Lines |
|
Renaming used as it was confusing to assume the .mk file based on the
python test case, which was testssl.py.
Change-Id: I903b59aecf3b167f75494aefcfcde916febee69e
Reviewed-on: https://gerrit.libreoffice.org/69217
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
...instead of the 'make PythonTest_pytests' hack introduced with
4e887567c5b4b06646ab1340376e240d6c5af9cb "A rudimentary framework for additional
Python tests not run by default".
PythonTest_pyuno_pytests_insertremovecells and
PythonTest_pyuno_pytests_testcollections apparently have various dependencies
that are not spelled out, so simply add them to subsequentcheck for now (also,
the latter appears to take quite some time to execute).
Change-Id: Ie9d3c301af28f67ab65c09eba93d9778a3c82c8a
Reviewed-on: https://gerrit.libreoffice.org/42822
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I70da65e08c75cd732000597a09ed113b3075c5a8
|
|
- Simplifies working with UNO objects by giving the behaviour of
Python lists, dicts and iterators to objects which implement UNO
container interfaces
- Applies a custom behaviour to allow objects which implement
com::sun::star::table::XCellRange to yield cells and cell ranges by
subscript
- When UNO container objects are addressed in the new style,
eliminates the requirement to manually construct Any objects for
contained elements which are typed sequences
- Allows lists and iterators to be passed wherever a UNO method
accepts a sequence
- Relaxes the requirements for initialising UNO structs to allow
some members to be skipped when all initialisers are passed by name
1. Collection interfaces
========================
Objects which implement core UNO collection interfaces are made to
behave in a way that is more natural for Python code.
com::sun::star::container::XIndexAccess
com::sun::star::container::XIndexReplace
com::sun::star::container::XIndexContainer
- Objects provide Python list access semantics
num = len(obj) # Number of elements
val = obj[0] # Access by index
val1,val2 = obj[2:4] # Access by slice
val1,val2 = obj[0:3:2] # Access by extended slice
if val in obj: ... # Test value presence
for val in obj: ... # Implicit iterator (values)
itr = iter(obj) # Named iterator (values)
obj[0] = val # Replace by index
obj[2:4] = val1,val2 # Replace by slice
obj[0:3:2] = val1,val2 # Replace by extended slice
obj[2:3] = val1,val2 # Insert/replace by slice
obj[2:2] = (val,) # Insert by slice
obj[2:4] = (val,) # Replace/delete by slice
obj[2:3] = () # Delete by slice (implicit)
del obj[0] # Delete by index
del obj[2:4] # Delete by slice
com::sun::star::container::XNameAccess
com::sun::star::container::XNameReplace
com::sun::star::container::XNameContainer
- Objects provide Python dict access semantics
num = len(obj) # Number of keys
val = obj[key] # Access by key
if key in obj: ... # Test key presence
for key in obj: ... # Implicit iterator (keys)
itr = iter(obj) # Named iterator (keys)
obj[key] = val # Replace by key
obj[key] = val # Insert by key
del obj[key] # Delete by key
com::sun::star::container::XEnumerationAccess
- Objects provide Python iterable semantics
for val in obj: ... # Implicit iterator
itr = iter(obj) # Named iterator
com::sun::star::container::XEnumeration
- Objects provide Python iterator semantics
for val in itr: ... # Iteration of named iterator
if val in itr: ... # Test value presence
Objects which implement both XIndex* and XName* are supported, and
respond to both integer and string keys. However, iterating over
such an object will return the keys (like a Python dict) rather than
the values (like a Python list).
2. Cell ranges
==============
A custom behaviour is applied to objects which implement
com::sun::star::table::XCellRange to allow their cells and cell
ranges to be addressed by subscript, in the style of a Python list
or dict (read-only). This is applicable to Calc spreadsheet sheets,
Writer text tables and cell ranges created upon these.
cell = cellrange[0,0] # Access cell by indices
rng = cellrange[0,1:2] # Access cell range by index,slice
rng = cellrange[1:2,0] # Access cell range by slice,index
rng = cellrange[0:1,2:3] # Access cell range by slices
rng = cellrange['A1:B2'] # Access cell range by descriptor
rng = cellrange['Name'] # Access cell range by name
Note that the indices used are in Python/C order, and differ from
the arguments to methods provided by XCellRange.
- The statement cellrange[r,c], which returns the cell from row r
and column c, is equivalent to calling
XCellRange::getCellByPosition(c,r)
- The statement cellrange[t:b,l:r], which returns a cell range
covering rows t to b(non-inclusive) and columns l to r(non-
inclusive), is equivalent to calling
XCellRange::getCellRangeByPosition(l,t,r-1,b-1).
In contrast to the handling of objects implementing XIndex*,
extended slice syntax is not supported. Negative indices (from-end
addresses) are supported only for objects which also implement
com::sun::star::table::XColumnRowRange (currently Calc spreadsheet
sheets and cell ranges created upon these). For such objects, the
following syntax is also available:
rng = cellrange[0] # Access cell range by row index
rng = cellrange[0,:] # Access cell range by row index
rng = cellrange[:,0] # Access cell range by column index
3. Elimination of explicit Any
==============================
PyUNO has not previously been able to cope with certain method
arguments which are typed as Any but require a sequence of specific
type to be passed. This is a particular issue for container
interfaces such as XIndexContainer and XNameContainer.
The existing solution to dealing with such methods is to use a
special method to pass an explicitly typed Any, giving code such as:
index = doc.createInstance("com.sun.star.text.ContentIndex");
...
uno.invoke( index.LevelParagraphStyles , "replaceByIndex",
(0, uno.Any("[]string", ('Caption',))) )
The new Pythonic container access is able to correctly infer the
expected type of the sequences required by these arguments. In the
new style, the above call to .replaceByIndex() can instead be
written:
index.LevelParagraphStyles[0] = ('Caption',)
4. List and iterator arguments
==============================
Wherever a UNO API expects a sequence, a Python list or iterator can
now be passed. This enables the use of list comprehensions and
generator expressions for method calls and property assignments.
Example:
tbl = doc.createInstance('com.sun.star.text.TextTable')
tbl.initialize(10,10)
# ... insert table ...
# Assign numbers 0..99 to the cells using a generator expression
tbl.Data = ((y for y in range(10*x,10*x + 10)) for x in range(10))
5. Tolerant struct initialisation
=================================
Previously, a UNO struct could be created fully uninitialised, or by
passing a combination of positional and/or named arguments to its
constructor. However, if any arguments were passed, all members were
required to be initialised or an exception was thrown.
This requirement is relaxed such that when all arguments passed to a
struct constructor are by name, some may be omitted. The existing
requirement that all members must be explicitly initialised when
some constructor arguments are unnamed (positional) is not affected.
Example:
from com.sun.star.beans import PropertyValue
prop = PropertyValue(Name='foo', Value='bar')
Change-Id: Id29bff10a18099b1a00af1abee1a6c1bc58b3978
Reviewed-on: https://gerrit.libreoffice.org/16272
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Matthew Francis <mjay.francis@gmail.com>
|
|
Change-Id: Ifa9d12fa190f929807dc0dc7342e162aeb9a0576
|
|
Change-Id: I9f6a50f00bd98aeffa46f3ef40211e30edf658d6
|
|
This reverts commit 89f6ff4c296de5e61d5bfb0cfef55e482839e227.
|
|
revert 6980da37549d9ae0a89812aeccfa5365c9f7a9b9 for the moment
Change-Id: I1c6e6d74bee6d3008e32c48c0da4a7faf90c8f60
|
|
Change-Id: I23ada017f4294fbd34e9b245d012700021914881
|
|
Change-Id: Ib256217aa014693c73b233a4d8be4c0224287739
|
|
Change-Id: I28884169cb633d2aa9ad11d4b31ab9424776b0f1
|
|
Change-Id: Ib85724173c0bf6d45776d5407220a415da9c591b
|
|
Change-Id: Ic18917ce16b27b35347c19d6b9fa5889dc00f2d5
|
|
Change-Id: Ia2dad214e6a224c979a8664bfded7d2caffb221a
|
|
Change-Id: I653cb0e36c1faa622ecc90e0316a1f1fd1e843db
|
|
The bug in question crashed LibO when inserting a group of cells.
This bug was quashed, per se, by commit
07e2c31831ad265b018e5fdf59bdde048fbb4d35, but it occurs to me that at
least the particular functionality of inserting a group of cells could
use more testing.
Change-Id: Icdbfff86fb0265eef325bcc94d9fc9f3e9e38413
|
|
* see the mail thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2014-February/059548.html>
"Testing/Working on PyUNO?" for a rationale
* run the tests via top-level "make PythonTest_pytests" or "cd pyuno && make -rs
PythonTest_pytests" or similar
* see the documentation in pyuno/PythonTest_pytests.mk for adding tests to the
framework
Change-Id: I6a2a9e60b3294cd649f9cccbaffbd3f6bd79ecff
|
|
Change-Id: I8932febdd39c35f23fb3a89703b69e25302f5678
|
|
Change-Id: I98b6263a464b46075e69e363c3eb9e4ec4557c46
|
|
Change-Id: Ic7515acd14916cc36b59749059ed623cda906c23
|
|
...this e.g. changes the error message when trying to register an extension that
contains an (actively registered) Python component but no pyuno is installed
from "Binary URP bridge disposed during call" to a less frightening "The service
com.sun.star.loader.Python cannot be instantiated."
Change-Id: I10f2b36b11395559ee95ce659878222b5ea99c11
|
|
Change-Id: I62fa315b942c5b2383ee83c644ecbcbca3d6c40f
|
|
|
|
- python3: deliver files to INSTDIR, with same layout as instset
and do not deliver .lib files
- pyuno: remove obsolete python.bin targets
- pyuno: remove usage of CustomTarget_zip for WNT and non-Mac UNX
platforms (sadly it is apparently still needed for "system" python on
MinGW)
- scp2: use the python3 filelist
There is still a problem here because the installer does not currently
allow to preserve the executable bit on files in a filelist
- RepositoryExternal: run python executable from INSTDIR
and link against libraries in UnpackedTarball dir
Change-Id: I931ca0a8be6ff40051b1ca50da1f0770e6057832
Reviewed-on: https://gerrit.libreoffice.org/3525
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
|
|
I am constantly amazed at the creativity of the original makefile
writers. An extra header file, processed by sed, rather then adding one
item to CDEFS? Really?
Change-Id: I41ae8b10fc447ea5ab91e767c8afb87e39b9b5f5
|
|
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
|
|
Change-Id: I3ee442ab6dac31eb7daac32e7a9ed5c6526f07ba
|
|
Change-Id: Ib46248d217b0161dc20dde0274842bd7381f0cda
|
|
Change-Id: I886f4a6aec492ae498ce86d71686c8d9fb26203d
|
|
Change-Id: I13d543f9f877f65f377ae914f8308876bf2c0532
|
|
Change-Id: I7f923a5622214f7540a789bcdd93bf6fd1d166db
|