Re: Where to report issues with lucene/pylucene

[Andi Vajda]

On Sun, 7 Jan 2024, Bob Kline wrote:


On Sun, Jan 7, 2024 at 7:10 AM Bob Kline  wrote:

I figured out how to get past all the problems I ran into, and was finally
able to get the package built and installed. Afterwards I captured notes on
the process so if I (or a colleague) needs to do this again, we'll have a
head start. I'm sharing these notes (attached) in case any of the
information might suggest improvements to the instructions page
. Feel free to use or
ignore any of these notes as you think appropriate.


Thank you for your notes. Replies inline:


Skip over the "For the Impatient Ones" section. Those steps won't work
because the Makefile must be edited first.


Well, the steps said to edit setup.py and Makefile to match your environment 
except that the markup on the site was bogus for those lines and these 
instructions were not rendered :-(

I fixed that now: https://lucene.apache.org/pylucene/install.html


The build will not be able to use the Ubuntu distro's jcc, because it's
not built to support the --shared option.


I wasn't aware that Ubuntu has a prebuilt package for JCC now. If it is not 
built with --shared then you can't use shared mode for PyLucene. If all you 
need/want is build PyLucene and no other wrappers later around other JARs 
for use in the same VM, then you can skip shared mode and drop --shared 
from the JCC invocations.



The makefile needs help finding the JDK libraries.


This shouldn't be necessary as JCC, when setup.py is edited as required, 
will populate that information.



sudo make test


I would stronly recommend using a python virtual environment (venv) so that 
you don't pollute the system python with your work. This doesn't require 
root nor later careful cleanup of the system python installation should 
something go wrong. Yes, 20 years ago, when PyLucene/JCC were started, venv 
wasn't as much of a thing but nowadays it's very good practice.



All of the tests pass except one:


I wonder what version of PyICU you have installed. I just verified that 
tests do all pass if you do _not_ have PyICU installed.


Andi..

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

Re: Where to report issues with lucene/pylucene

[Andi Vajda]

On Jan 7, 2024, at 15:57, Bob Kline  wrote:I tried to sign up with ASF's JIRA system but got the messageThe project you have selected does not use Jira for issue tracking. Please contact the project at dev@lucene.apache.org to find out where to submit issues.https://issues.apache.org/jira/projects/PYLUCENEI'm trying to build pylucene on Ubuntu but I'm getting an error message which is a little bit opaque. jar lucene-java-9.7.0/lucene/core/build/runtimeJars/lucene-core-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/common/build/runtimeJars/lucene-analysis-common-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/backward-codecs/build/runtimeJars/lucene-backward-codecs-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/classification/build/runtimeJars/lucene-classification-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/codecs/build/runtimeJars/lucene-codecs-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/expressions/build/runtimeJars/lucene-expressions-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/extensions/build/runtimeJars/lucene-extensions-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/facet/build/runtimeJars/lucene-facet-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/grouping/build/runtimeJars/lucene-grouping-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/highlighter/build/runtimeJars/lucene-highlighter-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/join/build/runtimeJars/lucene-join-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/kuromoji/build/runtimeJars/lucene-analysis-kuromoji-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/memory/build/runtimeJars/lucene-memory-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/misc/build/runtimeJars/lucene-misc-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/monitor/build/runtimeJars/lucene-monitor-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/nori/build/runtimeJars/lucene-analysis-nori-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/queries/build/runtimeJars/lucene-queries-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/queryparser/build/runtimeJars/lucene-queryparser-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/sandbox/build/runtimeJars/lucene-sandbox-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/spatial3d/build/runtimeJars/lucene-spatial3d-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/stempel/build/runtimeJars/lucene-analysis-stempel-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/suggest/build/runtimeJars/lucene-suggest-9.7.0-SNAPSHOT.jar  --use_full_names --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/antlr4-runtime-4.11.1.jar --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/asm-7.2.jar --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/asm-commons-7.2.jar --include lucene-java-9.7.0/lucene/facet/build/runtimeJars/hppc-0.9.1.jar --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.function --package java.util.regex --package java.io java.io.StringReader --package java.nio.file java.nio.file.Path java.nio.file.Files java.nio.file.Paths --package org.antlr.v4.runtime --package org.antlr.v4.runtime.atn --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --exclude org.apache.lucene.misc.store.WindowsDirectory --exclude org.apache.lucene.misc.store.NativePosixUtil --exclude 'module-info' --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractCollection 'size:()I' '-:-' --sequence java.util.AbstractList '-:-' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader org.apache.lucene.analysis.Tokenizer:input --version 9.7.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py  --files  --build Illegal option: lTry `jar --help' for more information.Where should I report issues for this project?https://issues.apache.org/jira/projects/PYLUCENEIf you have questions, just ask on pylucene-...@lucene.apache.org.Andi..Thanks.-- Bob Klinehttps://www.rksystems.commailto:bkl...@rksystems.com

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

> On Nov 9, 2022, at 01:52, Uwe Schindler  wrote:
> 
> Hi Andi,
> 
>> I did that now, and wouldn't have if someone had told me about the branch 
>> change.
> 
> Normally before you push the branch and edit anything, you should do a "git 
> pull" to get latest changes from server. A "git pull" fails with error 
> message if the branch does not exist on server. So normally you would notice 
> the issue. It is exactly like with Subversion, if you update a branch there 
> that no longer exists, you get a 404. The only difference (and that's the 
> pain) on Git: if you push a non-existing branch, it is created on server 
> automatically.
> 
> We changed from master to main long ago, I think at latest when we splitted 
> Lucene/Solr. Sorry for not informing you.

Well, I made a release against 'master' in April of this year and nothing broke 
then.

>>> I will check how to setup branch protection to not allow pushing a master 
>>> branch.
>> 
>> I no longer have a master branch on my system.
> 
> Great!
> 
> No problem, it seems all well again,

Good, thank you for catching and fixing this and sorry for the noise.

Andi..

> 
> Uwe
> 
>> Andi..
>> 
>>> 
>>> Uwe
>>> 
>>> Am 09.11.2022 um 01:42 schrieb Uwe Schindler:
 Hi Andi,
 
 you pushed the "master" branch to lucene-site Git repo, which was outdated 
 and was no longer existing on server. I deleted it because main AND master 
 cause issues with website build and makes it hard to understand what needs 
 to be changed for website updates. Please push your changes to "main" 
 branch! The problem with duplicate branches is that your push removed some 
 stuff from the website.
 
 Your last push was yesterday and that caused havoc: it removed our latest 
 releases from web page because you were overwriting it with an old version.
 
 Please cleanup your local repo and use "main" branch instead. I don't know 
 what changes are now lost by deleting the branch on server. Please add 
 your release of python lucene again on correct branch.
 
 Uwe
 
> Am 28.04.2022 um 02:02 schrieb va...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> vajda pushed a change to branch master
>> in repository https://gitbox.apache.org/repos/asf/lucene-site.git
>> 
>> 
>>at 038f44716 release 9.1.0
>> 
>> This branch includes the following new commits:
>> 
>>   new 038f44716 release 9.1.0
>> 
>> The 1 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>> 
>>> -- 
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Confusing to have main and master branches in lucene-site

[Andi Vajda]

On Wed, 9 Nov 2022, Uwe Schindler wrote:


Ok I deleted it, BUT:

the branch was pushed by Andi in error as he had an old version of master 
branch still on his computer. This also caused issues with website build.


I asked him to redo his changes on correct branch by checking what he 
committed. I think we should add a branch protection.


Yes, my bad here, but I didn't know we switched branches. I updated my notes 
for making a release accordingly. They now say to use branches 'main' and 
'production'.


Andi..



Uwe

Am 09.11.2022 um 01:26 schrieb Uwe Schindler:

I think we forgot to remove it. I will do that in a moment.

Uwe

Am 09.11.2022 um 00:43 schrieb sebb:

The https://github.com/apache/lucene-site repo has both main and
master branches.

This is confusing.

Are both still in use?

Sebb

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


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


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




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

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

On Wed, 9 Nov 2022, Uwe Schindler wrote:

I was able to merge the missing changes into the main branch from production. 
It should be uptodate now. There was some hickup with asf.yaml, too, but 
should be ok now. Website was rebuilt.


Thank you for fixing this !

Please please make sure to NOT push to master branch anymore! Please switch 
to main and pull changes before editing. And delete your local "master" 
branch, too.


I did that now, and wouldn't have if someone had told me about the branch 
change.


I will check how to setup branch protection to not allow pushing a master 
branch.


I no longer have a master branch on my system.

Andi..



Uwe

Am 09.11.2022 um 01:42 schrieb Uwe Schindler:

Hi Andi,

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs 
to be changed for website updates. Please push your changes to "main" 
branch! The problem with duplicate branches is that your push removed some 
stuff from the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


Uwe

Am 28.04.2022 um 02:02 schrieb va...@apache.org:

This is an automated email from the ASF dual-hosted git repository.

vajda pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-site.git


   at 038f44716 release 9.1.0

This branch includes the following new commits:

  new 038f44716 release 9.1.0

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


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



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

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

On Tue, 8 Nov 2022, Andi Vajda wrote:


Hi Uwe,

On Wed, 9 Nov 2022, Uwe Schindler wrote:

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs 
to be changed for website updates. Please push your changes to "main" 
branch! The problem with duplicate branches is that your push removed some 
stuff from the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


My notes said to use the 'master' branch. I can change my notes to use 'main' 
but I need to be told first (!)


All changes are on the 'production' branch as well, so things need not have 
been completely lost ?


My git-fu is limited so I can't reconstruct stuff from git, purely, but I can 
make sure the PyLucene stuff is current in the 'main' and 'production' 
branches. I've now updated my notes to use 'main'.


I did the following in lucene-site.git
  - git checkout main
  - git pull
  - git branch -D master
  - git branch
* main
  production
I then checked the content/pylucene/pylucene_news, content/pages/pylucene
directories as well as the content/pylucene/doap.rdf file (which I fixed 
this morning for a XML tag (my bad)).

All looks fine.
For good measure, I also checked the production branch and it looks fine 
too.


Andi..

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

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

 Hi Uwe,

On Wed, 9 Nov 2022, Uwe Schindler wrote:

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs to 
be changed for website updates. Please push your changes to "main" branch! 
The problem with duplicate branches is that your push removed some stuff from 
the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


My notes said to use the 'master' branch. I can change my notes to use 
'main' but I need to be told first (!)


All changes are on the 'production' branch as well, so things need not have 
been completely lost ?


My git-fu is limited so I can't reconstruct stuff from git, purely, but I 
can make sure the PyLucene stuff is current in the 'main' and 'production' 
branches. I've now updated my notes to use 'main'.


Andi..



Uwe

Am 28.04.2022 um 02:02 schrieb va...@apache.org:

This is an automated email from the ASF dual-hosted git repository.

vajda pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-site.git


   at 038f44716 release 9.1.0

This branch includes the following new commits:

  new 038f44716 release 9.1.0

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


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




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

Re: Fwd: Error when processing doap file https://lucene.apache.org/pylucene/doap.rdf:

[Andi Vajda]

On Tue, 8 Nov 2022, sebb wrote:


Please fix the broken tag here:

https://github.com/apache/lucene-site/blob/7b2112e47026270eac3146d1f46cace64192a144/content/pylucene/doap.rdf#L45


Done, sorry for the breakage.

Andi..



-- Forwarded message -
From: Projects 
Date: Tue, 8 Nov 2022 at 02:00
Subject: Error when processing doap file
https://lucene.apache.org/pylucene/doap.rdf:
To: Site Development 


URL: https://lucene.apache.org/pylucene/doap.rdf
mismatched tag: line 46, column 8
Source: 
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml

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




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

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Andi Vajda]

-1 (PMC, but not a veto)

Why ? As stated earlier, I'm not confortable with depending on GitHub for 
governance. As long as Lucene is an "Apache" project, I'd like Apache 
governance to determine who may or may not participate, not GitHub. I'd like 
Apache to determine what is and is not "acceptable behavior" from project 
participants.


That being said, the reasons for migrating off of Jira are all sound and, as 
an alternative, I propose that we consider moving to an Apache-hosted 
instance of GitLab. We'd still get all the benefits of migrating off of Jira 
but also the benefits of Apache running our infrastructure and setting our 
governance. Feature-wise, GitHub and GitLab are very similar but GitLab 
offers the possibility of self-hosting our instance.


Andi..

On Tue, 31 May 2022, Tomoko Uchida wrote:


Hi everyone!

As we had previous discussion thread [1], I propose migration to GitHub
issue from Jira.
It'd be technically possible (see [2] for details) and I think it'd be good
for the project - not only for welcoming new developers who are not
familiar with Jira, but also for improving the experiences of long-term
committers/contributors by consolidating the conversation platform.

You can see a short summary of the discussion, some stats on current Jira
issues, and a draft migration plan in [2].
Please review [2] if you haven't seen it and vote for this proposal.

The vote will be open until 2022-06-06 16:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

*IMPORTANT NOTE*
I set a local protocol for this vote.
There are 95 committers on this project [3] - the vote will be effective if
it successfully gains more than 15% of voters (>= 15) from committers
(including PMC members). This means, that although only PMC member votes
are counted for the final result, the votes from all committers are
important to make the vote result effective.

If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand the
term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters after
the expanded time limit, I'll cancel this vote regardless of the result.
But why do I set such an extra bar? My fear is that if such things are
decided by the opinions of a few members, the result shouldn't yield a good
outcome for the future. It isn't my goal to just pass the vote [4].

[1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk
[2] https://issues.apache.org/jira/browse/LUCENE-10557
[3] https://projects.apache.org/committee.html?lucene
[4] I'm sorry for being overly cautious, but I have never met in person or
virtually any of the committers (with a very few exceptions), therefore
cannot assess if the vote result is reliable or not unless there is certain
explicit feedback.

Tomoko



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

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

On Mon, 9 May 2022, Gus Heck wrote:


It's been a long time since I've tried to look around in the issue tracker
space. Are there 3rd options that might be easier to use, under our direct
control and perhaps easier to influence. I've not looked at it, what do we
know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
have a nice ASF using it's own software angle...


As I suggested earlier, an Apache hosted version of GitLab might work. I'm 
not sure how different it is from GitHub from the point of view of issue 
tracking but it checks the better control box. The ASF has been hosting all 
our infra for decades, I'm sure they're capable of hosting a GitLab install.
If the Videolan [1] (VLC project) or the ISC [2] (Bind project) can do it, 
so can Apache.


Andi..

[1] https://code.videolan.org/videolan/vlc
[2] https://gitlab.isc.org/isc-projects/bind9


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

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

On Thu, 5 May 2022, Jan Høydahl wrote:

ASF has officially blessed use of github issues as alternative to Jira. 
They are not going to setup a private GitLab or tool X. While GitLab is 
nice, I don't think the main intention with the proposal was to inroduce 
yet another platform where contributors need to register an account and 
learn the UI :)


That's precisely the crux of the disagreement: I want to be able to register 
an account at Apache and *not* GitHub and still be able to contribute. So 
yes, registering accounts in various places makes one's participation in 
them more resilient to auto-banning-without-due-process-nor-recourse.


As for learning the new UI, GitLab and GitHub are very alike.

Is the original Jira -> GitHub move just a change of defaults or are we, 
once moved to GitHub, not letting people use Jira at all anymore ?


Andi..




GitHub issues versions are tracked in "Milestones" - 
https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones 


See example from solr-operator. These issues or PRs were released in v0.5.1: 
https://github.com/apache/solr-operator/milestone/8?closed=1 

Labels are also very flexibl.

Jan


5. mai 2022 kl. 22:18 skrev David Smiley :

Is anyone familiar with using GitHub (or maybe GitLab I suppose) for tracking metadata 
about the issue -- something JIRA excels at?  For example the version of our project that 
a given PR is released in -- aka the JIRA "Fix Version"?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley 


On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida mailto:tomoko.uchida.1...@gmail.com>> wrote:
Hello everyone!

Recently, we relaxed the requirement for creating a Jira issue when opening a pull 
request (LUCENE-10545 ).

As the next and bigger (perhaps ambitious) step, I opened a rough proposal for 
migration to GitHub issue from Jira.
https://issues.apache.org/jira/browse/LUCENE-10557 


According to the INFRA issue for the RocketMQ project (Michael McCandless gave 
the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result 
is needed for the decision.
https://issues.apache.org/jira/browse/INFRA-15702 


Eventually, we'd need a formal vote, but before that, I'd like to hear general 
opinions/thoughts (or feelings) on this topic from developers.

In brief, I think it'd be technically possible and also be good for the project 
- not only for welcoming new developers who are not familiar with Jira, but 
also for improving the experiences of long-term contributors by consolidating 
the conversation platform.
It'll need some administrative work though, I'm willing to work for it if we 
reach an agreement.

Please note that:
* This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
don't aim to reach a conclusion in this thread.
* Let's not discuss "how to migrate existing Jira issues" for now. Once we 
decide the migration will be good for us, then we can try to figure out a reasonable 
solution for technical/administrative matters.

I may be too optimistic about it; but - a bit of stupidness will be needed to 
start such a move, and I'm serious about this proposal :)

Thanks and regards,
Tomoko




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

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

> On May 5, 2022, at 08:49, Tomoko Uchida  wrote:
> 
> 
> It's really interesting to me to hear how others feel comfortable (or 
> discomfortable) with the tools!
> 
> I myself am not an expert of either JIra or GitHub, and actually have no 
> feelings on which tool is better. 
> The only motivation for my proposal was, "consolidate the conversation 
> platform and reduce the context switch between two platforms".
> 
> However, I don't want to narrow the theme of conversation too early, so 
> please freely express your thoughts. 

My main gripe with Jira is that I can't respond to Jira comments via email. I 
have to always use their interface.

Andi..

> 
> Hi Ishan,
> 
> > I'm generally opposed to this idea because GitHub has been known to take 
> > political decisions to cut off access to developers just because of their 
> > nationality/region etc.
> 
> Sorry I haven't heard of such matters for GitHub. Can you please present the 
> reference?
> 
> Tomoko
> 
> 
> 2022年5月6日(金) 0:41 Ishan Chattopadhyaya :
>> (Repeating in public what I mentioned in private)
>> 
>> 
>> I'm generally opposed to this idea because GitHub has been known to take 
>> political decisions to cut off access to developers just because of their 
>> nationality/region etc. As a community, we should stay politically neutral 
>> and not rely on GitHub to decide on our behalf who to exclude from our 
>> community.
>> 
>>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl,  wrote:
>>> Given how JIRA has become a monster of a product with different markup 
>>> syntax for each version, and bugs everywhere (does not even work on 
>>> mobile), I'm no longer the JIRA fan I once was.
>>> 
>>> In Solr we already use github issues for the Solr-Operator sub project 
>>> https://github.com/apache/solr-operator/issues and I believe it has worked 
>>> well. Of course excellent integration with PRs :)
>>> In earlier discussions on this topic, the idea has been shot down with the 
>>> argument of split bug history and migration challenges. But I think you are 
>>> wise to delay the HOW discussion for now.
>>> This discussion should also not be about politics. Some may be opposed to 
>>> Microsoft and GitHub, but as long as the ASF has officially blessed github 
>>> as an official option, i'ts not a very constructive discussion.
>>> The most important decision point on my part is perception by new / young 
>>> users. Look at OpenOffice, they have remained on Bugzilla - are you 
>>> compelled to contribute? :)
>>> 
>>> Jan
>>> 
 5. mai 2022 kl. 04:23 skrev Tomoko Uchida :
 
 Hello everyone!
 
 Recently, we relaxed the requirement for creating a Jira issue when 
 opening a pull request (LUCENE-10545).
 
 As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
 for migration to GitHub issue from Jira.
 https://issues.apache.org/jira/browse/LUCENE-10557
 
 According to the INFRA issue for the RocketMQ project (Michael McCandless 
 gave the pointer in a comment on the issue; thanks!), a PMC agreement or 
 Vote result is needed for the decision.
 https://issues.apache.org/jira/browse/INFRA-15702
 
 Eventually, we'd need a formal vote, but before that, I'd like to hear 
 general opinions/thoughts (or feelings) on this topic from developers.
 
 In brief, I think it'd be technically possible and also be good for the 
 project - not only for welcoming new developers who are not familiar with 
 Jira, but also for improving the experiences of long-term contributors by 
 consolidating the conversation platform. 
 It'll need some administrative work though, I'm willing to work for it if 
 we reach an agreement.
 
 Please note that:
 * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but 
 we don't aim to reach a conclusion in this thread.
 * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
 decide the migration will be good for us, then we can try to figure out a 
 reasonable solution for technical/administrative matters. 
 
 I may be too optimistic about it; but - a bit of stupidness will be needed 
 to start such a move, and I'm serious about this proposal :)
 
 Thanks and regards,
 Tomoko
>>> 

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

> On May 5, 2022, at 08:41, Ishan Chattopadhyaya  
> wrote:
> 
> 
> (Repeating in public what I mentioned in private)
> 
> 
> I'm generally opposed to this idea because GitHub has been known to take 
> political decisions to cut off access to developers just because of their 
> nationality/region etc. As a community, we should stay politically neutral 
> and not rely on GitHub to decide on our behalf who to exclude from our 
> community.

Agreed. My main issue with hosted services like GitHub and others like it is 
that as they there is no due process, very little recourse, when some AI or 
other automated process gets you banned. Again, this is an issue for all such 
services and it's worse the bigger they are. It's also an "all eggs in the same 
basket" problem.
Thus, I prefer to depend on Apache than on GitHub.
If we want to move off of Jira, I think doing so on a self (Apache)-hosted 
instance of GitLab would be a lot better and offer the same enticing eye candy 
and issue/PR integration as GitHub.

Andi..


