Re: [VOTE] Release PyLucene 8.8.1

[Bart Moelans]

+1



Op di 2 mrt. 2021 om 03:36 schreef Andi Vajda :

>
> The PyLucene 8.8.1 (rc1) release tracking the recent release of
> Apache Lucene 8.8.1 is ready.
>
> A release candidate is available from:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2F8.8.1-rc1%2Fdata=04%7C01%7CBart.Moelans%40uantwerpen.be%7C7d20509b8a6e448a8fa708d8dd23e610%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502493998256967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0XG%2FQ1fg4hzh%2FQJN%2Fd2QqyRknUEf16VLprMdDWqTZEU%3Dreserved=0
>
> PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.
>
> JCC 3.9 supports Python 3.3 up to Python 3.9 (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.8.1.
> Anyone interested in this release can and should vote !
>
> Thanks !
>
> Andi..
>
> ps: the KEYS file for PyLucene release signing is at:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Frelease%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7CBart.Moelans%40uantwerpen.be%7C7d20509b8a6e448a8fa708d8dd23e610%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502493998266970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vcPETqAC4GCK5Xc0DxuWRQybCKktzVOAYU60hv0zk9Y%3Dreserved=0
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7CBart.Moelans%40uantwerpen.be%7C7d20509b8a6e448a8fa708d8dd23e610%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502493998266970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2avUfzAV4oywhIhG0AdlnvNOXiXr4b3COtBciHUHtIk%3Dreserved=0
>
> pps: here is my +1
>

Re: [VOTE] Release PyLucene 8.8.1

[Nelia Vb]

+1

> On 2 Mar 2021, at 08:21, Marc Jeurissen  wrote:
> 
> +1
>  
> Met vriendelijke groeten,
> Marc Jeurissen
> 
> 
> 
> Bibliotheek UAntwerpen
> Stadscampus – Ve35.303
> Venusstraat 35 – 2000 Antwerpen
> marc.jeuris...@uantwerpen.be 
> T +32 3 265 49 71
>  
>  
> From: Andi Vajda 
> Sent: dinsdag 2 maart 2021 3:37
> To: pylucene-dev@lucene.apache.org 
> Cc: gene...@lucene.apache.org 
> Subject: [VOTE] Release PyLucene 8.8.1
>  
>  
> The PyLucene 8.8.1 (rc1) release tracking the recent release of
> Apache Lucene 8.8.1 is ready.
>  
> A release candidate is available from:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2F8.8.1-rc1%2Fdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=e0w9pmUGU8PhWPkTV0gm%2B2eGKlLvIaV8wM6GlDyAy9U%3Dreserved=0
>  
> 
>  
> PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.
>  
> JCC 3.9 supports Python 3.3 up to Python 3.9 (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.8.1.
> Anyone interested in this release can and should vote !
>  
> Thanks !
>  
> Andi..
>  
> ps: the KEYS file for PyLucene release signing is at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Frelease%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TlLv6eAZxXSlgR8wKB4ipsyVfhYj05tDPP9Q7C%2Fhi1Q%3Dreserved=0
>  
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=A%2B9KMqQMl51zcC9xAcQv4LZ2uLfEgaCBHoep60TlHOk%3Dreserved=0
>  
> 
>  
> pps: here is my +1
>  

RE: [VOTE] Release PyLucene 8.8.1

[Marc Jeurissen]

+1

Met vriendelijke groeten,
Marc Jeurissen

Bibliotheek UAntwerpen
Stadscampus – Ve35.303
Venusstraat 35 – 2000 Antwerpen
marc.jeuris...@uantwerpen.be
T +32 3 265 49 71


From: Andi Vajda
Sent: dinsdag 2 maart 2021 3:37
To: pylucene-dev@lucene.apache.org
Cc: gene...@lucene.apache.org
Subject: [VOTE] Release PyLucene 8.8.1


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

A release candidate is available from:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2F8.8.1-rc1%2Fdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=e0w9pmUGU8PhWPkTV0gm%2B2eGKlLvIaV8wM6GlDyAy9U%3Dreserved=0

PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.

JCC 3.9 supports Python 3.3 up to Python 3.9 (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.8.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Frelease%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TlLv6eAZxXSlgR8wKB4ipsyVfhYj05tDPP9Q7C%2Fhi1Q%3Dreserved=0
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Flucene%2Fpylucene%2FKEYSdata=04%7C01%7Cmarc.jeurissen%40uantwerpen.be%7C20ba06c7ec0046c7863f08d8dd23e66b%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637502494126459957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=A%2B9KMqQMl51zcC9xAcQv4LZ2uLfEgaCBHoep60TlHOk%3Dreserved=0

pps: here is my +1

Re: [VOTE] Release PyLucene 8.8.1

[Jeff Breidenbach]

+1

On Mon, Mar 1, 2021, 6:35 PM Andi Vajda  wrote:

>
> The PyLucene 8.8.1 (rc1) release tracking the recent release of
> Apache Lucene 8.8.1 is ready.
>
> A release candidate is available from:
> https://dist.apache.org/repos/dist/dev/lucene/pylucene/8.8.1-rc1/
>
> PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.
>
> JCC 3.9 supports Python 3.3 up to Python 3.9 (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.8.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
>

[VOTE] Release PyLucene 8.8.1

[Andi Vajda]

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

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

PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.

JCC 3.9 supports Python 3.3 up to Python 3.9 (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.8.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: jcc - Output unbuilt package

[Andi Vajda]

 Hi Phil,

On Mon, 1 Mar 2021, Phil wrote:


Great - I've attached a one-line change that outputs the missing info to
stdout.  I haven't added a command line switch at this stage as there is
no functional change to the output - just an extra line of logging.


Yes, a flag is not necessary for this change.


Note this is necessary because although the program already outputs the
setup args which are also required, the Extension class doesn't render
its args as text on printing the setup args, so I also need to output
the inputs to the Extension so that I can capture all the inputs to setup().

This would be hugely useful for me if we could even this simple change.


I incorporated your change and committed into rev 1887063.


I will look at automating the full generation of a source package, and
adding an optional switch to control this - but this is a larger undertaking,
so I'll have to add it to the to-do list.  I'll let you know when I have
had a chance to implement this.


Great, thank you !

Andi..

Re: Review request - New Solr website

[Alexandre Rafalovitch]

> I'm not aware that Confluence is going away, is it?
Sorry, I meant our continual attempts to reduce its importance in
favour of other options and reduction of (out of date) pages it has.
But, if there are no better options...

Regards,
   Alex.

On Mon, 1 Mar 2021 at 17:30, Jan Høydahl  wrote:
>
> Thanks for feedback Alexandre.
>
> These sound like good proposals, but probably well suited as followup cleanup 
> after the site move.
> Or you can make a PR against the "main/solr" branch if you want to merge it 
> in from day one.
>

>
> Jam
>
> > 1. mar. 2021 kl. 23:16 skrev Alexandre Rafalovitch :
> >
> > Looks good.
> >
> > I wonder if there is a way to bring the Reference Guide more
> > prominently to the home page. Maybe even in the top "Learn More"
> > section or even a section of its own right after.
> >
> > I also wonder if the book section is so out-of-date (in terms of Solr)
> > that it should retreat to the Documentation page.
> >
> > We are also linking to CWiki still in the Social Proof section (Visit
> > Solr's Public Servers listing page to learn more), I wonder if we
> > should eliminate that link, at least from the home page as part of
> > CWiki purge. On the other hand, that seems like a useful page and not
> > completely out of date.
> >
> > Regards,
> >   Alex.
> >
> > On Mon, 1 Mar 2021 at 03:56, Jan Høydahl  wrote:
> >>
> >> Hi,
> >>
> >> I have been working on https://issues.apache.org/jira/browse/SOLR-14499 to 
> >> prepare the separate website for Solr.
> >> I believe the work is practically done, and would like a broader review 
> >> before I actually publish the changes.
> >>
> >> The staging site which will eventually be solr.apache.org is at 
> >> https://lucene-solrtlp.staged.apache.org/
> >> The staging site which shows the lucene site without Solr is at 
> >> https://lucene-new.staged.apache.org/
> >>
> >> Any feedback is welcome, here or in the JIRA issue. I intend to publish 
> >> the new sites in a couple of days.
> >>
> >> Jan
> >> -
> >> 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
>

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

Re: Review request - New Solr website

[Jan Høydahl]

Thanks for feedback Alexandre. 

These sound like good proposals, but probably well suited as followup cleanup 
after the site move.
Or you can make a PR against the "main/solr" branch if you want to merge it in 
from day one.

I'm not aware that Confluence is going away, is it?

Jam

> 1. mar. 2021 kl. 23:16 skrev Alexandre Rafalovitch :
> 
> Looks good.
> 
> I wonder if there is a way to bring the Reference Guide more
> prominently to the home page. Maybe even in the top "Learn More"
> section or even a section of its own right after.
> 
> I also wonder if the book section is so out-of-date (in terms of Solr)
> that it should retreat to the Documentation page.
> 
> We are also linking to CWiki still in the Social Proof section (Visit
> Solr's Public Servers listing page to learn more), I wonder if we
> should eliminate that link, at least from the home page as part of
> CWiki purge. On the other hand, that seems like a useful page and not
> completely out of date.
> 
> Regards,
>   Alex.
> 
> On Mon, 1 Mar 2021 at 03:56, Jan Høydahl  wrote:
>> 
>> Hi,
>> 
>> I have been working on https://issues.apache.org/jira/browse/SOLR-14499 to 
>> prepare the separate website for Solr.
>> I believe the work is practically done, and would like a broader review 
>> before I actually publish the changes.
>> 
>> The staging site which will eventually be solr.apache.org is at 
>> https://lucene-solrtlp.staged.apache.org/
>> The staging site which shows the lucene site without Solr is at 
>> https://lucene-new.staged.apache.org/
>> 
>> Any feedback is welcome, here or in the JIRA issue. I intend to publish the 
>> new sites in a couple of days.
>> 
>> Jan
>> -
>> 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: Review request - New Solr website

[Jan Høydahl]

> David:
> * The news announcement that Solr has "graduated" to a separate TLP seems off 
> to me in use of this word.  To me, that word suggests it was too small or 
> immature to warrant it previously.

I think you are right. I'll find a better wording. I've replaced graduated --> 
moved for now. 
https://github.com/apache/lucene-site/commit/cf893ddca1c04e336966d789d7f0cb72c1531294
 Feel free to suggest better wording.

> * IMO with Solr gone, the Lucene-core content should not be just some 
> sub-page but should move into the front page.  The front page would then have 
> the tabs that Lucene-core has.  PyLucene could be another tab.

Perhaps. But let's make that another JIRA that Lucene can do later. For the 
Solr move I like to just surgically remove Solr and leave it with that.

> * I like the note that shows up immediately to alert the user of the switch!  
> I see that it doesn't re-appear on every return (e.g. due to a cookie)?  I 
> imagine we will stop doing this in a year or maybe sooner.

Yep, it's a cookie. Good idea to only show the popup the first year. I have now 
put that in - 
https://github.com/apache/lucene-site/commit/a694482032bc300440905936c8fccf9a37b39aea
 

> Mike:
>  I noticed that the Ref Guide is missing from the new site. Is this something 
> that we will have to figure out how to restore after the site goes live? 


It is a slightly bigger task, so I extracted it in 
https://issues.apache.org/jira/browse/SOLR-15177.

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

Re: Review request - New Solr website

[Alexandre Rafalovitch]

Looks good.

I wonder if there is a way to bring the Reference Guide more
prominently to the home page. Maybe even in the top "Learn More"
section or even a section of its own right after.

I also wonder if the book section is so out-of-date (in terms of Solr)
that it should retreat to the Documentation page.

We are also linking to CWiki still in the Social Proof section (Visit
Solr's Public Servers listing page to learn more), I wonder if we
should eliminate that link, at least from the home page as part of
CWiki purge. On the other hand, that seems like a useful page and not
completely out of date.

Regards,
   Alex.

On Mon, 1 Mar 2021 at 03:56, Jan Høydahl  wrote:
>
> Hi,
>
> I have been working on https://issues.apache.org/jira/browse/SOLR-14499 to 
> prepare the separate website for Solr.
> I believe the work is practically done, and would like a broader review 
> before I actually publish the changes.
>
> The staging site which will eventually be solr.apache.org is at 
> https://lucene-solrtlp.staged.apache.org/
> The staging site which shows the lucene site without Solr is at 
> https://lucene-new.staged.apache.org/
>
> Any feedback is welcome, here or in the JIRA issue. I intend to publish the 
> new sites in a couple of days.
>
> Jan
> -
> 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: [DISCUSS] Sunset the general@l.a.o mailing list?

[David Smiley]

+1 to remove.

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


On Sun, Feb 28, 2021 at 4:03 PM 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?
>
> Jan Høydahl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: jcc - Output unbuilt package

[Phil]

Hi Andi,

Great - I've attached a one-line change that outputs the missing info to
stdout.  I haven't added a command line switch at this stage as there is
no functional change to the output - just an extra line of logging.

Note this is necessary because although the program already outputs the
setup args which are also required, the Extension class doesn't render
its args as text on printing the setup args, so I also need to output
the inputs to the Extension so that I can capture all the inputs to setup().

This would be hugely useful for me if we could even this simple change.

I will look at automating the full generation of a source package, and
adding an optional switch to control this - but this is a larger undertaking,
so I'll have to add it to the to-do list.  I'll let you know when I have
had a chance to implement this.

Cheers,
Phil.




Index: python.py
===
--- python.py	(revision 1887057)
+++ python.py	(working copy)
@@ -1870,6 +1870,7 @@
 i += 1
 config_vars['CFLAGS'] = ' '.join(cflags)
 
+print("extension args = %s" % args)
 extensions = [Extension('.'.join([moduleName, extname]), **args)]
 script_args.extend(extra_setup_args)
 

Andi Vajda writes:

>  Hi Phil,
>
> Excellent !
>
> Yes, I'd accept a patch that makes your feature available via a new
> command line flag to JCC (don't forget to document it in __main__.py).
>
> It's ok to only send in a patch for the python3 version (under
> jcc3). The python2 version (under jcc2) is maintenance only, don't
> bother.
>
> Thanks !
>
> Andi..
>
> On Sun, 28 Feb 2021, Phil wrote:
>
>>
>> Thanks very much for the reply Andi.
>>
>> I've done a bit more digging and the short answer is you can't do what I
>> wanted with the current JCC. but, it turns out it was fairly
>> straightforward to tweak JCC to provide me with the all details I needed.
>>
>> I successfully made this work today with Guix with the project
>> that previously used JCC to build a wheel.
>>
>> Do you accept patches onto the subversion source trunk? - I could
>> prepare a very simple, optional extension to dump out the data I needed.
>> If I have time I also could write something which would fully automate
>> the entire process in the future.
>>
>> Some more details below.
>>
>> Andi Vajda writes:
>>
>>> I did not write the bdist nor the wheel support, they were contributed
>>> and I don't now that --wheel makes a binary wheel, specifically.
>>> Note that you have binaries in whatever you distribute, if you
>>> consider that the JAR files or the .class files are binaries. They are
>>> required (.class files are) for JCC to operate as it uses reflection
>>> to do its job.
>>
>> Yes the --wheel switch implies that the C++ build will be performed.
>>
>> I agree the JAR/.class files will always be binaries, but it is
>> possible to distribute a package which contains only the JARs as
>> binaries, along with python API and unbuilt C/C++, with a setup.py,
>> describing the build process.
>>
>> This delays the calling of setuptools, and thus the building the C++ to
>> package install time rather than wheel creation time - and allows us to
>> create a regular setup.py file.
>>
>>>
>>> If you don't invoke JCC with --wheel, --bdist, --build or --compile,
>>> you get just source files (not countng .jar).
>>
>> Almost - you get the C++, but no setup.py or python wrapper generated.
>> At least this was the case for me.
>>
>> However, if you build the wheel the build directories do contain
>> everything you need apart from the setup.py - you just need to lift the
>> right files out and put them into the right directory structure.
>>
>> To create a setup.py you need both the setup and extension arguments
>> generated by JCC.  Normally these are fed straight into setuptools by
>> JCC, but we can leak them out instead.
>>
>> JCC already ouputs the setup arguments to stdout, so the only change I
>> had to do to the source was to also output the extension args
>> dictionary to stdout too, towards the end of:
>> https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/python.py
>>
>> extensions = [Extension('.'.join([moduleName, extname]), **args)]
>>
>> print("extensions args = %s" % args) # I added this
>>
>>
>> Then at the bottom the setuptools args are already output to stdout:
>>
>> print("setup args = %s" % args)
>>
>> setup(**args)
>>
>>
>> My setup.py then contains a call to setuptools.setup() providing same
>> **args structure generated by the script (I'd link it here to demonstrate 
>> this,
>> but the repo is behind the a firewall, alas).
>>
>> This plus a tiny bit of tweaking and boilerplate gives me exactly what I 
>> want.
>>
>>
>>> Maybe what you actually want is to implement 'sdist' support for JCC ?
>>> (again, not familiar with wheels, so I may not be making sense here).
>>
>> I thought this too - but I couldn't get it to work.
>>
>> I tried passing '--extra-setup-arg sdist' 

Re: Configurable Postings Block Size?

[Greg Miller]

Oh, got it. This is great, thanks!

Cheers,
-Greg

On Mon, Mar 1, 2021 at 11:28 AM Robert Muir  wrote:

> Yeah, have a look at gen_ForUtil.py
>
> On Mon, Mar 1, 2021 at 1:05 PM Greg Miller  wrote:
>
>> Thanks for the feedback Robert; makes sense to me. I'll tinker with a
>> forked codec and see if the experimentation produces anything interesting.
>>
>> When you mention "autogenerated decompression code", do you mean that
>> some of this code is actually being generated?
>>
>> Cheers,
>> -Greg
>>
>> On Sun, Feb 28, 2021 at 5:05 AM Robert Muir  wrote:
>>
>>> If you want to test a different block size (say 64 or 256), I really
>>> recommend to just fork a different codec for the experiment.
>>>
>>> There will likely be higher level changes you need to make, not just
>>> changing a number. For example if you just increased this number to 256
>>> without doing anything else, I wouldn't be surprised if you see worse
>>> performance. More of the postings would be vint-encoded than before with
>>> 128, which might have some consequences. skipdata layout might be
>>> inappropriate, these things are optimized for blocks of 128.
>>>
>>> Just in general, I recommend making a codec for the benchmarking
>>> experiments, tools like luceneutil support comparing codecs against each
>>> other anyway so you can easily compare fairly against the existing codec.
>>> Also, it should be much easier/faster to just make a new codec and adapt it
>>> to test what you want!
>>>
>>> I think it is an antipattern to make stuff within the codec "flexible",
>>> it is autogenerated decompression code :) I am concerned such "flexibility"
>>> would create barriers in the future to optimizations. For example we should
>>> be able to experiment with converting this compression code over to
>>> explicit vector API in java.
>>>
>>> On Sat, Feb 27, 2021 at 4:29 PM Greg Miller  wrote:
>>>
 Hi folks!

 I've been a bit curious to test out different block size configurations
 in the Lucene postings list format, but thought I'd reach out to the
 community here first to see what work may have gone into this previously.
 I'm essentially interested in benchmarking different block size
 configurations on the real-world application of Lucene I'm working on.

 If my understanding of the code is correct, I know we're currently
 encoding compressed runs of 128 docs per block, relying on ForUtil for
 encoding/decoding purposes. It looks like we define this in
 ForUtil#BLOCK_SIZE (and reference it in a few external classes), but also
 know that it's not as simple as just changing that one definition. It
 appears much of the logic in ForUtil relies on the assumption of 128
 docs-per-block.

 I'm toying with the idea of making ForUtil a bit more flexible to allow
 for different block sizes to be tested in order to run the benchmarking I'd
 like to run, but the class looks heavily optimized to generate SIMD
 instructions (I think?), so that might be folly. Before I start hacking on
 a local branch to see what I can learn, is there any prior work that might
 be useful to be aware of? Anyone gone down this path and have some
 learnings to share? Any thoughts would be much appreciated!

 Cheers,
 -Greg

>>>

Re: Configurable Postings Block Size?

[Robert Muir]

Yeah, have a look at gen_ForUtil.py

On Mon, Mar 1, 2021 at 1:05 PM Greg Miller  wrote:

> Thanks for the feedback Robert; makes sense to me. I'll tinker with a
> forked codec and see if the experimentation produces anything interesting.
>
> When you mention "autogenerated decompression code", do you mean that
> some of this code is actually being generated?
>
> Cheers,
> -Greg
>
> On Sun, Feb 28, 2021 at 5:05 AM Robert Muir  wrote:
>
>> If you want to test a different block size (say 64 or 256), I really
>> recommend to just fork a different codec for the experiment.
>>
>> There will likely be higher level changes you need to make, not just
>> changing a number. For example if you just increased this number to 256
>> without doing anything else, I wouldn't be surprised if you see worse
>> performance. More of the postings would be vint-encoded than before with
>> 128, which might have some consequences. skipdata layout might be
>> inappropriate, these things are optimized for blocks of 128.
>>
>> Just in general, I recommend making a codec for the benchmarking
>> experiments, tools like luceneutil support comparing codecs against each
>> other anyway so you can easily compare fairly against the existing codec.
>> Also, it should be much easier/faster to just make a new codec and adapt it
>> to test what you want!
>>
>> I think it is an antipattern to make stuff within the codec "flexible",
>> it is autogenerated decompression code :) I am concerned such "flexibility"
>> would create barriers in the future to optimizations. For example we should
>> be able to experiment with converting this compression code over to
>> explicit vector API in java.
>>
>> On Sat, Feb 27, 2021 at 4:29 PM Greg Miller  wrote:
>>
>>> Hi folks!
>>>
>>> I've been a bit curious to test out different block size configurations
>>> in the Lucene postings list format, but thought I'd reach out to the
>>> community here first to see what work may have gone into this previously.
>>> I'm essentially interested in benchmarking different block size
>>> configurations on the real-world application of Lucene I'm working on.
>>>
>>> If my understanding of the code is correct, I know we're currently
>>> encoding compressed runs of 128 docs per block, relying on ForUtil for
>>> encoding/decoding purposes. It looks like we define this in
>>> ForUtil#BLOCK_SIZE (and reference it in a few external classes), but also
>>> know that it's not as simple as just changing that one definition. It
>>> appears much of the logic in ForUtil relies on the assumption of 128
>>> docs-per-block.
>>>
>>> I'm toying with the idea of making ForUtil a bit more flexible to allow
>>> for different block sizes to be tested in order to run the benchmarking I'd
>>> like to run, but the class looks heavily optimized to generate SIMD
>>> instructions (I think?), so that might be folly. Before I start hacking on
>>> a local branch to see what I can learn, is there any prior work that might
>>> be useful to be aware of? Anyone gone down this path and have some
>>> learnings to share? Any thoughts would be much appreciated!
>>>
>>> Cheers,
>>> -Greg
>>>
>>

Re: Review request - New Solr website

[Mike Drob]

I noticed that the Ref Guide is missing from the new site. Is this
something that we will have to figure out how to restore after the site
goes live?

On Mon, Mar 1, 2021 at 2:56 AM Jan Høydahl  wrote:

> Hi,
>
> I have been working on https://issues.apache.org/jira/browse/SOLR-14499
> to prepare the separate website for Solr.
> I believe the work is practically done, and would like a broader review
> before I actually publish the changes.
>
> The staging site which will eventually be solr.apache.org is at
> https://lucene-solrtlp.staged.apache.org/
> The staging site which shows the lucene site without Solr is at
> https://lucene-new.staged.apache.org/
>
> Any feedback is welcome, here or in the JIRA issue. I intend to publish
> the new sites in a couple of days.
>
> Jan
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Review request - New Solr website

[David Smiley]

Thanks for doing this Jan!

Some quick feedback on the Lucene site:
* The news announcement that Solr has "graduated" to a separate TLP seems
off to me in use of this word.  To me, that word suggests it was too small
or immature to warrant it previously.
* IMO with Solr gone, the Lucene-core content should not be just some
sub-page but should move into the front page.  The front page would then
have the tabs that Lucene-core has.  PyLucene could be another tab.

Solr side:
* I like the note that shows up immediately to alert the user of the
switch!  I see that it doesn't re-appear on every return (e.g. due to a
cookie)?  I imagine we will stop doing this in a year or maybe sooner.

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


On Mon, Mar 1, 2021 at 1:03 PM Michael Sokolov  wrote:

> I clicked around a bit; didn't do a thorough copy edit or anything,
> but it seems as if the links are working, content looks accurate. The
> notices about the new TLP seem good to me, too. Thanks for forging
> ahead, Jan
>
> -Mike
>
> On Mon, Mar 1, 2021 at 3:56 AM Jan Høydahl  wrote:
> >
> > Hi,
> >
> > I have been working on https://issues.apache.org/jira/browse/SOLR-14499
> to prepare the separate website for Solr.
> > I believe the work is practically done, and would like a broader review
> before I actually publish the changes.
> >
> > The staging site which will eventually be solr.apache.org is at
> https://lucene-solrtlp.staged.apache.org/
> > The staging site which shows the lucene site without Solr is at
> https://lucene-new.staged.apache.org/
> >
> > Any feedback is welcome, here or in the JIRA issue. I intend to publish
> the new sites in a couple of days.
> >
> > Jan
> > -
> > 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: [DISCUSS] Sunset the general@l.a.o mailing list?

[Michael Sokolov]

Yes, let's consolidate

On Mon, Mar 1, 2021 at 6:45 AM Tomoko Uchida
 wrote:
>
> > 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 ?
>
> In my view it's totally okay to send PyLucene release votes to lucene-dev.
>
> Best,
> Tomoko
>
>
> 2021年3月1日(月) 18:12 Bruno Roustant :
>>
>> +1
>>
>> Le dim. 28 févr. 2021 à 22:23, Andi Vajda  a écrit :
>>>
>>>
>>> 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

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

Re: Configurable Postings Block Size?

[Greg Miller]

Thanks for the feedback Robert; makes sense to me. I'll tinker with a
forked codec and see if the experimentation produces anything interesting.

When you mention "autogenerated decompression code", do you mean that some
of this code is actually being generated?

Cheers,
-Greg

On Sun, Feb 28, 2021 at 5:05 AM Robert Muir  wrote:

> If you want to test a different block size (say 64 or 256), I really
> recommend to just fork a different codec for the experiment.
>
> There will likely be higher level changes you need to make, not just
> changing a number. For example if you just increased this number to 256
> without doing anything else, I wouldn't be surprised if you see worse
> performance. More of the postings would be vint-encoded than before with
> 128, which might have some consequences. skipdata layout might be
> inappropriate, these things are optimized for blocks of 128.
>
> Just in general, I recommend making a codec for the benchmarking
> experiments, tools like luceneutil support comparing codecs against each
> other anyway so you can easily compare fairly against the existing codec.
> Also, it should be much easier/faster to just make a new codec and adapt it
> to test what you want!
>
> I think it is an antipattern to make stuff within the codec "flexible", it
> is autogenerated decompression code :) I am concerned such "flexibility"
> would create barriers in the future to optimizations. For example we should
> be able to experiment with converting this compression code over to
> explicit vector API in java.
>
> On Sat, Feb 27, 2021 at 4:29 PM Greg Miller  wrote:
>
>> Hi folks!
>>
>> I've been a bit curious to test out different block size configurations
>> in the Lucene postings list format, but thought I'd reach out to the
>> community here first to see what work may have gone into this previously.
>> I'm essentially interested in benchmarking different block size
>> configurations on the real-world application of Lucene I'm working on.
>>
>> If my understanding of the code is correct, I know we're currently
>> encoding compressed runs of 128 docs per block, relying on ForUtil for
>> encoding/decoding purposes. It looks like we define this in
>> ForUtil#BLOCK_SIZE (and reference it in a few external classes), but also
>> know that it's not as simple as just changing that one definition. It
>> appears much of the logic in ForUtil relies on the assumption of 128
>> docs-per-block.
>>
>> I'm toying with the idea of making ForUtil a bit more flexible to allow
>> for different block sizes to be tested in order to run the benchmarking I'd
>> like to run, but the class looks heavily optimized to generate SIMD
>> instructions (I think?), so that might be folly. Before I start hacking on
>> a local branch to see what I can learn, is there any prior work that might
>> be useful to be aware of? Anyone gone down this path and have some
>> learnings to share? Any thoughts would be much appreciated!
>>
>> Cheers,
>> -Greg
>>
>

Re: Review request - New Solr website

[Michael Sokolov]

I clicked around a bit; didn't do a thorough copy edit or anything,
but it seems as if the links are working, content looks accurate. The
notices about the new TLP seem good to me, too. Thanks for forging
ahead, Jan

-Mike

On Mon, Mar 1, 2021 at 3:56 AM Jan Høydahl  wrote:
>
> Hi,
>
> I have been working on https://issues.apache.org/jira/browse/SOLR-14499 to 
> prepare the separate website for Solr.
> I believe the work is practically done, and would like a broader review 
> before I actually publish the changes.
>
> The staging site which will eventually be solr.apache.org is at 
> https://lucene-solrtlp.staged.apache.org/
> The staging site which shows the lucene site without Solr is at 
> https://lucene-new.staged.apache.org/
>
> Any feedback is welcome, here or in the JIRA issue. I intend to publish the 
> new sites in a couple of days.
>
> Jan
> -
> 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: jcc - Output unbuilt package

[Andi Vajda]

 Hi Phil,

Excellent !

Yes, I'd accept a patch that makes your feature available via a new command 
line flag to JCC (don't forget to document it in __main__.py).


It's ok to only send in a patch for the python3 version (under jcc3). The 
python2 version (under jcc2) is maintenance only, don't bother.


Thanks !

Andi..

On Sun, 28 Feb 2021, Phil wrote:



Thanks very much for the reply Andi.

I've done a bit more digging and the short answer is you can't do what I
wanted with the current JCC. but, it turns out it was fairly
straightforward to tweak JCC to provide me with the all details I needed.

I successfully made this work today with Guix with the project
that previously used JCC to build a wheel.

Do you accept patches onto the subversion source trunk? - I could
prepare a very simple, optional extension to dump out the data I needed.
If I have time I also could write something which would fully automate
the entire process in the future.

Some more details below.

Andi Vajda writes:


I did not write the bdist nor the wheel support, they were contributed
and I don't now that --wheel makes a binary wheel, specifically.
Note that you have binaries in whatever you distribute, if you
consider that the JAR files or the .class files are binaries. They are
required (.class files are) for JCC to operate as it uses reflection
to do its job.


Yes the --wheel switch implies that the C++ build will be performed.

I agree the JAR/.class files will always be binaries, but it is
possible to distribute a package which contains only the JARs as
binaries, along with python API and unbuilt C/C++, with a setup.py,
describing the build process.

This delays the calling of setuptools, and thus the building the C++ to
package install time rather than wheel creation time - and allows us to
create a regular setup.py file.



If you don't invoke JCC with --wheel, --bdist, --build or --compile,
you get just source files (not countng .jar).


Almost - you get the C++, but no setup.py or python wrapper generated.
At least this was the case for me.

However, if you build the wheel the build directories do contain
everything you need apart from the setup.py - you just need to lift the
right files out and put them into the right directory structure.

To create a setup.py you need both the setup and extension arguments
generated by JCC.  Normally these are fed straight into setuptools by
JCC, but we can leak them out instead.

JCC already ouputs the setup arguments to stdout, so the only change I
had to do to the source was to also output the extension args
dictionary to stdout too, towards the end of:
https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/python.py

extensions = [Extension('.'.join([moduleName, extname]), **args)]

print("extensions args = %s" % args) # I added this


Then at the bottom the setuptools args are already output to stdout:

print("setup args = %s" % args)

setup(**args)


My setup.py then contains a call to setuptools.setup() providing same
**args structure generated by the script (I'd link it here to demonstrate this,
but the repo is behind the a firewall, alas).

This plus a tiny bit of tweaking and boilerplate gives me exactly what I want.



Maybe what you actually want is to implement 'sdist' support for JCC ?
(again, not familiar with wheels, so I may not be making sense here).


I thought this too - but I couldn't get it to work.

I tried passing '--extra-setup-arg sdist' into JCC, but this got the
same result as not passing --build or --wheel as discussed above.  Only
C++ is generated.


As long as GUIX knows how to drive a C++ compiler and linker, build
python extensions (and knows how to build the libjcc shared library),
you should be fine.


Yep this all works perfectly in Guix once we have a regular python repo
containing the source with the setup.py as described.

The only downside is the whole thing is rather manual now - I'd like to
tweak JCC to make this more streamlined - let me know if a patch
interests you?

Re: Some small questions on streaming expressions

[Joel Bernstein]

Your first example looks like a bug to me. This may be work around for you:

select(echo("Hello"),
  echo as blah,
  lower(echo) as blah1)

Returns:

{ "result-set": { "docs": [ { "blah": "Hello", "blah1": "hello" }, { "EOF":
true, "RESPONSE_TIME": 0 } ] } }

The string manipulation function is working properly but the straight
mapping does not.

Your second question: can we split a stream's output to two streams.
Currently only the let expression does this I believe.

But, to your third question, the let expression does not stream, it's all
in memory. The let expression is designed for vector math over samples or
aggregations (time series).

So, right now I don't think we have a way to split a stream and operate
over it with a different set of streams.

Joel Bernstein
http://joelsolr.blogspot.com/


On Sat, Feb 27, 2021 at 4:42 PM ufuk yılmaz 
wrote:

> Hello all,
>
>
>
> I’m trying to reindex from a collection to a new collection with a
> different schema, using streaming expressions. I can’t use
> REINDEXCOLLECTION directly, because I need to process documents a bit.
>
>
>
> I couldn’t figure out 3 simple, related things for hours so forgive me if
> I just ask.
>
>
>
>1. Is there a way to duplicate the value of a field of an incoming
>tuple into two fields?
>
> I tried the select expression:
>
> select(
>
>   echo("Hello"),
>
>   echo as echy, echo as echee
>
> )
>
>
>
> But when I use the same field twice, only the last “as” takes effect, it
> doesn’t copy the value to two fields:
>
> {
>
>   "result-set": {
>
> "docs": [
>
>   {
>
> "echee": "Hello"
>
>   },
>
>   {
>
> "EOF": true,
>
> "RESPONSE_TIME": 0
>
>   }
>
> ]
>
>   }
>
> }
>
>
>
> I accomplished this by using leftOuterJoin, with same exact stream in left
> and right, joining on itself with different field names. But this has the
> penaly of executing the same stream twice, It’s no problem for small
> streams but in my case there will be a couple hundred million tuples coming
> from the stream.
>
>
>
>
>
>1. Is there a way to “feed” one stream’s output to two different
>streams? Like feeding output of a stream source to two different stream
>decorator without executing the same stream twice?
>2. Does the “let” stream hold its entire content in memory when a
>stream is assigned to a variable, or does it stream continuously too? If
>not, I imagine it can be used for my question 2.
>
>
>
>
>
> I’m glad that Solr has streaming expressions.
>
>
>
> --ufuk yilmaz
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

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

[Tomoko Uchida]

> 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 ?

In my view it's totally okay to send PyLucene release votes to lucene-dev.

Best,
Tomoko


2021年3月1日(月) 18:12 Bruno Roustant :

> +1
>
> Le dim. 28 févr. 2021 à 22:23, Andi Vajda  a écrit :
>
>>
>> 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: [DISCUSS] Sunset the general@l.a.o mailing list?

[Bruno Roustant]

+1

Le dim. 28 févr. 2021 à 22:23, Andi Vajda  a écrit :

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

Review request - New Solr website

[Jan Høydahl]

Hi,

I have been working on https://issues.apache.org/jira/browse/SOLR-14499 to 
prepare the separate website for Solr.
I believe the work is practically done, and would like a broader review before 
I actually publish the changes.

The staging site which will eventually be solr.apache.org is at 
https://lucene-solrtlp.staged.apache.org/
The staging site which shows the lucene site without Solr is at 
https://lucene-new.staged.apache.org/

Any feedback is welcome, here or in the JIRA issue. I intend to publish the new 
sites in a couple of days.

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