[jira] [Resolved] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-70.

Resolution: Fixed

fixed in rev 1916468.

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827781#comment-17827781
 ] 

Andi Vajda commented on PYLUCENE-70:


Hi Petrus, thank you for the bug report and patch.
Please, test the attached jcc_python.patch file that handles more than just 
package_dir and switches to using r"strings" where \ chars are not a problem.
I don't have access to Windows, your help in verifying this patch is 
appreciated !

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda updated PYLUCENE-70:
---
Attachment: jcc_python.patch

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-65) Support the default java on debian in `setup.py`.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815420#comment-17815420
 ] 

Andi Vajda commented on PYLUCENE-65:


on my rather old debian install and also on ubuntu 22.04, I get these packages 
when I search for default-java

apt search default-java
Sorting... Done
Full Text Search... Done
libplexus-container-default-java/jammy 2.1.0-1 all
  Plexus Inversion-of-control Container

libplexus-container-default1.5-java/jammy 2.1.0-1 all
  Plexus Inversion-of-control Container (transitional package)

which java are you referring to ?
Does the fix you propose apply only to Debian and its derivatives ?

> Support the default java on debian in `setup.py`.
> -
>
> Key: PYLUCENE-65
> URL: https://issues.apache.org/jira/browse/PYLUCENE-65
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: A. Coady
>Priority: Major
>
> On debian, the `default-java` package does not have `jre/lib/amd64` in its 
> path, so it breaks the `linux/x86_64` build. The `temurin` flags have the 
> correct paths, so one easy fix would be to change the [temurin 
> check|https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/setup.py?revision=1900087=markup#l194]
>  to:
> {code:python}
>     if 'temurin' in JDK['linux'] or 'default' in JDK['linux']:
> {code}
> That would also support `linux/aarch64` without any further changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815416#comment-17815416
 ] 

Andi Vajda commented on PYLUCENE-69:


Try with the latest but I doubt you'll be able to build a wheel that includes 
the JVM.

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-68.

Resolution: Fixed

Fixed in HEAD.

> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815414#comment-17815414
 ] 

Andi Vajda edited comment on PYLUCENE-68 at 2/7/24 7:51 PM:


I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force

  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force



was (Author: vajda):
I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force
  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force


> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 

[jira] [Commented] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815414#comment-17815414
 ] 

Andi Vajda commented on PYLUCENE-68:


I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force
  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force


> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-31) JCC Parallel/Multiprocess Compilation + Caching

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-31.
--
Resolution: Fixed

distutils is on its way out with Python 3.12

> JCC Parallel/Multiprocess Compilation + Caching
> ---
>
> Key: PYLUCENE-31
> URL: https://issues.apache.org/jira/browse/PYLUCENE-31
> Project: PyLucene
>  Issue Type: Improvement
> Environment: Linux 3.11.0-19-generic #33-Ubuntu SMP x86_64 GNU/Linux
>Reporter: Lee Skillen
>Priority: Minor
>  Labels: build, cache, ccache, distutils, jcc, parallel
> Attachments: feature-parallel-build.patch
>
>
> JCC utilises distutils.Extension() in order to build JCC itself and the 
> packages that it generates for Java wrapping - Unfortunately distutils 
> performs its build sequentially and doesn't take advantage of any additional 
> free cores for parallel building.  As discussed on the list this is likely a 
> design decision due to potential issues that may arise when building projects 
> with awkward, cyclic or recursive dependencies.
> These issues shouldn't appear within JCC-based projects because of the 
> generative nature of the build; i.e. all dependencies are resolved and 
> generated prior to building, and the build process itself is about 
> compilation and construction of the wrapper alone, of which the wrapper files 
> are contained to a sequence of flattened compilation units.
> Enabling this requires monkey patching of distutils, which was also discussed 
> on the list as being a potential source of issues, although we feel that the 
> risk is likely lower than the current setuptools patching utilised.  This 
> would be optional functionality that is also only enabled if the 
> monkey-patching succeeds.  Distutils itself is also part of the standard 
> library and might be less susceptible to change than setuptools, and the area 
> of code monkey patched almost hasn't changed since 2002 (see: 
> http://hg.python.org/cpython/file/tip/Lib/distutils/ccompiler.py).
> In addition to the distutils changes this patch also includes changes to the 
> wrapper class generation to make it more cache friendly, with the target 
> being that no changes in the wrapped code equals no changes in the wrapper 
> code.  So any changes that minimally change the wrapped code mean that with a 
> tool such as ccache the rebuild time would be significantly reduced (almost 
> to a nth, where n is the number of files and only one has changed).
> Obviously the maintainers would have to assess this risk and decide whether 
> they would like to accept the patch or not.  Code has only been tested on 
> Linux with Python 2.7.5 but should gracefully fail and prevent 
> parallelisation if one of the requirements hasn't been met (not on linux, no 
> multiprocessing support, or monkey patching somehow fails).  The change to 
> caching should still benefit everyone regardless.
> Please note that an additional dependency on orderedset has been added to 
> achieve the more deterministic ordering - This may not be desirable (i.e. 
> another package might be desired, such as ordered-set, or the code might be 
> inlined into the package instead), as per maintainer comments.
> --- [following repeated from mailing list] ---
> Performance Statistics :-
> The following are some quick and dirty statistics for building the jcc 
> pylucene itself (incl. java lucene which accounts for about 30-ish seconds 
> upfront) - The JCC files are split using --files 8, and each build is 
> preceded with a make clean:
> Serial (unpatched):
> real5m1.502s
> user5m22.887s
> sys 0m7.749s
> Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs):
> real1m37.382s
> user7m16.658s
> sys 0m8.697s
> Furthermore, some additional changes were made to the wrapped file generation 
> to make the generated code more ccache friendly (additional deterministic 
> sorting for methods and some usage of an ordered set).  With these in place 
> and the CC and CCACHE_COMPILERCHECK environment variables set to "ccache gcc" 
> and "content" respectively, and ensuring ccache is installed, subsequent 
> compilation time is reduced again as follows:
> Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs, ccache 
> enabled):
> real0m43.051s
> user1m10.392s
> sys 0m4.547s
> This was a run in which nothing changed between runs, so a realistic run in 
> which changes occur it'll be a figure between 0m43.051s and 1m37.382s, 
> depending on how drastic the change was. If many changes are expected and you 
> want to keep it more cache friendly then using a higher --files would 
> probably work (to an extent), or ideally use --files separate, although it 
> doesn't currently work for me (need to investigate).
> We're mostly 

[jira] [Closed] (PYLUCENE-8) lucene.JCC_VERSION isn't set properly on Windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-8.
-
Resolution: Fixed

> lucene.JCC_VERSION isn't set properly on Windows
> 
>
> Key: PYLUCENE-8
> URL: https://issues.apache.org/jira/browse/PYLUCENE-8
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows XP, MinGW gcc 4.5, Python 2.6.6, PyLucene 3.0.2
>Reporter: Bill Janssen
>Priority: Minor
>
> After installing 3.0.2 on Win XP with MinGW/msys, I see the following:
> Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import lucene
> >>> lucene.initVM(classpath=lucene.CLASSPATH)
> 
> >>> lucene.JCC_VERSION
> 'JCC_VER'
> >>> quit()



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-18) Version 3.6.0 lacks readme

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-18.
--
Resolution: Fixed

> Version 3.6.0 lacks readme
> --
>
> Key: PYLUCENE-18
> URL: https://issues.apache.org/jira/browse/PYLUCENE-18
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Dion Gillard
>Priority: Minor
>
> Hi,
> It looks like pylucene version 3.6.0 lacks CHANGES in tarball. Also README 
> has followed content:
> {code}
>   Please see doc/documentation/readme.html
> {code}
> At the same there is no docs directory in tarball at all.
> These files are important for linux distributions (like Debian) where they 
> are usually installed to /usr/share/doc



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-64) ModuleNotFoundError: No module named 'lucene' when intalling PyLucene

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-64.
--
Resolution: Fixed

seems to work fine

> ModuleNotFoundError: No module named 'lucene' when intalling PyLucene
> -
>
> Key: PYLUCENE-64
> URL: https://issues.apache.org/jira/browse/PYLUCENE-64
> Project: PyLucene
>  Issue Type: Bug
>Reporter: anis amirouche
>Priority: Major
>
> I'm trying to install Pylucene 8.11.0 on mac os. the jcc is built and 
> installed successfully, but from pylucene folder when running make test i'm 
> encountering the following error : ModuleNotFoundError: No module named 
> 'lucene', please note the make command is successfull.
> please can anyone help me with solving this error. I don't even understand 
> what i'm doing wrong, it's like lucene is not installed, and i'm having this 
> error with all the files of pylucene. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-56) Can't build JCC on Mac

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-56.
--
Resolution: Fixed

building JCC on M2 mac works fine

> Can't build JCC on Mac
> --
>
> Key: PYLUCENE-56
> URL: https://issues.apache.org/jira/browse/PYLUCENE-56
> Project: PyLucene
>  Issue Type: Bug
> Environment: MacOSX 10.15.7, Intel Core i7, Python 3.8.2, gcc 
> (Homebrew GCC 10.2.0_3) 10.2.0
> following the instructions here:
> http://lucene.apache.org/pylucene/jcc/install.html
> svn co https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc jcc
> Checked out revision 1886645.
>Reporter: Clem Wang
>Priority: Major
>  Labels: build
>
> This is puzzling to me, as I can't figure out how the failing gcc command 
> line gets its arguments (mostly).  I found one problem in the setup.py, but I 
> can't find the error causing strings anywhere in the files in the jcc 
> directory of sub directory.
>  
> Steps:
>  
> {code:java}
> svn co https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc jcc
> Checked out revision 1886645.
> cd jcc
> python setup.py build
>  
> {code}
> ...
> /opt/local/bin/gcc -Wno-unused-result -Wsign-compare -Wunreachable-code 
> -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall 
> {color:#ff}*-iwithsysroot/*{color}System/Library/Frameworks/System.framework/PrivateHeaders
>  
> {color:#ff}*-iwithsysroot/*{color}Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers
>  {color:#ff}*-arch arm64*{color} -arch x86_64 
> -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp -dynamiclib 
> -D_jcc_lib -DJCC_VER="3.8" 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include/darwin
>  -I_jcc3 -Ijcc3/sources -I/Users/cwang/3.7/include 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8
>  -c jcc3/sources/jcc.cpp -o 
> build/temp.macosx-10.14.6-x86_64-3.8/jcc3/sources/jcc.o -DPYTHON 
> -fno-strict-aliasing -Wno-write-strings -mmacosx-version-min=10.9 -std=c++11  
> {color:#ff}*-stdlib=libc++*{color}
>  
> which generates 4 errors due to the parts marked above in red bold:
>  
> *gcc:* *error:* this compiler does not support arm64
> *gcc:* *error:* unrecognized command-line option 
> '*-iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders*'
> *gcc:* *error:* unrecognized command-line option 
> '*-iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers*'
> *gcc:* *error:* unrecognized command-line option '*-stdlib=libc++*'
> error: command '/opt/local/bin/gcc' failed with exit status 1
>  
> Obviously, the contradictory 
> *-arch arm64*
> needs to be removed but I can't find arm64 anywhere.
>  
> The unnecessary
> *-stdlib=libc++*
>  
> can be removed from setup.py:
> {code:java}
> CFLAGS = {
>  'darwin': ['-fno-strict-aliasing', '-Wno-write-strings',
>  '-mmacosx-version-min=10.9', '-std=c++11', '-stdlib=libc++'],{code}
>  
> After poking around, I figured out that gcc uses
> {code:java}
> -I {code}
> not
> {code:java}
> -i {code}
> for includes.
>  
> Making these modifications (and adding
> {code:java}
> -Wno-attributes{code}
> to remove warnings)
>  
> I came up with this line that does successfully compile without errors:
> /opt/local/bin/gcc -Wno-attributes -Wno-unused-result -Wsign-compare 
> -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall 
> -I/System/Library/Frameworks/System.framework/PrivateHeaders 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers
>  -arch x86_64 -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp 
> -dynamiclib -D_jcc_lib -DJCC_VER="3.8" 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include/darwin
>  -I_jcc3 -Ijcc3/sources -I/Users/cwang/3.7/include 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8
>  -c jcc3/sources/jcc.cpp -o 
> build/temp.macosx-10.14.6-x86_64-3.8/jcc3/sources/jcc.o -DPYTHON 
> -fno-strict-aliasing -Wno-write-strings -mmacosx-version-min=10.9 -std=c++11
>  
> But other than removing  *'-stdlib=libc++'*  from the setup.py file I have no 
> idea how to modify things to fix the compile errors by the line generated 
> some how by setup.py



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-27) JCC should be able to create sdist archives

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785231#comment-17785231
 ] 

Andi Vajda commented on PYLUCENE-27:


Yes, with the upcoming demise of setuptools/distutils, this issue may get 
resolution.
Instead of invoking setuptools.setup() produce something that pypa/build can 
use as input, some yaml maybe ?

> JCC should be able to create sdist archives
> ---
>
> Key: PYLUCENE-27
> URL: https://issues.apache.org/jira/browse/PYLUCENE-27
> Project: PyLucene
>  Issue Type: Wish
> Environment: jcc-svn-head
>Reporter: Martin Scherer
>Priority: Major
> Attachments: createSetupScript.patch
>
>
> I was not able to create a complete (in terms one is able to compile and 
> install the desired wrapper) source distribution.
> I've tried following calls:
>   python -m jcc --jar foo  --egg-info --extra-setup-arg sdist
> and
>  python -m jcc --jar foo --extra-setup-arg sdist
> Both create archives only containing the egg-info and setup.py but no source 
> code at all.
> I really need this feature for my testing environment with tox, since this 
> heavily depends on the sdist feature.
> thanks,
> best,
> Martin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785230#comment-17785230
 ] 

Andi Vajda edited comment on PYLUCENE-69 at 11/11/23 10:54 PM:
---

JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ you could do this, the wheel would be enormous: the number of Python 
* C++ * Java * OS versions possible makes for a lot of combos. There is a 
reason I don't ever ship binaries, it's just too much (!)


was (Author: vajda):
JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ could do this, the wheel would be enormous: the number of Python * 
C++ * Java * OS versions possible makes for a lot of combos. There is a reason 
I don't ever ship binaries, it's just too much (!)

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785230#comment-17785230
 ] 

Andi Vajda commented on PYLUCENE-69:


JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ could do this, the wheel would be enormous: the number of Python * 
C++ * Java * OS versions possible makes for a lot of combos. There is a reason 
I don't ever ship binaries, it's just too much (!)

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785219#comment-17785219
 ] 