> 
>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl,  wrote:
>> Given how JIRA has become a monster of a product with different markup 
>> syntax for each version, and bugs everywhere (does not even work on mobile), 
>> I'm no longer the JIRA fan I once was.
>> 
>> In Solr we already use github issues for the Solr-Operator sub project 
>> https://github.com/apache/solr-operator/issues and I believe it has worked 
>> well. Of course excellent integration with PRs :)
>> In earlier discussions on this topic, the idea has been shot down with the 
>> argument of split bug history and migration challenges. But I think you are 
>> wise to delay the HOW discussion for now.
>> This discussion should also not be about politics. Some may be opposed to 
>> Microsoft and GitHub, but as long as the ASF has officially blessed github 
>> as an official option, i'ts not a very constructive discussion.
>> The most important decision point on my part is perception by new / young 
>> users. Look at OpenOffice, they have remained on Bugzilla - are you 
>> compelled to contribute? :)
>> 
>> Jan
>> 
>>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida :
>>> 
>>> Hello everyone!
>>> 
>>> Recently, we relaxed the requirement for creating a Jira issue when opening 
>>> a pull request (LUCENE-10545).
>>> 
>>> As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
>>> for migration to GitHub issue from Jira.
>>> https://issues.apache.org/jira/browse/LUCENE-10557
>>> 
>>> According to the INFRA issue for the RocketMQ project (Michael McCandless 
>>> gave the pointer in a comment on the issue; thanks!), a PMC agreement or 
>>> Vote result is needed for the decision.
>>> https://issues.apache.org/jira/browse/INFRA-15702
>>> 
>>> Eventually, we'd need a formal vote, but before that, I'd like to hear 
>>> general opinions/thoughts (or feelings) on this topic from developers.
>>> 
>>> In brief, I think it'd be technically possible and also be good for the 
>>> project - not only for welcoming new developers who are not familiar with 
>>> Jira, but also for improving the experiences of long-term contributors by 
>>> consolidating the conversation platform. 
>>> It'll need some administrative work though, I'm willing to work for it if 
>>> we reach an agreement.
>>> 
>>> Please note that:
>>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
>>> don't aim to reach a conclusion in this thread.
>>> * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
>>> decide the migration will be good for us, then we can try to figure out a 
>>> reasonable solution for technical/administrative matters. 
>>> 
>>> I may be too optimistic about it; but - a bit of stupidness will be needed 
>>> to start such a move, and I'm serious about this proposal :)
>>> 
>>> Thanks and regards,
>>> Tomoko
>> 

Re: issue with modules while building PyLucene

[Andi Vajda]

On Tue, 4 Jan 2022, Andi Vajda wrote:



On Tue, 4 Jan 2022, Dawid Weiss wrote:


You have to exclude that module-info.class from processing somehow, Andi.
It isn't a proper class indeed. Can jcc accept an exclusion pattern 
somehow?


Oh yes, that's not a problem, just add it via --exclude, let me try that and 
report back.


Yes, that worked like a charm.
PyLucene now builds with Lucene 9x sources and passes its tests.

Thank you for the clue !

Andi..



Andi..



Dawid

On Tue, Jan 4, 2022 at 7:36 PM Andi Vajda  wrote:



  Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its
tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars
Gradle task) and I'm hitting an issue that seems to be related to the new
work around java modules:

   Exception in thread "main" java.lang.NoClassDefFoundError: module-info
is
   not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical
but all JCC is doing with the Lucene jars in order to build PyLucene is to
load them, walk their class trees and, using reflection, generate wrappers
for the publicly accessible methods and some extra ones as well, as listed
in the JCC command line (at line 215 in PyLucene's Makefile here:
   https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question
even make sense ? is there a proper way to do what JCC is doing with
modules
enabled ?)

Thanks !

Andi..

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






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




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

Re: issue with modules while building PyLucene

[Andi Vajda]

On Tue, 4 Jan 2022, Dawid Weiss wrote:


You have to exclude that module-info.class from processing somehow, Andi.
It isn't a proper class indeed. Can jcc accept an exclusion pattern somehow?


Oh yes, that's not a problem, just add it via --exclude, let me try that and 
report back.


Andi..



Dawid

On Tue, Jan 4, 2022 at 7:36 PM Andi Vajda  wrote:



  Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its
tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars
Gradle task) and I'm hitting an issue that seems to be related to the new
work around java modules:

   Exception in thread "main" java.lang.NoClassDefFoundError: module-info
is
   not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical
but all JCC is doing with the Lucene jars in order to build PyLucene is to
load them, walk their class trees and, using reflection, generate wrappers
for the publicly accessible methods and some extra ones as well, as listed
in the JCC command line (at line 215 in PyLucene's Makefile here:
   https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question
even make sense ? is there a proper way to do what JCC is doing with
modules
enabled ?)

Thanks !

Andi..

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






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

issue with modules while building PyLucene

[Andi Vajda]

 Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars 
Gradle task) and I'm hitting an issue that seems to be related to the new 
work around java modules:


  Exception in thread "main" java.lang.NoClassDefFoundError: module-info is
  not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical 
but all JCC is doing with the Lucene jars in order to build PyLucene is to 
load them, walk their class trees and, using reflection, generate wrappers 
for the publicly accessible methods and some extra ones as well, as listed 
in the JCC command line (at line 215 in PyLucene's Makefile here:

  https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question 
even make sense ? is there a proper way to do what JCC is doing with modules 
enabled ?)


Thanks !

Andi..

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

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

On Mon, 3 Jan 2022, Dawid Weiss wrote:


I've applied it to branch_9x and main, Andi.


Thank you, Dawid, I was able to get PyLucene to build and all its tests to 
pass with this code added to Lucene 9.0 from Lucene 9.x.


Andi..



D.

On Mon, Jan 3, 2022 at 6:34 PM Andi Vajda  wrote:



On Mon, 3 Jan 2022, Dawid Weiss wrote:


Hi Andi,

Try this:
https://github.com/apache/lucene/pull/576

if you run 'gradlew collectRuntimeJars' it'll compile module jars but

also

collect any runtime binary dependencies under each project's build

folder.

For example:


ls lucene/analysis/icu/build/runtimeJars

icu4j-70.1.jar
lucene-analysis-icu-10.0.0-SNAPSHOT.jar

Let me know if this works for you and I'll merge with main.


Yes, this is perfect. This is exactly what I was looking for.
Thanks !

Andi..



Dawid

On Sun, Jan 2, 2022 at 11:29 PM Andi Vajda  wrote:



Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build

PyLucene:

   ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
   ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
   ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
   HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for

pylucene

or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the

external

jar files of topic. I don't think a special task is needed for any of

the

Lucene .jar files. For the external ones, maybe ?


2) a separate project that would include all of Lucene sources, build

them

and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the
Lucene jar files using Gradle's jar task.


3) a separate project that would only depend on Lucene binaries and

fetch

whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this

is

what Ivy was doing for us until Lucene 8.x then, yes, something like

that

using Gradle that puts the external jars in a place I can access via a
filesystem path would be great.


I haven't looked at PyLucene's makefiles but if you let me know which

one

of the above works best for you, I'll prepare something on the gradle

side.

If you do something for one of the subprojects (say, the expressions

one),

I
can then extend this to others as needed. From my newbie understanding

of

the Lucene Gradle build, I'd think that an extra task that "persists"

the

external jars somewhere accessible via a simple filesystem path usable
from
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would

be

easiest to consume by the PyLucene build.

Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build

via a

 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra

extensions.jar

in

 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer

available.

They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in

there

but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene

is

not
a Java project), mess with pom.xml files or create a new Gradle

project

for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene

that

replaces its Makefile ? Or is there an easy way for me to request from

the

Lucene Gradle build that these external jar files be put somewhere

more

accessible ? Uwe, you say that they are present in the Luke .tgz ?

What

is

the task that produces the Luke .tgz ? I might just be able to fish

the

.jar
files

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

On Mon, 3 Jan 2022, Dawid Weiss wrote:


Hi Andi,

Try this:
https://github.com/apache/lucene/pull/576

if you run 'gradlew collectRuntimeJars' it'll compile module jars but also
collect any runtime binary dependencies under each project's build folder.
For example:


ls lucene/analysis/icu/build/runtimeJars

icu4j-70.1.jar
lucene-analysis-icu-10.0.0-SNAPSHOT.jar

Let me know if this works for you and I'll merge with main.


Yes, this is perfect. This is exactly what I was looking for.
Thanks !

Andi..



Dawid

On Sun, Jan 2, 2022 at 11:29 PM Andi Vajda  wrote:



Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build PyLucene:
   ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
   ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
   ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
   HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for

pylucene

or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the external
jar files of topic. I don't think a special task is needed for any of the
Lucene .jar files. For the external ones, maybe ?


2) a separate project that would include all of Lucene sources, build

them

and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the
Lucene jar files using Gradle's jar task.


3) a separate project that would only depend on Lucene binaries and fetch
whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this is
what Ivy was doing for us until Lucene 8.x then, yes, something like that
using Gradle that puts the external jars in a place I can access via a
filesystem path would be great.


I haven't looked at PyLucene's makefiles but if you let me know which one
of the above works best for you, I'll prepare something on the gradle

side.

If you do something for one of the subprojects (say, the expressions one),
I
can then extend this to others as needed. From my newbie understanding of
the Lucene Gradle build, I'd think that an extra task that "persists" the
external jars somewhere accessible via a simple filesystem path usable
from
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would be
easiest to consume by the PyLucene build.

Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build

via a

 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra extensions.jar

in

 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer

available.

They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there
but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene is
not
a Java project), mess with pom.xml files or create a new Gradle project
for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene

that

replaces its Makefile ? Or is there an easy way for me to request from

the

Lucene Gradle build that these external jar files be put somewhere more
accessible ? Uwe, you say that they are present in the Luke .tgz ? What

is

the task that produces the Luke .tgz ? I might just be able to fish the
.jar
files out of it then. I tried assembleBinaryTgz but that only makes the
Lucene one and assembleRelease fails for me on checkWorkingCopyClean

since

I
have a bunch of changes not ready to be checked in...

Thank you for your insights !

Andi..


If you have the state of your work (do you use Gradle to build

already?)

we may be able to 

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build PyLucene:
  ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
  ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
  ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
  HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for pylucene
or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the external 
jar files of topic. I don't think a special task is needed for any of the 
Lucene .jar files. For the external ones, maybe ?



2) a separate project that would include all of Lucene sources, build them
and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the 
Lucene jar files using Gradle's jar task.



3) a separate project that would only depend on Lucene binaries and fetch
whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this is 
what Ivy was doing for us until Lucene 8.x then, yes, something like that 
using Gradle that puts the external jars in a place I can access via a 
filesystem path would be great.



I haven't looked at PyLucene's makefiles but if you let me know which one
of the above works best for you, I'll prepare something on the gradle side.


If you do something for one of the subprojects (say, the expressions one), I 
can then extend this to others as needed. From my newbie understanding of 
the Lucene Gradle build, I'd think that an extra task that "persists" the 
external jars somewhere accessible via a simple filesystem path usable from 
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would be 
easiest to consume by the PyLucene build.


Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build via a
 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra extensions.jar in
 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer available.
They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there
but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene is
not
a Java project), mess with pom.xml files or create a new Gradle project
for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene that
replaces its Makefile ? Or is there an easy way for me to request from the
Lucene Gradle build that these external jar files be put somewhere more
accessible ? Uwe, you say that they are present in the Luke .tgz ? What is
the task that produces the Luke .tgz ? I might just be able to fish the
.jar
files out of it then. I tried assembleBinaryTgz but that only makes the
Lucene one and assembleRelease fails for me on checkWorkingCopyClean since
I
have a bunch of changes not ready to be checked in...

Thank you for your insights !

Andi..


If you have the state of your work (do you use Gradle to build already?)
we may be able to help you. You may need to write a Gradle task that

calls

your compiler. See ECJ (calls Java) or Changes2html (calls python) tasks
as examples.

BTW, the jar files are hidden in the Gradle cache folder somewhere in

your

home dir. Bit to access them you need Gradle Apis.

Uwe

Am 31. Dezember 2021 18:24:47 UTC schrieb Uwe Schindler 
Hi,

The Lucene 9.0 binary tgz no longer contains 3rd party dependencies,

unless they are needed to run Luke.


Generally we expect people to parse the pom.xml files and download

artifacts as part of a downstream build. If you are able to use Maven, I'd
recommend

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:

As a Gradle project you can depend on Lucene artifacts and use Gradle Apis 
in your build files.


Until 8.x, PyLucene is built via a Makefile that:
  - calls Ant to build Lucene, building a bunch of jars individually
  - calls Ant to build Lucene extensions (Java classes extending some Lucene
classes with native methods that are then implemented in Python)
  - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
  - inserts the Lucene extension classes into Lucene's Gradle build via a
new subproject called 'extensions'
  - calls Gradle to build all Lucene jars and the extra extensions.jar in
one command: ./gradlew jar
  - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer available.
They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there but 
that seems very brittle as there are multiple versions present there.


If at all possible, I'd like to not create a Maven project (PyLucene is not 
a Java project), mess with pom.xml files or create a new Gradle project for 
PyLucene.


But maybe I should actually create a new Gradle project for PyLucene that 
replaces its Makefile ? Or is there an easy way for me to request from the 
Lucene Gradle build that these external jar files be put somewhere more 
accessible ? Uwe, you say that they are present in the Luke .tgz ? What is 
the task that produces the Luke .tgz ? I might just be able to fish the .jar 
files out of it then. I tried assembleBinaryTgz but that only makes the 
Lucene one and assembleRelease fails for me on checkWorkingCopyClean since I 
have a bunch of changes not ready to be checked in...


Thank you for your insights !

Andi..

If you have the state of your work (do you use Gradle to build already?) 
we may be able to help you. You may need to write a Gradle task that calls 
your compiler. See ECJ (calls Java) or Changes2html (calls python) tasks 
as examples.


BTW, the jar files are hidden in the Gradle cache folder somewhere in your 
home dir. Bit to access them you need Gradle Apis.


Uwe

Am 31. Dezember 2021 18:24:47 UTC schrieb Uwe Schindler :

Hi,

The Lucene 9.0 binary tgz no longer contains 3rd party dependencies, unless 
they are needed to run Luke.

Generally we expect people to parse the pom.xml files and download artifacts as 
part of a downstream build. If you are able to use Maven, I'd recommend to 
create a small Maven Java Project listing the Lucene dependencies and ask it to 
make a complete distribution.

If you have the source distribution, I'd recommend to make pylucene also use 
Gradle to build and then you can consume dependencies.

Uwe

Am 31. Dezember 2021 18:12:55 UTC schrieb Andi Vajda :


 Hi,

I've begun adapting PyLucene to Lucene 9.0 and switching it to using gradle.

The expressions sub-project depends on antlr4 and asm and I'm able to build
all of Lucene 9.0 without explicitely downloading these jar files.

The PyLucene build needs these jar files then to produce wrappers for the
entrypoints into the expressions sub-project classes.

Where are these jar files stored ?
$ find lucene-java-9.0.0 -name '*.jar' | grep antlr
produces nothing.

Thanks !

Andi..

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



--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de


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

where is the antlr4 runtime jar ?

[Andi Vajda]

 Hi,

I've begun adapting PyLucene to Lucene 9.0 and switching it to using gradle.

The expressions sub-project depends on antlr4 and asm and I'm able to build
all of Lucene 9.0 without explicitely downloading these jar files.

The PyLucene build needs these jar files then to produce wrappers for the 
entrypoints into the expressions sub-project classes.


Where are these jar files stored ?
$ find lucene-java-9.0.0 -name '*.jar' | grep antlr
produces nothing.

Thanks !

Andi..

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

Re: [DISCUSS] Sunset the general@l.a.o mailing list?

[Andi Vajda]

On Sun, 28 Feb 2021, Jan Høydahl wrote:


Hi

The general@ list is not being used for practically anything. I see some 
user questions there and we announce releases. It may have had more 
purpose when there were 5 sub projects in Lucene. Now it is more confusing 
users and they do not get timely replies. The list has 1088 subscribers.


I propose to discontinue the list, i.e. make it Read-Only and remove it 
from the web page. Anyone who would miss it?


I've been sending periodic PyLucene release votes there in order not to spam
lucene-dev but I guess I can use lucene-dev instead ?

Andi..

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

Re: [VOTE] Lucene logo contest, third time's a charm

[Andi Vajda]

D (binding)

Andi..

> On Sep 1, 2020, at 12:21, Steve Rowe  wrote:
> 
> D (binding)
> 
> --
> Steve
> 
>> On Sep 1, 2020, at 4:21 PM, Ryan Ernst  wrote:
>> 
>> Dear Lucene and Solr developers!
>> 
>> Sorry for the multiple threads. This should be the last one.
>> 
>> In February a contest was started to design a new logo for Lucene 
>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
>> some confusion on the rules, as well the request for one additional 
>> submission. The second attempt [second-vote] yesterday had incorrect links 
>> for one of the submissions. I would like to call a new vote, now with more 
>> explicit instructions on how to vote, and corrected links.
>> 
>> Please read the following rules carefully before submitting your vote.
>> 
>> Who can vote?
>> 
>> Anyone is welcome to cast a vote in support of their favorite submission(s). 
>> Note that only PMC member's votes are binding. If you are a PMC member, 
>> please indicate with your vote that the vote is binding, to ease collection 
>> of votes. In tallying the votes, I will attempt to verify only those marked 
>> as binding.
>> 
>> How do I vote?
>> 
>> Votes can be cast simply by replying to this email. It is a ranked-choice 
>> vote [rank-choice-voting]. Multiple selections may be made, where the order 
>> of preference must be specified. If an entry gets more than half the votes, 
>> it is the winner. Otherwise, the entry with the lowest number of votes is 
>> removed, and the votes are retallied, taking into account the next preferred 
>> entry for those whose first entry was removed. This process repeats until 
>> there is a winner.
>> 
>> The entries are broken up by variants, since some entries have multiple 
>> color or style variations. The entry identifiers are first a capital letter, 
>> followed by a variation id (described with each entry below), if applicable. 
>> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
>> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, 
>> the following should be in your reply:
>> 
>> (binding)
>> vote: A1, A2, C3, D, B4e
>> 
>> Entries
>> 
>> The entries are as follows:
>> 
>> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>> 
>> [A1] 
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>> 
>> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
>> linked entry there are 7 patterns and 7 color palettes. Any vote for B 
>> should contain the pattern number followed by the lowercase letter of the 
>> color palette. For example, B3e or B1a.
>> 
>> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>> 
>> C. Submitted by Baris Kazar. This entry has 8 variants.
>> 
>> [C1] 
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>> [C2] 
>> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
>> [C3] 
>> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
>> [C4] 
>> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
>> [C5] 
>> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
>> [C6] 
>> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
>> [C7] 
>> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
>> [C8] 
>> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>> 
>> D. The current Lucene logo.
>> 
>> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>> 
>> Please vote for one of the above choices. This vote will close about one 
>> week from today, Mon, Sept 7, 2020 at 11:59PM.
>> 
>> Thanks!
>> 
>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>> [first-vote] 
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>> [second-vote] 
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
>> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
> 

Re: [jira] [Created] (LUCENE-9466) JCC creates the classes in non-deterministic order

[Andi Vajda]

Can you be more specific about "not working" ?
Why does the order of classes matter ?
(thanks!)

> On Aug 16, 2020, at 11:49, Andrea Sterbini (Jira)  wrote:
> 
> Andrea Sterbini created LUCENE-9466:
> ---
> 
> Summary: JCC creates the classes in non-deterministic order
> Key: LUCENE-9466
> URL: https://issues.apache.org/jira/browse/LUCENE-9466
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/tools
>Reporter: Andrea Sterbini
> 
> 
> I am trying to wrap the BabelNet API code.
> 
> The resulting module is non-deterministically not-working (once every 5 I get 
> it OK).
> 
> This seems to be related to the order the classes are handled.
> 
> By changing cpp.py at line 696 to sort the class names I get a working module.
> {code:java}
> // changed from
> for cls in todo:
> {code}
> {code:java}
> // to
> for cls in sorted(todo, key=lambda c: c.getName()):
> {code}
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
> 
> -
> To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
> For additional commands, e-mail: issues-h...@lucene.apache.org
> 


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

Re: [VOTE] Lucene logo contest

[Andi Vajda]

C. (current logo)

Andi.. (pmc)

> On Jun 15, 2020, at 15:08, Ryan Ernst  wrote:
> 
> 
> Dear Lucene and Solr developers!
> 
> In February a contest was started to design a new logo for Lucene [1]. That 
> contest concluded, and I am now (admittedly a little late!) calling a vote.
> 
> The entries are labeled as follows:
> 
> A. Submitted by Dustin Haver [2]
> 
> B. Submitted by Stamatis Zampetakis [3] Note that this has several variants. 
> Within the linked entry there are 7 patterns and 7 color palettes. Any vote 
> for B should contain the pattern number, like B1 or B3. If a B variant wins, 
> we will have a followup vote on the color palette.
> 
> C. The current Lucene logo [4]
> 
> Please vote for one of the three (or nine depending on your perspective!) 
> above choices. Note that anyone in the Lucene+Solr community is invited to 
> express their opinion, though only Lucene+Solr PMC cast binding votes 
> (indicate non-binding votes in your reply, please). This vote will close one 
> week from today, Mon, June 22, 2020.
> 
> Thanks!
> 
> [1] https://issues.apache.org/jira/browse/LUCENE-9221
> [2] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [3] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
> [4] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Andi Vajda]

+1 (binding)

Andi..

