Re: [VOTE] Release PyLucene 6.2.0 (rc2)

[Jeff Breidenbach]

+1

Re: [VOTE] Release PyLucene 6.2.0 (rc2)

[Marc Jeurissen]

+1


On 9/09/2016 12:06, Andi Vajda wrote:


After an almost two year hiatus, a new PyLucene version is ready for 
release. The PyLucene 6.2.0 (rc2) release tracking the recent release 
of Apache Lucene 6.2.0 is ready.


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

PyLucene 6.2.0 is built with JCC 2.22 included in these release 
artifacts.


Please vote to release these artifacts as PyLucene 6.2.0.
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



--
Signature Marc Jeurissen | UAntwerpen
Met vriendelijke groeten,

Marc Jeurissen


Bibliotheek UAntwerpen
Stadscampus - S.A.085
Prinsstraat 9 - 2000 Antwerpen
marc.jeuris...@uantwerpen.be 
T +32 3 265 49 71

[VOTE] Release PyLucene 6.2.0 (rc2)

[Andi Vajda]

After an almost two year hiatus, a new PyLucene version is ready for 
release. The PyLucene 6.2.0 (rc2) release tracking the recent release of 
Apache Lucene 6.2.0 is ready.


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

PyLucene 6.2.0 is built with JCC 2.22 included in these release artifacts.

Please vote to release these artifacts as PyLucene 6.2.0.
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: testing PyLucene 6.2

[Andi Vajda]

On Fri, 9 Sep 2016, Andi Vajda wrote:



On Fri, 9 Sep 2016, Dirk Rothe wrote:


Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you 
think?
Not sure what to think. While your change looks fine, if Lucene decided 
to make this 'hard', it may be a sign that you're doing something wrong 
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're 
probably not the first one to transition from 3.x to something more 
recent.

Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for 
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an implementation 
for initReader() in all the tests that make a subclass of PythonAnalyzer 
(search for createComponents() implementations) otherwise, when 
initReader() gets called from Java, you'll get a stack overflow (it'd be 
good, as an aside, if I could make a better error out of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some 
imports there, use patch).


Shouldn't the need for implementation be optional? I don't understand.


Once you define a native method on a class, a native method implementation 
must be provided. JCC does that but that native implementation just invokes 
the python implementation on the python subclass instance. If that python 
subclass has no method implementation, the inherited method is invoked again, 
which in turn calls the native method again, and so on until the stack 
overflows.


This could maybe be improved at the JCC level but until it is, a Python
implementation must be provided. The default initReader() method just returns 
'reader' and so should the python default implementation.


I just did this so that I could produce a new RC and restart the voting 
process. I added initReader() and all needed implementations in tests and 
samples.


Thanks !

Andi..



Andi..



--dirk

Re: FacetExample.py's indexes are too old

[Andi Vajda]

On Fri, 9 Sep 2016, Andi Vajda wrote:


 Hi Thomas,

As you may have noticed, PyLucene is being refreshed to Lucene 6.2.0.
The FacetExample.py sample you submitted to PyLucene is using an index from
Lucene version 2, FacetExample.Index.

Sadly, Lucene 6 no longer supports that version, it must be at least version
4. Could you please refresh FacetExample.Index ? (and FacetExample.Taxonomy
looks like needing that too).


False alert, I had old indexes lying around and FacetExample.py is capable 
of regenerating the index. It runs now on PyLucene 6.2.0.


Andi..



Thanks !

Andi..

FacetExample.py's indexes are too old

[Andi Vajda]

  Hi Thomas,

As you may have noticed, PyLucene is being refreshed to Lucene 6.2.0.
The FacetExample.py sample you submitted to PyLucene is using an index from
Lucene version 2, FacetExample.Index.

Sadly, Lucene 6 no longer supports that version, it must be at least version
4. Could you please refresh FacetExample.Index ? (and FacetExample.Taxonomy
looks like needing that too).

Thanks !

Andi..

Re: testing PyLucene 6.2

[Andi Vajda]

On Fri, 9 Sep 2016, Dirk Rothe wrote:


Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you 
think?
Not sure what to think. While your change looks fine, if Lucene decided 
to make this 'hard', it may be a sign that you're doing something wrong 
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're 
probably not the first one to transition from 3.x to something more 
recent.

Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for 
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an implementation 
for initReader() in all the tests that make a subclass of PythonAnalyzer 
(search for createComponents() implementations) otherwise, when 
initReader() gets called from Java, you'll get a stack overflow (it'd be 
good, as an aside, if I could make a better error out of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some imports 
there, use patch).


I see no patch attached probably because the apache mail server strips 
attachments sent to mailing lists. Either you include the patch inline or 
you send it to me as an attachment directly.


Thanks !

Andi..



Shouldn't the need for implementation be optional? I don't understand.

--dirk

Re: testing PyLucene 6.2

[Andi Vajda]

On Fri, 9 Sep 2016, Dirk Rothe wrote:


Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you 
think?
Not sure what to think. While your change looks fine, if Lucene decided 
to make this 'hard', it may be a sign that you're doing something wrong 
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're 
probably not the first one to transition from 3.x to something more 
recent.

Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for 
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an implementation 
for initReader() in all the tests that make a subclass of PythonAnalyzer 
(search for createComponents() implementations) otherwise, when 
initReader() gets called from Java, you'll get a stack overflow (it'd be 
good, as an aside, if I could make a better error out of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some imports 
there, use patch).


Ooh, I forgot about samples. I need to check them and produce a new release 
candidate. Thanks for pointing this out.


Andi..



Shouldn't the need for implementation be optional? I don't understand.

--dirk

Re: testing PyLucene 6.2

[Dirk Rothe]

Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda :


On Thu, 8 Sep 2016, Dirk Rothe wrote:
 I've made initReader() python-overridable (see patch). What do you  
think?
 Not sure what to think. While your change looks fine, if Lucene  
decided to make this 'hard', it may be a sign that you're doing  
something wrong or going the wrong way about it.
 I suggest you ask on the java-u...@lucene.apache.org list as you're  
probably not the first one to transition from 3.x to something more  
recent.

 Please let pylucene-dev@ know what you find out...


OK.

Making Analyzer.initReader() python-overridable is also important for  
use-cases like this: http://stackoverflow.com/a/10290635

So the patch should be fine independently of my usage/hack.


Actually, your patch is not good enough. You need to add an  
implementation for initReader() in all the tests that make a subclass of  
PythonAnalyzer (search for createComponents() implementations)  
otherwise, when initReader() gets called from Java, you'll get a stack  
overflow (it'd be good, as an aside, if I could make a better error out  
of that...).


OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some  
imports there, use patch).


Shouldn't the need for implementation be optional? I don't understand.

--dirk