Andi Vajda commented on PYLUCENE-68:


I was afraid of that...
I did try to build jcc with pypa/build and it seems to work just fine:
{code:java}
$ cd jcc
$ python3 -m build
$ python3 -m pip install dist/JCC-3.13-cp312-cp312-macosx_13_0_arm64.whl{code}
worked fine.
Then, I get the warnings you reported when running "jcc ... --install" from 
pylucene's Makefile are due to jcc's calling setuptools.setup() function to 
build the extension it generated.
Do you know of a migration guide from setuptools.setup() to calling similar 
stuff in pypa/build ?

> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-28) JCC reuses JVM instances in impl, if compile() is called twice.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736851#comment-17736851
 ] 

Andi Vajda commented on PYLUCENE-28:


I see 2 things:

  - if a constructor takes no arguments, like 
org.apache.lucene.document.Document(), then anything passed to it is ignored.
  - all constructor wrappers have a kwds parameter but it's ignored.

Both could be fixed at the cost of extra code that raises an error if kwds is 
not empty.
Also, extra code would have to be generated for checking that args is empty for 
contructores not taking any args.
Is it worth it ?

> JCC reuses JVM instances in impl, if compile() is called twice.
> ---
>
> Key: PYLUCENE-28
> URL: https://issues.apache.org/jira/browse/PYLUCENE-28
> Project: PyLucene
>  Issue Type: Improvement
> Environment: jcc-svn-head (2.18-pre)
>Reporter: Martin Scherer
>Priority: Blocker
>  Labels: patch
> Attachments: jvm_instance_check.patch
>
>
> If you import jcc.cpp to call compile yourself (a wrapped setup.py script to 
> generate a wrapper on the fly, which seems to be a common use case), the 
> current version complains about the JVM already being initialized before.
> The patch first checks for a running instance and creates one, if none is 
> being found.
> For myself, this is a blocker, since it raises otherwise.
> Best, 
> Martin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/4/22 7:52 PM:
-

See code for installType() function in this file:
[https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/sources/functions.cpp]

 


was (Author: vajda):
The installType function in jcc/jcc3/sources/functions.cpp is supposed to be

{{
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
}}

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/4/22 7:50 PM:
-

The installType function in jcc/jcc3/sources/functions.cpp is supposed to be

{{
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
}}


was (Author: vajda):
The installType function in jcc/jcc3/sources/functions.cpp is supposed to be
```
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
```



> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda commented on PYLUCENE-66:


The installType function in jcc/jcc3/sources/functions.cpp is supposed to be
```
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
```



> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629183#comment-17629183
 ] 

Andi Vajda commented on PYLUCENE-66:


Use the JCC in the 9.4.1 release candidate or get the diff for rev 1904960.

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626895#comment-17626895
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/1/22 1:12 AM:
-

I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)


was (Author: vajda):
I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626895#comment-17626895
 ] 

Andi Vajda commented on PYLUCENE-66:


I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-66.

Resolution: Fixed

fixed in rev 1904960.

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-64) ModuleNotFoundError: No module named 'lucene' when intalling PyLucene

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545615#comment-17545615
 ] 

Andi Vajda commented on PYLUCENE-64:


I believe there is an issue with running 'make test' in PyLucene 8.x. This is 
hopefully solved in PyLucene 9.1.0, which was released on 4/27/22.
To see if your PyLucene install works, you can try these steps in Python:
  >>> import lucene
  >>> lucene.initVM()
  >>> from org.apache.lucene.document import Document

If you need more help, please include the portion of the PyLucene Makefile you 
edited before you ran 'make' and 'make install'.



> ModuleNotFoundError: No module named 'lucene' when intalling PyLucene
> -
>
> Key: PYLUCENE-64
> URL: https://issues.apache.org/jira/browse/PYLUCENE-64
> Project: PyLucene
>  Issue Type: Bug
>Reporter: anis amirouche
>Priority: Major
>
> I'm trying to install Pylucene 8.11.0 on mac os. the jcc is built and 
> installed successfully, but from pylucene folder when running make test i'm 
> encountering the following error : ModuleNotFoundError: No module named 
> 'lucene', please note the make command is successfull.
> please can anyone help me with solving this error. I don't even understand 
> what i'm doing wrong, it's like lucene is not installed, and i'm having this 
> error with all the files of pylucene. 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529472#comment-17529472
 ] 

Andi Vajda commented on PYLUCENE-63:


The first 'make print-GENERATE' shows that you didn't follow the instructions 
at the top of the Makefile. You must uncomment one of the example groups so 
that PREFIX_PYTHON, PYTHON, JCC and NUM_FILES are set. And they must be set 
correctly for your environment.
You then did this, apparently, and your next print-GENERATE is making more 
sense (!).

The next issue then is that you didn't rebuild JCC (it shows you using version 
3.10 but PyLucene 9.1.0 comes with 3.12) and the earlier JCC build you made was 
built with an incompatible version of Java. Please rebuild JCC so that you are 
using version 3.12.

The last issue is that your java installation's layout (in particular its paths 
to libraries libjava and libjvm) is not covered in JCC's setup.py. This is a 
known issue, there are just so many different layouts that it's difficult to 
guess the correct one. You need to edit jcc's setup.py at line 172,173,174 and 
set the values for the -L flags to match your installation. I suspect that you 
don't need the final amd64 parts in there, ie, change -L%(linux)s/jre/lib/amd64 
into -L%(linux)s/jre/lib, change -L%(linux)s/jre/lib/amd64/server to 
-L%(linux)s/jre/lib/server and 
'-Wl,-rpath=%(linux)s/jre/lib/amd64:%(linux)s/jre/lib/amd64/server to 
'-Wl,-rpath=%(linux)s/jre/lib:%(linux)s/jre/lib/server.

Last but not least, you seem to be using python 2.7. It's still supported by 
PyLucene and JCC but not by the Python people anymore and it is not going to be 
supported by PyLucene and JCC much longer. I strongly recommend you install 
python3. Python 2.7 has been dead and deprecated for years now. If you are just 
getting started with Python now, please start with python 3.

And finally, this entire conversation should be had on the 
pylucene-dev@lucene.apache.org mailing list instead of buried in JIRA. This 
issue is not a bug.

> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> 

[jira] [Commented] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529212#comment-17529212
 ] 

Andi Vajda commented on PYLUCENE-63:


What does 'make print-GENERATE' return for you ?
Also, please include the values you uncommmented in Makefile for:
  PREFIX_PYTHON, PYTHON, JCC, NUM_FILES


> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.pom (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.jar (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]
> [ivy:cachepath] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> BUILD FAILED
>  
>  
> how can i fix this bug?
> i am sure the file ( 
> [https://repo1.maven.o|https://repo1.maven.o/]rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar)
>  is not exist



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-63.

Resolution: Information Provided

I cannot help you with proxy issues and this bug is obsolete by now as Lucene 
is now at version 9.1.0 and is no longer using Ant nor Ivy but switched its 
build to Gradle.
Just 10 minutes ago, I released [PyLucene 
9.1.0|https://lucene.apache.org/pylucene/index.html] which also switched to 
using Gradle for building the Lucene part. If you have issues with building the 
Lucene part of PyLucene with Gradle, please contact the Lucene project at 
java-u...@lucene.apache.org.
Thank you !

> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.pom (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.jar (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]
> [ivy:cachepath] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> BUILD FAILED
>  
>  
> how can i fix this bug?
> i am sure the file ( 
> [https://repo1.maven.o|https://repo1.maven.o/]rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar)
>  is not exist



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-62.

Resolution: Fixed

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523433#comment-17523433
 ] 

Andi Vajda commented on PYLUCENE-62:


Thank you for having verified the changes again.
The 'import jcc' case, as you say, is not very useful but can be made to work 
by calling os.add_dll_directory(jvm_dll_path) manually first. If one is import 
the jcc package this way, they must know what they're up to.
I can't connect the %PREFIX%\lib\site-packages\jcc3\jcc3.lib issue to code in 
jcc other than the extra_link_args being set in python.py around line 1843. I 
don't see, at first glance, where %prefix% would be coming from.
I think this bug can now be marked fixed, please reopen if you think it needs 
more work.
Thank you again for all your work on this !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523248#comment-17523248
 ] 

Andi Vajda commented on PYLUCENE-62:


Thank you for the fixes and explanations. I think I integrated your changes and 
even simplified things a bit more in python.py, now that we're including 
windows.py when --find-jvm-dll is set.
I committed the changes to HEAD. Please, try this out again by setting 
--find-jvm-dll server and let me know if it all works. Thank you !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522433#comment-17522433
 ] 

Andi Vajda commented on PYLUCENE-62:


Does it work as expected if you pass --find-jvm-dll server to your command line 
?

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521968#comment-17521968
 ] 

Andi Vajda commented on PYLUCENE-62:


Hi Petrus, this issue seems to have stalled. 
Is it actually solved by the latest jvm_dll.diff patch attached here ?
I'm preparing to release PyLucene 9.1.0 and it'd be nice to know if it still 
works on Windows !

(thanks)

Andi..

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495042#comment-17495042
 ] 

Andi Vajda commented on PYLUCENE-62:


I'd like which kind of jvm.dll is used to not be random with regards to client 
or server kind. But if you prefer both to be searchable as well, we can add 
support for a "both" --find_jvm_dll value, that searches "client", then 
"server" (or the opposite, but again, not random)The default should remain 
"client" since that is what it's been doing for years. Also, it would be good 
to emit a log statement of some sort that says what jvm.dll (its full path) was 
found and added to the DLL path.
Bullet 2: I can't bet that people wouldn't copy source code around. It's also 
easier to debug if the same code is emitted everywhere, regardless of platform, 
using conditional code as necessary.
The stuff after SHARED is unchanged, your patch didn't touch it, nor did my 
changes. I'm wondering what to do about it, though, as it is also messing with 
PATH. Are you using --shared mode ?
About "it doesn't work": I can't debug this as I don't have access to Windows. 
Here, on mac, the following works fine, of course: python -c "import jcc; 
print(jcc.__file__)". Could you please take the current patch and "make it 
work" or, if you'd like my help with debugging it, tell me more details about 
what doesn't actually work ? In particular, please, add print statements in the 
__init__.py  and windows.py files as to what is going on until it eventually 
fails and send me the output. Thanks !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492230#comment-17492230
 ] 

Andi Vajda commented on PYLUCENE-62:


I also not sure what to about the code in __init__.py, after line 28, in the 
SHARED case ?
Should the eggpath be added via os.add_dll_directory() as well ?
Are you using shared mode ?


> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492229#comment-17492229
 ] 

Andi Vajda commented on PYLUCENE-62:


I took a look at your patch and attached a version that should be less 
intrusive and work, hopefully, too:
  - you do not need to add windows.py to modules, it is already included and 
installed
  - you do need to keep code conditional to windows, you can't assume people 
are not
going to carry code around between machines
  - in windows.py, I renamed get_jvm_dll_directory() to 
get_jvm_dll_directory_from_registry()
   and otherwise kept it unchanged
  - in windows.py, I added get_jvm_dll_directory_from_env() based on your code.
  - in windows.py, I also changed add_jvm_dll_directory_to_path() to do the 
right thing, like
you did
  - I changed the --find-jvm-dll command line flag from a boolean to a string 
that must be one
of "client" or "server" and made it default to "client" for python >= 3.8, 
None otherwise.
Please, try the attached patch out by passing it --find-jvm-dll client (or 
server), I have no access to Windows, so I could not try it out myself. I 
verified that it didn't break on Mac.
Thank you !


> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda updated PYLUCENE-62:
---
Attachment: jvm_dll.diff

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491669#comment-17491669
 ] 

Andi Vajda commented on PYLUCENE-62:


As is, --find-jvm-dll shouldn't solve the issue because it modifies PATH and 
doesn't use the new os.add_dll_directory() function. 
If, on the other hand, you modify windows.py's add_jvm_dll_directory_to_path() 
to call os.add_dll_directory() instead of messing with Path, does 
--find-jvm-dll then solve the problem ? 
I have no access to Windows so I can't test any fix myself.
Currently, windows.py's get_jvm_dll_directory() does not look on JAVA_HOME. I 
think that it's reasonable that it should do so, as well as looking in the 
Windows registry like it does already. Maybe it should look at JAVA_HOME first, 
then continue looking in the registry if nothing is found ? Your JAVA_HOME 
traversal code should be added to get_jvm_dll_directory() so that all this 
logic is in one place.

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491471#comment-17491471
 ] 

Andi Vajda edited comment on PYLUCENE-62 at 2/12/22, 11:34 PM:
---