> On May 12, 2020, at 00:37, Dawid Weiss  wrote:
> 
> Dear Lucene and Solr developers!
> 
> According to an earlier [DISCUSS] thread on the dev list [2], I am
> calling for a vote on the proposal to make Solr a top-level Apache
> project (TLP) and separate Lucene and Solr development into two
> independent entities.
> 
> To quickly recap the reasons and consequences of such a move: it seems
> like the reasons for the initial merge of Lucene and Solr, around 10
> years ago, have been achieved. Both projects are in good shape and
> exhibit signs of independence already (mailing lists, committers,
> patch flow). There are many technical considerations that would make
> development much easier if we move Solr out into its own TLP.
> 
> We discussed this issue [2] and both PMC members and committers had a
> chance to review all the pros and cons and express their views. The
> discussion showed that there are clearly different opinions on the
> matter - some people are in favor, some are neutral, others are
> against or not seeing the point of additional labor. Realistically, I
> don't think reaching 100% level consensus is going to be possible --
> we are a diverse bunch with different opinions and personalities. I
> firmly believe this is the right direction hence the decision to put
> it under the voting process. Should something take a wrong turn in the
> future (as some folks worry it may), all blame is on me.
> 
> Therefore, the proposal is to separate Solr from under Lucene TLP, and
> make it a TLP on its own. The initial structure of the new PMC,
> committer base, git repositories and other managerial aspects can be
> worked out during the process if the decision passes.
> 
> Please indicate one of the following (see [1] for guidelines):
> 
> [ ] +1 - yes, I vote for the proposal
> [ ] -1 - no, I vote against the proposal
> 
> Please note that anyone in the Lucene+Solr community is invited to
> express their opinion, though only Lucene+Solr committers cast binding
> votes (indicate non-binding votes in your reply, please).
> 
> The vote will be active for a week to give everyone a chance to read
> and cast a vote.
> 
> Dawid
> 
> [1] https://www.apache.org/foundation/voting.html
> [2] 
> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [VOTE] Release PyLucene 8.1.1

[Andi Vajda]

On Mon, 17 Jun 2019, David Allouche wrote:


Thank you, that was very informative.

+0 for this release, I builds and pass my test suite.

But I was unable to make a complete integration test because I do not have 
a proper index format migration infrastructure and my index is made of 
incompletely-upgraded lucene6 and lucene7 segments.


So far, you're the only one who has cast a vote.
No one else, no PMC member, none of the longtime users, no one.

Besides the Apache procedural aspect, voting is also a gauge of interest in 
a project. If there is no user interest in the PyLucene project anymore

maybe it's time to stop making releases for a while ?

PyLucene is a bit special in that it doesn't involve many people for 
development since it is machine-generated by JCC and JCC has been stable for 
a while. In that sense, it is important that actual users of PyLucene make 
themselves known by voting, not much else goes on on the project's mailing 
list or in the source code.


If there are actual users showing interest by voting here, I feel more 
confortable then in nagging people on the Lucene PMC for their procedural 
vote.


Andi..



I will post my questions about index upgrading on 
java-u...@lucene.apache.org <mailto:java-u...@lucene.apache.org>.





Regards.


On 11 Jun 2019, at 16:50, Andi Vajda  wrote:



On Jun 11, 2019, at 06:30, David Allouche  wrote:

This is maybe a silly question, but what is the purpose of this voting process?


By the rules of Apache, three PMC binding votes are needed to make a release. 
In addition, it's a gauge of general interest in the project.


Is this something required by the project governance?


https://www.apache.org/foundation/voting.html
(see "votes on package releases", in particular)


What is the meaning of a vote? Does that mean "I am interested", or does it mean "I 
have tested the latest trunk and it looks good", or something else?


If you find a bug in the release artifacts (not in the latest trunk) before the 
release is made, the release is likely to be pulled.


What is the typical expected delay for reply? For example, I reserve Fridays 
for technical debt management (including upgrading dependencies), so I cannot 
typically validate a new PyLucene version in less than a week.


A vote must run for at least 72 hours.
Because you are not on the PMC, your vote falls into the "interest gauging" category, is 
not binding and is considered "best effort".


This is probably all common questions with well documented answers. If that's 
the case, then it would be nice to have a link to the answers in VOTE requests.


https://www.apache.org/foundation/voting.html

Andi..




On 11 Jun 2019, at 00:39, Andi Vajda  wrote:


The PyLucene 8.1.1 (rc1) release tracking the recent release of
Apache Lucene 8.1.1 is ready.

A release candidate is available from:
https://dist.apache.org/repos/dist/dev/lucene/pylucene/8.1.1-rc1/

PyLucene 8.1.1 is built with JCC 3.5, included in these release artifacts.

JCC 3.5 supports Python 3.3+ (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 8.1.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: Welcome Namgyu Kim as Lucene/Solr committer

[Andi Vajda]

> On Jun 3, 2019, at 21:21, Milind Thombre  wrote:
> 
> I would like to contribute to PyLucene. Please guide me on the
>  next steps

Subscribe to pylucene-dev@ and start a new thread there (don't highjack an 
existing one).

Andi..

> 
>> On Mon, Jun 3, 2019 at 11:22 PM Adrien Grand  wrote:
>> Hi all,
>> 
>> Please join me in welcoming Namgyu Kim as Lucene/ Solr committer!
>> 
>> Kim has been helping address technical debt and fixing bugs in the
>> last year, including a cleanup to our DutchAnalyzer[0] and
>> improvements to the StoredFieldsVisitor API[1]. More recently he also
>> started improving our korean analyzer[2].
>> 
>> [0] https://issues.apache.org/jira/browse/LUCENE-8582
>> [1] https://issues.apache.org/jira/browse/LUCENE-8805
>> [2] https://issues.apache.org/jira/browse/LUCENE-8784
>> 
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>> 
>> -- 
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 

[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)

Re: pylucene on Ubuntu 18.04

[Andi Vajda]

 Hi Jeff,

On Mon, 28 May 2018, Jeff Breidenbach wrote:


To be a little more specific, here's what happens with version 4.9.0
which I've had good luck with in the past. The system contains the
following shared libraries.


Why are you using such an old release ?
I'm afraid that old release is going to depend on equally old everything 
else to function. I don't think Lucene 4.9.0 is even supported with Java 8.


How about you use the pylucene 7.2.0 rc1 release candidate available from
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.2.0-rc1/
instead ?

Andi..



/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so

It looks like LFLAGS in jcc/setup.py should find them. I'm on the
linux2/X86_64 platform, using '/usr/lib/jvm/java-8-openjdk-amd64'
for the JDK. JCC builds and installs without complaint, but fails at
runtime.

Traceback (most recent call last):
 File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
   mod_name, _Error)
 File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
   __import__(mod_name)  # Do not catch exceptions initializing package
 File
"/usr/local/lib/python2.7/dist-packages/JCC-2.20-py2.7-linux-x86_64.egg/jcc/__init__.py",
line 31, in 
   from jcc import _jcc
ImportError: libjvm.so: cannot open shared object file: No such file or
directory

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Andi Vajda]

On Wed, 17 May 2017, Ishan Chattopadhyaya wrote:


Please vote for release candidate 1 for Lucene/Solr 6.6.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e



Something strange with the links in this message. They refer to both 6.6.0 
and 6.5.0 ?


Andi..



You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e


Here's my +1
SUCCESS! [0:32:20.501484]



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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Andi Vajda]

On Tue, 21 Mar 2017, jim ferenczi wrote:


Please vote for release candidate 1 for Lucene/Solr 6.5.0


+1

I checked out branch_6_5 and built PyLucene with it, all tests pass.

Andi..



The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95

Here's my +1
SUCCESS! [0:49:02.989006]



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

Re: python 3 support is checked into trunk

[Andi Vajda]

On Mon, 20 Mar 2017, Ruediger Meier wrote:


On Sunday 19 March 2017, Andi Vajda wrote:

I just now checked in support for Python 3 (3.5+),


Thanks a lot!


built and tested
on Mac OS X 10.12 only, with Python 3.6.


FYI I've tested a HelloWorld.jar using your svn trunk on travis build
farm for OSX 10.11 and xcode 7.3, 8, 8.1, 8.2:
https://travis-ci.org/rudimeier/jcc/builds/212820385


Linux support should be next.


It would work already on Linux with this patch
https://github.com/rudimeier/jcc/commit/2ccf7e4b828c678577fc0ace24bdb4680ede207a


I changed linux2 to linux but still need to see what kind of setuptools 
patching/monkeypatching hackery is needed to produce a usable libjcc.so.


Thanks !

Andi..



plus fixing -ljcc and -lpython soname.

BTW support for python >=3.3 would be nice and very easy. We just need
one define like this in macros.h:

#if PY_VERSION_HEX < 0x0305
#define Py_DecodeLocale(_arg_, _size_) _Py_char2wchar(_arg_, _size_)
#endif

... as you see here a huge Ubuntu 14.04 build matrix
https://travis-ci.org/rudimeier/jcc/builds/212830434


Someone with access to Windows, please help test/fix/finish support
for Python 3 on Windows, both with the MSVC and Mingw compilers. I
have no access to Windows anymore.


I know already about one MSVC issue:
https://github.com/rudimeier/jcc/issues/1

probably fixed by
https://github.com/rudimeier/jcc/commit/764ed0dc1f77c68e4a6998688d2e8340704fd237
(But this fix is also not tested yet.)

cu,
Rudi

Re: python 3 support is checked into trunk

[Andi Vajda]

On Mon, 20 Mar 2017, Ruediger Meier wrote:


On Sunday 19 March 2017, Andi Vajda wrote:

I just now checked in support for Python 3 (3.5+),


Thanks a lot!


built and tested
on Mac OS X 10.12 only, with Python 3.6.


FYI I've tested a HelloWorld.jar using your svn trunk on travis build
farm for OSX 10.11 and xcode 7.3, 8, 8.1, 8.2:
https://travis-ci.org/rudimeier/jcc/builds/212820385


Linux support should be next.


It would work already on Linux with this patch
https://github.com/rudimeier/jcc/commit/2ccf7e4b828c678577fc0ace24bdb4680ede207a

plus fixing -ljcc and -lpython soname.

BTW support for python >=3.3 would be nice and very easy. We just need
one define like this in macros.h:

#if PY_VERSION_HEX < 0x0305
#define Py_DecodeLocale(_arg_, _size_) _Py_char2wchar(_arg_, _size_)
#endif


Added to jcc.cpp since that't the only place this is used.


... as you see here a huge Ubuntu 14.04 build matrix
https://travis-ci.org/rudimeier/jcc/builds/212830434


Someone with access to Windows, please help test/fix/finish support
for Python 3 on Windows, both with the MSVC and Mingw compilers. I
have no access to Windows anymore.


I know already about one MSVC issue:
https://github.com/rudimeier/jcc/issues/1

probably fixed by
https://github.com/rudimeier/jcc/commit/764ed0dc1f77c68e4a6998688d2e8340704fd237
(But this fix is also not tested yet.)


I changed strhash to use Py_hash_t.

Andi..



cu,
Rudi

Re: MSDN subscription renewal

[Andi Vajda]

