Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2024-01-19T12:32:10ZSaxonica Developer Community
Planio SaxonC - Bug #6325 (New): saxonche.PySaxonApiError: Null found in Java string conversation. Line ...https://saxonica.plan.io/issues/63252024-01-19T12:32:10ZO'Neil Delprattoneil@saxonica.com
<p>Reported by user via email.</p>
<p>The user is migrating from saxonpy to saxonche.</p>
<p>Error reported:</p>
<pre><code>saxonche.PySaxonApiError: Null found in Java string conversation. Line number: -1
</code></pre>
<p>You can find the Git repository with the relevant files and code here:</p>
<p><a href="https://github.com/sirisha09-till/xml2dita/tree/main/xml2dita" class="external">https://github.com/sirisha09-till/xml2dita/tree/main/xml2dita</a></p> SaxonC - Bug #6299 (New): Add a Makefile to the release for building of the SaxonC C/C++ API libraryhttps://saxonica.plan.io/issues/62992023-12-20T13:02:23ZO'Neil Delprattoneil@saxonica.com
<p>Reported by user here <a href="https://stackoverflow.com/questions/77684816/undefined-reference-error-when-link-to-saxon-library-in-c/77690492#77690492" class="external">https://stackoverflow.com/questions/77684816/undefined-reference-error-when-link-to-saxon-library-in-c/77690492#77690492</a></p>
<p>The SaxonC release should contain a MakeFile to build the C/C++ library. This is something we attempted to do long time ago, but for some reason we proceed with its use. Since we are now using Graalvm we should use a Makefile.</p> SaxonC - Bug #6297 (New): 12.4.1 command build errors on CentOS 7https://saxonica.plan.io/issues/62972023-12-19T11:50:46ZTony Graham
<p>Running <code>build-saxonc-commands.sh</code> on CentOS 7 generated errors about the C version, such as:</p>
<pre><code>Transform.c: In function ‘transform’:
Transform.c:33:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 1; i < argc; i++) {
^
Transform.c:33:3: note: use option -std=c99 or -std=gnu99 to compile your code
</code></pre>
<p>After adding <code>-std=c99</code> to the GCC command lines, there were errors about <code>int64_t</code>, such as:</p>
<pre><code>In file included from ../Saxon.C.API/SaxonCGlue.c:1:0:
../Saxon.C.API/SaxonCGlue.h:92:3: error: unknown type name ‘int64_t’
int64_t value; /*!< Internal use only. The value of the parameter points
^
</code></pre>
<p>That was worked around by adding <code>#include <stdint.h></code> for <code>__LINUX__</code> and <code>__APPLE__</code> in <code>SaxonCGlue.h</code>. I don't know whether <code>#include <stdint.h></code> would be necessary for <code>__APPLE__</code>.</p>
<p>Also, it's not clear why <code>#include <stdio.h></code> is included a second time for <code>__LINUX__</code> and <code>__APPLE__</code>.</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- build-saxonc-commands.sh~ 2023-12-01 12:17:46.000000000 +0000
</span><span class="gi">+++ build-saxonc-commands.sh 2023-12-19 08:52:51.329869064 +0000
</span><span class="p">@@ -4,15 +4,15 @@</span>
parent_path=$( cd "$(dirname "$0")" ; pwd -P )
library_dir=${1-$(pwd -P)}/../libs/nix
#cd "$parent_path"
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm -c ../Saxon.C.API/SaxonCGlue.c -o SaxonCGlue.o $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm -c ../Saxon.C.API/SaxonCGlue.c -o SaxonCGlue.o $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Transform.c -o transform -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Transform.c -o transform -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Query.c -o query -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Query.c -o query -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Gizmo.c -o gizmo -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Gizmo.c -o gizmo -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
if [ -f Validate.c ]; then
<span class="gd">- gcc -m64 -fPIC -I../Saxon.C.API/graalvm Validate.c -o validate -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+ gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Validate.c -o validate -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span> fi
</code></pre>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- SaxonCGlue.h~ 2023-12-01 12:17:48.000000000 +0000
</span><span class="gi">+++ SaxonCGlue.h 2023-12-19 09:00:42.996931099 +0000
</span><span class="p">@@ -17,6 +17,7 @@</span>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
<span class="gi">+#include <stdint.h>
</span> #else
#include <stdint.h>
#include <windows.h>
</code></pre> SaxonC - Bug #6291 (New): Warnings for invalid keywords from transform_to_string methods on PyXsl...https://saxonica.plan.io/issues/62912023-12-15T15:06:24ZDebbie Lockettdebbie@saxonica.com
<p>The documentation for the <code>PyXslt30Processor</code> <code>transform_to_string</code> method says that the keywords <code>source_file</code> and <code>stylesheet_file</code> are required. The method currently raises a warning only when <code>len(kwds) == 0</code>. It would be better to raise a warning precisely when <code>source_file</code> and <code>stylesheet_file</code> are not both supplied.</p>
<p>Meanwhile for <code>transform_to_string</code> on <code>PyXsltExecutable</code>, there is some other confusion about supplied keywords. Here only one of <code>source_file</code> or <code>xdm_node</code> can be supplied, and a warning is raised if both are (I committed a change here yesterday to check for precisely both of these keywords, rather than <code>len(kwds) > 0</code>). (Note that it is OK to supply neither.) The other possible keywords are <code>base_output_uri</code> and <code>encoding</code>. It looks like you'll currently get a (unhelpfully worded) warning if you try to supply only <code>encoding</code> - but that should be permitted.</p> SaxonC - Feature #6290 (New): Python exceptionshttps://saxonica.plan.io/issues/62902023-12-15T13:30:42ZDebbie Lockettdebbie@saxonica.com
<p>A number of python API methods raise Exceptions. For instance methods which have a <code>**kwds</code> argument may raise an error when invalid keywords, or invalid keyword combinations, are used.</p>
<p>Raising this issue to review whether these should be <code>PySaxonApiError</code> rather than <code>Exception</code>.</p> SaxonC - Feature #6287 (New): User extension function for the C++, PHP and Python APIshttps://saxonica.plan.io/issues/62872023-12-15T10:09:44ZO'Neil Delprattoneil@saxonica.com
<p>SaxonC 12 currently does not support user extension functions written in the languages C++, PHP and Python.</p>
<p>We used to support this feature in SaxonC 11, but since we have moved from using Excelsior Jet to Graalvm as the underlying JVM engine it is no longer straightforward to reuse the JNI mechanism to do the callbacks for the extension functions.</p>
<p>Following a user request on stackoverflow (i.e. <a href="https://stackoverflow.com/questions/77641333/use-external-user-python-functions-in-a-xml-or-xslt-by-using-saxonc-12-4-for-pyt" class="external">https://stackoverflow.com/questions/77641333/use-external-user-python-functions-in-a-xml-or-xslt-by-using-saxonc-12-4-for-pyt</a>), I am adding this issue as a feature request for SaxonC 12.</p>
<p>On the Graalvm slack I have been advised that we can call C/C++ method from Java code in native using CFunction.</p>
<p>Also to consider that "C++ method is hard, you need a C proxy that calls desired method".</p> SaxonC - Bug #6276 (New): https://pypi.org/project/saxonche/ claims current print(proc.version) g...https://saxonica.plan.io/issues/62762023-12-02T10:58:42ZMartin Honnenmartin.honnen@gmx.de
<p>I am not sure this is a build problem/quirk or a documentation problem/quirk but <a href="https://pypi.org/project/saxonche/" class="external">https://pypi.org/project/saxonche/</a> claims current <code>print(proc.version)</code> would give <code>SaxonC-HE 12.4.1 from Saxonica</code> while even with 12.4.1 the output remains at <code>SaxonC-HE 12.4 from Saxonica</code>.</p>
<p>But the inconsistency between the documentation of the wheel on PyPi and its version number and the actual result might be confusing.</p> SaxonC - Bug #6120 (New): Unclear installation instruction for linking SaxonC library in C++https://saxonica.plan.io/issues/61202023-07-07T09:25:40ZO'Neil Delprattoneil@saxonica.com
<p>If a users want to compile a program that links against SaxonC the documentation does not make it clear enough how to do this. It should make it clear that either add the library to LIBRARY_PATH, or use -L to point
directly to the library.</p>
<p>At runtime, if the dynamic library has not been installed in “a standard
place”, the location needs to be set on the LD_LIBRARY_PATH.</p> SaxonC - Bug #6000 (New): net.sf.saxon.trans.LicenseException: Failed to read license file /usr/l...https://saxonica.plan.io/issues/60002023-04-27T13:16:44ZO'Neil Delprattoneil@saxonica.com
<p>Given the follow python script:</p>
<pre><code class="python syntaxhl" data-language="python"><span class="n">proc</span> <span class="o">=</span> <span class="n">PySaxonProcessor</span><span class="p">(</span><span class="n">license</span><span class="o">=</span><span class="bp">True</span><span class="p">)</span>
<span class="n">proc</span><span class="p">.</span><span class="n">set_configuration_property</span><span class="p">(</span><span class="s">"http://saxon.sf.net/feature/licenseFileLocation"</span><span class="p">,</span> <span class="s">"/usr/lib/saxon-license.lic"</span><span class="p">)</span>
<span class="n">xsltproc</span> <span class="o">=</span> <span class="n">proc</span><span class="p">.</span><span class="n">new_xslt30_processor</span><span class="p">()</span>
</code></pre>
<p>If the license file is not fould using the @set_configuration property@ it will crash as follows:</p>
<pre><code>net.sf.saxon.trans.LicenseException: Failed to read license file /usr/lib/saxon-license.lic
at com.saxonica.config.Verifier.loadLicense(Verifier.java:130)
at com.saxonica.config.ProfessionalConfiguration.setConfigurationProperty(ProfessionalConfiguration.java:230)
at net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:402)
at net.sf.saxon.option.cpp.SaxonCAPI.applyToConfiguration(SaxonCAPI.java:569)
</code></pre>
<p>The problem is the @applyToConfiguration@ method in the class SaxonCAPI does not have graalvm exception handling annotation. We also need to add code in the C++ API to thrown the exception as a @SaxonApiException@</p> SaxonC - Bug #5871 (New): Correct pylint warningshttps://saxonica.plan.io/issues/58712023-02-05T08:06:14ZNorm Tovey-Walsh
<p>If you run <code>pylint</code> against a script that uses our wheels, you'll get warnings like this:</p>
<pre><code>module.py:7:0: E0611: No name 'PySaxonProcessor' in module 'saxonche' (no-name-in-module)
</code></pre>
<p>These warnings also appear in IDEs that do linting and I presume the lack of declarations "in the module" means that IDEs have no way to offer completions.</p>
<p>I assume this could be fixed by putting something in, probably, a <code>__init__.py</code> file, but I don't know what.</p> SaxonC - Bug #5860 (New): Self built python extension failure to link libraryhttps://saxonica.plan.io/issues/58602023-01-26T18:03:31ZO'Neil Delprattoneil@saxonica.com
<p>Reported by userL <a href="https://saxonica.plan.io/boards/4/topics/9261" class="external">https://saxonica.plan.io/boards/4/topics/9261</a></p>
<p>There is a problem to self build the python library from the pypi directory.</p>
<p>Currently if we build the wheel with the command:</p>
<pre><code>python3 setup.py bdist_wheel
</code></pre>
<p>or building the extension locallly:</p>
<pre><code>python3 setup.py build_ext -if
</code></pre>
<p>It builds successfully (although user reported that they had to make changes in the setup file to locate the library).
When we run a sample python script we get the following error:</p>
<pre><code>Traceback (most recent call last):
File "/Users/ond1/work/saxondev/build/temp/libsaxon-EEC-mac-x86_64-v12.0/pypi/samples/saxon_example.py", line 1, in <module>
import saxoncee
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/saxoncee.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace (_addProcessorDataPair)
</code></pre> SaxonC - Feature #5833 (New): Add the Path class as argument to method PyQueryProcessor.set_query...https://saxonica.plan.io/issues/58332023-01-18T17:48:12ZO'Neil Delprattoneil@saxonica.com
<p>Following on from the stackoverflow issue: <a href="https://stackoverflow.com/questions/75142854/how-to-use-the-collection-function-with-saxonche/75162395#75162395" class="external">https://stackoverflow.com/questions/75142854/how-to-use-the-collection-function-with-saxonche/75162395#75162395</a></p>
<p>It would be good to add the Path class object (<a href="https://docs.python.org/3/library/pathlib.html" class="external">https://docs.python.org/3/library/pathlib.html</a>) as an argument on the PyQueryProcessor.set_query_base_uri() method. Currently this method only access the URI as a string.</p> SaxonC - Bug #5821 (New): Feature request: allow xml_file for parse_xml, etc.https://saxonica.plan.io/issues/58212023-01-16T10:05:03ZNorm Tovey-Walsh
<p>The <code>click</code> Python library allows me to declare that the input parameter or argument is an existing file. When I do, what I get as an argument is the opened file. It would be nice to be able to pass that directly to <code>parse_xml</code>, etc.</p> SaxonC - Feature #5638 (New): Support extension functions in Pythonhttps://saxonica.plan.io/issues/56382022-08-08T08:42:54ZPeter Jan
<p>Hi!</p>
<p>As written on <a href="https://www.saxonica.com/saxon-c/documentation11/index.html#!extensibility" class="external">https://www.saxonica.com/saxon-c/documentation11/index.html#!extensibility</a>:
"It is not currently possible to write extension functions in Python."</p>
<p>I would very much like to register custom functions in Python, as can be done with PHP already. I would prefer to use the PHP language, however I'm on PHP 8.1 which is not supported (yet).</p> SaxonC - Bug #5621 (New): C++ build-windows.bat gives warning "SaxonProcessor.obj : warning LNK40...https://saxonica.plan.io/issues/56212022-07-28T18:13:26ZMartin Honnenmartin.honnen@gmx.de
<p>The build bat file for Windows HEC 11.4 still needs some improvement, for all samples it outputs a warning</p>
<blockquote>
<p>C++ build-windows.bat gives warning "SaxonProcessor.obj : warning LNK4042: object specified more than once; extras ignored</p>
</blockquote>
<p>so somewhere SaxonProcessor.c is duplicated in the commands.</p>