It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locate this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding another DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).


was (Author: vajda):
It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locale this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding a DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491471#comment-17491471
 ] 

Andi Vajda commented on PYLUCENE-62:


It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locale this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding a DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (PYLUCENE-61) `adoptopenjdk` succeeded by `temurin` on macOS.

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-61.

Resolution: Fixed

Committed revision 1895796.

> `adoptopenjdk` succeeded by `temurin` on macOS.
> ---
>
> Key: PYLUCENE-61
> URL: https://issues.apache.org/jira/browse/PYLUCENE-61
> Project: PyLucene
>  Issue Type: Bug
> Environment: macOS
>Reporter: A. Coady
>Priority: Major
>
> {code:java}
> % brew info adoptopenjdk
> adoptopenjdk: 16.0.1,9
> https://adoptopenjdk.net/
> /usr/local/Caskroom/adoptopenjdk/16.0.1,9 (196.9MB)
> From: 
> https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/adoptopenjdk.rb
> ==> Name
> AdoptOpenJDK Java Development Kit
> ==> Description
> JDK from the Java User Group (JUG)
> ==> Artifacts
> OpenJDK16U-jdk_x64_mac_hotspot_16.0.1_9.pkg (Pkg)
> ==> Caveats
> Temurin is the official successor to this software:
>   brew install --cask temurin
> adoptopenjdk has been officially discontinued upstream.
> It may stop working correctly (or at all) in recent versions of macOS.
> {code}
> The support for `darwin/adoptopenjdk` in `setup.py` is based on checking 
> whether `adoptopenjdk` is in `JAVAHOME`. Under `temurin`, the check defaults 
> to `darwin/home`, breaking the paths for `INCLUDES` and `LFLAGS`.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Closed] (PYLUCENE-60) we are providing the projects for mtech and btech students.

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-60.
--
Resolution: Invalid

This is spam, right ?

> we are providing the projects for mtech and btech students.
> ---
>
> Key: PYLUCENE-60
> URL: https://issues.apache.org/jira/browse/PYLUCENE-60
> Project: PyLucene
>  Issue Type: Blog - New Blog Request
> Environment: python
>Reporter: Nasima Takeoff
>Priority: Trivial
>  Labels: btech, final, mtech, projects, python
> Attachments: Python projects.png
>
>
> h4. Python has been within the top 10 popular programming languages for an 
> extended time because the community of Python programmers has grown tons 
> thanks to its easy syntax and library support. during this article, Takeoff 
> will be able to introduce you to 60 amazing Python projects with ASCII text 
> files solved and explained by experts in [Takeoff 
> Projects|https://takeoffprojects.com/].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (PYLUCENE-59) Python warns about missing __module__, but means that type names have no '.' in them.

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-59.

Resolution: Workaround

> Python warns about missing __module__, but means that type names have no '.' 
> in them.
> -
>
> Key: PYLUCENE-59
> URL: https://issues.apache.org/jira/browse/PYLUCENE-59
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Erik Groeneveld
>Priority: Trivial
>
> When starting JCC, Python emits warnings such as
> {code:java}
> DeprecationWarning: builtin type Object has no __module__ attribute
> {code}
> It does this because, early in de process of creating types, it does not find 
> a '.' in de name of the type. The warning is somewhat misleading. The code 
> from Python is (fragment from typeobject.c): 
> {code:java}
>     /* Set type.__module__ */
>     s = strrchr(spec->name, '.');
>     if (s != NULL) {
>         int err;
>         modname = PyUnicode_FromStringAndSize(
>                 spec->name, (Py_ssize_t)(s - spec->name));
>         if (modname == NULL) {
>             goto fail;
>         }
>         err = _PyDict_SetItemId(type->tp_dict, ___module__, modname);
>         Py_DECREF(modname);
>         if (err != 0)
>             goto fail;
>     } else {
>         if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
>                 "builtin type %.200s has no __module__ attribute",
>                 spec->name))
>             goto fail;
>     }
> {code}
> The name of the types in JCC do not include a package name and hence no dot.
> Python 3.10 still does it like this.
> The __module__ is set correctly later on in the JCC code!
> Maybe you could add a package name (and a dot) to the typename to avoid these 
> warning?
> I am just reporting this for your convenience and maybe it helps others 
> seeing these warnings. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PYLUCENE-59) Python warns about missing __module__, but means that type names have no '.' in them.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383336#comment-17383336
 ] 

Andi Vajda commented on PYLUCENE-59:


I did 'fix' that as much as possible by setting it later as you saw in the
code already. The warning is harmless and a proper fix to workaround what
looks like a kludge in Python is more involved than the problem is worth.


> Python warns about missing __module__, but means that type names have no '.' 
> in them.
> -
>
> Key: PYLUCENE-59
> URL: https://issues.apache.org/jira/browse/PYLUCENE-59
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Erik Groeneveld
>Priority: Trivial
>
> When starting JCC, Python emits warnings such as
> {code:java}
> DeprecationWarning: builtin type Object has no __module__ attribute
> {code}
> It does this because, early in de process of creating types, it does not find 
> a '.' in de name of the type. The warning is somewhat misleading. The code 
> from Python is (fragment from typeobject.c): 
> {code:java}
>     /* Set type.__module__ */
>     s = strrchr(spec->name, '.');
>     if (s != NULL) {
>         int err;
>         modname = PyUnicode_FromStringAndSize(
>                 spec->name, (Py_ssize_t)(s - spec->name));
>         if (modname == NULL) {
>             goto fail;
>         }
>         err = _PyDict_SetItemId(type->tp_dict, ___module__, modname);
>         Py_DECREF(modname);
>         if (err != 0)
>             goto fail;
>     } else {
>         if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
>                 "builtin type %.200s has no __module__ attribute",
>                 spec->name))
>             goto fail;
>     }
> {code}
> The name of the types in JCC do not include a package name and hence no dot.
> Python 3.10 still does it like this.
> The __module__ is set correctly later on in the JCC code!
> Maybe you could add a package name (and a dot) to the typename to avoid these 
> warning?
> I am just reporting this for your convenience and maybe it helps others 
> seeing these warnings. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PYLUCENE-58) SEGV on import lucene

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359016#comment-17359016
 ] 

Andi Vajda commented on PYLUCENE-58:


I did not reproduce the issue you reported but I still fixed a couple of bugs, 
one serious, that I found by running JCC with Python 3.9.5 configured 
--with-pydebug. Namely, the makeType() function was
not INCREF'ing types it returned when they existed already, which caused their 
refcount to drop to 0, not a good thing at all. I hadn't run with dbg python in 
a long time, thank you for pointing me to it.
The fixes are checked into rev 1890581., please try them out and let me know if 
you still see the original issue.
Thanks !

> SEGV on import lucene
> -
>
> Key: PYLUCENE-58
> URL: https://issues.apache.org/jira/browse/PYLUCENE-58
> Project: PyLucene
>  Issue Type: Bug
> Environment: Debian Buster, Python 3.7
>Reporter: Erik Groeneveld
>Priority: Critical
>
> Hi Andy,
> Thanks again for your great work on PyLucene and JCC!
> Recently, after porting everything to python3, we get occasional SEGV's on 
> shutdown. It happens very late, when the garbage collector starts cleaning up.
> Using python3-dbg exposed another problem however. With python3-dbg, "import 
> lucene" already triggers SEGV. Here is the top of the backtrace:
>  
> {code:bash}
> #0  0x0060 in ?? ()
> #1  0x7fe8aee51d6e in unicode_fromformat_write_cstr 
> (writer=writer@entry=0x7ffdc0dcd170, str=, 
> width=width@entry=-1, precision=) at 
> ../Objects/unicodeobject.c:2596
> #2  0x7fe8aee525ec in unicode_fromformat_arg (vargs=0x7ffdc0dcd150, 
> f=, writer=0x7ffdc0dcd170) at ../Objects/unicodeobject.c:2797
> #3  PyUnicode_FromFormatV (format=, vargs=) at 
> ../Objects/unicodeobject.c:2914
> #4  0x7fe8aedca3dd in PyErr_FormatV (exception=, 
> format=0x7fe8aefe2568 "%s:%d: bad argument to internal function", 
> vargs=vargs@entry=0x7ffdc0dcd210) at ../Python/errors.c:835
> #5  0x7fe8aedca4a4 in PyErr_Format (exception=, 
> format=) at ../Python/errors.c:852
> #6  0x7fe8aee89fcd in PyDict_SetItem (op=, key= out>, value=) at ../Objects/dictobject.c:1448
> #7  PyDict_SetItem (op=, key=, value= out>, op=, key=, value=) at 
> ../Objects/dictobject.c:1443
> #8  0x7fe8aee76f4a in module_init_dict (md_dict= 0x7fe8ae9f6060>, name=name@entry=, 
> doc=None, doc@entry=0x0, mod=) at ../Objects/moduleobject.c:72
> #9  0x7fe8aee7da83 in PyModule_NewObject (name=name@entry= remote 0x7fe8ae9f5030>) at ../Objects/moduleobject.c:103
> #10 0x7fe8aee7de2a in PyModule_New (name=name@entry=0x7fe8b32bfa20 
> "lucene._lucene") at ../Objects/moduleobject.c:120
> #11 0x7fe8aee7deec in _PyModule_CreateInitialized (module=0x7fe8b2612080 
> <_lucene_def>, module_api_version=) at 
> ../Objects/moduleobject.c:215
> #12 0x7fe8b1238de7 in PyInit__lucene () from 
> /data/bouwen/van_kras/pylucene-8.6.1/build/test/lucene-8.6.1-py3.7-linux-x86_64.egg/lucene/_lucene.cpython-37m-x86_64-linux-gnu.so
> {code}
> It could be that this goes undetected with normal python, yet causes an SEGV 
> on shutdown.
>  
> The error above can be reproduced with the following script that downloads 
> the sources, builds JCC and PyLucene and the executes: python3-dbg -c "import 
> lucene"
>  
> {code:bash}
> # Environment
> # debian buster
> # ant 1.10.5-2
> export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
> export PYTHON=/usr/bin/python3
> export PYLUCENE="pylucene-8.6.1"
> rm ${PYLUCENE}-src.tar.gz ${PYLUCENE} -rf
> wget 
> https://ftp.nluug.nl/internet/apache/lucene/pylucene/${PYLUCENE}-src.tar.gz
> tar xzf ${PYLUCENE}-src.tar.gz
> (cd ${PYLUCENE}
> (cd jcc
> export JCC_JDK=${JAVA_HOME}
> export 
> JCC_INCLUDES=/usr/include/python3.7m:${JAVA_HOME}/include:${JAVA_HOME}/include/linux
> ${PYTHON} setup.py build
> )
> export NUM_FILES=10
> export ANT=/usr/bin/ant
> export JCC="${PYTHON} -m jcc --shared"
> make
> make test
> )
> PYTHONPATH='pylucene-8.6.1/build/test/lucene-8.6.1-py3.7-linux-x86_64.egg'
> ${PYTHON}-dbg -c "import lucene"
> {code}
> Would you be as kind as to look into this? Perhaps our problem is solved, or 
> it enables us to find an other problem at shutdown.
> Best regards,
> Erik



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PYLUCENE-50) StoredField of an int has the wrong type.

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866175#comment-16866175
 ] 

Andi Vajda commented on PYLUCENE-50:


Thank you, Aric, for you reporting this.

Andi..


?? {{field = document.StoredField('', 0)}}


> StoredField of an int has the wrong type.
> -
>
> Key: PYLUCENE-50
> URL: https://issues.apache.org/jira/browse/PYLUCENE-50
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3 official docker container, 8.1.1rc
>Reporter: A. Coady
>Priority: Critical
>
> The StoredField constructor is interpreting ints as bytes.  It's only 
> reproducing on the 8 rc.
> {{import lucene}}
>  {{lucene.initVM()}}
>  {{from org.apache.lucene import document}}
>   
>  {{field = document.StoredField('', 0)}}
>  {{print(field.numericValue(), field.binaryValue())}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-50) StoredField of an int has the wrong type.

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866171#comment-16866171
 ] 

Andi Vajda commented on PYLUCENE-50:


For the longest time, it was possible to pass an int where a byte was expected. 
This overlap was intentional and, probably, for convenience. The fix to 
PYLUCENE-47 changed the order in which signatures were considered and may have 
caused this long latent bug to now bite.
To fix this, I removed the overlap. To pass a byte, use b'x'.


> StoredField of an int has the wrong type.
> -
>
> Key: PYLUCENE-50
> URL: https://issues.apache.org/jira/browse/PYLUCENE-50
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3 official docker container, 8.1.1rc
>Reporter: A. Coady
>Priority: Critical
>
> The StoredField constructor is interpreting ints as bytes.  It's only 
> reproducing on the 8 rc.
> {{import lucene}}
>  {{lucene.initVM()}}
>  {{from org.apache.lucene import document}}
>   
>  {{field = document.StoredField('', 0)}}
>  {{print(field.numericValue(), field.binaryValue())}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-50) StoredField of an int has the wrong type.

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-50.

Resolution: Fixed

fixed in rev 1861553

> StoredField of an int has the wrong type.
> -
>
> Key: PYLUCENE-50
> URL: https://issues.apache.org/jira/browse/PYLUCENE-50
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3 official docker container, 8.1.1rc
>Reporter: A. Coady
>Priority: Critical
>
> The StoredField constructor is interpreting ints as bytes.  It's only 
> reproducing on the 8 rc.
> {{import lucene}}
>  {{lucene.initVM()}}
>  {{from org.apache.lucene import document}}
>   
>  {{field = document.StoredField('', 0)}}
>  {{print(field.numericValue(), field.binaryValue())}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-49) Comply with Apache download page and mirror requirements

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-49.