> On Feb 2, 2017, at 01:06, Dawid Weiss  wrote:
> 
> I've been trying to get my MSDN subscription renewed (useful for
> testing on various flavors of Windows) and unfortunately I failed. I
> didn't hear back from Ross Gardler
> (https://svn.apache.org/repos/private/committers/donated-licenses/msdn.txt)
> and Microsoft support doesn't know anything about this donated
> license.
> 
> Was anybody successful at getting MSDN access updated (say, since
> approximately last September)?

Same here, I sent mail requesting a renewal following the instructions I was 
able to dig up and got no response. 

Andi..

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


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

[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&focusedCommentId=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

Re: Installing PyLucene

[Andi Vajda]

> On Jan 12, 2017, at 02:37, Thomas Koch  wrote:
> 
> Dear Andi,
> 
> many thanks for your review of the patch and helpful comments.
> 
> As mentioned in my previous mail to the list I’m afraid to let you know that 
> we currently cannot put more effort into this task. This may change in the 
> future of course.

That's ok. This is also how I feel.

> However, with „funding“ my idea was to look for open source funding such as 
> provided by the Python Software Foundation (e.g.):
> https://www.python.org/psf/grants
> 
> That’s probably worth a try - especially because the PSF is well known, has 
> some sponsors and also receives donations by companies using Python and 
> Python related projects on regular basis…

For me, it's not a problem of money but of time.
Whether I hire someone to do the work or do it myself, the same amount of time 
has to be spent dealing with the issue. Hiring someone and finding money takes 
time too. Probably more than integrating your patch, actually.

The way open source works is usually by donation of time, not money or code. 
This is why your code donation is going to sit there until someone spends the 
_time_ to integrate it.

>> Thank you for the work done so far, it's looking really good but it needs to
>> be refreshed to JCC/trunk and latest Python 3 to minimize work on my side.
> 
> Ok. Maybe ASF could contact PSF and ask for such a grant that could be uses 
> to 
>>hire back the contractor who did the JCC Python 3 port originally and have
>>him/her refresh it for the latest JCC on trunk
> ? (If he/she is willing to do so … that’s another question).
> 
> Just thinking about ways to get this forward. I’m afraid I cannot provide 
> more support currently ,-(

Same here. 

Andi..

> 
> 
> best regards,
> 
> Thomas 
> —
>> Am 06.01.2017 um 22:01 schrieb Andi Vajda :
>> 
>> 
>> I now took a look at the python 3 patches you sent a link to in an earlier 
>> message and here is the gist of my thoughts:
>>  - Moving the Python 3 is desirable but what about Python 2 support today
>>in 2017 ? I have no desire to support both for PyLucene manually. If,
>>somehow, there can be two versions of JCC, one for Python 2, one for
>>Python 3 and the PyLucene tests can be 2to3'd automatically, then the
>>Python 3 support idea looks more attractive already. Supporting two
>>versions of JCC is fine until 2020.
>> 
>>  - The JCC patches look very reasonable but should be updated to the latest
>>Python 3. In particular, the internal Python 3 string representation was
>>changed again after 3.2 (?) and has clever optimizations possible based
>>on the internal byte size of characters chosen by Python (internally)
>>for each string, based on the range of the characters used in the string.
>>This makes it possible to often just copy chars from Python to Java.
>>I just did a rewrite for this in PyICU (another long
>>term project of mine, https://github.com/ovalhub/pyicu/) and the Python 3
>>string story got much cleaner post 3.2 (at least more
>>understandable). Lots of bugs with long unicode chars (forgot the proper
>>term, sorry) got fixed along the way (emoticon support, yay).
>> 
>>So, if you're prepared to fund this effort, it might be best to hire
>>back the contractor who did the JCC Python 3 port originally and have
>>him/her refresh it for the latest JCC on trunk (not too many changes
>>happened in the past few years) and to the use the Python internal string
>>APIs that appeared post Python 3.2. The ones in use in the patch are
>>deprecated already. I love it that we'd then shed _all_ backwards
>>compatibility baggage in JCC going forward in Python 3.x, x >= 6.
>> 
>>If you get the JCC/Python3 patches into a shape where I can apply them to
>>trunk without trouble and using the latest CPython string APIs:
>>   https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AsUCS4
>>and related (PyUnicode_KIND, etc...)
>>then there is a good chance that PyLucene/JCC would be fully supported
>>with Python 3.x, x >= 6.
>> 
>>  - The PyLucene patches should probably be redone so that they can be
>>automated with 2to3. If we get JCC in shape, I can take care of the rest.
>> 
>> Thank you for the work done so far, it's looking really good but it needs to
>> be refreshed to JCC/trunk and latest Python 3 to minimize work on my side.
>> 
>> Andi..
> 

Re: Installing PyLucene

[Andi Vajda]

> On Jan 4, 2017, at 13:51, marco turchi  wrote:
> 
> No I didn't.
> 
> I have run the codes in sample and they work. For my project the
> functionalities in the samples are enough. If necessary I can recompile jcc
> with --shared. What do you suggest?

If you don't use --shared then the jcc that is linked into PyLucene is not 
running shared mode and the test failure you're seeing is due to that.

It's easy enough to rebuild PyLucene with --shared.
Up to you !

Andi..

> 
> Best
> Marco
> 
> 
> Il 04 Gen 2017 19:42, "Andi Vajda"  ha scritto:
> 
> 
>> On Jan 4, 2017, at 04:24, marco turchi  wrote:
>> 
>> Dear Andi and Thomas,
>> following your advice I have removed the Windows error.
>> 
>> I still have this
>> 
>> ERROR: testThroughLayerException (__main__.PythonExceptionTestCase)
>> 
>> To answer Andi, I have printed the config.SHARED just before the error and
>> the output is true, in my opinion, showing that the shared mode is enabled
>> when running tests. Is this that you were mentioning in your email?
> 
> When you built PyLucene did you include --shared on the jcc invocation
> command line ?
> 
> Andi..
> 
>> 
>> Thanks a lot for your help!
>> Marco
>> 
>> 
>> On Wed, Jan 4, 2017 at 10:59 AM, Petrus Hyvönen 
>> wrote:
>> 
>>> Dear Thomas,
>>> 
>>> I would be very interested in a python 3 port of JCC. I am not a very
>>> skilled developer, looked at starting a development based on the old
>>> python-3 version but it's beyond my current skills.
>>> 
>>> I would be happy to help and test and review the JCC patches, I think
> your
>>> patches would be a valuable contribution to JCC.
>>> 
>>> With Best Regards
>>> /Petrus
>>> 
>>> 
>>> On Wed, Jan 4, 2017 at 9:13 AM, Thomas Koch  wrote:
>>> 
>>>>> NameError: global name 'WindowsError' is not defined
>>>> 
>>>> Note that PyLucene currently lacks official Python3 support!
>>>> We've done a port of PyLucene 3.6 (!) to support Python3 and offered the
>>>> patches needed to JCC and PyLucene for use/review on the list - but
>>> didn't
>>>> get any feedback so far.
>>>> cf. https://www.mail-archive.com/pylucene-dev@lucene.apache.
>>>> org/msg02167.html <https://www.mail-archive.com/
>>>> pylucene-...@lucene.apache.org/msg02167.html>
>>>> 
>>>> Regards,
>>>> Thomas
>>>> 
>>> --
>>> _
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>>> 

Re: [VOTE] Release PyLucene 6.2.0 (rc2)

[Andi Vajda]

> On Sep 12, 2016, at 14:56, Jan Høydahl  wrote:
> 
> I downloaded and installed JDK from Oracle. And point to it with JAVA_HOME

Not at my computer right now so can't be too specific but setting JAVA_HOME is 
not good enough. You need to run some script from Oracle to make this java 
version the default for your OS.
A quick search found this for java 7: 
http://docs.oracle.com/javase/7/docs/webnotes/install/mac/mac-jdk.html
I remember doing something similar for java 8.

Andi..

> 
> Looks to me that in setup.py, LFLAGS get populated with correct -rpath to the 
> lib folder including libjava.dylib but I’m not that into make, so I’m afraid 
> I’m stuck and cannot vote on the release yet...
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 12. sep. 2016 kl. 14.26 skrev Andi Vajda :
>> 
>> 
>> 
>> On Sep 12, 2016, at 13:25, Jan Høydahl  wrote:
>>>> It looks like JCC can't find java (failing to find libjava.dylib). Which 
>>>> java did you install ?
>>> Java 1.8.0_102
>>>> When building JCC, the java version (library or franework) is reported. 
>>>> What did it say ?
>>> 
>>> found JAVAHOME = 
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home
>> 
>> Well, I haven't tried this combination of OS and Java before. You need to 
>> find where libjava.dylib actually is and see that the settngs in JCC's 
>> setup.py file are correct and correspond to the path and name of that 
>> library.
>> 
>> Is this a java you installed or did it come with that macOS beta ?
>> 
>> Andi..
>> 
>>> 
>>>> You also need to make sure JCC is built in shared mode and use a moderm 
>>>> setuptools (version >= 8).
>>> pip install --upgrade setuptools
>>> 
>>> Successfully uninstalled setuptools-23.1.0
>>> Successfully installed setuptools-27.1.2
>>> 
>>> Tried again with updated setuptools, same result.
>>> /usr/local/opt/python/bin/python2.7: 
>>> dlopen(/usr/local/lib/python2.7/site-packages/JCC-2.22-py2.7-macosx-10.12-x86_64.egg/jcc/_jcc.so,
>>>  2): Library not loaded: @rpath/libjava.dylib
>>> 
>>> Makefile settings:
>>> PREFIX_PYTHON=/usr/local/Cellar/python/2.7.12
>>> ANT=ant
>>> PYTHON=$(PREFIX_PYTHON)/bin/python
>>> JCC=$(PYTHON) -m jcc.__main__ --shared --arch x86_64
>>> NUM_FILES=8
>>> 
>>> GNU Make 3.81
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>>>> 12. sep. 2016 kl. 12.04 skrev Andi Vajda :
>>>>> 
>>>>> 
>>>>> On Sep 12, 2016, at 09:54, Jan Høydahl  wrote:
>>>>> 
>>>>> I’m trying to test on my mac.
>>>>> 
>>>>> Successfully built and installed JCC.
>>>>> Trying to build pylucene, “make” fails with this error:
>>>>> 
>>>>>> BUILD SUCCESSFUL
>>>>>> Total time: 1 second
>>>>>> ICU not installed
>>>>>> /usr/local/Cellar/python/2.7.12/bin/python -m jcc.__main__ --shared 
>>>>>> --arch x86_64 --jar 
>>>>>> lucene-java-6.2.0/lucene/build/core/lucene-core-6.2.0.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/analysis/common/lucene-analyzers-common-6.2.0.jar
>>>>>>  --jar lucene-java-6.2.0/lucene/build/memory/lucene-memory-6.2.0.jar 
>>>>>> --jar 
>>>>>> lucene-java-6.2.0/lucene/build/highlighter/lucene-highlighter-6.2.0.jar 
>>>>>> --jar build/jar/extensions.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/queries/lucene-queries-6.2.0.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/queryparser/lucene-queryparser-6.2.0.jar 
>>>>>> --jar lucene-java-6.2.0/lucene/build/sandbox/lucene-sandbox-6.2.0.jar 
>>>>>> --jar 
>>>>>> lucene-java-6.2.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-6.2.0.jar
>>>>>>  --jar lucene-java-6.2.0/lucene/build/grouping/lucene-grouping-6.2.0.jar 
>>>>>> --jar lucene-java-6.2.0/lucene/build/join/lucene-join-6.2.0.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/facet/lucene-facet-6.2.0.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/suggest/lucene-suggest-6.2.0.jar --jar 
>>>>>> lucene-java-6.2.0/lucene/build/expressions/lucene-expressions-6.2.0.jar 
>>>>>> --jar 
>>>>>

Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history in git

[Andi Vajda]

On Wed, 16 Dec 2015, Dawid Weiss wrote:


We can't touch Apache's SVN so it definitely stays! :)

This was also something that crossed my mind -- we effectively have
multiple separate projects in one git repo. While it's something SVN can
take, it's a more problematic issue with git. I don't know if one Apache
project can have multiple git repos, but I'd assume it'd be a natural way
out for pylucene? I can also include it in the git repo, of course, but I'd
opt for having a separate branch for it (one that is orphaned from actual
Lucene code).


I personally don't care. Git has been a non-issue in PyLucene.
It can move with Lucene or stay in SVN, either way is fine by me.

Andi..



Dawid

On Wed, Dec 16, 2015 at 10:33 PM, Andi Vajda  wrote:



On Wed, 16 Dec 2015, Dawid Weiss (JIRA) wrote:



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

Dawid Weiss updated LUCENE-6933:

   Description:
Goals:
* selectively drop projects and core-irrelevant stuff:
 ** {{lucene/site}}
 ** {{lucene/nutch}}
 ** {{lucene/lucy}}
 ** {{lucene/tika}}
 ** {{lucene/hadoop}}
 ** {{lucene/mahout}}
 ** {{lucene/pylucene}}



Does dropping lucene/pylucene mean it stays back in SVN (fine) or it
disappears (err, let's talk) ?

Andi..


 ** {{lucene/lucene.net}}

 ** {{lucene/old_versioned_docs}}
 ** {{lucene/openrelevance}}
 ** {{lucene/board-reports}}
 ** {{lucene/java/site}}
 ** {{lucene/java/nightly}}
 ** {{lucene/dev/nightly}}
 ** {{lucene/dev/lucene2878}}
 ** {{lucene/sandbox/luke}}
 ** {{lucene/solr/nightly}}
* preserve the history of all changes to core sources (Solr and Lucene).
 ** {{lucene/java}}
 ** {{lucene/solr}}
 ** {{lucene/dev/trunk}}
 ** {{lucene/dev/branches/branch_3x}}
 ** {{lucene/dev/branches/branch_4x}}
 ** {{lucene/dev/branches/branch_5x}}
* provide a way to link git commits and history with svn revisions (amend
the log message).
* annotate release tags
* deal with large binary blobs (JARs): keep empty files instead for their
historical reference only.

Non goals:
* no need to preserve "exact" merge history from SVN (see "impossible"
below).
* Ability to build ancient versions is not an issue.

Impossible:
* It is not possible to preserve SVN "merge history" because of the
following reasons:
 ** Each commit in SVN operates on individual files. So one commit can
"copy" (and record a merge) files from anywhere in the object tree, even
modifying them along the way. There simply is no equivalent for this in git.
 ** There are historical commits in SVN that apply changes to multiple
branches in one commit ({{r1569975}}).
* Because exact merge tracking is impossible then what follows is that
exact "linearized" history of a given file is also impossible to record.
Let's say changes X, Y and Z have been applied to a branch of a file A and
then merged back. In git, this would be reflected as a single commit
flattening X, Y and Z (on the target branch) and three independent commits
on the branch. The "copy-from" link from one branch to another cannot be
represented because, as mentioned, merges are done on entire branches in
git, not on individual files. Yes, there are commits in SVN history that
have selective file merges (not entire branches).


 was:
Goals:
- selectively drop unnecessary stuff from history (cms/, javadocs/, JARs
and perhaps other binaries),
- *preserve* history of all core sources. So svn log IndexWriter has to
go back all the way back to when Doug was young and pretty. Ooops, he's
still pretty of course.
- provide a way to link git history with svn revisions. I would, ideally,
include a "imported from svn:rev XXX" in the commit log message.
- annotate release tags and branches. I don't care much about interim
branches -- they are not important to me (please speak up if you think
otherwise).

Non goals
- no need to preserve "exact" history from SVN (the project may skip
JARs, etc.). Ability to build ancient versions is not an issue.


Create a (cleaned up) SVN history in git



Key: LUCENE-6933
URL: https://issues.apache.org/jira/browse/LUCENE-6933
Project: Lucene - Core
 Issue Type: Task
   Reporter: Dawid Weiss
   Assignee: Dawid Weiss

Goals:
* selectively drop projects and core-irrelevant stuff:
  ** {{lucene/site}}
  ** {{lucene/nutch}}
  ** {{lucene/lucy}}
  ** {{lucene/tika}}
  ** {{lucene/hadoop}}
  ** {{lucene/mahout}}
  ** {{lucene/pylucene}}
  ** {{lucene/lucene.net}}
  ** {{lucene/old_versioned_docs}}
  ** {{lucene/openrelevance}}
  ** {{lucene/board-reports}}
  ** {{lucene/java/site}}
  ** {{lucene/java/nightly}}
  ** {{lucene/dev/nightly}}
  ** {{lucene/dev/lucene2878}}
  ** {{lucene/sandbox/luke}}
  ** {{lucene/solr/nig

Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history in git

[Andi Vajda]

On Wed, 16 Dec 2015, Dawid Weiss (JIRA) wrote:



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

Dawid Weiss updated LUCENE-6933:

   Description:
Goals:
* selectively drop projects and core-irrelevant stuff:
 ** {{lucene/site}}
 ** {{lucene/nutch}}
 ** {{lucene/lucy}}
 ** {{lucene/tika}}
 ** {{lucene/hadoop}}
 ** {{lucene/mahout}}
 ** {{lucene/pylucene}}


Does dropping lucene/pylucene mean it stays back in SVN (fine) or 
it disappears (err, let's talk) ?


Andi..


 ** {{lucene/lucene.net}}
 ** {{lucene/old_versioned_docs}}
 ** {{lucene/openrelevance}}
 ** {{lucene/board-reports}}
 ** {{lucene/java/site}}
 ** {{lucene/java/nightly}}
 ** {{lucene/dev/nightly}}
 ** {{lucene/dev/lucene2878}}
 ** {{lucene/sandbox/luke}}
 ** {{lucene/solr/nightly}}
* preserve the history of all changes to core sources (Solr and Lucene).
 ** {{lucene/java}}
 ** {{lucene/solr}}
 ** {{lucene/dev/trunk}}
 ** {{lucene/dev/branches/branch_3x}}
 ** {{lucene/dev/branches/branch_4x}}
 ** {{lucene/dev/branches/branch_5x}}
* provide a way to link git commits and history with svn revisions (amend the 
log message).
* annotate release tags
* deal with large binary blobs (JARs): keep empty files instead for their 
historical reference only.

Non goals:
* no need to preserve "exact" merge history from SVN (see "impossible" below).
* Ability to build ancient versions is not an issue.

Impossible:
* It is not possible to preserve SVN "merge history" because of the following 
reasons:
 ** Each commit in SVN operates on individual files. So one commit can "copy" 
(and record a merge) files from anywhere in the object tree, even modifying them along 
the way. There simply is no equivalent for this in git.
 ** There are historical commits in SVN that apply changes to multiple branches 
in one commit ({{r1569975}}).
* Because exact merge tracking is impossible then what follows is that exact "linearized" 
history of a given file is also impossible to record. Let's say changes X, Y and Z have been 
applied to a branch of a file A and then merged back. In git, this would be reflected as a single 
commit flattening X, Y and Z (on the target branch) and three independent commits on the branch. 
The "copy-from" link from one branch to another cannot be represented because, as 
mentioned, merges are done on entire branches in git, not on individual files. Yes, there are 
commits in SVN history that have selective file merges (not entire branches).


 was:
Goals:
- selectively drop unnecessary stuff from history (cms/, javadocs/, JARs and 
perhaps other binaries),
- *preserve* history of all core sources. So svn log IndexWriter has to go back 
all the way back to when Doug was young and pretty. Ooops, he's still pretty of 
course.
- provide a way to link git history with svn revisions. I would, ideally, include a 
"imported from svn:rev XXX" in the commit log message.
- annotate release tags and branches. I don't care much about interim branches 
-- they are not important to me (please speak up if you think otherwise).

Non goals
- no need to preserve "exact" history from SVN (the project may skip JARs, 
etc.). Ability to build ancient versions is not an issue.



Create a (cleaned up) SVN history in git


Key: LUCENE-6933
URL: https://issues.apache.org/jira/browse/LUCENE-6933
Project: Lucene - Core
 Issue Type: Task
   Reporter: Dawid Weiss
   Assignee: Dawid Weiss

Goals:
* selectively drop projects and core-irrelevant stuff:
  ** {{lucene/site}}
  ** {{lucene/nutch}}
  ** {{lucene/lucy}}
  ** {{lucene/tika}}
  ** {{lucene/hadoop}}
  ** {{lucene/mahout}}
  ** {{lucene/pylucene}}
  ** {{lucene/lucene.net}}
  ** {{lucene/old_versioned_docs}}
  ** {{lucene/openrelevance}}
  ** {{lucene/board-reports}}
  ** {{lucene/java/site}}
  ** {{lucene/java/nightly}}
  ** {{lucene/dev/nightly}}
  ** {{lucene/dev/lucene2878}}
  ** {{lucene/sandbox/luke}}
  ** {{lucene/solr/nightly}}
* preserve the history of all changes to core sources (Solr and Lucene).
  ** {{lucene/java}}
  ** {{lucene/solr}}
  ** {{lucene/dev/trunk}}
  ** {{lucene/dev/branches/branch_3x}}
  ** {{lucene/dev/branches/branch_4x}}
  ** {{lucene/dev/branches/branch_5x}}
* provide a way to link git commits and history with svn revisions (amend the 
log message).
* annotate release tags
* deal with large binary blobs (JARs): keep empty files instead for their 
historical reference only.
Non goals:
* no need to preserve "exact" merge history from SVN (see "impossible" below).
* Ability to build ancient versions is not an issue.
Impossible:
* It is not possible to preserve SVN "merge history" because of the following 
reasons:
  ** Each commit in SVN operates on individual files. So one commit can "copy" 
(and record a merge) files from anywhere in the object tree, even modifying them alo

Re: [VOTE] Release 4.10.4 RC0

[Andi Vajda]

I checked out rev 1662817 from branch lucene_solr_4_10 and built a version 
of PyLucene 4.10.4 from it. All tests pass !


+1

Andi..

On Fri, 27 Feb 2015, Michael McCandless wrote:


Artifacts: 
http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.10.4-RC0-rev1662817

Smoke tester: python3 -u dev-tools/scripts/smokeTestRelease.py
http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.10.4-RC0-rev1662817
1662817 4.10.4 /tmp/smoke4104 True

SUCCESS! [0:39:34.527017]

I also confirmed Elasticsearch 1.x tests pass after upgrading to this.

Here's my +1

Mike McCandless

http://blog.mikemccandless.com

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




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

Re: FSDirectory and creating directory

[Andi Vajda]

> On Feb 4, 2015, at 10:12, Uwe Schindler  wrote:
> 
> Hi Robert,
> 
> I am fine with any of your comments. We can move this issue to later 
> releases, I just want that FSDirectory and its subclasses to document that 
> they create the directory on its ctor if it does not yet exist. Please 
> understand that I want to figure out if this could cause "human" issues, 
> because I know people are always complaining about this shit. And I also 
> wanted to be sure this causes no problems with read-only filesystems. People 
> will for sure complain if they just want to open an indexreader and suddenly 
> the FSDirectory complains about "I cannot write" instead of "Directory does 
> not exist". I understand the reason behind this change: we want the "real" 
> (canonical path), so NativeFSLockingFactory's stupid

Maybe I'm missing some context here but if the file system is read-only, why is 
the locking stuff even getting involved ?

Andi..

> internal Set works correctly. No worry, I don’t want to change that for 
> 5.0 - only document it! But we can think in later Lucene releases to go back 
> to not creating the directory on front under read-only conditions (opening an 
> IndexReader).
> 
> Should I add those Javadocs, costs me not much, I just wanted to check this 
> out before?  In fact I would move the comment you added to the Javadocs of 
> ctor and open() with an additional sentence.
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
>> -Original Message-
>> From: Robert Muir [mailto:rcm...@gmail.com]
>> Sent: Wednesday, February 04, 2015 3:21 PM
>> To: dev@lucene.apache.org
>> Subject: Re: FSDirectory and creating directory
>> 
>>> On Wed, Feb 4, 2015 at 9:15 AM, Uwe Schindler  wrote:
>>> I have no idea what happens if you call Files.createDirectories() on a read-
>> only file system if all directory components already exist (it should be a 
>> no-
>> op, but who knows).
>>> 
>> 
>> Why do you respond like this Uwe? Its clear what it does: it does what the
>> javadocs claim it does, or its a bug in the JDK.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
>> commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

Re: Set path to JRE / JDK in code

[Andi Vajda]

On Tue, 20 Jan 2015, Petrus Hyvönen wrote:


Hi,

I'm trying to package a wrapped library together with a non system-wide
java JDK so that it can be easily installed.

Can I somehow direct which JDK to use besides using JCC_JDK and putting the
JRE in the PATH (I'm currently under windows)? The JCC_JDK could be patched
in the setup.py but the PATH JRE that is accessed during running the
wrapped library I don't understand where it is accessed, or how to patch
this?


So you're asking how to control where to pickup the JRE DLLs (on Windows) at 
runtime ? If I remember correctly, on Windows you just set the Path 
environment variable, no ?



For example it would be good to have this in the config.py file if
possible?


If you're sure config.py is run _before_ any JRE DLL is loaded, you might be 
able to change the Path fron there too.


Andi..



Any thoughts or someone who's done this already?

Regards
/Petrus


--
_
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00

Re: [jira] [Created] (PYLUCENE-33) Cannot override newTermQuery method of class QueryParser

[Andi Vajda]

On Wed, 24 Dec 2014, iceout wrote:


I just subscribe the mail list. And I don't know how reply the thread
before. So I have to create a new one.

In lucene 4.4, the method newTermQuery() is defined in class
QueryParserBase, and QueryParser extends QueryParserBase.

In lucene 4.10, the method newTermQuery() is defined in class QueryBuilder,
and class QueryParserBase extends QueryBuilder, and class QueryParser
extends QueryParserBase.

In java, I can simply override newTermQuery() method when extends
QueryParser.
But in pylucene, it didn't work, both 4.4 and 4.10 version.

Is there something wrong?


If you apply the attached patch to a PyLycene 4.10.1 checkout:
(if the attachment disappeared, let me know and I'll send it inline)
  $ cd 
  $ patch -Nup0 < patch.newTermQuery.txt
and rebuild PyLucene
  $ find . -name 'extensions.jar' | xargs rm
  $ make
and run tests
  $ make test
you should see that newTermQuery is called when the
  test_PythonQueryParser.py
file is run by make test, that this output is emitted:
  .CALLING newTermQuery with all:foo
  CALLING newTermQuery with all:bar
  .

As far as stock 4.10.1 PyLucene is concerned, extended newTermQuery() as 
shown by this patch seems to be working as expected.
If you find otherwise, please reply with a patch that applies to PyLucene 
4.10.1, that reproduces the problem you're experiencing.


Thanks !

Andi..



--
Best Regards,
iceout
Index: java/org/apache/pylucene/queryparser/classic/PythonQueryParser.java
===
--- java/org/apache/pylucene/queryparser/classic/PythonQueryParser.java 
(revision 1628343)
+++ java/org/apache/pylucene/queryparser/classic/PythonQueryParser.java 
(working copy)
@@ -18,6 +18,7 @@
 import java.util.List;
 
 import org.apache.lucene.analysis.Analyzer;
+import org.apache.lucene.index.Term;
 import org.apache.lucene.search.Query;
 import org.apache.lucene.queryparser.classic.QueryParser;
 import org.apache.lucene.queryparser.classic.CharStream;
@@ -70,6 +71,8 @@
 public native Query getFieldQuery_slop(String field, String queryText,
int slop);
 
+public native Query newTermQuery(Term term);
+
 public Query getFieldQuery_quoted_super(String field, String queryText,
 boolean quoted)
 throws ParseException
Index: test/test_PythonQueryParser.py
===
--- test/test_PythonQueryParser.py  (revision 1628343)
+++ test/test_PythonQueryParser.py  (working copy)
@@ -42,6 +42,9 @@
 class TestQueryParser(BooleanTestMixin, PythonQueryParser):
 def getFieldQuery_quoted(_self, field, queryText, quoted):
 return super(TestQueryParser, 
_self).getFieldQuery_quoted_super(field, queryText, quoted)
+def newTermQuery(_self, term):
+print "CALLING newTermQuery with", term
+return TermQuery(term)
 
 qp = TestQueryParser(Version.LUCENE_CURRENT, 'all',
  StandardAnalyzer(Version.LUCENE_CURRENT))

Re: [VOTE] Release PyLucene 4.7.1-1

[Andi Vajda]

sh = PyObject_Hash(arg);
>   ^~
> 1 warning generated.
> cc -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common 
> -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX 
> -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os 
> -Wall -Wstrict-prototypes -DENABLE_DTRACE 
> -Wno-error=unused-command-line-argument-hard-error-in-future -dynamiclib 
> -Wno-error=unused-command-line-argument-hard-error-in-future -D_jcc_lib 
> -DJCC_VER="2.18" 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include/darwin
>  -I_jcc -Ijcc/sources 
> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 
> -c jcc/sources/JCCEnv.cpp -o 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -DPYTHON 
> -fno-strict-aliasing -Wno-write-strings
> clang: warning: unknown argument: '-mno-fused-madd' 
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a warning) in 
> the future
> clang: warning: argument unused during compilation: '-mno-fused-madd'
> clang: warning: argument unused during compilation: '-dynamiclib'
> c++ -Wl,-x -dynamiclib -undefined dynamic_lookup 
> -Wno-error=unused-command-line-argument-hard-error-in-future 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -o 
> build/lib.macosx-10.9-intel-2.7/libjcc.dylib 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -ljava 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -ljvm -Wl,-rpath 
> -Wl,/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -Wl,-rpath 
> -Wl,/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -Wl,-S -install_name @rpath/libjcc.dylib -current_version 2.18 
> -compatibility_version 2.18
> ld: internal error: atom not found in 
> symbolIndex(__ZN7JNIEnv_13CallIntMethodEP8_jobjectP10_jmethodIDz) for 
> architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> error: command 'c++' failed with exit status 1
> 
> —%< —
> 
> I read that the JNI CallIntMethod function cannot be found by the linker  - 
> the compile did succeed (e.g. jcc.o) so headers should be found - the -L dirs 
> have jvm libs:
> 
> in jre/lib/server
> - libjsig.dylib
> - libjvm.dylib
> in jre/lib
> - libjava.dylib
> -  ..
> - libjsound.dylib
> 
> Am I missing the JNI lib?
> 
> Here is the 'verbose' output of the linker phase
> 
> $ c++ -v -Wl,-x -dynamiclib -undefined dynamic_lookup 
> -Wno-error=unused-command-line-argument-hard-error-in-future 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -o 
> build/lib.macosx-10.9-intel-2.7/libjcc.dylib 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -ljava 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -ljvm -Wl,-rpath 
> -Wl,/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -Wl,-rpath 
> -Wl,/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -Wl,-S -install_name @rpath/libjcc.dylib -current_version 2.18 
> -compatibility_version 2.18
> Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
> Target: x86_64-apple-darwin13.1.0
> Thread model: posix
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
>  -demangle -dynamic -dylib -dylib_compatibility_version 2.18 
> -dylib_current_version 2.18 -arch x86_64 -dylib_install_name 
> @rpath/libjcc.dylib -macosx_version_min 10.9.0 -undefined dynamic_lookup 
> -undefined dynamic_lookup -o build/lib.macosx-10.9-intel-2.7/libjcc.dylib 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -L/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -x build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -ljava -ljvm -rpath 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib 
> -rpath 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/lib/server
>  -S -lc++ -lSystem 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
> ld: internal error: atom not found in 
> symbolIndex(__ZN7JNIEnv_13CallIntMethodEP8_jobjectP10_jmethodIDz) for 
> architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> 
> This is Max OS X 10.9.2 with XCode version 5.1 - any hints are appreciated ,-)
> 
> 
> regards
> 
> Thomas Koch
> --
> OrbiTeam Software GmbH & Co. KG
> www.orbiteam.de
> 
>> Am 09.04.2014 um 03:57 schrieb Andi Vajda :
>> 
>> 
>> This vote has been obsoleted by the upcoming release of Lucene 4.7.2.
>> 
>> Andi..
> 

Re: Can't build on Mavericks (different issue)

[Andi Vajda]

> On Mar 28, 2014, at 15:48, Mike McCormick  wrote:
> 
> Hi Andi, thanks for your reply.  Not only was it compiling against Java 8 
> binaries, it was using Java 6 headers.  I took a look at helpers/darwin.py 
> and noticed two problems with it:
> 
> 1. It uses /usr/libexec/java_home to find the JDK and does not observe the 
> JAVA_HOME environment variable.  I have Apple’s JDK 6 plus Oracle’s JDK 7 and 
> 8 on my system and /usr/libexec/java_home always return the path to Java 8.
> 
> 2. JAVAHOME and JAVAFRAMEWORKS end up pointing to two different versions.  As 
> I mentioned above, java_home will return the path to the latest JDK and 
> JAVAFRAMEWORKS is hard-coded to look in Apple’s path which is for JDK 6 
> headers.  The headers for Oracle’s JDKs are in $JAVA_HOME/include.
> 
> I modified setup.py to just use my JDK 7 installation.  The two modules 
> compile the same as before, and the linker still dies.  I set JCC_LDFLAGS=-v 
> and got this:

It is most deterministic to set the variables controlling which version of 
everything is used. It us also important to use the same compiler (gcc vs 
clang) that was used to build your version of python.

> Thread model: posix
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
>  -demangle -dynamic -dylib -dylib_compatibility_version 2.19 
> -dylib_current_version 2.19 -arch x86_64 -dylib_install_name 
> @rpath/libjcc.dylib -macosx_version_min 10.9.0 -undefined dynamic_lookup 
> -undefined dynamic_lookup -o build/lib.macosx-10.9-intel-2.7/libjcc.dylib -x 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o 
> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -S -lc++ -lSystem 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
> ld: internal error: atom not found in 
> symbolIndex(__ZN7JNIEnv_13CallIntMethodEP8_jobjectP10_jmethodIDz) for 
> architecture x86_64

You still have a mismatch somewhere.
But I can't see what version of the jdk you're linking against ?

Andi..

> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> error: command 'g++' failed with exit status 1
> 
> CallIntMethod smells like it should be part of a JDK library, correct?  
> Should there be another library referenced in that linker command that isn’t? 
>  My other thought is that maybe something is being deadstripped.
> 
> M
> 
>> On Mar 28, 2014, at 3:05 AM, Andi Vajda  wrote:
>> 
>> 
>>> On Mar 28, 2014, at 5:58, Mike McCormick  wrote:
>>> 
>>> Hi folks,
>>> 
>>> I am trying to build jcc to install JModelica.  The linking process dies:
>>> 
>>> building 'jcc' extension
>>> gcc -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -Qunused-arguments 
>>> -dynamiclib -D_jcc_lib -DJCC_VER="2.19" 
>>> -I/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include 
>>> -I/Library/Java/JavaVirtualMachines/jdk1.8.0
>> 
>> You're building against Java 8 which has not yet been tested with jcc. It 
>> may work, or not.
>> 
>>> .jdk/Contents/Home/include/darwin -I_jcc -Ijcc/sources 
>>> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
>>>  -c jcc/sources/jcc.cpp -o 
>>> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o -DPYTHON 
>>> -fno-strict-aliasing -Wno-write-strings
>>> gcc -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -Qunused-arguments 
>>> -dynamiclib -D_jcc_lib -DJCC_VER="2.19" 
>>> -I/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include 
>>> -I/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include/darwin
>>>  -I_jcc -Ijcc/sources 
>>> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
>>>  -c jcc/sources/JCCEnv.cpp -o 
>>> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -DPYTHON 
>>> -fno-strict-aliasing -Wno-write-strings
>>> g++ -Wl,-x -dynamiclib -undefined dynamic_lookup -Qunused-arguments 
>>> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o 
>>> build/temp.macosx-10.9-intel-2.7/jcc/sources/JCCEnv.o -o 
>>> build/lib.macosx-10.9-intel-2.7/libjcc.dylib 
>>> -L/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib 
>>> -ljava 
>>> -L/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/server
>>>  -ljvm -Wl,-rpath 
>>> -Wl,/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib 
>>> -Wl,-rpath 
>>> -Wl,/Library/Java/JavaVirtualMachines/jdk

Re: JCC build fails on Mac OS X Mavericks

[Andi Vajda]

> On Mar 12, 2014, at 4:44, Peter Ganong  wrote:
> 
> Hi,
> 
> I'm having trouble installing JCC. I don't know if this is the right forum,
> but I figured I would post here, since
> thispage said
> this was the list to post build issues.
> 
> I'm trying to install JCC as a first step to installing PyLucene. I've
> installed JDK 1.7, Python 2.7, Python 3.3, XCode, XCode Command Line Tools
> and setuptools 3.1. I've pasted the error I'm getting below.
> 
> Thanks,
> 
> Peter
> 
> Macintosh-58:jcc ganong$ python setup.py build
> 
> found JAVAHOME =
> /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
> 
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> 
> Loading source files for package org.apache.jcc...
> 
> Constructing Javadoc information...
> 
> Standard Doclet version 1.7.0_51
> 
> Building tree for all the packages and classes...
> 
> Generating javadoc/org/apache/jcc/PythonException.html...
> 
> Generating javadoc/org/apache/jcc/PythonVM.html...
> 
> Generating javadoc/org/apache/jcc/package-frame.html...
> 
> Generating javadoc/org/apache/jcc/package-summary.html...
> 
> Generating javadoc/org/apache/jcc/package-tree.html...
> 
> Generating javadoc/constant-values.html...
> 
> Generating javadoc/serialized-form.html...
> 
> Building index for all the packages and classes...
> 
> Generating javadoc/overview-tree.html...
> 
> Generating javadoc/index-all.html...
> 
> Generating javadoc/deprecated-list.html...
> 
> Building index for all classes...
> 
> Generating javadoc/allclasses-frame.html...
> 
> Generating javadoc/allclasses-noframe.html...
> 
> Generating javadoc/index.html...
> 
> Generating javadoc/help-doc.html...
> 
> running build
> 
> running build_py
> 
> writing /Users/ganong/Downloads/pylucene-4.6.1-1/jcc/jcc/config.py
> 
> copying jcc/config.py -> build/lib.macosx-10.9-intel-2.7/jcc
> 
> copying jcc/classes/org/apache/jcc/PythonVM.class ->
> build/lib.macosx-10.9-intel-2.7/jcc/classes/org/apache/jcc
> 
> copying jcc/classes/org/apache/jcc/PythonException.class ->
> build/lib.macosx-10.9-intel-2.7/jcc/classes/org/apache/jcc
> 
> running build_ext
> 
> building 'jcc' extension
> 
> cc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -arch i386 -g -Os
> -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd
> -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes
> -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
> -DENABLE_DTRACE -dynamiclib -D_jcc_lib -DJCC_VER="2.19"
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include/darwin
> -I_jcc -Ijcc/sources
> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
> -c jcc/sources/jcc.cpp -o
> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o -DPYTHON
> -fno-strict-aliasing -Wno-write-strings
> 
> clang: error: unknown argument: '-mno-fused-madd'
> [-Wunused-command-line-argument-hard-error-in-future]

The wrong compiler flag here is produced by Python based on the compiler 
knowledge it gained while it was built. In other words, you must use the same 
compiler for building JCC than the one used to build your python VM.
The easiest way to ensure that is to build python 2.7 from sources yourself.

Andi..

> 
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
> 
> error: command 'cc' failed with exit status 1
> 
> -- 
> Peter Ganong
> PhD Candidate in Economics at Harvard
> scholar.harvard.edu/ganong/

Re: Problems installing Pylucene on Ubuntu 12.04

[Andi Vajda]

On Thu, 6 Mar 2014, Ritzschke, Uwe wrote:


Hello,

I'm facing problems with installing Pylucene on an Ubuntu 12.04 Server (32bit). 
Perhaps someone can give me some helpful advice?
I've followed the official installation instructions [1]. It seems that building and installing JCC 
works fine. Also, running "make" to build Pylucene seems to succeed. But if I run 
"make test", I get the errors attached below.


It looks like there is a left-over 'import pdb; pdb.set_trace()' statement 
in the test_PythonDirectory.py test, at line 260.

Please, remove it and re-run the tests.

Thanks !

Andi..




Thank you in advance!
Uwe

1: http://lucene.apache.org/pylucene/install.html



Output of "make test" (shortened):

[...]

==
ERROR: test_FieldEnumeration (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 236, in 
test_FieldEnumeration
   self.test_indexDocument()
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 84, in 
test_indexDocument
   self.closeStore(store, writer)
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
   return self.dispatch_line(frame)
 File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
   if self.quitting: raise BdbQuit
BdbQuit

==
ERROR: test_IncrementalLoop (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "test/test_PythonDirectory.py", line 268, in test_IncrementalLoop
   self.test_indexDocument()
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 84, in 
test_indexDocument
   self.closeStore(store, writer)
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
   return self.dispatch_line(frame)
 File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
   if self.quitting: raise BdbQuit
BdbQuit

==
ERROR: test_getFieldInfos (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 282, in 
test_getFieldInfos
   self.test_indexDocument()
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 84, in 
test_indexDocument
   self.closeStore(store, writer)
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
   return self.dispatch_line(frame)
 File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
   if self.quitting: raise BdbQuit
BdbQuit

==
ERROR: test_indexDocument (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 84, in 
test_indexDocument
   self.closeStore(store, writer)
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
   return self.dispatch_line(frame)
 File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
   if self.quitting: raise BdbQuit
BdbQuit

==
ERROR: test_indexDocumentWithText (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py", line 112, in 
test_indexDocumentWithText
   self.closeStore(store, writer)
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "test/test_PythonDirectory.py", line 255, in closeStore
   for arg in args:
 File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
   return self.dispatch_line(frame)
 File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
   if self.quitting: raise BdbQuit
BdbQuit

==
ERROR: test_indexDocumentWithUnicodeText (__main__.PythonDirectoryTests)
--
Traceback (most recent call last):
 File "/root/pylucene-4.6.1-1/test/test_PyLucene.py",

[VOTE] Release PyLucene 4.6.1-1

[Andi Vajda]

The PyLucene 4.6.1-1 release tracking the recent release of Apache Lucene 
4.6.1 is ready.


The previous release candidate's tar archive contained Mac OS X resource 
forks and had to be respinned without them.


A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_6/CHANGES

PyLucene 4.6.1 is built with JCC 2.19 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_6_1/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.6.1-1.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 4.6.1-0

[Andi Vajda]

On Fri, 7 Feb 2014, Michael McCandless wrote:


Hmm I see many ._* files in the .tar.gz, e.g.:


Thank you for catching that Mike.
It seems that Mac OS X resource forks are now (?) included by default unless 
one use the --disable-copyfile flag.

I've got a rc1 being uploaded with this fixed...

Andi..



mike@vine:~/src/pylucene-4.6.1-0/jcc$ tar tzf pylucene-4.6.1-0-src.tar.gz | head

./._pylucene-4.6.1-0
pylucene-4.6.1-0/
pylucene-4.6.1-0/._CHANGES
pylucene-4.6.1-0/CHANGES
pylucene-4.6.1-0/._CREDITS
pylucene-4.6.1-0/CREDITS
pylucene-4.6.1-0/._extensions.xml
pylucene-4.6.1-0/extensions.xml
pylucene-4.6.1-0/._INSTALL
pylucene-4.6.1-0/INSTALL


Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 5, 2014 at 7:29 PM, Andi Vajda  wrote:


The PyLucene 4.6.1-0 release tracking the recent release of Apache Lucene
4.6.1 is ready.

A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_6/CHANGES

PyLucene 4.6.1 is built with JCC 2.19 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_6_1/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.6.1-0.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

Re: Problem using generic types?

[Andi Vajda]

> On Feb 2, 2014, at 10:08, Petrus Hyvönen  wrote:
> 
> Hi Andi and Others,
> 
> The latest trunk jcc works and builds very fine on my windows machine, and 
> happy about the extendend support of generics. But I am experiencing the 
> problem below when building on my mac, using same wrap parameters as on the 
> windows platform. To me it seems like some compiler problem related to 
> macros, but don't know.
> 
> Does anyone have experience of these failures?
> 
> Regards
> /Petrus
> 
> 
> error: expected unqualified-id
>  self->parameters[0] = &::PY_TYPE([D);
>   ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>  note: 
>  expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
>  ^
> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
>  'D$$Type'
>  self->parameters[0] = &::PY_TYPE([D);

Take a look at the code around line 2344 in that __wrap__.cpp file and figure 
out what java code this corresponds to. You might be using a classname that's a 
C macro on some platforms - do you have a class named D for example ?
If you're hitting such a name conflict, add that name to the --reserved list 
passed to jcc.

Andi..

>   ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>  note: 
>  expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
>  ^
> :73:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
>  self->parameters[0] = &::PY_TYPE([D);
>      ^
> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
>  self->parameters[0] = &::PY_TYPE([D);
> 
> 
> 
>> On 14 Jan 2014, at 19:02 , Andi Vajda  wrote:
>> 
>> 
>> Hi Petrus,
>> 
>>> On Jan 14, 2014, at 4:24, Petrus Hyvönen  wrote:
>>> 
>>> Dear Andi,
>>> 
>>> Many many thanks for looking into this! 
>>> 
>>> I am on travel for a week and do not have the computer with the special 
>>> case with me to test. I did now however run it on the library that I am 
>>> wrapping, and there get some errors in the creation of the wrapped module 
>>> (orekit):
>>> 
>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>>  'HarmonicOscillator$Parametric$$Type' in namespace
>> 
>> I believe I fixed this bug in rev 1557613, header files for classes for 
>> inherited fixed parameters were not included as required.
>> 
>> Andi..
>> 
>>>  'org::apache::commons::math3::analysis::function'
>>>  ...= 
>>> &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>>>~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>>>  note: 
>>>  expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>>  ^
>>> :63:1: note: expanded from here
>>> HarmonicOscillator$Parametric$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>>>  'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>>>self->parameters[0] = 
>>> &::org::orekit::errors::PY_TYPE(OrekitMessages);
>>>   ~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>>>  note: 
>>>  expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>>  ^
>>> :9:1: note: expanded from here
>>> OrekitMessages$$Type
>>> ^
>>> 2 errors generated.
>>> error: command 'gcc' failed with exit status 1
>>> 
>>> 
>>> 
>>> The OrekitMessages is defined as a "public enum OrekitMessages implements 
>>> Localizable { ..."
>>> and the "public class HarmonicOscillator implements 
>>> UnivariateDifferentiable, DifferentiableUnivariateFunction". 
>>> 
>>> Maybe this says you something, I will try to test more and r

Re: [VOTE] Release Lucene/Solr 4.6.1 RC4

[Andi Vajda]

On Thu, 23 Jan 2014, Mark Miller wrote:


Sorry - watch out for that link - I?m seeing the text correctly, but the 
underlying link incorrectly when I look at it in my send folder. The evils of 
html mail I guess.


+1

PyLucene built from branch_4x's rev 1560866 passes all its tests.

Andi..



To be sure you have the right artifacts, make sure you are looking at the 
following location:

http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/

- Mark

On Jan 23, 2014, at 9:57 PM, Mark Miller  wrote:


Here we go, hopefully for that last time now?thanks everyone for bearing with 
us.

Please vote to release the following artifacts:

http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/

Here is my +1.

SUCCESS! [0:56:37.409716]

--
- Mark





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

Re: [VOTE] Release Lucene/Solr 4.6.1 RC2

[Andi Vajda]

+1

PyLucene built from branch_4x r1559610 built and passed its tests.

Andi..

On Sun, 19 Jan 2014, Mark Miller wrote:


Please vote to release the following artifacts:

http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/

Here is my +1.

SUCCESS! [0:51:51.964657]

--
- Mark



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

Re: Problem using generic types?

[Andi Vajda]

On Tue, 14 Jan 2014, Petrus Hyvönen wrote:


Andy,

It works fine now. Many many thanks.


Sweet !

Andi..



Regards
/Petrus

On 14 Jan 2014, at 15:02 , Andi Vajda  wrote:



 Hi Petrus,

On Jan 14, 2014, at 4:24, Petrus Hyvönen  wrote:


Dear Andi,

Many many thanks for looking into this!

I am on travel for a week and do not have the computer with the special case 
with me to test. I did now however run it on the library that I am wrapping, 
and there get some errors in the creation of the wrapped module (orekit):

build/_orekit/__wrap__.cpp:86504:89: error: no member named
  'HarmonicOscillator$Parametric$$Type' in namespace


I believe I fixed this bug in rev 1557613, header files for classes for 
inherited fixed parameters were not included as required.

Andi..

Re: overriding getRangeQuery

[Andi Vajda]

> On Jan 9, 2014, at 16:00, Shawn Grant  wrote:
> 
> Updating the parameters in the extension's method and rebuilding wasn't 
> enough to fix the problem for me.  Not sure what I'm missing.

I checked in a fix on trunk a couple of days ago. Did you remove extensions.jar 
so that it would be rebuilt and rewrapped ?
If this still doesn't fix it, please write a small test case so that I can 
reproduce this.
Thanks !

> It looks like this bug also affects the analysis of the range clause.  I need 
> the terms to be case sensitive so I'm using a per-field analyzer to make sure 
> that field doesn't get lowercased but it's getting ignored and sent to the 
> default analyzer.

That's probably an issue with using Lucene itself. You should ask about this on 
java-u...@lucene.apache.org.

Andi..

> 
> On 01/03/2014 05:38 PM, Andi Vajda wrote:
>>> On Jan 3, 2014, at 21:35, Shawn Grant  wrote:
>>> 
>>> whoops, bad link expansion.  Was supposed to be:
>>> getRangeQuery(String field, String part1, String part2, boolean 
>>> startInclusive, boolean endInclusive);
>> Yes, that would be the problem. The signature changed but the extension's 
>> didn't.
>> 
>> Andi..
>> 
>>>> On 01/03/2014 04:33 PM, Shawn Grant wrote:
>>>> I have a subclass of PythonQueryParser that overrides several methods but 
>>>> I can't seem to get it to use getRangeQuery.  I noticed that the method 
>>>> definition in PythonQueryParser is:
>>>> 
>>>> getRangeQuery(String field, String part1, String part2, boolean inclusive);
>>>> 
>>>> but the lucene definition for QueryParser (in QueryParserBase) is:
>>>> 
>>>> |*getRangeQuery 
>>>> <https://lucene.apache.org/core/4_4_0/queryparser/org/apache/lucene/queryparser/classic/QueryParserBase.html#getRangeQuery%28java.lang.String,%20java.lang.String,%20java.lang.String,%20boolean,%20boolean%29>*(String
>>>>  
>>>> <http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true>
>>>>  field, String 
>>>> <http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true>
>>>>  part1, String 
>>>> <http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true>
>>>>  part2, boolean startInclusive, boolean endInclusive)|
>>>> 
>>>> Is that an issue?
>>>> 

Re: [nag][VOTE] Release PyLucene 4.5.1-1

[Andi Vajda]

On Mon, 4 Nov 2013, Steve Rowe wrote:


+1

As with the 4.5.0 RC, the install instructions to ?make test? after ?sudo make 
install? fail:

   writing lucene.egg-info/PKG-INFO
   error: lucene.egg-info/PKG-INFO: Permission denied
   make: *** [install-test] Error 1

I ran ?sudo chown -R username .?, and then "make test? succeeded, all tests 
pass.


Thank you, Steve, I need to change the install instructions to run 'make 
test' _before_ make install (in a future release).


Andi..



Steve

On Nov 3, 2013, at 3:38 PM, Andi Vajda  wrote:



One more PMC vote is needed to make this release.
Please, consider voting on it.

Thanks !

Andi..

-- Forwarded message --
Date: Mon, 28 Oct 2013 17:46:30 -0700 (PDT)
From: Andi Vajda 
Reply-To: pylucene-...@lucene.apache.org, Andi Vajda 
To: pylucene-...@lucene.apache.org
Cc: gene...@lucene.apache.org
Subject: [VOTE] Release PyLucene 4.5.1-1


The PyLucene 4.5.1-1 release tracking the recent release of Apache Lucene 4.5.1 
is ready.

A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_5/CHANGES

PyLucene 4.5.1 is built with JCC 2.18 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_5_1/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.5.1-1.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

[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&focusedCommentId=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-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&focusedCommentId=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)

Lucene/Solr 4.5.1 release tag is missing

[Andi Vajda]

 Hi Mark,

Thank you for getting the 4.5.1 release out but the release tag seems to be 
missing in svn. Could you please add it to:

  http://svn.apache.org/repos/asf/lucene/dev/tags
This URL 404s right now:
  http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_5_1

Thanks !

Andi..

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

Re: [VOTE] Release PyLucene 4.5.0-1

[Andi Vajda]

 Hi Steve,

On Thu, 10 Oct 2013, Steve Rowe wrote:


After make'ing and installing jcc (no setup.py changes required); uncommenting 
the first Mac OS X 10.6 section in Makefile (I have OS X 10.8.5, with stock 
Python 2.7.2 and Oracle Java 1.7.0_25); and finally make'ing pylucene: 'sudo 
make install' fails - here's the tail end of the output:

-
writing build/bdist.macosx-10.8-x86_64/egg/EGG-INFO/native_libs.txt
creating dist
creating 'dist/lucene-4.5.0-py2.7-macosx-10.8-x86_64.egg' and adding 
'build/bdist.macosx-10.8-x86_64/egg' to it
removing 'build/bdist.macosx-10.8-x86_64/egg' (and everything under it)
Processing lucene-4.5.0-py2.7-macosx-10.8-x86_64.egg
creating 
/Library/Python/2.7/site-packages/lucene-4.5.0-py2.7-macosx-10.8-x86_64.egg
Extracting lucene-4.5.0-py2.7-macosx-10.8-x86_64.egg to 
/Library/Python/2.7/site-packages
Removing lucene 4.4.0 from easy-install.pth file
Adding lucene 4.5.0 to easy-install.pth file

Installed 
/Library/Python/2.7/site-packages/lucene-4.5.0-py2.7-macosx-10.8-x86_64.egg
Processing dependencies for lucene==4.5.0
Searching for lucene==4.5.0
Reading http://pypi.python.org/simple/lucene/
Couldn't find index page for 'lucene' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
No local packages or download links found for lucene==4.5.0
error: Could not find suitable distribution for 
Requirement.parse('lucene==4.5.0')


This error has been a problem for a while.
You need to make, then make install, in two steps.
Otherwise, when 'make install' in pylucene from clean, this error 
seems to happen. I don't know of a fix.


Andi..


make: *** [install] Error 1
-

I've included the entire 'sudo make install' output here: 
<https://paste.apache.org/8gAF>

Steve

On Oct 8, 2013, at 1:00 AM, Andi Vajda  wrote:



The PyLucene 4.5.0-1 release tracking the recent release of Apache Lucene 4.5.0 
is ready.

A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_5/CHANGES

PyLucene 4.5.0 is built with JCC 2.17 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_5_0/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.5.0-1.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

[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

Re: JCC for Java -> C++ and initializeClass

[Andi Vajda]

On Aug 30, 2013, at 15:55, Toivo Henningsson  
wrote:

>> -Original Message-
>> From: Andi Vajda [mailto:va...@apache.org]
>> Sent: den 30 augusti 2013 15:13
>> To: pylucene-...@lucene.apache.org
>> Subject: Re: JCC for Java -> C++ and initializeClass
>> 
>> 
>> On Fri, 30 Aug 2013, Toivo Henningsson wrote:
>> 
>>> I've been using JCC successfully for a number of months for wrapping Java
>> code to use in a C++ program.
>>> My question is about initializeClass. Right now, I'm calling
>>> 
>>> mypackage::MyClass::initializeClass(false);
>>> 
>>> on some of my classes during initialization (in the C++ code), as I got the
>> impression that I am supposed to do. But it doesn't seem to make a 
>> difference if
>> I remove those calls. Is it still required, and if it is, for what?
>> 
>> initializeClass() is called for you, lazily, when the C++ wrapper class 
>> constructor is
>> called for the first time.
>> You can see this in the generated .h files.
> 
> Ok, great!
> 
> So it's only if I need to use something inside of a class before creating any 
> instances that I need to call initializeClass()?

Thinking about this, from C++, there may be holes. From Python, when import on 
the Python wrapper is called, initializeClass() ends up being called too.

Andi..

> 
>> If initializeClass() were not called for you, your code would be crashing 
>> really
>> fast.
> 
> I suspected as much :)
> 
> / Toivo
> 
> Toivo Henningsson, PhD
> Software Engineer
> Simulation & Optimization R&D
> 
> Phone direct: +46 46 286 22 11
> Email: toivo.hennings...@modelon.com
> 
> 
> 
> Modelon AB
> Ideon Science Park
> SE-223 70 Lund, Sweden Phone: +46 46 286 2200
> Fax: +46 46 286 2201
> Web: http://www.modelon.com
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged. If you are not one of the named recipients or have received this 
> email in error, (i) you should not read, disclose, or copy it, (ii) please 
> notify sender of your receipt by reply email and delete this email and all 
> attachments, (iii) Modelon does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 

Re: JCC for Java -> C++ and initializeClass

[Andi Vajda]

On Aug 30, 2013, at 15:55, Toivo Henningsson  
wrote:

>> -Original Message-
>> From: Andi Vajda [mailto:va...@apache.org]
>> Sent: den 30 augusti 2013 15:13
>> To: pylucene-...@lucene.apache.org
>> Subject: Re: JCC for Java -> C++ and initializeClass
>> 
>> 
>> On Fri, 30 Aug 2013, Toivo Henningsson wrote:
>> 
>>> I've been using JCC successfully for a number of months for wrapping Java
>> code to use in a C++ program.
>>> My question is about initializeClass. Right now, I'm calling
>>> 
>>> mypackage::MyClass::initializeClass(false);
>>> 
>>> on some of my classes during initialization (in the C++ code), as I got the
>> impression that I am supposed to do. But it doesn't seem to make a 
>> difference if
>> I remove those calls. Is it still required, and if it is, for what?
>> 
>> initializeClass() is called for you, lazily, when the C++ wrapper class 
>> constructor is
>> called for the first time.
>> You can see this in the generated .h files.
> 
> Ok, great!
> 
> So it's only if I need to use something inside of a class before creating any 
> instances that I need to call initializeClass()?

How could you other than static data ?
Check the source for the class first to see if what you're accessing calls 
initializeClass() for you.

Andi..

> 
>> If initializeClass() were not called for you, your code would be crashing 
>> really
>> fast.
> 
> I suspected as much :)
> 
> / Toivo
> 
> Toivo Henningsson, PhD
> Software Engineer
> Simulation & Optimization R&D
> 
> Phone direct: +46 46 286 22 11
> Email: toivo.hennings...@modelon.com
> 
> 
> 
> Modelon AB
> Ideon Science Park
> SE-223 70 Lund, Sweden Phone: +46 46 286 2200
> Fax: +46 46 286 2201
> Web: http://www.modelon.com
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged. If you are not one of the named recipients or have received this 
> email in error, (i) you should not read, disclose, or copy it, (ii) please 
> notify sender of your receipt by reply email and delete this email and all 
> attachments, (iii) Modelon does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
> 

Re: Problem using Benchmark

[Andi Vajda]

 Abishek,

On Aug 8, 2013, at 12:08, Abhishek Gupta  wrote:

> You can see the complete error I am getting here.

Like I told you on pylucene-dev, you need to setup your classpath correctly so 
that these classes are found. If you are a Java newbie (as you said) and don't 
know what that means or how to achieve it you need to research the issue 
yourself first.

This mailing list is not the right forum for this question. Try a general Java 
programming forum first.

Andi..

> 
> 
> On Thu, Aug 8, 2013 at 3:10 PM, Abhishek Gupta  
> wrote:
>> Anyone pls help!!
>> 
>> 
>> 
>> On Wed, Aug 7, 2013 at 12:36 PM, Abhishek Gupta  
>> wrote:
>>> Hi,
>>> I am using PyLucene and there I tried to use lucene's Benchmark to evaluate 
>>> Trec Data. I was having a doubt which I first asked on pylucene-dev mailing 
>>> list. After solving the first problem I got another problem which is 
>>> referred a java error by Andi. You can see the thread here 
>>> (http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/201308.mbox/%3CCAJBtL5GG-LghfKBCKFhi%2BPXVmEFMdnM1zC%3D9NtDd-kL-Pv1nuQ%40mail.gmail.com%3E)
>>> 
>>> I am getting the class not found exception for 
>>> Compressor(http://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/compressors/package-summary.html).
>>>  I an a newbie to java development, so I don't know about Ant much. PLease 
>>> help in solving this issue.
>>>  
>>> 
>>> Thanking You
>>> Abhishek Gupta,
>>> 9624799165
>> 
>> 
>> 
>> -- 
>> Abhishek Gupta,
>> 897876422, 9416106204, 9624799165
> 
> 
> 
> -- 
> Abhishek Gupta,
> 897876422, 9416106204, 9624799165

[VOTE] Release PyLucene 4.3.1-1

[Andi Vajda]

The PyLucene 4.3.1-1 release tracking the recent release of Apache Lucene 
4.3.1 is ready.


A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_3/CHANGES

PyLucene 4.3.1 is built with JCC 2.16 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_3_1/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.3.1-1.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

[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-tabpanel&focusedCommentId=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

Re: [VOTE] Lucene Solr 4.3.1 RC1

[Andi Vajda]

+1

PyLucene 4.3.1 builds and passes its tests.

Andi..

On Mon, 10 Jun 2013, Shalin Shekhar Mangar wrote:


http://people.apache.org/~shalin/staging_area/lucene-solr-4.3.1-RC1-rev1491148/

Smoke tester is happy for me (osx).

Here's my +1!

--
Regards,
Shalin Shekhar Mangar.



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

Re: SIGSEGV indexing jcc-compiled module in IDEA PyCharm

[Andi Vajda]

On Wed, 29 May 2013, Barry Wark wrote:


On Wed, May 29, 2013 at 1:53 PM, Andi Vajda  wrote:



On Tue, 28 May 2013, Barry Wark wrote:

 On Tue, May 28, 2013 at 11:09 PM, Andi Vajda  wrote:




On Tue, 28 May 2013, Barry Wark wrote:

 Hi all,



This is an edge case, I realize, but thought I'd throw it out there in
case
anyone has come across a solution.

I'm using IDEA's PyCharm IDE (v2.7). The project virtualenv contains a
jcc-compiled module (which the project uses). PyCharm's indexer crashes



Which project ? yours or PyCharm-the-project ?
What version of JCC was this module compiled with ?




The project is mine, a python wrapper around Physion's Ovation API. We're
using JCC 2.16. PyCharm is IDEA's Python IDE (
http://www.jetbrains.com/**pycharm/ <http://www.jetbrains.com/pycharm/>).





 when indexing this module with the crash report below. When running the


project's unit tests in PyCharm, this jcc-compiled module is imported
(and
functions) without issue. PyCharm is a Java app, and I'm sure it's doing
some Java-Python bridging as well



If PyCharm is a Java app, what kind of python bridging is it doing ? And
how does that involve JCC ? I'm assuming that if PyCharm is a Java
module,
its indexing would be implemented in Java too ?




I don't really know how PyCharm handles Java/Python bridging. PyCharm is
built on IDEA's (Java) IDE framework, and it works with Python code. It's
purely speculation on my part that PyCharm's Java/Python bridging (if any)
is involved here.





 , so it's possible there's a conflict that


is the root of this crash. If so, I'll gladly file this as a PyCharm
issue,
but though I'd run this by the JCC gurus in case they recognize what's
going on. I've never seen the PyCharm indexer crash before on modules
that
don't use jcc.



What version(s) of JCC are involved here ?




2.16 on OS X 10.8, Python 2.7.



So, to paraphrase to make sure I understand this correctly:
  - PyCharm is a Java program that can spawn Python processes



Yes. In particular, it spawns a python process to "index" a python module
for code completion



  - Your python project uses JCC and runs fine by itself



Yes



  - Your python project crashes when run under PyCharm



Almost. My project *runs* fine when spawned under PyCharm, but the PyCharm
"indexer" crashes when attempting to index my module built with jcc.


That is not what your stacktrace shows. It's ends up somewhere in your 
jcc-built extension:


  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   _ovation_api.so

Andi..


One possibility here is that there is a clash of Java VMs. There can only
be one Java VM in a given process. JCC can be embedding a Java VM (the
default case) and it controls and initializes it or JCC can be embedded
inside a existing Java VM (when run inside Tomcat, for example). This
latter feature is not well documented but works fine (see the PythonVM.java
file in the JCC sources for more information).



Interesting. The process that crashes is a python child process spawned by
PyCharm. I don't know whether there is a JavaVM running in this child
process. I looked at the source of PythonVM.java and I don't see any
comments/docs about the various embedding options. Can you give me a bit
more information?





I don't know how PyCharm controls Python programs, does it embed a Python
VM ? does it spawn a sub-process ? There could be an issue here.



It's not transparent to me how PyCharm handles python VMs either. From the
crash log, it appears that in this particular case it is spawning a child
process.

Thank you,
Barry




Andi..



Thanks,
Barry





Andi..



 Thanks,

Barry


The Crash Log:

Process: python [85552]
Path:/Users/USER/*/python
Identifier:  python
Version: 60.3
Code Type:   X86-64 (Native)
Parent Process:  pycharm [85481]
User ID: 501

Date/Time:   2013-05-28 13:35:21.728 -0400
OS Version:  Mac OS X 10.8.3 (12D78)
Report Version:  10
Sleep/Wake UUID: 45FF7EDE-FE31-4248-B03D-1EE79118E02F


Interval Since Last Report:  36408 sec
Crashes Since Last Report:   3
Per-App Crashes Since Last Report:   3
Anonymous UUID:  5340B35B-8410-1D7A-63C1-**

2E05A95E2522

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x544857bc

VM Regions Near 0x544857bc:
-->
   __TEXT 000104484000-000104485000 [
 4K]

r-x/rwx SM=COW  /Users/USER/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _ovation_api.so   0x00010509e6c5 JArray::JArray(long) + 37
1   _ovation_api.so   0x000105095250 _jclass*
initializeClass(bool) + 42
2   _ovation_api.so   0x0001050

Re: [ANNOUNCE] Apache PyLucene 4.3.0

[Andi Vajda]

On May 15, 2013, at 10:08, Michael McCandless  wrote:

> Hmm the web site News section doesn't have 4.3.0?

I checked in the web site change last night. It probably needs some propagation 
time ?

Andi..

> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
> On Wed, May 15, 2013 at 11:14 AM, Andi Vajda  wrote:
>> 
>> I am pleased to announce the availability of Apache PyLucene 4.3.0, the
>> first PyLucene release wrapping the Lucene 4.x API.
>> 
>> Apache PyLucene, a subproject of Apache Lucene, is a Python extension for
>> accessing Apache Lucene Core. Its goal is to allow you to use Lucene's text
>> indexing and searching capabilities from Python. It is API compatible with
>> the latest version of Lucene 4.x Core, 4.3.0.
>> 
>> This release contains a number of bug fixes and improvements. Details can be
>> found in the changes files:
>> 
>> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_4_3_0/CHANGES
>> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>> 
>> Apache PyLucene is available from the following download page:
>> http://www.apache.org/dyn/closer.cgi/lucene/pylucene/pylucene-4.3.0-1-src.tar.gz
>> 
>> When downloading from a mirror site, please remember to verify the downloads
>> using signatures found on the Apache site:
>> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
>> 
>> For more information on Apache PyLucene, visit the project home page:
>>  http://lucene.apache.org/pylucene
>> 
>> Andi..

[ANNOUNCE] Apache PyLucene 4.3.0

[Andi Vajda]

I am pleased to announce the availability of Apache PyLucene 4.3.0, the 
first PyLucene release wrapping the Lucene 4.x API.


Apache PyLucene, a subproject of Apache Lucene, is a Python extension for
accessing Apache Lucene Core. Its goal is to allow you to use Lucene's text
indexing and searching capabilities from Python. It is API compatible with
the latest version of Lucene 4.x Core, 4.3.0.

This release contains a number of bug fixes and improvements. Details can be 
found in the changes files:


http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_4_3_0/CHANGES
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

Apache PyLucene is available from the following download page:
http://www.apache.org/dyn/closer.cgi/lucene/pylucene/pylucene-4.3.0-1-src.tar.gz

When downloading from a mirror site, please remember to verify the downloads 
using signatures found on the Apache site:

https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS

For more information on Apache PyLucene, visit the project home page:
  http://lucene.apache.org/pylucene

Andi..

Re: [VOTE] Lucene / Solr 4.3 RC4

[Andi Vajda]

On Tue, 30 Apr 2013, Simon Willnauer wrote:


ok guys here is my +1 for TAKE 4 !!

http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC4-rev1477023/


+1

PyLucene passes its tests with this release candidate.

Andi..



sorry for the delay & happy voting

simon

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




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

Re: [VOTE] Lucene Solr 4.3.0 RC3

[Andi Vajda]

+1 !

PyLucene 4.3 built from this RC rev builds and passes its tests.

Andi..

On Tue, 23 Apr 2013, Simon Willnauer wrote:


Here is a new RC candidate...

http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/

here is my +1

thanks for voting...

simon

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




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

Re: AW: AW: AW: [VOTE] Release PyLucene 4.2.1-1

[Andi Vajda]

On Apr 22, 2013, at 4:06, "Thomas Koch"  wrote:

>> Thanks again. A trick - on Windows - might be to rename the testrepo dir
> to
>> testrepo. and move to the next test. And clean them all
>> up at the end. Or create a testrepos directory tree where each
>> testrepo. is going to be created and remove the whole tree at
>> the end.
> 
> Sure, that's similar to what I did for the test_PyLucene (in
> setup/teardown):
> 
>>> I then ended up in using a 'fresh' test-repository (i.e. new dir name)
>>> if rmtree fails. The test_PyLucene test then passes on windows - the
>>> downside is that you end up with some testrepo.1, testrepo.2 etc. dirs
>>> - and of course an attempt to cleanup these dirs after
>>> unittest.main(exit=False) also fails...
> 
> Problem here is that one cannot cleanup the testrepos while inside the test
> loop. It must be done outside, i.e. on Makefile level (well on windows
> only).

Yes, that was my thought too.

>> GIven that Lucene 4.3 is about to be released, I think I'm going to drop
> the
>> 4.2.1 PyLucene release and move to proposing a PyLucene 4.3 release
>> candidate next.
> 
> Is there a release date yet?

Lucene/Solr 4.3 RC2 is being voted on right now.

Andi..

> Saw something on twitter, but not on the
> website and JIRA still states a number of open issues:
> https://issues.apache.org/jira/browse/LUCENE/fixforversion/12324143#selected
> Tab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> 
> 
> Regards,
> Thomas
> 
> 

Re: "[VOTE] Lucene/Solr 4.3 Take 2 (RC2)"

[Andi Vajda]

On Sat, 20 Apr 2013, Simon Willnauer wrote:


Here is the RC:
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC2-rev1470054

happy voting...

here is my +1


PyLucene 4.3 builds and passes its tests.

+1 !

Andi..

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

Re: [VOTE] Release PyLucene 4.2.1

[Andi Vajda]

On Tue, 16 Apr 2013, Chris Hostetter wrote:


: A release candidate is available from:
: http://people.apache.org/~vajda/staging_area/

-1 to releasing the files with the following MD5 checksums...

c84b71c718cee06bff63d5757115aa71  pylucene-4.2.1-0-src.tar.gz
a49300178884804ba9f7438a19732b21  pylucene-4.2.1-0-src.tar.gz.asc
f9d4c51dc4a04fc65d7630c8c8371be5  pylucene-4.2.1-0-src.tar.gz.md5

Problems encountered...

1) pylucene-4.2.1-0-src.tar.gz.md5 is not formated such that it can be
easily verified using "md5sum -c" (refers to "stdin")


Fixed, using md5sum to generate checksum now.


2) NOTICE file does not correctly reflect year of the distribution (2009
instead of 2013)


Fixed.


3) INSTALL and README files that refer to files in "doc/documentation"
however there is no "doc" directory, and the file names refered to
("readme.html" and "install.html") do not exist in any directory.


Removed the reference to the no longer existing docs directory and edited 
side to no longer refer to now obsolete (and removed) Lucene in Action 
samples.



4) Attempting to "make" the project resulted in an immediate build failure
w/o a clear indication of what the problem was...

hossman@frisbee:~/tmp/pylucene_4_2_1_rc/pylucene-4.2.1-0$ make
cd lucene-java-4.2.1/lucene; ( ivy-fail ||  ivy-bootstrap)
/bin/sh: 1: ivy-fail: not found
/bin/sh: 1: ivy-bootstrap: not found
make: *** [ivy] Error 127

(based on the install.html from the pylucene website, i'm guessing this is
related to not manually editing the Makefile, or specifying some mandatory
variables to 'make' on the commandline, but it seems wrong not to have a
more straight forward error here if that is what's required.)


Fixed by adding error messages complaining about the missing env var(s).

Andi..

Re: AW: [VOTE] Release PyLucene 4.2.1

[Andi Vajda]

ections.h(129) : error C2334: Unerwartete(s) Token vor ':';
sichtbarer Funktionstext wird übersprungen
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(129) : error C2760: Syntaxfehler: '{' erwartet und nicht
';'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(130) : error C2144: Syntaxfehler: 'java::util::List'
sollte auf '}' folgen
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\org/ap
ache/lucene/util/automaton/CompiledAutomaton$AUTOMATON_TYPE.h(42) : error
C2059: Syntaxfehler: 'Zeichenfolge'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\org/ap
ache/lucene/util/automaton/CompiledAutomaton$AUTOMATON_TYPE.h(42) : error
C2238: Unerwartete(s) Token vor ';'



-Ursprüngliche Nachricht-
Von: Andi Vajda [mailto:va...@apache.org]
Gesendet: Samstag, 13. April 2013 23:52
An: pylucene-...@lucene.apache.org
Cc: gene...@lucene.apache.org
Betreff: [VOTE] Release PyLucene 4.2.1


It looks like the time has finally come for a PyLucene 4.x release !

The PyLucene 4.2.1-0 release tracking the recent release of Apache Lucene
4.2.1 is ready.

A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_2/
CHANGES

PyLucene 4.2.1 is built with JCC 2.16 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_2_1/lucen
e/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.2.1-0.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

Re: AW: [VOTE] Release PyLucene 4.2.1

[Andi Vajda]

ene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(129) : error C2686: Statische und nicht-statische
> Memberfunktionen mit denselben Parametertypen k”nnen nicht überladen werden
> 
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126): kann 'int java::util::Collections::Object(void)'
> sein
> 
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(129): oder "int java::util::Collections::Object(void)"
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(129) : warning C4183: 'Object': Rückgabetyp fehlt;
> Memberfunktion, die 'int' zurckgibt wird angenommen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(129) : error C2334: Unerwartete(s) Token vor ':';
> sichtbarer Funktionstext wird übersprungen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(129) : error C2760: Syntaxfehler: '{' erwartet und nicht
> ';'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(130) : error C2144: Syntaxfehler: 'java::util::List'
> sollte auf '}' folgen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\org/ap
> ache/lucene/util/automaton/CompiledAutomaton$AUTOMATON_TYPE.h(42) : error
> C2059: Syntaxfehler: 'Zeichenfolge'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\org/ap
> ache/lucene/util/automaton/CompiledAutomaton$AUTOMATON_TYPE.h(42) : error
> C2238: Unerwartete(s) Token vor ';'
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: Andi Vajda [mailto:va...@apache.org]
>> Gesendet: Samstag, 13. April 2013 23:52
>> An: pylucene-...@lucene.apache.org
>> Cc: gene...@lucene.apache.org
>> Betreff: [VOTE] Release PyLucene 4.2.1
>> 
>> 
>> It looks like the time has finally come for a PyLucene 4.x release !
>> 
>> The PyLucene 4.2.1-0 release tracking the recent release of Apache Lucene
>> 4.2.1 is ready.
>> 
>> A release candidate is available from:
>> http://people.apache.org/~vajda/staging_area/
>> 
>> A list of changes in this release can be seen at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_2/
>> CHANGES
>> 
>> PyLucene 4.2.1 is built with JCC 2.16 included in these release artifacts:
>> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>> 
>> A list of Lucene Java changes can be seen at:
>> http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_2_1/lucen
>> e/CHANGES.txt
>> 
>> Please vote to release these artifacts as PyLucene 4.2.1-0.
>> 
>> Thanks !
>> 
>> Andi..
>> 
>> ps: the KEYS file for PyLucene release signing is at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
>> http://people.apache.org/~vajda/staging_area/KEYS
>> 
>> pps: here is my +1
> 
> 

Re: [VOTE] Release PyLucene 4.2.1

[Andi Vajda]

On Apr 15, 2013, at 3:52, Michael McCandless  wrote:

> I'm having trouble on an Ubuntu 12.10 box, using Java 1.7_07 and Python 2.7.3.
> 
> I was able to build and install both JCC and PyLucene, apparently 
> successfully.
> 
> I can "import lucene" in Python and print lucene.VERSION and confirm it's 
> 4.2.1.
> 
> lucene.initVM(lucene.CLASSPATH) succeeds.
> 
> Yet, there are no Lucene classes in the lucene module?  When I print
> dir(lucene) I just get this:
> 
> ['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass',
> 'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool',
> 'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float',
> 'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short',
> 'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError',
> 'PrintWriter', 'StringWriter', 'VERSION', '__builtins__', '__dir__',
> '__doc__', '__file__', '__name__', '__package__', '__path__',
> '_lucene', 'findClass', 'getVMEnv', 'initVM', 'makeClass',
> 'makeInterface', 'os', 'sys']
> 
> Am I missing something silly...?  Shouldn't Lucene's classes (eg
> FSDirectory) be visible in globals() in the lucene module?

The one big change on the PyLucene side is that now Lucene classes are in a 
package structure that mirrors the Java one. Thus, to get FSDirectory you now 
need to:

  import lucene
  from org.apache.lucene.store import FSDirectory

Besides providing initVM() and a few other things such as JArray, importing 
lucene also installs the org package tree.

Andi..

> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> On Sat, Apr 13, 2013 at 5:51 PM, Andi Vajda  wrote:
>> 
>> It looks like the time has finally come for a PyLucene 4.x release !
>> 
>> The PyLucene 4.2.1-0 release tracking the recent release of Apache Lucene
>> 4.2.1 is ready.
>> 
>> A release candidate is available from:
>> http://people.apache.org/~vajda/staging_area/
>> 
>> A list of changes in this release can be seen at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_2/CHANGES
>> 
>> PyLucene 4.2.1 is built with JCC 2.16 included in these release artifacts:
>> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>> 
>> A list of Lucene Java changes can be seen at:
>> http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_2_1/lucene/CHANGES.txt
>> 
>> Please vote to release these artifacts as PyLucene 4.2.1-0.
>> 
>> Thanks !
>> 
>> Andi..
>> 
>> ps: the KEYS file for PyLucene release signing is at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
>> http://people.apache.org/~vajda/staging_area/KEYS
>> 
>> pps: here is my +1

Re: initVM segmentation fault

[Andi Vajda]

On Mar 12, 2013, at 2:51, Jeune Asuncion  wrote:

> Dear *Pylucene*,
> 
> I am trying to run pylucene on my Fedora box but I get a segmentation fault
> when I do so. I was able to trace the cause of this error to initVM().
> 
> In the Python interpreter when I execute the lines of code below I get the
> segmentation fault:
> 
 import lucene
 lucene.initVM()
> Segmentation fault
> 
> I thought this was because jcc isn't installed because I have pylucene
> installed on another box and it returns a jcc object. However, I have jcc
> installed as well on the box where lucene.initVM() isn't working:
> 
 import jcc
 jcc.initVM()
> 
> 
> Would like to get some pointers as to why this is happening.

Did you build PyLucene and JCC on this box ?

Andi..


> 
> Thanks,
> 
> Jeune

Re: FacetExample.py

[Andi Vajda]

On Feb 14, 2013, at 0:30, Dawid Weiss  wrote:

>> This one:
>>  lucene/core/src/test/org/apache/lucene/search/TestSort.java
> 
> Yeah, I figured by comparing the size of these three... So, to make it
> short -- every thread should get its own Random instance from a call
> to LuceneTestCase's
> 
>  public static Random random() {
>return RandomizedContext.current().getRandom();
>  }
> 
> More specifically, the inside of this method returns per-thread Random
> instance. The first time a thread calls this method it initializes to
> the same (master) seed.
> 
> These are not super-easy things to rewrite, Andi. Don't know if you
> want to emulate the entire randomized testing infrastructure or just
> make it work consistently with one seed.

No, definitely not. As an alternative, I could jcc-wrap the test framework but 
that would defeat some of the purpose.

So, if each thread gets the same seed, then they should also get the same 
random values, right ?
I was generating "more random" values (no per thread generator) and producing 
per-thread field configurations that were incompatible with each other in the 
field cache. I've now worked around this by caching some key random choices and 
reusing them for all threads.

Andi..

> 
> Dawid

Re: [jira] [Created] (LUCENE-4779) Simplify TestSort

[Andi Vajda]

+1

Andi..


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

Re: FacetExample.py

[Andi Vajda]

 Hi Thomas,

On Tue, 12 Feb 2013, Thomas Koch wrote:


Thanks to your hints I was now able to build PyLucene4.1 and got further with 
the FacetExample.py - The imports should be OK now and most of the required 
changes are done I guess. However I now reached another problem: I need to 
instantiate the class 'FacetsCollector' but get an error when doing so:

 File "samples/FacetExample.py", line 222, in searchWithRequestAndQuery
   facetsCollector = FacetsCollector(facetSearchParams, indexReader, taxoReader)
NotImplementedError: ('instantiating java class', )

The java example has this line:
   FacetsCollector facetsCollector = new FacetsCollector(facetSearchParams, 
indexReader, taxoReader);
and javadocs state it has a public constructor:
http://lucene.apache.org/core/4_1_0/facet/org/apache/lucene/facet/search/FacetsCollector.html#FacetsCollector(org.apache.lucene.facet.search.params.FacetSearchParams,%20org.apache.lucene.index.IndexReader,%20org.apache.lucene.facet.taxonomy.TaxonomyReader)

So what could be the reason for this behavior?


The FacetCollector class is declared abstract. Thus you can't instantiate 
it, constructor or not. I think the intent is to instantiate one of its 
concrete inner subclasses.

See 
lucene-java-4.1/lucene/facet/src/java/org/apache/lucene/facet/search/FacetsCollector.java


I have another problem with the constructor of FacetSearchParams: it is 
expecting arguments:
 (List facetRequests, FacetIndexingParams indexingParams)
but neither
FacetSearchParams(Arrays.asList([facetRequest,]), indexingParams)
nor
FacetSearchParams([facetRequest,], indexingParams)
does it here.  I get

lucene.InvalidArgsError: (, '__init__', (, ))


There are four constructors on FacetSearchParams, none of which seems to match 
your call:
  public FacetSearchParams(FacetRequest... facetRequests)
  public FacetSearchParams(List facetRequests)
  public FacetSearchParams(FacetIndexingParams indexingParams, FacetRequest... 
facetRequests)
  public FacetSearchParams(FacetIndexingParams indexingParams, 
List facetRequests)

See 
lucene-java-4.1/lucene/facet/src/java/org/apache/lucene/facet/params/FacetSearchParams.java

You seem to be passing FacetIndexingParams last.

Andi..




I thought that JavaList could help, but I cannot import it:

from lucene.collections import JavaList

Traceback (most recent call last):
 File "", line 1, in 
 File 
"/Users/koch/.virtualenvs/pylucene/lib/python2.7/site-packages/lucene-4.1-py2.7-macosx-10.8-x86_64.egg/lucene/collections.py",
 line 17, in 
   from org.apache.pylucene.util import \
ImportError: No module named pylucene.util




That's probably because I had to disable in Makefile
## JARS+=$(HIGHLIGHTER_JAR)# needs memory contrib
## JARS+=$(EXTENSIONS_JAR) # needs highlighter contrib

Do you think that's a type cast issue and that JavaList would help here?
I need to define a 'typed' list , e.g. List

FacetSearchParams API docs:
http://lucene.apache.org/core/4_1_0/facet/org/apache/lucene/facet/search/params/FacetSearchParams.html

Current version of FacetExample.py
https://dl.dropbox.com/u/4384120/FacetExample.py

Any hints?

regards,
Thomas
--
Am 12.02.2013 um 09:19 schrieb Andi Vajda :



On Tue, 12 Feb 2013, Andi Vajda wrote:


Indeed. I reproduced that error here.
A new method was added to the FieldCache.Parser interface.
I added it to the classes missing it (rev 1445048).

I then found that the test case from hell, TestSort.java, has majorly changed 
again and test_Sort.py needs to be ported again. Sigh.


That being said, you should be able to build PyLucene 4.1 again and proceed 
with FacetExample.py. The test_Sort.py needed work shouldn't be blocking you.

Andi..

Re: Please help building pylucene 3.6.2 on Solaris 11

[Andi Vajda]

On Jan 30, 2013, at 5:43, Thomas Feuerstack 
 wrote:

> Am 29.01.2013 17:29, schrieb Andi Vajda:
>>>> What can you see at the line mentioned in the first compile error ?
>>>> build/_lucene/org/apache/lucene/analysis/tokenattributes/TypeAttribute.h:39:42
>>> 
>>>static ::java::lang::String *DEFAULT_TYPE;
>> 
>> It could be that DEFAULT_TYPE is macro-defined somewhere in your compiler's 
>> header files.
>> A way around that problem is to add --reserved DEFAULT_TYPE to the jcc 
>> invocation command in the Makefile.
> 
> it obviously *is* that DEFAULT_TYPE is macro-defined somewhere in some header 
> files. I added --reserved DEFAULT_TYPE to the Makefile and the compiler ran 
> (except of some warnings) without any errors.
> 
> While gmake test also didn't make any difficulties, i think the whole thing 
> will run (in the meantime, while i write this mail, the first bigger index is 
> created).
> 
> Do you think, it might be a good idea to refresh the Solaris-Infos under 
> http://lucene.apache.org/pylucene/install.html ?

Absolutely. If you want to contribute a patch with what you learned getting 
pylucene and jcc to run on your combination of compiler and operating system, 
by all means, send it in and I'll integrate it.

> I know that Solaris is some kind of exotic dinosaur, but at least there are 
> still people (like me), who have to use it. And a pylucene-instance based on 
> more recent standard-packages and gcc has in my opinion more charme, than 
> working with Sunstudio.
> 
> Anyway, thanks a lot for your help :-) Thomas

You're welcome !

Andi..

Re: Please help building pylucene 3.6.2 on Solaris 11

[Andi Vajda]

On Jan 29, 2013, at 5:09, Thomas Feuerstack 
 wrote:

> Hi Andi,
> 
> thanks for your immediate response.
> 
> Am 28.01.2013 18:13, schrieb Andi Vajda:
> 
> (...)
> 
>> What can you see at the line mentioned in the first compile error ?
>> build/_lucene/org/apache/lucene/analysis/tokenattributes/TypeAttribute.h:39:42
> 
>static ::java::lang::String *DEFAULT_TYPE;

It could be that DEFAULT_TYPE is macro-defined somewhere in your compiler's 
header files.
A way around that problem is to add --reserved DEFAULT_TYPE to the jcc 
invocation command in the Makefile.

> inside a
> 
> namespace org {
>  namespace apache {
>namespace lucene {
>  namespace analysis {
>namespace tokenattributes {
> 
>  class TypeAttribute : public ::org::apache::lucene::util::Attribute {
>  public:
>enum {
>  mid_setType_5fdc3f48,
>  mid_type_14c7b5c5,
>  max_mid
>};
> 
>static ::java::lang::Class *class$;
>static jmethodID *mids$;
>static bool live$;
>static jclass initializeClass(bool);
> 
>explicit TypeAttribute(jobject obj) : 
> ::org::apache::lucene::util::Attribute(obj) {
>  if (obj != NULL)
>env->getClass(initializeClass);
>}
>TypeAttribute(const TypeAttribute& obj) : 
> ::org::apache::lucene::util::Attribute(obj) {}
> 
>static ::java::lang::String *DEFAULT_TYPE;
> 
>void setType(const ::java::lang::String &) const;
>::java::lang::String type() const;
>  };
>}
>  }
>}
>  }
> }
> 
> (...)
> 
>> Same question for
>> "jcc/sources/JObject.h", line 102: Error: "," expected instead of "Type".
> 
> extern PyTypeObject PY_TYPE(JObject);

I can't make sense of that error.
I've had PyLucene built with that or an earlier version of that compiler in the 
past, though. But try the other compiler and the --reserved workaround first.

Andi..


> 
> inside a block
> 
> #ifdef PYTHON
> 
> #include 
> #include "macros.h"
> 
> class t_JObject {
> public:
>PyObject_HEAD
>JObject object;
> };
> 
> extern PyTypeObject PY_TYPE(JObject);
> 
> #endif /* PYTHON */
> 
>> "jcc/sources/jcc.cpp", line 82: Error: "," expected instead of "Type".
> 
> PyTypeObject PY_TYPE(JCCEnv) = {
> 
> as the beginning of a structure(? - Sorry, i'm not so familiar with C++)
> 
> PyTypeObject PY_TYPE(JCCEnv) = {
>PyObject_HEAD_INIT(NULL)
>0,   /* ob_size */
>"jcc.JCCEnv",/* tp_name */
>sizeof(t_jccenv),/* tp_basicsize */
>0,   /* tp_itemsize */
>(destructor)t_jccenv_dealloc,/* tp_dealloc */
>0,   /* tp_print */
>0,   /* tp_getattr */
>0,   /* tp_setattr */
>0,   /* tp_compare */
>0,   /* tp_repr */
>0,   /* tp_as_number */
>0,   /* tp_as_sequence */
>0,   /* tp_as_mapping */
>0,   /* tp_hash  */
>0,   /* tp_call */
>0,   /* tp_str */
>0,   /* tp_getattro */
>0,   /* tp_setattro */
>0,   /* tp_as_buffer */
>Py_TPFLAGS_DEFAULT,  /* tp_flags */
>"JCCEnv",/* tp_doc */
>0,   /* tp_traverse */
>0,   /* tp_clear */
>0,   /* tp_richcompare */
>0,   /* tp_weaklistoffset */
>0,   /* tp_iter */
>0,   /* tp_iternext */
>t_jccenv_methods,/* tp_methods */
>t_jccenv_members,/* tp_members */
>t_jccenv_properties, /* tp_getset */
>0,   /* tp_base */
>0,   /* tp_dict */
>0,   /* tp_descr_get */
>0,   /* tp_descr_set */
>0,   /* tp_dictoffset */
>0,   /* tp_init */
>0,   /* tp_alloc */
>0,   /* tp_new */
> };
> 
> Hope, that this might help you.
> 
> Thanks - Thomas

Re: will Lucene seek past the end of an IndexInput?

[Andi Vajda]

On Mon, 7 Jan 2013, Stuart Halloway wrote:


Problem found.  Implementation inheritance + java.lang.Cloneable for the
lose. :-)


Yes, that rings a bell for me. I have a Python implementation of a Lucene 
store and the cloning of IndexInput instances provides for some debugging 
fun and obfuscation :-)


Andi..



Sorry for the noise.






On Mon, Jan 7, 2013 at 5:23 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:


On Mon, Jan 7, 2013 at 2:34 PM, Stuart Halloway
 wrote:

Still no joy isolating, increasingly convinced the problem is in my code.
The overseeks are always in the .frq files, and always modest, e.g. 10%

past

the end, not 1000%.  Always from the ConjunctionScorer -- I can search

for

every word in the index in isolation without hitting the problem.


Strange ...


Any of that ring bells?


Sorry no bells ringing ...

When you run this same test on one of Lucene's stock directories does
it hit EOFE?  Ie, seeking beyond end of file and reading ought to
throw EOFE with the existing dir impls ...

(RAMInputStream seems to allow seeking beyond the end, but a
subsequent read should throw EOFE).

Mike McCandless

http://blog.mikemccandless.com

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






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

Re: AW: [VOTE] Release PyLucene 3.6.2

[Andi Vajda]

On Jan 3, 2013, at 2:18, "Thomas Koch"  wrote:

> Maybe I should add that both java and python are universal binary files for
> 32/64 bit : 
> 
> ios:~ koch$ file /usr/bin/java
> /usr/bin/java: Mach-O universal binary with 2 architectures
> /usr/bin/java (for architecture x86_64):Mach-O 64-bit executable
> x86_64
> /usr/bin/java (for architecture i386):Mach-O executable i386
> 
> ios:~ koch$ file /usr/bin/python
> /usr/bin/python: Mach-O universal binary with 2 architectures
> /usr/bin/python (for architecture i386):Mach-O executable i386
> /usr/bin/python (for architecture x86_64):Mach-O 64-bit executable
> x86_64
> 
> It seems to me that JCC is also build for both architecture because of the
> flags -arch i386 AND -arch x86_64.
> Maybe the warning relates to the 32bit binaries? Just guessing  - don't
> really know how this universal binary compile magic really works ,-(

When building PyLucene on my mac, I only build the 64-bit version by specifying 
-arch x86_64, skipping the 32-bit version. It cuts build time (and size) in 
half.

Andi..

> 
> However Apple Docs say one should take care of theses warnings:
> 
> --%<--
> -Wshorten-64-to-32
> 
>This flag is like -Wconversion, but is specific to 64-bit data types.
> This flag causes GCC to issue a warning whenever a value is implicitly
> converted (truncated) from a 64-bit type to a 32-bit type. You should fix
> any warnings generated by this flag, as they are likely to be bugs.
> --%<--
> Found here:
> https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64b
> itPorting/building/building.html
> 
> 
> regards
> Thomas
> 
>> -Ursprüngliche Nachricht-
>> Von: Thomas Koch [mailto:k...@orbiteam.de]
>> Gesendet: Donnerstag, 3. Januar 2013 09:54
>> An: pylucene developers
>> Betreff: Re: [VOTE] Release PyLucene 3.6.2
>> ...
>> I'm on 10.8.2 too with builtin python 2.7.2. I used the makefile snippet
> for
>> Mac OS X 10.6 (for 64-bit and 32-bit Python):
>> 
>> PREFIX_PYTHON=/usr
>> ANT=ant
>> PYTHON=$(PREFIX_PYTHON)/bin/python
>> JCC=$(PYTHON) -m jcc.__main__ --shared --arch x86_64 --arch i386
>> NUM_FILES=4
>> 
>> As said: jcc and pylucene both build and run fine…
>> 
>> 
>> regards,
>> Thomas
> 
> 
> 

Re: tiny patch for java7 on os X

[Andi Vajda]

On Wed, 26 Dec 2012, Robert Muir wrote:


i installed java7 on my os X... with the following build patch
pylucene seems to work fine (tests pass etc).
I think java7 is just pickier about -source/-target both being set for
jcc. And the extensions should use the same explicit source/target (or
the build can hit classfile version problems).


Applied in rev 1426118, thank you !

Andi..



Index: extensions.xml
===
--- extensions.xml  (revision 1425975)
+++ extensions.xml  (working copy)
@@ -16,7 +16,7 @@

  

-
+
  

  
Index: jcc/setup.py
===
--- jcc/setup.py(revision 1425975)
+++ jcc/setup.py(working copy)
@@ -149,7 +149,7 @@
LFLAGS['linux2'] = LFLAGS['linux2/%s' %(machine)]

JAVAC = {
-'darwin': ['javac', '-target', '1.5'],
+'darwin': ['javac', '-source', '1.5', '-target', '1.5'],
'ipod': ['jikes', '-cp', '/usr/share/classpath/glibj.zip'],
'linux2': ['javac'],
'sunos5': ['javac'],




http://pastebin.com/raw.php?i=qHpMw9Na

Re: [VOTE] Release PyLucene 3.6.2

[Andi Vajda]

On Wed, 26 Dec 2012, Andi Vajda wrote:



On Dec 26, 2012, at 11:58, Robert Muir  wrote:


On Wed, Dec 26, 2012 at 11:14 AM, Andi Vajda  wrote:


Very strange. Why would it go out to pypi to install unrelated packages ?
Odd. Did you run just 'make' first before running 'make test' ? (my workflow).



I just tried make, followed by make test, and it worked fine. So I
think i must have just tried 'make test' in one shot... must be a
little build thing.

doesn't seem like a blocker to me, just seemed a bit odd.


I'll see if I can reproduce this. Thank you for the clarification.


I did reproduce something similar running 'make test' after 'make clean'. 
Adding a dependency on 'all' fixed it.


Andi..



Andi..

Re: VOTE: release 3.6.2

[Andi Vajda]

+1

I prepared a PyLucene 3.6.2 release from the tip of the lucene_solr_3_6 
branch and all tests passed.


Andi..

On Wed, 19 Dec 2012, Robert Muir wrote:


Hello everyone, given the bug Mike fixed in
https://issues.apache.org/jira/browse/LUCENE-4635, I think we should
push out a 3.6.2 bugfix release with the fix.
Tom (the reporter of the bug) confirmed his checkindex passed
successfully last night, and besides that we have a few other nice
bugfixes there.

Artifacts are here: http://s.apache.org/lusolr362rc0

If you want to use the smoketester, of course you must run it from the
lucene_solr_3_6 branch. This passes for me on linux. I'm not sure it
works on other platforms.

Thanks,
Robert

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




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

Re: jar error while trying to build

[Andi Vajda]

On Sep 19, 2012, at 8:20, Mohamed Lrhazi  wrote:

> to make sure, I just re-unpacked the tarball and rerun:
> 
> ml623@cab2b:~/tmp/pylucene-3.6.1-2/ > ANT=/opt/ant/bin/ant make

Did you follow the instructions at the top of the Makefile ?

Andi..

> 
> and got the same error.
> 
> Any idea what could be causing this?
> 
> Thanks a lot,
> Mohamed.
> 
> On Tue, Sep 18, 2012 at 6:39 PM, Andi Vajda  wrote:
>> 
>> On Tue, 18 Sep 2012, Mohamed Lrhazi wrote:
>> 
>>> Hello,
>>> 
>>> I am trying to build pylucene on a redhat ent 6.1. the make fails with
>>> an error pasted bellow.
>>> 
>>> Any hints appreciated.
>> 
>> 
>> Your Makefile seems to be broken in a way that --jar somewhere became just
>> jar and it's downhill from there.
>>   jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>> 
>> Andi..
>> 
>> 
>>> 
>>> Thanks a lot,
>>> Mohamed.
>>> 
>>> 
>>> cd lucene-java-3.6.1/lucene; (/opt/ant/bin/ant ivy-fail ||
>>> /opt/ant/bin/ant ivy-bootstrap)
>>> Buildfile: /home/ml623/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build.xml
>>> 
>>> ivy-fail:
>>> 
>>> BUILD SUCCESSFUL
>>> Total time: 0 seconds
>>> ICU not installed
>>> jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>>> 
>>> lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
>>> --jar
>>> lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
>>> --jar
>>> lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter
>>> -3.6.1.jar --jar build/jar/extensions.jar --jar
>>> lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
>>> --jar lucene-java-3.6.1/lucene/
>>> build/contrib/grouping/lucene-grouping-3.6.1.jar --jar
>>> lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
>>> --jar lucene-java-3.6.1/lucene
>>> /build/contrib/facet/lucene-facet-3.6.1.jar --jar
>>> 
>>> lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar
>>> --package java.lan
>>> g java.lang.System java.lang.Runtime java.lang.IllegalStateException
>>> java.lang.IndexOutOfBoundsException --package java.util
>>> java.util.Arrays java.util
>>> .HashMap java.util.HashSet java.util.NoSuchElementException
>>> java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator
>>> --package java.util.regex --package java.io java.io.StringReader
>>> java.io.InputStreamReader java.io.FileInputStream --exclude
>>> org.apache.lucene.queryParser.Token --exclude
>>> org.apache.lucene.queryParser.TokenMgrError --exclude
>>> org.apache.lucene.queryParser.QueryParserTokenManager --exclude
>>> org.apache.lucene.queryParser.ParseException --exclude
>>> org.apache.lucene.queryParser.CharStream --exclude
>>> org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude
>>> org.apache.regexp.RegexpTunnel --exclude
>>> org.apache.lucene.analysis.cn.smart.AnalyzerProfile --python lucene
>>> --mapping org.apache.lucene.document.Document
>>> 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping
>>> java.util.Properties
>>> 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
>>> java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' --rename
>>> org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer
>>> --rename org.apache.lucene.search.highlight.Scorer=HighlighterScorer
>>> --rename org.apache.lucene.search.spell.Dictionary=SpellDictionary
>>> --rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort
>>> --rename org.apache.lucene.store.DataInput=StoreDataInput --rename
>>> org.apache.lucene.store.DataOutput=StoreDataOutput --rename
>>> org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer --rename
>>> org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer --rename
>>> org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer --rename
>>> org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer
>>> --version 3.6.1 --module python/collections.py --module
>>> python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py
>>> --module python/ICUTransformFilter.py  --files  --build
>>> Illegal option: l
>>> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point]
>>> [-C dir] files ...
>>> Options:
>>>   -c  create new archive
>>>   -t  list table of contents for archive
>>> ...
>>> 
>> 

Re: JCC access to a nested iteration class

[Andi Vajda]

On Fri, 17 Aug 2012, csrickle wrote:


...

This is an Apache Accumulo interface. The particular class containing the 
nested class, analogous to App.Embedded.hello2(), is 
TabletServerBatchReaderIterator:


http://svn.apache.org/viewvc/accumulo/tags/1.4.1/src/core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderIterator.java?view=markup

Getting jcc to recognize MyEntry (listed below) is the actual problem I'm 
still hoping to solve.


 private static class MyEntry implements Entry {
98
99   private Key key;
100  private Value value;
101
102  MyEntry(Key key, Value value) {
103  this.key = key;
104  this.value = value;
105  }
106
107  @Override
108  public Key getKey() {
109  return key;
110  }
111
112  @Override
113  public Value getValue() {
114  return value;
115  }
116
117  @Override
118  public Value setValue(Value value) {
119  throw new UnsupportedOperationException();
120  }
121
122  }

If this class is contained within a specified --jar argument in the jcc 
invocation, can I then add a --rename command such that I can refer to the 
"private" and "static" MyEntry class.


When using --jar, only public classes are wrapped. The reason is that 
non-public classes are not meant to be accessed from the outside and that 
this offers a great way to reduce the amount of code generated by JCC.


This is also why you should carefully consider which --package flags to use 
so that dependencies to classes outside the set you'd like to wrap also get 
wrapped. By default, methods whose signature refers to classes outside your 
wrap-set that are not in a package listed with --package are skipped.


If JCC was greedy in its wrapping by default, you'd very quickly end up 
wrapping the entire JRE.


Now, to your question more specifically: to wrap a non-public class, just 
list their name on the jcc command line.


For example, if you change your jcchello Embedded class to private and give 
it a public constructor, then your earlier example still works as before, 
you can still call AppEmbedded(App()).hello2(). If you don't give it a 
public constructor, you won't be able to instantiate Embedded from the 
outside, as only public methods and constructors are wrapped, for similar 
reasons.


Andi..

Changing Python class/module layout, dropping --rename ?

[Andi Vajda]

On Tue, 10 Jul 2012, Andi Vajda wrote:


I would also like to propose a change, to allow for more flexible
mechanism of generating Python class names. The patch doesn't change
the default pylucene behaviour, but it gives people a way to replace
class names with patterns. I have noticed that there are more
same-name classes from different packages in the new lucene (and it
becomes worse when one has to deal with both lucene and solr).


Another way to fix this is to reproduce the namespace hierarchy used in 
Lucene, following along the Java packages, something I've been dreading to 
do. Lucene just loves a really long deeply nested class structure.

I'm not convinced yet it is bad enough to go down that route, though.

Your proposal to use patterns may in fact yield a much more convenient 
solution. Thanks !


Rethinking this a bit, I'm prepared to change my mind on this. Your 
patterned rename patch shows that we're slowly but surely reaching the limit 
of the current setup that consists in throwing all wrapped classes under the 
one global 'lucene' namespace.


Lucene 4.0 has seen a large number of deeply nested classes with similar 
names added since 3.x. Renaming these one by one (or excluding some) doesn't 
scale. Using the proposed patterned rename scales more but makes it 
difficult to know what got renamed and how.
Ultimately, the more classes that are like-named, the more classes would 
have instable names from one release to the next as more duplicated names 
are encountered.


What if instead JCC supported the original Java namespaces all the way to 
the Python inteface (still dropping the original 'org.apache' Java package 
tree prefix) ?
The world-rooted style of naming Java classes isn't Pythonic but using the 
second half of the package structure feels right at home in the Python 
world.


JCC already re-creates the complete Java package structure in C++ as 
namespaces for all the C++ code it generates, for both the JNI wrapper 
classes and the C++/Python types. It's only the installation of the class 
names into the Python VM that is done in the flat 'lucene' namespace.


I think it shouldn't be too hard to change the code that installs classes to 
create sub-modules of the lucene module and install classes in these 
submodules instead (down to however many levels are in the original).


In other words:
  - from lucene import Document
would become
  - from lucene.document import Document

One could of course also say:
  - import lucene.document.Document as whateverOneLikes

If that proposal isn't mortally flawed somewhere, I'm prepared to drop 
support for --rename and replace it with this new Python class/module 
layout.


Since this is being talked about in the context of a major PyLucene release, 
version 4.0, and that all tests/samples have to be reworked anyway, this 
backwards compat break shouldn't be too controversial, hopefully.


If it is, the old --rename could be preserved for sure, but I'd prefer 
simplying the JCC interface than to accrete more to it.


What do you think ?

Andi..



Andi..



I can confirm the test_test_BinaryDocument.py crashes the JVM no more.

Roman


On Tue, Jul 10, 2012 at 8:54 AM, Andi Vajda  wrote:


 Hi Roman,


On Mon, 9 Jul 2012, Roman Chyla wrote:


Thanks, I am attaching a new patch that adds the missing test base.
Sorry for the tabs, I was probably messing around with a few editors
(some of them not configured properly)



I integrated your test class (renaming it to fit the naming scheme used).
Thanks !



So far, found one serious problem, crashes VM -- see. eg
test/test_BinaryDocument.py - when getting the document using:
reader.document(0)



test/test_BInaryDocument.py doesn't seem to crash the VM but fails because
of some API changes. I suspect the crash to be some issue related to using
an older jcc.

I see a comment saying: "couldn't find any combination with lucene4.0 
where
it would raise errors". Most of these unit tests are straight ports from 
the
original Java version. If you're stumped about a change, check the 
original

Java test, it may have changed too.

Andi..

[jira] [Commented] (LUCENE-4190) IndexWriter deletes non-Lucene files

[Andi Vajda (JIRA)]

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

Andi Vajda commented on LUCENE-4190:



{quote}
1. subdirectories currently are a foreign concept to Directory, we would have
to make some serious changes there to support subdirectories.
2. Lucene 3.x and Lucene4-alpha indexes still need to be supported, and we
dont want to leave behind baggage when we merge, so the transition would be
tricky.
{quote}

The way I imagined this working (short of looking at the code and proposing a
patch) was to just append something like "lucene.index" to the directory path
given by the user and pretend that's what the user gave it (and create that
subdirectory). Code deleting the index files becomes simpler, it's just a
recursive delete of that subdirectory Lucene created.

That name, "lucene.index", could be in fact an additional parameter to the
Directory class so that one could pick different names and store multiple
indexes in the directory part.

Having that extra name parameter would make it harder to a just use c:\ or 
c:\tmp which, while apparently silly, is also easy to hit accidentally. Imagine 
a shell script that puts together an index directory path with, say, some 
environment variables or command line parameters, and because of a bug there or 
some human error some inputs making up that path are now missing. Fancy 
generated path /home/fred/$(indexes) is now shorter all of a sudden, /home/fred 
gets used instead and later (partially) wiped. Ouch. No, I didn't just make 
this up :-)

{quote}
3. the user could also do this on their own right? e.g. we still have the same 
situation we have currently, where anything in that directory can get deleted 
by lucene, its just underneath another layer.
{quote}

Of course they could, but the difference is that if Lucene is the one creating
a directory, I expect it to more or less control the files in it, whereas if I
create a directory myself, that is not the case. I don't expect Lucene to take
it over by deleting files in it it didn't create.

With the extra index name parameter, one would make it much less likely to 
stomp over something not belonging to Lucene. As for backwards compatibility, 
one could tolerate for the next release cycle, that this extra name be empty 
(which would be equivalent to the situation we have now, bug 4190).


> IndexWriter deletes non-Lucene files
> 
>
> Key: LUCENE-4190
> URL: https://issues.apache.org/jira/browse/LUCENE-4190
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Robert Muir
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4190.patch, LUCENE-4190.patch, LUCENE-4190.patch, 
> LUCENE-4190.patch
>
>
> Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog 
> post: 
> http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html
> IndexWriter will now (as of 4.0) delete all foreign files from the index 
> directory.  We made this change because Codecs are free to write to any files 
> now, so the space of filenames is hard to "bound".
> But if the user accidentally uses the wrong directory (eg c:/) then we will 
> in fact delete important stuff.
> I think we can at least use some simple criteria (must start with _, maybe 
> must fit certain pattern eg _(_X).Y), so we are much less likely to 
> delete a non-Lucene file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4190) IndexWriter deletes non-Lucene files

[Andi Vajda (JIRA)]

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

Andi Vajda commented on LUCENE-4190:


If Joe user gives c:\ as their index directory, which is silly, sure, it's even 
worse to just delete all files in there.
Even if you just delete files there that are prefixed with _, we should know 
better than that. By putting the files we want to control into their own 
directory, a subdirectory of the Lucene index directory, there is very little 
room for mistakes.
_ is just not a namespace for files reserved to Lucene, but a sub-directory 
chosen by Lucene instead is.
If you persist in picking just _, why not picking _90439043_ to make it at 
least more unique ?

> IndexWriter deletes non-Lucene files
> 
>
> Key: LUCENE-4190
> URL: https://issues.apache.org/jira/browse/LUCENE-4190
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Robert Muir
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4190.patch, LUCENE-4190.patch
>
>
> Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog 
> post: 
> http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html
> IndexWriter will now (as of 4.0) delete all foreign files from the index 
> directory.  We made this change because Codecs are free to write to any files 
> now, so the space of filenames is hard to "bound".
> But if the user accidentally uses the wrong directory (eg c:/) then we will 
> in fact delete important stuff.
> I think we can at least use some simple criteria (must start with _, maybe 
> must fit certain pattern eg _(_X).Y), so we are much less likely to 
> delete a non-Lucene file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4190) IndexWriter deletes non-Lucene files

[Andi Vajda (JIRA)]

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

Andi Vajda commented on LUCENE-4190:


I think that the way to "bound" the namespace of files is to put everything in 
a subdirectory of the index directory chosen by the user and control the name 
of that subdirectory, making it clear that this is semi-private to Lucene and 
that all files in that subdirectory are fair game.

> IndexWriter deletes non-Lucene files
> 
>
> Key: LUCENE-4190
> URL: https://issues.apache.org/jira/browse/LUCENE-4190
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-4190.patch
>
>
> Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog 
> post: 
> http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html
> IndexWriter will now (as of 4.0) delete all foreign files from the index 
> directory.  We made this change because Codecs are free to write to any files 
> now, so the space of filenames is hard to "bound".
> But if the user accidentally uses the wrong directory (eg c:/) then we will 
> in fact delete important stuff.
> I think we can at least use some simple criteria (must start with _, maybe 
> must fit certain pattern eg _(_X).Y), so we are much less likely to 
> delete a non-Lucene file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (PYLUCENE-17) Possible race condition with pylucene attachCurrentThread

[Andi Vajda (JIRA)]

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

Andi Vajda commented on PYLUCENE-17:


While there could be something like your scenario going on, I'm not sure it's a 
problem (I'm a bit confused right now).
The static fields are not initialized during initializeClass() and their 
initialization is not triggered by initializeClass() either (your step 1 there 
is incomplete). The static fields are setup during ::initialize() which 
is called by the __initialize__() calls defined in __init__.cpp which are 
called by the main __initialize__() function which is what is called when you 
call initVM() from Python for your module (thus why it is important to call the 
initVM() that comes with your module).

If importing the module and calling initVM() is all done in one thread, the 
main one, others not running until initVM is complete, then I don't even 
understand right now (I'm confused, I said :-), how we can even get this bug. 
But I reproduced it, so I'm not arguing anything, just trying to wrap my head 
around this process again.

Right now, I'm clearly missing something. I don't understand why this bug even 
happened in the first place anymore :-(


> Possible race condition with pylucene attachCurrentThread
> -
>
> Key: PYLUCENE-17
> URL: https://issues.apache.org/jira/browse/PYLUCENE-17
> Project: PyLucene
>  Issue Type: Bug
> Environment: Linux 2.6.39
> Sun jdk 1.6.26
>Reporter: Greg Bowyer
>  Labels: pylucene
> Attachments: PYLUCENE-17-3.patch, PYLUCENE-17-4.patch, backtrace, 
> diff.17.txt, lucene-threadtest.py
>
>
> It looks like there is a possible race that can cause null pointer exceptions 
> in the JVM, making it crash
> Because its a race it is hard to reproduce, the best luck I have had so far 
> is dropping my FS cache in the OS, which seems to slow down the 
> initialisation of the JVM enough to make it easier to reproduce.
> Attached is my test case
> Test session follows
> ---
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f79226b35c8, pid=26581, tid=140158003312384
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4b05c8]  instanceKlass::cached_itable_index(unsigned 
> long)+0x18
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid26581.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ rm -r /tmp/test-index/
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> [thread 139988165344768 also had an error][thread 139988165344768 also had an 
> error]#
> #  SIGSEGV (0xb)
>  at pc=0x7f5197550a29, pid=27657, tid=139988039468800
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4f2a29]  unsigned+0x299
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid27657.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f51bc2eaa1e, pid=28124, tid=139988377052928
>

[jira] [Updated] (PYLUCENE-17) Possible race condition with pylucene attachCurrentThread

[Andi Vajda (JIRA)]

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

Andi Vajda updated PYLUCENE-17:
---

Attachment: diff.17.txt

With this patch, I can no longer reproduce this bug using Greg's test. Please 
try it with your use case and let me know if this resolves the issue for your 
use case too.
In this patch, I only use the lock if the class$ variable was found to be NULL.

> Possible race condition with pylucene attachCurrentThread
> -
>
> Key: PYLUCENE-17
> URL: https://issues.apache.org/jira/browse/PYLUCENE-17
> Project: PyLucene
>  Issue Type: Bug
> Environment: Linux 2.6.39
> Sun jdk 1.6.26
>Reporter: Greg Bowyer
>  Labels: pylucene
> Attachments: PYLUCENE-17-3.patch, backtrace, diff.17.txt, 
> lucene-threadtest.py
>
>
> It looks like there is a possible race that can cause null pointer exceptions 
> in the JVM, making it crash
> Because its a race it is hard to reproduce, the best luck I have had so far 
> is dropping my FS cache in the OS, which seems to slow down the 
> initialisation of the JVM enough to make it easier to reproduce.
> Attached is my test case
> Test session follows
> ---
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f79226b35c8, pid=26581, tid=140158003312384
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4b05c8]  instanceKlass::cached_itable_index(unsigned 
> long)+0x18
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid26581.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ rm -r /tmp/test-index/
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> [thread 139988165344768 also had an error][thread 139988165344768 also had an 
> error]#
> #  SIGSEGV (0xb)
>  at pc=0x7f5197550a29, pid=27657, tid=139988039468800
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4f2a29]  unsigned+0x299
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid27657.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > 
> /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f51bc2eaa1e, pid=28124, tid=139988377052928
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4f2a1e]  unsigned+0x28e
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid28124.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PYLUCENE-18) Version 3.6.0 lacks chagelog/readme

[Andi Vajda (JIRA)]

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

Andi Vajda commented on PYLUCENE-18:


The beginning of the list of files in pylucene-3.6.0-2.tar.gz is shown below. 
CHANGES is in second position and is 6046 bytes in size. Which tar archive are 
you talking about ?

About the README and the lack of docs in tarball, you're right. The lucene 
website was changed and the 'forrest' site abandoned. The new site is in 
transition and its contents are no longer included in the tarball as before.
README should at least have a correct link to the docs on the site. That part 
of the bug is real.

   drwxr-xr-x 501/800 pylucene-3.6.0-2/
 -rw-r--r-- 501/80 6046 pylucene-3.6.0-2/CHANGES
 -rw-r--r-- 501/80 1353 pylucene-3.6.0-2/CREDITS
 -rw-r--r-- 501/80  729 pylucene-3.6.0-2/extensions.xml
 -rw-r--r-- 501/80  107 pylucene-3.6.0-2/INSTALL
 drwxr-xr-x 501/800 pylucene-3.6.0-2/java/
 drwxr-xr-x 501/800 pylucene-3.6.0-2/jcc/
 -rw-r--r-- 501/8011358 pylucene-3.6.0-2/LICENSE
 drwxr-xr-x 501/800 pylucene-3.6.0-2/lucene-java-3.6.0/
 -rw-r--r-- 501/8014551 pylucene-3.6.0-2/Makefile
 -rw-r--r-- 501/80  229 pylucene-3.6.0-2/NOTICE
 drwxr-xr-x 501/800 pylucene-3.6.0-2/python/
 -rw-r--r-- 501/80   42 pylucene-3.6.0-2/README
 drwxr-xr-x 501/800 pylucene-3.6.0-2/samples/
 drwxr-xr-x 501/800 pylucene-3.6.0-2/test/

etc...


> Version 3.6.0 lacks chagelog/readme
> ---
>
> Key: PYLUCENE-18
> URL: https://issues.apache.org/jira/browse/PYLUCENE-18
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Dmitry Nezhevenko
>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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: jcc dll loading error

[Andi Vajda]

On May 25, 2012, at 22:57, Mark Finkelstein  wrote:

> Hello everyone!
> 
> I hope this is a relevant question. I was trying to use jcc to create a
> wrapper for a different project's library but when I try to run python -m
> jcc.main
> I get the error C:\Python26\python.exe: DLL load failed: The specified
> module could not be found.
> I'm not sure why this is since I put the directory containing jcc.dll into
> my PATH. I am not sure if it will help, but the following is my PATH:
> C:\Python26;C:\Python26\Lib\site-packages;C:\Python26\Lib\site-packages\PyQt4;"C:\Program
> Files (x86)\MiKTeX 2.9\miktex/bin/";"C:\Program
> Files\TortoiseSVN\bin";"C:\Program Files (x86)\CMake 2.8\bin";"C:\Program
> Files (x86)\Java\jdk1.7.0_04\jre\bin\client"

I don't think jcc.dll is likely to be in any of the directories of the PATH you 
show. What is the full path of the directory containing jcc.dll on your system ?

Andi..

> 
> Any help would be very much appreciated.
> 
> Thank you in advance,
> 
> Mark.