Resolution: Fixed

rev 1045830 of cms

> Comply with Apache download page and mirror requirements
> 
>
> Key: PYLUCENE-49
> URL: https://issues.apache.org/jira/browse/PYLUCENE-49
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jan Høydahl
>Priority: Minor
>
> See LUCENE-8820 and LUCENE-8821. The same applies for PyLucene:
> * Use https links everywhere
> * Remove old releases from the mirrors
> * Consider creating a DOWNLOAD page (not sure if that is a hard requirement)
> * At the least, use https when linking to closer.lua



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-49) Comply with Apache download page and mirror requirements

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854862#comment-16854862
 ] 

Andi Vajda commented on PYLUCENE-49:



Use https links everywhere
done
Remove old releases from the mirrors
done
Consider creating a DOWNLOAD page (not sure if that is a hard requirement)
unnecessary
At the least, use https when linking to closer.lua
done

> Comply with Apache download page and mirror requirements
> 
>
> Key: PYLUCENE-49
> URL: https://issues.apache.org/jira/browse/PYLUCENE-49
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jan Høydahl
>Priority: Minor
>
> See LUCENE-8820 and LUCENE-8821. The same applies for PyLucene:
> * Use https links everywhere
> * Remove old releases from the mirrors
> * Consider creating a DOWNLOAD page (not sure if that is a hard requirement)
> * At the least, use https when linking to closer.lua



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-48) --files separate not working with --use-full-names

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-48.

Resolution: Fixed

> --files separate not working with --use-full-names 
> ---
>
> Key: PYLUCENE-48
> URL: https://issues.apache.org/jira/browse/PYLUCENE-48
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 64, python 3.7
>Reporter: Petrus Hyvönen
>Priority: Minor
> Attachments: separate files example.zip
>
>
> Hi,
> It seems like the --file separate option is not working together with the 
> --use-full-names option.
> The linking says:
> {{build\_test2\java\__init__.cpp(23): error C3861: 'getJavaModule': 
> identifier not found}}
> {{build\_test2\java\__init__.cpp(32): error C3861: 'getJavaModule': 
> identifier not found}}
> {{error: command 'C:\\Program Files (x86)\\Microsoft Visual 
> Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.20.27508\\bin\\HostX86\\x64\\cl.exe'
>  failed with exit status 2}}
> The __init__,cpp file at the failed location:
> {{void __install__(PyObject *module)}}
> {{{}}
> {{ module = getJavaModule(module, "", "java");}}
> {{ io::__install__(module);}}
> {{ lang::__install__(module);}}
> {{ util::__install__(module);}}
> {{}}}
>  
> Same works without the --use-full-names.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-47) Type matching in methods with same number of arguments

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-47.

Resolution: Fixed

> Type matching in methods with same number of arguments
> --
>
> Key: PYLUCENE-47
> URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: build_and_wrap_Test_parameters_v3.zip, 
> java-example-test-parameters-v2.2.zip, java-example-test-parameters.zip, 
> pylucene-47-including-constructors.patch
>
>
> If the same number of arguments are used in a method and the arguments are 
> positively matched also on subclasses of the argument. The order of testing 
> in the generated code will matter and give unpredictable results. 
> A test case is attached below. It should fail in most cases but with a  piece 
> of luck the order of tests in the generated code may get right and it will 
> work (1/24 chance if at random).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-48) --files separate not working with --use-full-names

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824343#comment-16824343
 ] 

Andi Vajda commented on PYLUCENE-48:


fixed in rev 1858014

> --files separate not working with --use-full-names 
> ---
>
> Key: PYLUCENE-48
> URL: https://issues.apache.org/jira/browse/PYLUCENE-48
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 64, python 3.7
>Reporter: Petrus Hyvönen
>Priority: Minor
> Attachments: separate files example.zip
>
>
> Hi,
> It seems like the --file separate option is not working together with the 
> --use-full-names option.
> The linking says:
> {{build\_test2\java\__init__.cpp(23): error C3861: 'getJavaModule': 
> identifier not found}}
> {{build\_test2\java\__init__.cpp(32): error C3861: 'getJavaModule': 
> identifier not found}}
> {{error: command 'C:\\Program Files (x86)\\Microsoft Visual 
> Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.20.27508\\bin\\HostX86\\x64\\cl.exe'
>  failed with exit status 2}}
> The __init__,cpp file at the failed location:
> {{void __install__(PyObject *module)}}
> {{{}}
> {{ module = getJavaModule(module, "", "java");}}
> {{ io::__install__(module);}}
> {{ lang::__install__(module);}}
> {{ util::__install__(module);}}
> {{}}}
>  
> Same works without the --use-full-names.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-48) --files separate not working with --use-full-names

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823700#comment-16823700
 ] 

Andi Vajda commented on PYLUCENE-48:


ah, --files separate, I haven't used that in a long time...



> --files separate not working with --use-full-names 
> ---
>
> Key: PYLUCENE-48
> URL: https://issues.apache.org/jira/browse/PYLUCENE-48
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 64, python 3.7
>Reporter: Petrus Hyvönen
>Priority: Minor
> Attachments: separate files example.zip
>
>
> Hi,
> It seems like the --file separate option is not working together with the 
> --use-full-names option.
> The linking says:
> {{build\_test2\java\__init__.cpp(23): error C3861: 'getJavaModule': 
> identifier not found}}
> {{build\_test2\java\__init__.cpp(32): error C3861: 'getJavaModule': 
> identifier not found}}
> {{error: command 'C:\\Program Files (x86)\\Microsoft Visual 
> Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.20.27508\\bin\\HostX86\\x64\\cl.exe'
>  failed with exit status 2}}
> The __init__,cpp file at the failed location:
> {{void __install__(PyObject *module)}}
> {{{}}
> {{ module = getJavaModule(module, "", "java");}}
> {{ io::__install__(module);}}
> {{ lang::__install__(module);}}
> {{ util::__install__(module);}}
> {{}}}
>  
> Same works without the --use-full-names.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-48) --files separate not working with --use-full-names

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823627#comment-16823627
 ] 

Andi Vajda commented on PYLUCENE-48:


What doesn't work ?
There is no --file option, did you mean --files ?
What is the actual command line that fails ?
For reference, the PyLucene build uses both --files 8 and --use_full_names...
  https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

> --files separate not working with --use-full-names 
> ---
>
> Key: PYLUCENE-48
> URL: https://issues.apache.org/jira/browse/PYLUCENE-48
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 64, python 3.7
>Reporter: Petrus Hyvönen
>Priority: Minor
> Attachments: separate files example.zip
>
>
> Hi,
> It seems like the --file separate option is not working together with the 
> --use-full-names option.
> The linking says:
> {{build\_test2\java\__init__.cpp(23): error C3861: 'getJavaModule': 
> identifier not found}}
> {{build\_test2\java\__init__.cpp(32): error C3861: 'getJavaModule': 
> identifier not found}}
> {{error: command 'C:\\Program Files (x86)\\Microsoft Visual 
> Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.20.27508\\bin\\HostX86\\x64\\cl.exe'
>  failed with exit status 2}}
> The __init__,cpp file at the failed location:
> {{void __install__(PyObject *module)}}
> {{{}}
> {{ module = getJavaModule(module, "", "java");}}
> {{ io::__install__(module);}}
> {{ lang::__install__(module);}}
> {{ util::__install__(module);}}
> {{}}}
>  
> Same works without the --use-full-names.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823602#comment-16823602
 ] 

Andi Vajda commented on PYLUCENE-47:


Fixed in rev 1857978 (the attached test passes  both with python2 and python3).
Thank you for the patch and the test case.
I had to expand on your patch considerably to make the comparisons really 
deterministic as that was one part of the bug, it would only happen 
sometimes... based on the original order of the signatures returned by java and 
the order of comparisons in python's sort.
I also wanted to do the rank compare only when it's actually needed as it's not 
free.

> Type matching in methods with same number of arguments
> --
>
> Key: PYLUCENE-47
> URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: build_and_wrap_Test_parameters_v3.zip, 
> java-example-test-parameters-v2.2.zip, java-example-test-parameters.zip, 
> pylucene-47-including-constructors.patch
>
>
> If the same number of arguments are used in a method and the arguments are 
> positively matched also on subclasses of the argument. The order of testing 
> in the generated code will matter and give unpredictable results. 
> A test case is attached below. It should fail in most cases but with a  piece 
> of luck the order of tests in the generated code may get right and it will 
> work (1/24 chance if at random).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821358#comment-16821358
 ] 

Andi Vajda commented on PYLUCENE-47:




In that case, my comment makes no sense, sorry for the noise.


Not in terms of isAssignableFrom() but in terms of how many interfaces a 
parameter class implements (in essence, the interface hierarchy is a 
parallel class hierarchy, with multiple super-interfaces allowed). Counting 
those may give us some signal as to how deep a parameter class is and help 
with sorting.


Yes, we have the same bug there.

Andi..


> Type matching in methods with same number of arguments
> --
>
> Key: PYLUCENE-47
> URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: java-example-test-parameters-v2.2.zip, 
> java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch
>
>
> If the same number of arguments are used in a method and the arguments are 
> positively matched also on subclasses of the argument. The order of testing 
> in the generated code will matter and give unpredictable results. 
> A test case is attached below. It should fail in most cases but with a  piece 
> of luck the order of tests in the generated code may get right and it will 
> work (1/24 chance if at random).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819386#comment-16819386
 ] 

Andi Vajda commented on PYLUCENE-47:


I took at your patch and it makes sense (thanks!)
Would it make sense to include the return type of the method in the rang 
calculation ?
Would it make sense to then continue sorting, as a third criteria, on the rang 
of interfaces each parameter and return type class implements ?

Andi..

> Type matching in methods with same number of arguments
> --
>
> Key: PYLUCENE-47
> URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: java-example-test-parameters-v2.2.zip, 
> java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch
>
>
> If the same number of arguments are used in a method and the arguments are 
> positively matched also on subclasses of the argument. The order of testing 
> in the generated code will matter and give unpredictable results. 
> A test case is attached below. It should fail in most cases but with a  piece 
> of luck the order of tests in the generated code may get right and it will 
> work (1/24 chance if at random).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-46) __dir__ module paramter

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-46.

Resolution: Fixed

> __dir__ module paramter 
> 
>
> Key: PYLUCENE-46
> URL: https://issues.apache.org/jira/browse/PYLUCENE-46
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows, Python3.7, JCC 3.4
>Reporter: Petrus Hyvönen
>Priority: Minor
>
> Hi,
> Since Python 3.7 the __dir__ module attribute is part of the API to return 
> the values that shall be presented from the "dir" python command.
> [https://www.python.org/dev/peps/pep-0562/]
> [https://docs.python.org/3/reference/datamodel.html#object.__dir__]
> The top level module of wrapped libraries use this variable name for the path 
> to the module location, which confuses some IDE's. "TypeError: 'str' object 
> is not callable"
> The best would be if this module __dir__() returned the names of the top 
> level wrapped classes, but renaming the variable should solve the IDE problem.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-46) __dir__ module paramter

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783852#comment-16783852
 ] 

Andi Vajda commented on PYLUCENE-46:


Fixed in rev 1854800 (renamed __dir__ to __module_dir__).

> __dir__ module paramter 
> 
>
> Key: PYLUCENE-46
> URL: https://issues.apache.org/jira/browse/PYLUCENE-46
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows, Python3.7, JCC 3.4
>Reporter: Petrus Hyvönen
>Priority: Minor
>
> Hi,
> Since Python 3.7 the __dir__ module attribute is part of the API to return 
> the values that shall be presented from the "dir" python command.
> [https://www.python.org/dev/peps/pep-0562/]
> [https://docs.python.org/3/reference/datamodel.html#object.__dir__]
> The top level module of wrapped libraries use this variable name for the path 
> to the module location, which confuses some IDE's. "TypeError: 'str' object 
> is not callable"
> The best would be if this module __dir__() returned the names of the top 
> level wrapped classes, but renaming the variable should solve the IDE problem.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-45) JArray.cast_ raises SystemError in Python 3.

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-45.

Resolution: Fixed

Fixed in rev 1843965. Thank you for the bug report.

> JArray.cast_ raises SystemError in Python 3.
> 
>
> Key: PYLUCENE-45
> URL: https://issues.apache.org/jira/browse/PYLUCENE-45
> Project: PyLucene
>  Issue Type: Bug
>Reporter: A. Coady
>Priority: Major
>
> `JArray_string.cast_` raises `SystemError` in Python 3 and 7.5 rc.
>  
> {code:java}
> a = lucene.JArray_string('text')
> lucene.JArray_string.cast_(a)
> {code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-41) JArray type issue

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649605#comment-16649605
 ] 

Andi Vajda commented on PYLUCENE-41:


Fixed in rev 1843871 (yay). JArray objects are instances of Object again.

> JArray type issue
> -
>
> Key: PYLUCENE-41
> URL: https://issues.apache.org/jira/browse/PYLUCENE-41
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 7, python 3
>Reporter: Petrus Hyvönen
>Priority: Major
>
> Hi,
>  
> In JCC 3.0 release version and early(2.7) it is possible to make a double 
> array by:
>  
> {{mask = JArray('object')(5)}}
> {{for i in range(5)}}
>  {{    mask[i] = JArray('double')([1.0, 2.0])}}
> It gives in the <=3.0 following type of 'mask'
> JArray[, , ...
> for svn version it gives a 'TypeError: JArray[1.0, 2.0]' in the 
> assignment to mask[i]
>  
> Not sure this is a bug or a change of how to do things.
> Best Regards
> /Petrus
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-41) JArray type issue

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-41.

Resolution: Fixed

> JArray type issue
> -
>
> Key: PYLUCENE-41
> URL: https://issues.apache.org/jira/browse/PYLUCENE-41
> Project: PyLucene
>  Issue Type: Bug
> Environment: windows 7, python 3
>Reporter: Petrus Hyvönen
>Priority: Major
>
> Hi,
>  
> In JCC 3.0 release version and early(2.7) it is possible to make a double 
> array by:
>  
> {{mask = JArray('object')(5)}}
> {{for i in range(5)}}
>  {{    mask[i] = JArray('double')([1.0, 2.0])}}
> It gives in the <=3.0 following type of 'mask'
> JArray[, , ...
> for svn version it gives a 'TypeError: JArray[1.0, 2.0]' in the 
> assignment to mask[i]
>  
> Not sure this is a bug or a change of how to do things.
> Best Regards
> /Petrus
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-44) pkg_resources.extern.packaging.version is Deprecated

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649429#comment-16649429
 ] 

Andi Vajda commented on PYLUCENE-44:


If you know that, on Arch, people always have a modern setuptools installed 
with JCC because, say, of a declared package dependency, then you can get rid 
of this problem altogether by just setting with_modern_setuptools to True in 
setup.py, thus no longer depending on these funky imports to make that 
determination. That is all they're used for.
Setup.py needs to know if setuptools is present (with_setuptools) and capable 
of building a plain shared library (with_modern_setuptools) for JCC's shared 
mode.



> pkg_resources.extern.packaging.version is Deprecated
> 
>
> Key: PYLUCENE-44
> URL: https://issues.apache.org/jira/browse/PYLUCENE-44
> Project: PyLucene
>  Issue Type: Bug
> Environment: Arch Linux
> Python 3.7.0
> setuptools 40.4.3
> Ant 1.10.5
> Pip 18.0
>Reporter: Shangning Xu
>Priority: Major
>
> {{pkg_resources.extern.packaging.version}} introduced in PYLUCENE-43 to 
> replace {{SetupToolsVersion}} is actually deprecated *before* 
> {{SetupToolsVersion}} ({{SetupToolsVersion}} is removed in setuptools 
> [v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0], 
> while {{pkg_resources.extern}} is in 
> [v34.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0]).
> The correct solution is to replace
> {code:java}
> from pkg_resources.extern.packaging.version import Version
> {code}
> with
> {code:java}
> from packaging.version import Version
> {code}
> in Line 215 of {{setup.py}}. The solution can be found in the release notes 
> of [setuptools 
> v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0] and 
> a [Github issue|https://github.com/anntzer/pypi2pkgbuild/issues/2].
> Maybe this setuptools drama may worth a minor version bump?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-44) pkg_resources.extern.packaging.version is Deprecated

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649273#comment-16649273
 ] 

Andi Vajda commented on PYLUCENE-44:


Note that this may be due to a python 2 vs python 3 problem: I tried with 
puthon 2.



> pkg_resources.extern.packaging.version is Deprecated
> 
>
> Key: PYLUCENE-44
> URL: https://issues.apache.org/jira/browse/PYLUCENE-44
> Project: PyLucene
>  Issue Type: Bug
> Environment: Arch Linux
> Python 3.7.0
> setuptools 40.4.3
> Ant 1.10.5
> Pip 18.0
>Reporter: Shangning Xu
>Priority: Major
>
> {{pkg_resources.extern.packaging.version}} introduced in PYLUCENE-43 to 
> replace {{SetupToolsVersion}} is actually deprecated *before* 
> {{SetupToolsVersion}} ({{SetupToolsVersion}} is removed in setuptools 
> [v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0], 
> while {{pkg_resources.extern}} is in 
> [v34.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0]).
> The correct solution is to replace
> {code:java}
> from pkg_resources.extern.packaging.version import Version
> {code}
> with
> {code:java}
> from packaging.version import Version
> {code}
> in Line 215 of {{setup.py}}. The solution can be found in the release notes 
> of [setuptools 
> v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0] and 
> a [Github issue|https://github.com/anntzer/pypi2pkgbuild/issues/2].
> Maybe this setuptools drama may worth a minor version bump?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-44) pkg_resources.extern.kg_resources.extern.packaging.version is Deprecated

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649113#comment-16649113
 ] 

Andi Vajda commented on PYLUCENE-44:


Did you actually try that ?
I upgrade my setuptools to the latest, version 40.4.3 and tried the various 
import statements in JCC's setup.py:

>>> from setuptools import setup, Extension
>>> from pkg_resources import require
>>> with_setuptools = require('setuptools')[0].parsed_version
>>> with_setuptools


>>> from pkg_resources import SetuptoolsVersion
Traceback (most recent call last):
  File "", line 1, in 
ImportError: cannot import name SetuptoolsVersion

Ok, that error is expected, especially since version 39.

>>> from pkg_resources.extern.packaging.version import Version

Ok, existing code in setup.py works with version 40.

>>> from packaging.version import Version
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named packaging.version
>>> import packaging
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named packaging

Not ok: your suggested replacement doesn't work.

This is running with Python 2.7.8.
In other words, what's in setup.py works but what you suggest to replace it 
with doesn't.
Why are you suggestion to change the code ? What is this bug about ?


> pkg_resources.extern.kg_resources.extern.packaging.version is Deprecated
> 
>
> Key: PYLUCENE-44
> URL: https://issues.apache.org/jira/browse/PYLUCENE-44
> Project: PyLucene
>  Issue Type: Bug
> Environment: Arch Linux
> Python 3.7.0
> setuptools 40.4.3
> Ant 1.10.5
> Pip 18.0
>Reporter: Shangning Xu
>Priority: Major
>
> {{pkg_resources.extern.kg_resources.extern.packaging.version}} introduced in 
> [PYLUCENE-43|https://issues.apache.org/jira/browse/PYLUCENE-43] to replace 
> {{SetupToolsVersion}} is actually deprecated *before* {{SetupToolsVersion}} 
> ({{SetupToolsVersion}} is removed in setuptools 
> [v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0], 
> while {{pkg_resources.extern}} is in 
> [v34.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0]).
> The correct solution is to replace
> {code:python}
> from pkg_resources.extern.kg_resources.extern.packaging.version import Version
> {code}
> with
> {code:python}
> from packaging.version import Version
> {code}
> in Line 20 of {{setup.py}}. The solution can be found in the release notes of 
> [setuptools 
> v39.0.0|https://setuptools.readthedocs.io/en/latest/history.html#v39-0-0] and 
> a [Github issue|https://github.com/anntzer/pypi2pkgbuild/issues/2].
> Maybe this setuptools drama may worth a minor version bump?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-43) Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-43.

Resolution: Fixed

Hopefully fixed in rev 1841356.
The newer setuptools helpfully dropped SetuptoolsVersion.
I added another case for looking for 
  pkg_resources.extern.packaging.version import Version
which seems to be there then, sigh.
Thank you for the bug report.

> Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools
> -
>
> Key: PYLUCENE-43
> URL: https://issues.apache.org/jira/browse/PYLUCENE-43
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Xiang Zhang
>Priority: Major
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Environment I'm Using*:
>  * ubuntu 16.04
>  * cleanly installed python 2.7.15 built with latest pyenv
>  * Setuptools 40.4.1
>  * pip 18.0
>  * pylucene-7.4.0.tar.gz
>  * jdk 1.8.0_181
>  * ant 1.10. 5
> *Phenomenon*
> Step1. build jcc
> In JCC's setup.py file, with_modern_setuptools is False by checking if 
> pkg_resource.SetuptoolsVersions is available.
> According to [setuptools 
> developer|https://github.com/pypa/setuptools/issues/1310], this is not 
> documented and is already removed, causing jcc not built with shared mode 
> consequently but no error or warning is prompted.
> Step2. build pylucene
> The final error comes with the following line:
> {code:java}
> python -m jcc --shared --jar 
> lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
> (omitted).  --version 7.4.0 --module python/collections.py --module 
> python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
> python/ICUTransformFilter.py  --files 8 --build
> (lots of warning omitted).
> Traceback (most recent call last):
>   File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, 
> in _run_module_as_main
> "__main__", fname, loader, pkg_name)
>   File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, 
> in _run_code
> exec code in run_globals
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
>  line 107, in 
> cpp.jcc(sys.argv)
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
>  line 736, in jcc
> egg_info, extra_setup_args)
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
>  line 1606, in compile
> raise NotImplementedError, "JCC was not built with --shared mode support, 
> see JCC's INSTALL file for more information"
> NotImplementedError: JCC was not built with --shared mode support, see JCC's 
> INSTALL file for more information
> Makefile:349: recipe for target 'compile' failed
> make: *** [compile] Error 1
> {code}
> It was hard to debug given that "JCC is not built with shared mode", actually 
> I indeed got a _jcc.so library in the build directory.
> *Quick Fix for Me*
> As long as I believe the setuptools package has enough high version, I force 
> the with_modern_setuptools switch to be True as the following(at line 210 in 
> JCC's setup.py):
> {code:java}
> ...
> try:
> from pkg_resources import SetuptoolsVersion
> with_modern_setuptools = True
> except ImportError:
> with_modern_setuptools = False
> enable_shared = False
> with_modern_setuptools = True
> if with_modern_setuptools and 'NO_SHARED' not in os.environ:
> 
> {code}
> i.e., the helpers for linux are still working well.
> then rebuilt JCC, remove the existing one and reinstall, then continue to 
> make pylucene, all things work now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-42) JCC build fails with Python 3.7 (release candidate).

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505050#comment-16505050
 ] 

Andi Vajda commented on PYLUCENE-42:


Patch applied, thank you for the fix !

> JCC build fails with Python 3.7 (release candidate).
> 
>
> Key: PYLUCENE-42
> URL: https://issues.apache.org/jira/browse/PYLUCENE-42
> Project: PyLucene
>  Issue Type: Bug
>Reporter: A. Coady
>Priority: Major
>  Labels: build
> Attachments: patch.txt
>
>
> Using PyLucene 7.2.0-rc1 and the official docker image {{python:rc}}.
> {code}
> gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
> -Wstrict-prototypes -fPIC -D_java_generics -DJCC_VER="3.1" 
> -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
> -I_jcc3 -Ijcc3/sources -I/usr/local/include/python3.7m -c 
> jcc3/sources/jcc.cpp -o build/temp.linux-x86_64-3.7/jcc3/sources/jcc.o 
> -DPYTHON -fno-strict-aliasing -Wno-write-strings
> cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for 
> C/ObjC but not for C++
> jcc3/sources/jcc.cpp: In function ‘PyObject* initVM(PyObject*, PyObject*, 
> PyObject*)’:
> jcc3/sources/jcc.cpp:486:52: error: invalid conversion from ‘const char*’ to 
> ‘char*’ [-fpermissive]
>  char *option = PyUnicode_AsUTF8(arg);
> ^
> error: command 'gcc' failed with exit status 1
> The command '/bin/sh -c cd jcc && JCC_JDK=/usr/lib/jvm/default-java 
> python setup.py install' returned a non-zero code: 1
> make: *** [rc] Error 1
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-42) JCC build fails with Python 3.7 (release candidate).

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-42.

Resolution: Fixed

> JCC build fails with Python 3.7 (release candidate).
> 
>
> Key: PYLUCENE-42
> URL: https://issues.apache.org/jira/browse/PYLUCENE-42
> Project: PyLucene
>  Issue Type: Bug
>Reporter: A. Coady
>Priority: Major
>  Labels: build
> Attachments: patch.txt
>
>
> Using PyLucene 7.2.0-rc1 and the official docker image {{python:rc}}.
> {code}
> gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
> -Wstrict-prototypes -fPIC -D_java_generics -DJCC_VER="3.1" 
> -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
> -I_jcc3 -Ijcc3/sources -I/usr/local/include/python3.7m -c 
> jcc3/sources/jcc.cpp -o build/temp.linux-x86_64-3.7/jcc3/sources/jcc.o 
> -DPYTHON -fno-strict-aliasing -Wno-write-strings
> cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for 
> C/ObjC but not for C++
> jcc3/sources/jcc.cpp: In function ‘PyObject* initVM(PyObject*, PyObject*, 
> PyObject*)’:
> jcc3/sources/jcc.cpp:486:52: error: invalid conversion from ‘const char*’ to 
> ‘char*’ [-fpermissive]
>  char *option = PyUnicode_AsUTF8(arg);
> ^
> error: command 'gcc' failed with exit status 1
> The command '/bin/sh -c cd jcc && JCC_JDK=/usr/lib/jvm/default-java 
> python setup.py install' returned a non-zero code: 1
> make: *** [rc] Error 1
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-38) JCC build error under recents versions of clang.

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491436#comment-16491436
 ] 

Andi Vajda commented on PYLUCENE-38:


Please subscribe to pylucene-dev@lucene.apache.org to discuss this.
The pylucene-38 bug here is irrelevant.

You seem to be using Anaconda ? Guessing from your 
/Users/mithun/miniconda3/lib/python3.6 path ?
I believe others have reported issues with Anaconda ?? (on the mailing list).
I don't know what environment and would suggest you start with using a plain 
python environment to start with PyLucene.

> JCC build error under recents versions of clang.
> 
>
> Key: PYLUCENE-38
> URL: https://issues.apache.org/jira/browse/PYLUCENE-38
> Project: PyLucene
>  Issue Type: Bug
> Environment: macOS
>Reporter: A. Coady
>Priority: Major
>
> {code:none}
> jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
>  ^ ~
> jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
> ~~ ^ ~
> {code}
> Comparisons between NULL and integers have been elevated from a warning to an 
> error in recent versions of clang.  And presumably the error handling wasn't 
> working anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-38) JCC build error under recents versions of clang.

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490003#comment-16490003
 ] 

Andi Vajda commented on PYLUCENE-38:


This is fixed in PyLucene 7.2.0 which is available here as a release candidate:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.2.0-rc1/
This release has been in limbo since 12/21/2017, not having received the 
required 3 PMC votes but the release artifacts are good. You should use them !

 

> JCC build error under recents versions of clang.
> 
>
> Key: PYLUCENE-38
> URL: https://issues.apache.org/jira/browse/PYLUCENE-38
> Project: PyLucene
>  Issue Type: Bug
> Environment: macOS
>Reporter: A. Coady
>Priority: Major
>
> {code:none}
> jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
>  ^ ~
> jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
> ~~ ^ ~
> {code}
> Comparisons between NULL and integers have been elevated from a warning to an 
> error in recent versions of clang.  And presumably the error handling wasn't 
> working anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-40) Document use of JCC_JDK

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363283#comment-16363283
 ] 

Andi Vajda commented on PYLUCENE-40:


I have not yet tested anything with Java 9. I haven't even installed it.

> Document use of JCC_JDK
> ---
>
> Key: PYLUCENE-40
> URL: https://issues.apache.org/jira/browse/PYLUCENE-40
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Ryan J Ollos
>Priority: Minor
> Attachments: jcc_build_output.txt
>
>
> I found two issues when trying to [help someone on Stack 
> Overflow|https://stackoverflow.com/questions/48711714/] build the library. 
> First, the [documentation on PyPI|https://pypi.python.org/pypi/JCC/] states:
> {quote}JCC’s setup.py file needs to be edited before building JCC to specify 
> the location of the Java Runtime Environment’s header files and libraries.
> {quote}
> However, it appears you have a better mechanism of setting {{JCC_JRE}}, but 
> it's not documented.
> Second, when setting {{JCC_JRE}} is appears to work correctly and use the 
> path to the specified {{JCC_JRE}} in the compilation, but the first line of 
> output might indicate that a different JRE is being used:
> {code:java}
> $JCC_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home 
> python setup.py install
> found JAVAHOME = 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> ...
> {code}
> So maybe the found {{JAVAHOME}} should not be printed if {{JCC_JRE}} is set, 
> so it appears that {{JCC_JRE}} is successfully overriding the {{JAVAHOME}}. 
> I'll attach the full output from building on my platform.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-40) Document use of JCC_JDK

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363001#comment-16363001
 ] 

Andi Vajda commented on PYLUCENE-40:


I improved the docs at [http://lucene.apache.org/pylucene/jcc/install.html] a 
bit, hopefully.

(press shift-reload to clear cache to view)

> Document use of JCC_JDK
> ---
>
> Key: PYLUCENE-40
> URL: https://issues.apache.org/jira/browse/PYLUCENE-40
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Ryan J Ollos
>Priority: Minor
> Attachments: jcc_build_output.txt
>
>
> I found two issues when trying to [help someone on Stack 
> Overflow|https://stackoverflow.com/questions/48711714/] build the library. 
> First, the [documentation on PyPI|https://pypi.python.org/pypi/JCC/] states:
> {quote}JCC’s setup.py file needs to be edited before building JCC to specify 
> the location of the Java Runtime Environment’s header files and libraries.
> {quote}
> However, it appears you have a better mechanism of setting {{JCC_JRE}}, but 
> it's not documented.
> Second, when setting {{JCC_JRE}} is appears to work correctly and use the 
> path to the specified {{JCC_JRE}} in the compilation, but the first line of 
> output might indicate that a different JRE is being used:
> {code:java}
> $JCC_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home 
> python setup.py install
> found JAVAHOME = 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> ...
> {code}
> So maybe the found {{JAVAHOME}} should not be printed if {{JCC_JRE}} is set, 
> so it appears that {{JCC_JRE}} is successfully overriding the {{JAVAHOME}}. 
> I'll attach the full output from building on my platform.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-40) Document use of JCC_JDK

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361762#comment-16361762
 ] 

Andi Vajda commented on PYLUCENE-40:


Similarly for JAVAC: if you don't set it, it'll pickup whatever's on your PATH.

 

> Document use of JCC_JDK
> ---
>
> Key: PYLUCENE-40
> URL: https://issues.apache.org/jira/browse/PYLUCENE-40
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Ryan J Ollos
>Priority: Minor
> Attachments: jcc_build_output.txt
>
>
> I found two issues when trying to [help someone on Stack 
> Overflow|https://stackoverflow.com/questions/48711714/] build the library. 
> First, the [documentation on PyPI|https://pypi.python.org/pypi/JCC/] states:
> {quote}JCC’s setup.py file needs to be edited before building JCC to specify 
> the location of the Java Runtime Environment’s header files and libraries.
> {quote}
> However, it appears you have a better mechanism of setting {{JCC_JRE}}, but 
> it's not documented.
> Second, when setting {{JCC_JRE}} is appears to work correctly and use the 
> path to the specified {{JCC_JRE}} in the compilation, but the first line of 
> output might indicate that a different JRE is being used:
> {code:java}
> $JCC_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home 
> python setup.py install
> found JAVAHOME = 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> ...
> {code}
> So maybe the found {{JAVAHOME}} should not be printed if {{JCC_JRE}} is set, 
> so it appears that {{JCC_JRE}} is successfully overriding the {{JAVAHOME}}. 
> I'll attach the full output from building on my platform.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (PYLUCENE-40) Document use of JCC_JDK

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361761#comment-16361761
 ] 

Andi Vajda commented on PYLUCENE-40:


Note, that, as the code is currently, if you *only* set JCC_JDK and not 
JCC_INCLUDES, etc..., then it will use the values derived from the found 
JAVAHOME/JAVAFRAMEWORKS for JCC_INCLUDES and JCC_LFLAGS

If you want to set your own JCC_JDK, you must also set the other JCC_ env vars 
that depend on it, or else you'll be building with the wrong version header 
files and libraries. See line 176 in setup.py where these are set (and later 
where they're used).

> Document use of JCC_JDK
> ---
>
> Key: PYLUCENE-40
> URL: https://issues.apache.org/jira/browse/PYLUCENE-40
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Ryan J Ollos
>Priority: Minor
> Attachments: jcc_build_output.txt
>
>
> I found two issues when trying to [help someone on Stack 
> Overflow|https://stackoverflow.com/questions/48711714/] build the library. 
> First, the [documentation on PyPI|https://pypi.python.org/pypi/JCC/] states:
> {quote}JCC’s setup.py file needs to be edited before building JCC to specify 
> the location of the Java Runtime Environment’s header files and libraries.
> {quote}
> However, it appears you have a better mechanism of setting {{JCC_JRE}}, but 
> it's not documented.
> Second, when setting {{JCC_JRE}} is appears to work correctly and use the 
> path to the specified {{JCC_JRE}} in the compilation, but the first line of 
> output might indicate that a different JRE is being used:
> {code:java}
> $JCC_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home 
> python setup.py install
> found JAVAHOME = 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> ...
> {code}
> So maybe the found {{JAVAHOME}} should not be printed if {{JCC_JRE}} is set, 
> so it appears that {{JCC_JRE}} is successfully overriding the {{JAVAHOME}}. 
> I'll attach the full output from building on my platform.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PYLUCENE-39) JArrays are no longer sliceable under Python 3.

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-39.

Resolution: Fixed

fixed in rev 1812596

> JArrays are no longer sliceable under Python 3.
> ---
>
> Key: PYLUCENE-39
> URL: https://issues.apache.org/jira/browse/PYLUCENE-39
> Project: PyLucene
>  Issue Type: Bug
> Environment: JCC 3
>Reporter: A. Coady
>Priority: Minor
>
> JArray objects use the legacy __getslice__ implementation, and hence aren't 
> sliceable in Python 3.
> {code}
> In []: lucene.JArray_byte(b'abc')[:]
> ...
> TypeError: sequence index must be integer, not 'slice'
> {code}
> I'm not necessarily advocating that they should be sliceable, just that it's 
> a regression.  It's also worth noting that slices returned Python sequences, 
> not JArray objects, which I think is worth revisiting if it's going to be 
> re-implemented anyway.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (PYLUCENE-38) JCC build error under recents versions of clang.

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-38.

Resolution: Fixed

This is fixed in rev 1812455

> JCC build error under recents versions of clang.
> 
>
> Key: PYLUCENE-38
> URL: https://issues.apache.org/jira/browse/PYLUCENE-38
> Project: PyLucene
>  Issue Type: Bug
> Environment: macOS
>Reporter: A. Coady
>
> {code:none}
> jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
>  ^ ~
> jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer and 
> zero ('PyObject *' (aka '_object *') and 'int')
> PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
> ~~ ^ ~
> {code}
> Comparisons between NULL and integers have been elevated from a warning to an 
> error in recent versions of clang.  And presumably the error handling wasn't 
> working anyway.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PYLUCENE-36) Python exception when handling a Java error

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16065129#comment-16065129
 ] 

Andi Vajda commented on PYLUCENE-36:


Done.




> Python exception when handling a Java error
> ---
>
> Key: PYLUCENE-36
> URL: https://issues.apache.org/jira/browse/PYLUCENE-36
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.5, Ubuntu 16.04, Java 8
>Reporter: Paulo Villegas
> Attachments: pylucene-6.5.0-py3.5.patch
>
>
> When handling a Java exception via the {{JavaError}} class, Python 3.5 
> generates an exception due to the call to {{unicode}} (which does not exist 
> in Python 3), hence masking the actual Java exception with a Python 
> _NameError_ exception.
> I guess this is a consequence of PYLUCENE-35. That one fixed the problem with 
> Unicode characters in Java exceptions for Python 2, but it shouldn't be 
> applied to Python 3 (since in Python 3 the {{str}} type *is* natively 
> Unicode).
> The attached small patch (applied only to the Python 3 branch) fixes it for 
> me.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064878#comment-16064878
 ] 

Andi Vajda commented on PYLUCENE-37:


If you use the wrappers generated for interfaces, you're going to face the 
problem reported here.
If you use the wrappers generated for classes implementing said interfaces, 
then you should be ok with all implemented methods anywhere as the implementing 
class has them all (or it is abstract).

You can also force the wrapping of private classes by explicitly listing them 
on the command line.


> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
> Attachments: jcc.multiple.inheritance.patch, Test.zip
>
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062324#comment-16062324
 ] 

Andi Vajda commented on PYLUCENE-37:


I've been working on this bug for a while now and I'm wondering how far a fix 
can get and what it achieves. I am about to check-in a large body of changes 
that makes a fix possible by switching Python type construction to use 
PyType_FromSpecWithBases() which can create a type with multiple base types. 
This is Python 3 only and this is fine. Python 2 support is in maintenance mode 
only.
What would fixing this bug achieve ?
  - wrappers would be correct with regards to their super types and 
side-casting interfaces would work
  - wrappers would inherit static fields and methods declared on interfaces 
beyond the first one)
Other than that, all is already working. For a non abstract java class to 
implement multiple interfaces, it has to have local implementations of all 
their methods (or inherit some from a parent class with local implementations) 
- thus I don't see any functional inheritance losses at the moment (beyond the 
static ones).
Also, Python has, to say the least, some strange layout requirements when 
constructing a type from multiple bases - they all have to have the same 
tp_basicsize. This is not the case with the JCC t_type, the types used with 
Python (their sizeof() is tp_basicsize), that wrap the C++/Java bridge types as 
they may have an array of type parameter of variable size (depending on the 
number of type parameters) when the java type being wrapped is generic. At the 
moment, I'm not even sure how much Python can support JCC types with multiple 
base types - maybe the t_type layout can be modified a bit to fix the size of 
type parameters by moving to an array pointer.
All that being said, it would be very nice if multiple inheritance could be 
properly supported:
  - it would better model 'class foo extends bar implements baz, ..."
  - it would better model the interface tree you proposed in the test
The new code now has a lot of stuff in place for supporting multiple 
inheritance but it is not enabled:
  - placeholder for virtual inheritance
  - support for multiple parents everywhere
  - Python type construction supports multiple bases
The code doesn't have the change in logic yet to properly track 'extends foo 
implements bar' and the code still suffers from the bug reported here, only the 
first interface is used as parent for a sub-interface.
I'm going to continue working on this on and off as it's an interesting 
problem...


> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
> Attachments: jcc.multiple.inheritance.patch, Test.zip
>
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048226#comment-16048226
 ] 

Andi Vajda commented on PYLUCENE-37:


I have gotten to the same point as you - the Python side needs to be reworked 
to accomodate
multiple parents, the current static initializations don't work with multiple 
base classes.
It's work in progress...




> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
> Attachments: jcc.multiple.inheritance.patch, Test.zip
>
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030244#comment-16030244
 ] 

Andi Vajda commented on PYLUCENE-37:


There seems to be something off with that code indeed.  
However, it would be helpful if you could include a small trivial example java 
code
that triggers the bug you found and an explanation of what you'd expect it
to do instead. This helps me ensure there is no misunderstanding and also helps 
with reproducing the bug.
Thanks !

> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (PYLUCENE-36) Python exception when handling a Java error

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16020146#comment-16020146
 ] 

Andi Vajda commented on PYLUCENE-36:


Thank you for your patch, I just integrated it !

> Python exception when handling a Java error
> ---
>
> Key: PYLUCENE-36
> URL: https://issues.apache.org/jira/browse/PYLUCENE-36
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.5, Ubuntu 16.04, Java 8
>Reporter: Paulo Villegas
> Attachments: pylucene-6.5.0-py3.5.patch
>
>
> When handling a Java exception via the {{JavaError}} class, Python 3.5 
> generates an exception due to the call to {{unicode}} (which does not exist 
> in Python 3), hence masking the actual Java exception with a Python 
> _NameError_ exception.
> I guess this is a consequence of PYLUCENE-35. That one fixed the problem with 
> Unicode characters in Java exceptions for Python 2, but it shouldn't be 
> applied to Python 3 (since in Python 3 the {{str}} type *is* natively 
> Unicode).
> The attached small patch (applied only to the Python 3 branch) fixes it for 
> me.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LUCENE-7636) Fix broken links in lucene.apache.org site

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15824559#comment-15824559
 ] 

Andi Vajda commented on LUCENE-7636:


Fixed the broken PyLucene and JCC links in rev 1779102.

> Fix broken links in lucene.apache.org site
> --
>
> Key: LUCENE-7636
> URL: https://issues.apache.org/jira/browse/LUCENE-7636
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/website
>Reporter: Jan Høydahl
>Priority: Minor
>
> I ran a broken links tool on lucene.apache.org site, found some broken links. 
> The scan excluded link checking of Javadoc, JIRA, localhost and 401 links 
> that need login to Apache:
> Getting links from: http://lucene.apache.org/pylucene/index.html
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_5/CHANGES 
> (HTTP_404)
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_4/CHANGES 
> (HTTP_404)
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_0_2/jcc/CHANGES
>  (HTTP_404)
> Finished! 174 links found. 3 broken.
> Getting links from: http://lucene.apache.org/pylucene/
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_5/CHANGES 
> (HTTP_404)
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_4/CHANGES 
> (HTTP_404)
> ├─BROKEN─ 
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_3_0_2/jcc/CHANGES
>  (HTTP_404)
> Finished! 174 links found. 3 broken.
> Getting links from: http://lucene.apache.org/core/discussion.html
> -├─BROKEN─ http://freenode.net/irc_servers.shtml (HTTP_404)- *FIXED*
> Finished! 93 links found. 1 broken.
> Getting links from: http://lucene.apache.org/core/developer.html
> ├─BROKEN─ https://builds.apache.org/job/Lucene-Artifacts-trunk/javadoc/ 
> (HTTP_404)
> ├─BROKEN─ 
> https://builds.apache.org/job/Lucene-Solr-Clover-trunk/lastSuccessfulBuild/clover-report/
>  (HTTP_404)
> ├─BROKEN─ 
> https://builds.apache.org/job/Lucene-Artifacts-trunk/lastSuccessfulBuild/artifact/lucene/dist/
>  (HTTP_404)
> Finished! 73 links found. 3 broken.
> Getting links from: http://lucene.apache.org/solr/resources.html
> -└─BROKEN─ http://mathieu-nayrolles.com/ (BLC_UNKNOWN)- *FIXED*
> Finished! 188 links found. 8 broken.
> Getting links from: http://lucene.apache.org/pylucene/features.html
> ├─BROKEN─ 
> http://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/samples/LuceneInAction
>  (HTTP_404)
> Finished! 60 links found. 1 broken.
> Getting links from: http://lucene.apache.org/pylucene/jcc/features.html
> ├─BROKEN─ http://docs.python.org/ext/defining-new-types.html (HTTP_404)
> ├─BROKEN─ http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html (HTTP_404)
> Finished! 66 links found. 2 broken.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (PYLUCENE-35) UnicodeEncodeError when a JavaException is raised

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14977701#comment-14977701
 ] 

Andi Vajda commented on PYLUCENE-35:


Thank you for the patch.

> UnicodeEncodeError when a JavaException is raised
> -
>
> Key: PYLUCENE-35
> URL: https://issues.apache.org/jira/browse/PYLUCENE-35
> Project: PyLucene
>  Issue Type: Bug
> Environment: Arch Linux x86_64 
> LANG=zh_CN.UTF-8
>Reporter: Vic Luo
>  Labels: easyfix, encoding
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When a javaException is raised and the stacktrace includes unicode 
> characters, the stacktrace will not be printed. Instead, line 11 of 
> __init__.py will raise a UnicodeEncodingError:
> !!!  File 
> "/usr/lib/python2.7/site-packages/lucene-4.9.0-py2.7-linux-x86_64.egg/lucene/__init__.py",
>  line 17, in __str__!!!
> !!!return "\n".join((super(JavaError, self).__str__(), "Java 
> stacktrace:", str(writer)))!!!
> !!!UnicodeEncodeError: 'ascii' codec can't encode characters in position 
> 102-103: ordinal not in range(128)!!!
> I found a workaround: change that line to
> return u"\n".join((unicode(super(JavaError, self)), u"Java 
> stacktrace:", unicode(writer)))
> ,then it could print the correct stacktrace which contains unicode characters 
> in file path.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PYLUCENE-34) Pylucene and multiprocessing

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-34.

Resolution: Cannot Reproduce

Please use the pylucene-dev@lucene.apache.org mailing list to ask usage 
questions. Send mail to pylucene-dev-subscr...@lucene.apache.org and follow the 
instructions in the response.

 Pylucene and multiprocessing
 

 Key: PYLUCENE-34
 URL: https://issues.apache.org/jira/browse/PYLUCENE-34
 Project: PyLucene
  Issue Type: Bug
 Environment: pylucene 4.10, java 7, python 2.7.9, jcc 2.21, OS Mac
Reporter: Jose Lopez Veiga
Priority: Minor

 I've built a index that will be used for searching in a multiprocessing 
 python program.
 When I try to search in the index, some queries are ok(first ones), but then 
 the program is blocked in the first seconds of the execution when I use 
 QueryParser.parse or IndexSearcher.search
 I tried all that I can think off but or the program is blocked or I get errors
 What is the best way to use multiprocessing and pylucene? I can't find a 
 example or tutorial about this.
 Thank you for your help.
 EDIT: I found that the block happend when I import nltk, only in 
 multriprocessing.
 is this a reported bug?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PYLUCENE-33) Cannot override newTermQuery method of class QueryParser

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-33.

Resolution: Not a Problem

works fine, see patch.

 Cannot override newTermQuery method of class QueryParser
 

 Key: PYLUCENE-33
 URL: https://issues.apache.org/jira/browse/PYLUCENE-33
 Project: PyLucene
  Issue Type: Bug
 Environment: ubuntu 12.04, python 2.7
Reporter: iceout
 Attachments: patch.newTermQuery.txt


 I want to override the newTermQuery method of class QueryParser.
 First, I add the following code in 
 org/apache/pylucene/queryparser/classic/PythonQueryParser.java.
 protected native Query newTermQuery(Term term);
 But it said:
 lucene.JavaError: 
 org.apache.jcc.PythonException:java.lang.UnsatisfiedLinkError: 
 org.apache.pylucene.queryparser.classic.PythonQueryParser.newTermQuery
 Then I changed the code:
 public native Query newTermQuery(Term term);
 But there still is a Exception:
 lucene.JavaError: org.apache.jcc.PythonException: 
 org.apache.jcc.PythonException: (type 'PayloadTermQuery', '__init__', 
 (Term: body:fox, type 'AveragePayloadFunction'))
 My python is:
 class PayloadQueryParser(PythonQueryParser):
 def __init__(self, matchVersion, f, a):
 super(PayloadQueryParser, self).__init__(matchVersion, f, a)
 def getFieldQuery_quoted(self, field, queryText, quoted):
 return super(PayloadQueryParser, 
 self).getFieldQuery_quoted_super(field, queryText, quoted)
 def newTermQuery(self, term):
 return PayloadTermQuery(term, AveragePayloadFunction)
  
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PYLUCENE-33) Cannot override newTermQuery method of class QueryParser

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257809#comment-14257809
 ] 

Andi Vajda commented on PYLUCENE-33:


Please, see comments on pylucene-dev@lucene.apache.org mailing list.
For questions, please contact the list instead of filing a bug.

 Cannot override newTermQuery method of class QueryParser
 

 Key: PYLUCENE-33
 URL: https://issues.apache.org/jira/browse/PYLUCENE-33
 Project: PyLucene
  Issue Type: Bug
 Environment: ubuntu 12.04, python 2.7
Reporter: iceout

 I want to override the newTermQuery method of class QueryParser.
 First, I add the following code in 
 org/apache/pylucene/queryparser/classic/PythonQueryParser.java.
 protected native Query newTermQuery(Term term);
 But it said:
 lucene.JavaError: 
 org.apache.jcc.PythonException:java.lang.UnsatisfiedLinkError: 
 org.apache.pylucene.queryparser.classic.PythonQueryParser.newTermQuery
 Then I changed the code:
 public native Query newTermQuery(Term term);
 But there still is a Exception:
 lucene.JavaError: org.apache.jcc.PythonException: 
 org.apache.jcc.PythonException: (type 'PayloadTermQuery', '__init__', 
 (Term: body:fox, type 'AveragePayloadFunction'))
 My python is:
 class PayloadQueryParser(PythonQueryParser):
 def __init__(self, matchVersion, f, a):
 super(PayloadQueryParser, self).__init__(matchVersion, f, a)
 def getFieldQuery_quoted(self, field, queryText, quoted):
 return super(PayloadQueryParser, 
 self).getFieldQuery_quoted_super(field, queryText, quoted)
 def newTermQuery(self, term):
 return PayloadTermQuery(term, AveragePayloadFunction)
  
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PYLUCENE-32) pylucene CharArraySet jvm error

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14174698#comment-14174698
 ] 

Andi Vajda commented on PYLUCENE-32:


There is no class org/apache/lucene/analysis/CharArraySet in the current
version of Lucene Core (4.10.1) but there is a CharArraySet class in the
util package of the analysis package:   
  org/apache/lucene/analysis/util/CharArraySet  

You are probably mixing versions of Lucene Core and your own that are not   
compatible.

 pylucene CharArraySet jvm error
 ---

 Key: PYLUCENE-32
 URL: https://issues.apache.org/jira/browse/PYLUCENE-32
 Project: PyLucene
  Issue Type: Question
 Environment: I added a customized lucene analyzer class to lucene 
 core in Pylucene. This class is google guava as a dependency because of the 
 array handling function available in com.google.common.collect.Iterables in 
 guava. When I tried to index using this analyzer, I got the following error: 
 Traceback (most recent call last): File C:\IndexFiles.py, line 78, in 
 lucene.initVM() JavaError: java.lang.NoClassDefFoundError: 
 org/apache/lucene/analysis/CharArraySet Java stacktrace: 
 java.lang.NoClassDefFoundError: org/apache/lucene/analysis/CharArraySet 
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.lucene.analysis.CharArraySet at 
 java.net.URLClassLoader$1.run(URLClassLoader.java:366) at 
 java.net.URLClassLoader$1.run(URLClassLoader.java:355) at 
 java.security.AccessController.doPrivileged(Native Method) at 
 java.net.URLClassLoader.findClass(URLClassLoader.java:354) at 
 java.lang.ClassLoader.loadClass(ClassLoader.java:425) at 
 sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at 
 java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 Even the example indexing code in Lucene in Action that I tried earlier and 
 worked, when I retried it after adding this class is returning the same error 
 above. Am not too familiar with CharArraySet class as I can see the problem 
 is from it. How do i handle this? Thanks
Reporter: Alex





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PYLUCENE-31) JCC Parallel/Multiprocess Compilation + Caching

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126652#comment-14126652
 ] 

Andi Vajda commented on PYLUCENE-31:


I did indeed eventually forget about this issue. My apologies.
My reservations about maintaining more monkey patches still stand but I need to 
review the patch to see how 'bad' it actually is.

 JCC Parallel/Multiprocess Compilation + Caching
 ---

 Key: PYLUCENE-31
 URL: https://issues.apache.org/jira/browse/PYLUCENE-31
 Project: PyLucene
  Issue Type: Improvement
 Environment: Linux 3.11.0-19-generic #33-Ubuntu SMP x86_64 GNU/Linux
Reporter: Lee Skillen
Priority: Minor
  Labels: build, cache, ccache, distutils, jcc, parallel
 Attachments: feature-parallel-build.patch


 JCC utilises distutils.Extension() in order to build JCC itself and the 
 packages that it generates for Java wrapping - Unfortunately distutils 
 performs its build sequentially and doesn't take advantage of any additional 
 free cores for parallel building.  As discussed on the list this is likely a 
 design decision due to potential issues that may arise when building projects 
 with awkward, cyclic or recursive dependencies.
 These issues shouldn't appear within JCC-based projects because of the 
 generative nature of the build; i.e. all dependencies are resolved and 
 generated prior to building, and the build process itself is about 
 compilation and construction of the wrapper alone, of which the wrapper files 
 are contained to a sequence of flattened compilation units.
 Enabling this requires monkey patching of distutils, which was also discussed 
 on the list as being a potential source of issues, although we feel that the 
 risk is likely lower than the current setuptools patching utilised.  This 
 would be optional functionality that is also only enabled if the 
 monkey-patching succeeds.  Distutils itself is also part of the standard 
 library and might be less susceptible to change than setuptools, and the area 
 of code monkey patched almost hasn't changed since 2002 (see: 
 http://hg.python.org/cpython/file/tip/Lib/distutils/ccompiler.py).
 In addition to the distutils changes this patch also includes changes to the 
 wrapper class generation to make it more cache friendly, with the target 
 being that no changes in the wrapped code equals no changes in the wrapper 
 code.  So any changes that minimally change the wrapped code mean that with a 
 tool such as ccache the rebuild time would be significantly reduced (almost 
 to a nth, where n is the number of files and only one has changed).
 Obviously the maintainers would have to assess this risk and decide whether 
 they would like to accept the patch or not.  Code has only been tested on 
 Linux with Python 2.7.5 but should gracefully fail and prevent 
 parallelisation if one of the requirements hasn't been met (not on linux, no 
 multiprocessing support, or monkey patching somehow fails).  The change to 
 caching should still benefit everyone regardless.
 Please note that an additional dependency on orderedset has been added to 
 achieve the more deterministic ordering - This may not be desirable (i.e. 
 another package might be desired, such as ordered-set, or the code might be 
 inlined into the package instead), as per maintainer comments.
 --- [following repeated from mailing list] ---
 Performance Statistics :-
 The following are some quick and dirty statistics for building the jcc 
 pylucene itself (incl. java lucene which accounts for about 30-ish seconds 
 upfront) - The JCC files are split using --files 8, and each build is 
 preceded with a make clean:
 Serial (unpatched):
 real5m1.502s
 user5m22.887s
 sys 0m7.749s
 Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs):
 real1m37.382s
 user7m16.658s
 sys 0m8.697s
 Furthermore, some additional changes were made to the wrapped file generation 
 to make the generated code more ccache friendly (additional deterministic 
 sorting for methods and some usage of an ordered set).  With these in place 
 and the CC and CCACHE_COMPILERCHECK environment variables set to ccache gcc 
 and content respectively, and ensuring ccache is installed, subsequent 
 compilation time is reduced again as follows:
 Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs, ccache 
 enabled):
 real0m43.051s
 user1m10.392s
 sys 0m4.547s
 This was a run in which nothing changed between runs, so a realistic run in 
 which changes occur it'll be a figure between 0m43.051s and 1m37.382s, 
 depending on how drastic the change was. If many changes are expected and you 
 want to keep it more cache friendly then using a higher --files would 
 probably work (to an extent), or ideally use --files 

[jira] [Resolved] (PYLUCENE-30) JCC: Through-Layer Python Exception Support

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-30.


Resolution: Fixed

Thank you Lee for the contribution.
This just got committed to JCC's trunk rev 1613934.


 JCC: Through-Layer Python Exception Support
 ---

 Key: PYLUCENE-30
 URL: https://issues.apache.org/jira/browse/PYLUCENE-30
 Project: PyLucene
  Issue Type: Improvement
 Environment: Linux 3.11.0-19-generic #33-Ubuntu SMP x86_64 GNU/Linux
 JCC version 2.20 (svn trunk)
Reporter: Lee Skillen
  Labels: exception, jcc, python
 Attachments: feature-thru-exception-3.patch, jccthrutest.tgz


 Add the capability to throw and re-capture the original Python exception when 
 thrown from the PythonVM layer (e.g. in an extension), passed through the 
 JavaVM, and re-caught within the host PythonVM.  Informally entitled as 
 through-layer python exception support.
 Work between myself and Andi Vajda has been conducted to add support for 
 this, with the original patch being submitted on the mailing list on Friday, 
 4th July 2014 - The latest patch which incorporates suggested code by Andi 
 was posted to the list on Thursday, 10th July (this patch will also be 
 attached to this issue).
 See: JCC Project Extensions email thread on the mailing list for more details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (PYLUCENE-29) JCC: JArray('int') from integer numpy ndarray not possible

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-29.


Resolution: Cannot Reproduce

I installed numpy 1.8.0 via easy-install from pypi and I can't reproduce the 
issue. It works fine for me with jcc 2.18, python 2.7, Oracle Java 1.7 64 bits:

   import numpy as np 
   from lucene import JArray, initVM
   initVM()
  jcc.JCCEnv object at 0x10029c138
   a = np.asarray([1.,2.,3.]).astype(np.double) 
   a
  array([ 1.,  2.,  3.])
   JArray('double')(a) 
  JArraydouble[1.0, 2.0, 3.0]
   a = np.asarray([1,2,3]).astype(np.int0) 
   JArray('int')(a) 
  JArrayint[1, 2, 3]
   from lucene import JCC_VERSION
   JCC_VERSION
  '2.18'

 JCC: JArray('int') from integer numpy ndarray not possible
 --

 Key: PYLUCENE-29
 URL: https://issues.apache.org/jira/browse/PYLUCENE-29
 Project: PyLucene
  Issue Type: Bug
 Environment: JCC-2.18, numpy-1.7.1, Java-1.7.0.25, Linux 64Bit
Reporter: Martin Scherer
  Labels: jcc

 One can properly directly convert numpy double arrays to JArrays, but numpy 
 integer arrays have to be converted to a Python list before. Else one would 
 receive a type error. The following code snippet shows the error:
 ##
 import numpy as np
 from emma2.util.pystallone import JArray, initVM
 if __name__ == '__main__':
 a = np.asarray([1.,2.,3.]).astype(np.double)
 print a
 print JArray('double')(a)
 a = np.asarray([1,2,3]).astype(np.int0)
 print JArray('int')(a)
 #
 Output:
 [ 1.  2.  3.]
 JArraydouble[1.0, 2.0, 3.0]
 Traceback (most recent call last):
   File minimal_example_int_convert_fails.py, line 14, in module
 print JArray('int')(a)
 TypeError: 1
 But this works:
 JArray('int')(a.tolist())
 Since I did not manage to figure out this behaviour, I'am filing this issue. 
 If it has a simple solution please let me know and close this one.
 Thanks in advance,
 Best - Martin



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (PYLUCENE-28) JCC reuses JVM instances in impl, if compile() is called twice.

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812882#comment-13812882
 ] 

Andi Vajda commented on PYLUCENE-28:


A couple of comments. Your patch introduces a silent failure: if the second 
invocation of initVM() is made with different parameters (in particular, with a 
different classpath) people are going to be tearing their hair out with odd 
class loading errors because the 'second' classpath didn't take. Your patch 
should at least make sure that the classpath in the second invocation either 
matches the first or that the second classpath is forced into the existing VM 
(possible but hacky).

I didn't intend jcc to be used this way because of the one Java VM per process 
limitation and I thus consider your bug a feature request. It's a worthwhile 
feature nonetheless but it needs to be implemented more solidly. 

Maybe a better way to support this would be to introduce a new entrypoint in 
cpp.py that takes a VMEnv. That way, there is no silent failure possible, the 
user knows what VMEnv they have and passed in. Or maybe the jcc() function 
could take an optional VMEnv parameter - and check that no VM configuration 
params are passed in via args (and error if there are) in that case ?


 JCC reuses JVM instances in impl, if compile() is called twice.
 ---

 Key: PYLUCENE-28
 URL: https://issues.apache.org/jira/browse/PYLUCENE-28
 Project: PyLucene
  Issue Type: Improvement
 Environment: jcc-svn-head (2.18-pre)
Reporter: Martin Scherer
Priority: Blocker
  Labels: patch
 Attachments: jvm_instance_check.patch


 If you import jcc.cpp to call compile yourself (a wrapped setup.py script to 
 generate a wrapper on the fly, which seems to be a common use case), the 
 current version complains about the JVM already being initialized before.
 The patch first checks for a running instance and creates one, if none is 
 being found.
 For myself, this is a blocker, since it raises otherwise.
 Best, 
 Martin



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (PYLUCENE-27) JCC should be able to create sdist archives

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812887#comment-13812887
 ] 

Andi Vajda commented on PYLUCENE-27:


By source code, did you mean the C++ code produced by JCC ?
You said on the list that moving this source code into a non-build directory 
solves the problem.
Did you try this ? Do you have a patch that fixes this problem ?
Creating source distributions from JCC output is an interesting use case that 
would be nice to support. But if JCC is then out of the picture to compile this 
source distribution, how does distutils/setuptools know where the JVM is ? (and 
all the necessary include and link flags) How does it know where libjcc is ? 
(if shared mode is desired)
It might still be 'simpler' to just use JCC to do the build from .java files, 
then no ?


 JCC should be able to create sdist archives
 ---

 Key: PYLUCENE-27
 URL: https://issues.apache.org/jira/browse/PYLUCENE-27
 Project: PyLucene
  Issue Type: Wish
 Environment: jcc-svn-head
Reporter: Martin Scherer

 I was not able to create a complete (in terms one is able to compile and 
 install the desired wrapper) source distribution.
 I've tried following calls:
   python -m jcc --jar foo  --egg-info --extra-setup-arg sdist
 and
  python -m jcc --jar foo --extra-setup-arg sdist
 Both create archives only containing the egg-info and setup.py but no source 
 code at all.
 I really need this feature for my testing environment with tox, since this 
 heavily depends on the sdist feature.
 thanks,
 best,
 Martin



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (PYLUCENE-27) JCC should be able to create sdist archives

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810843#comment-13810843
 ] 

Andi Vajda commented on PYLUCENE-27:


I have no idea how to do this or if this is even possible (I assume so).
A patch implementing this would be more than welcome.

 JCC should be able to create sdist archives
 ---

 Key: PYLUCENE-27
 URL: https://issues.apache.org/jira/browse/PYLUCENE-27
 Project: PyLucene
  Issue Type: Wish
 Environment: jcc-svn-head
Reporter: Martin

 I was not able to create a complete (in terms one is able to compile and 
 install the desired wrapper) source distribution.
 I've tried following calls:
   python -m jcc --jar foo  --egg-info --extra-setup-arg sdist
 and
  python -m jcc --jar foo --extra-setup-arg sdist
 Both create archives only containing the egg-info and setup.py but no source 
 code at all.
 I really need this feature for my testing environment with tox, since this 
 heavily depends on the sdist feature.
 thanks,
 best,
 Martin



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (PYLUCENE-26) extern keyword missing in reserved keywords in JCC cpp.py unit

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-26.


Resolution: Fixed

rev 1521851
Thank you for the patch.


 extern keyword missing in reserved keywords in JCC cpp.py unit
 

 Key: PYLUCENE-26
 URL: https://issues.apache.org/jira/browse/PYLUCENE-26
 Project: PyLucene
  Issue Type: Bug
 Environment: jcc-svn-head
Reporter: Martin
Priority: Minor
  Labels: patch
 Attachments: extern.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 The python unit cpp.py misses the reserved c++ keyword extern, which leads 
 to problems

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PYLUCENE-25) JCC: NameError: global name 'StringWriter' is not defined occurs when java exception raised

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685804#comment-13685804
 ] 

Andi Vajda commented on PYLUCENE-25:


Which version of jcc are you using ?
The __init__.py file I'm looking at right now ends with these two lines::

from _lucene import *
from java.io import PrintWriter, StringWriter

How does your look ?


 JCC: NameError: global name 'StringWriter' is not defined occurs when java 
 exception raised
 -

 Key: PYLUCENE-25
 URL: https://issues.apache.org/jira/browse/PYLUCENE-25
 Project: PyLucene
  Issue Type: Bug
Reporter: Ilia Meerovich
  Labels: jcc

 I used jcc and tried to run generated python code.
 I noticed that when java exception occurs, python throws NameError exception:
 NameError: global name 'StringWriter' is not defined
 It looks like __init__.py needs to adapt to the full names features.
 I found that somebody already sent an email regards similar failure:
 http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/201302.mbox/%3Calpine.OSX.2.01.1302041320590.1972@yuzu.local%3E

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PYLUCENE-24) Shared JCC object on Linux requires setuptools patch

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-24.


Resolution: Fixed

Thank you, Caleb, I applied your patch.
I simplified the setup.py logic a bit as require('setuptools') seems to work 
also on distribute.
Changes are checked into trunk rev 1396894.


 Shared JCC object on Linux requires setuptools patch
 

 Key: PYLUCENE-24
 URL: https://issues.apache.org/jira/browse/PYLUCENE-24
 Project: PyLucene
  Issue Type: Bug
 Environment: Linux
Reporter: Caleb Burns
  Labels: build, jcc, linux, pylucene, python
 Attachments: jcc-linux.patch

   Original Estimate: 0h
  Remaining Estimate: 0h

 The current method to build JCC as a shared object on Linux requires patching 
 the setuptools package. Here's a patch to JCC that monkey-patches the 
 setuptools Library and Extension classes to avoid the manual patch. It works 
 with setuptools-0.6c7-11 and distribute-0.6.1+ without the need of manually 
 patching setuptools. These are the same versions that the current manual 
 patches work with: patch.43.0.6c7 works with setuptools-0.6c7-10 and 
 distribute-0.6.1+ while patch.43.0.6.c11 works with setuptools-0.6c11.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PYLUCENE-23) OSError

[Andi Vajda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-23.


Resolution: Invalid

please ask questions about build issues on the pylucene-dev@lucene.apache.org 
mailing list (and subscribe to the list first by sending mail to 
pylucene-dev-subscr...@lucene.apache.org and following the instructions you get 
in the response).

 OSError
 ---

 Key: PYLUCENE-23
 URL: https://issues.apache.org/jira/browse/PYLUCENE-23
 Project: PyLucene
  Issue Type: Bug
 Environment: ubuntu12.04 python2.7
Reporter: goog cheng

 after type sudo python setup.py build , and terminal outputs:
 googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo 
 python setup.py build
 /usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension 
 options: 'force_shared'
   warnings.warn(msg)
 Traceback (most recent call last):
   File setup.py, line 382, in module
 main('--debug' in sys.argv)
   File setup.py, line 327, in main
 raise type(e), %s: %s %(e, args)
 OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes', 
 'java/org/apache/jcc/PythonVM.java', 
 'java/org/apache/jcc/PythonException.java']

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira