Classloaders, SPI, Directory ... OSGi?

Folks, Down at the bottom level of the SPI mechanism, the API accepts ClassLoader objects. However, the Directory API does not have methods that take a class loader, so, in practical terms, the SPI mechanism always uses the Thread Context Class Loader. I just spent some time sorting out a muddle

Re: Classloaders, SPI, Directory ... OSGi?

On Tue, Jan 26, 2016 at 9:35 AM, Uwe Schindler wrote: > Hi, > >> Down at the bottom level of the SPI mechanism, the API accepts >> ClassLoader objects. However, the Directory API does not have methods >> that take a class loader, so, in practical terms, the SPI mechanism >>

Re: Sharing a class across cores

What is the connection of a blob of data and a class in a class loader? Is it a class of your own that you're using to store the data? Solr can't change fundamental facts about class loader; if an object of a class needs to be shared across class loaders, it has to be loaded into a common parent.

Re: Solr search

On Wed, Sep 30, 2015 at 9:11 PM, vetrik kumaran murugesan wrote: > Hi Upayavira, > > Thanks for your quick reply. > > Files above use GPL and MIT license , like junit4-ant 2.1.13 has GPL and > MIT. There is no MIT or GPL to Xerces or ant, they are Apache products. Why makes

Re: Ant/JUnit/Bash bug with RTL languages?

Isn't this all about how your console does the Unicode bidi algo, and not about anything in the code? On Fri, Aug 21, 2015 at 10:12 AM, Mike Drob mad...@cloudera.com wrote: Hello, I noticed that when running tests, if the language selected is RTL then the JUnit says hello output is

Re: Ant/JUnit/Bash bug with RTL languages?

implements your actual UI output :-) On Fri, Aug 21, 2015 at 9:13 AM, Benson Margulies bimargul...@gmail.com wrote: Isn't this all about how your console does the Unicode bidi algo, and not about anything in the code? On Fri, Aug 21, 2015 at 10:12 AM, Mike Drob mad...@cloudera.com wrote: Hello

Re: Coverity scan results of Lucene

On Tue, Jul 14, 2015 at 10:59 AM, Rishabh Patel rishabh.mahendra.pa...@gmail.com wrote: org/apache/lucene/facet/taxonomy/directory/DirectoryTaxonomyWriter.java: What does coverity complain of? Why do you, personally, think that the complaint is legitimate? On Tue, Jul 14, 2015 at 10:44 AM,

Re: Custom PostingsFormat SPILoader issues

In Solr you need a CodecFactory to deliver a Codec that happens to use your PostingFormat. The CodecFactory can set any params you like. On Fri, Mar 13, 2015 at 12:13 PM, Tom Burton-West tburt...@umich.edu wrote: Thanks Uwe, I'm pretty much going from what Hoss told me in the thread

Is the Solr CodecFactory doc a bit off-kilter?

http://wiki.apache.org/solr/SimpleTextCodecExample Why does it have: codecFactory name=CodecFactory class=solr.SchemaCodecFactory / and then: postingsFormat=SimpleText Shouldn't the postingFormat match the codec factory name? For that matter, how much of this is obsolete? Is there better doc

Re: [VOTE] Move trunk to Java 8

I wish that the API improvements Rob Muir and I made to the analysis chain could be released in the foreseeable future, and I wish a little that they could be released in a version that does not require Java 8. - To unsubscribe,

Re: [VOTE] Move trunk to Java 8

On Mon, Sep 15, 2014 at 2:45 PM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: Ryan, I’m unclear on what makes a “procedural vote” as such. This seems to me to be about code modifications — in a big way as it’s a large change to the codebase. David, one way out of this is that

Re: [VOTE] Move trunk to Java 8

On Sun, Sep 14, 2014 at 3:10 PM, Jack Krupansky j...@basetechnology.com wrote: (Hmmm... I wonder what Heliosearch’s Java support policy is.) There was a Lucene wiki page for the Java 1.4 to 1.5 transition... is any of that thinking relevant to this 1.7 to 1.8 transition? See:

Re: [VOTE] Move trunk to Java 8

If we release the current contents of trunk first, I'm OK with this, not that i have a veto. There are many large organizations of the sort that use Lucene Solr that will not be moving to 8 for years yet. If the current trunk content is marooned until they move to 8, I will be sad. On Fri, Sep

Re: [VOTE] Move trunk to Java 8

On Fri, Sep 12, 2014 at 3:35 PM, Robert Muir rcm...@gmail.com wrote: On Fri, Sep 12, 2014 at 3:31 PM, Chris Hostetter hossman_luc...@fucit.org wrote: b) that your argument against benson's claims seemed missleading: just because Oracle is EOLing doesn't mean people won't be using OpenJDK;

Re: [VOTE] Move trunk to Java 8

Corporate overlords isn't helpful. Lucene is what it is because of its wide adoption. That includes big, small, smart, and stupid organizations. I don't think that an infrastructure component like Lucene needs to be 'ahead of the curve'. It should aim to be widely adoptable. To me, that means

RE: Hints on constructing/running Solr analyzer chains standalone

Uwe, the last time I looked, Solr was perfectly cheerful about using analysis components that did not advertise themselves via the factory SPI system. So someone might want to go further than calling the available methods. On Jul 12, 2014 7:24 PM, Uwe Schindler u...@thetaphi.de wrote: The

Re: CJKBigramFilter - position bug with outputUnigrams?

website: http://www.outerthoughts.com/ Current project: http://www.solr-start.com/ - Accelerating your Solr proficiency On Mon, Apr 21, 2014 at 8:50 AM, Shawn Heisey s...@elyograg.org wrote: On 4/20/2014 6:20 PM, Benson Margulies wrote: Could I perhaps wonder why your customer is so intent

Re: CJKBigramFilter - position bug with outputUnigrams?

Could I perhaps wonder why your customer is so intent on indexing ngrams? Why not use Kuromoji and index words? On Sun, Apr 20, 2014 at 2:00 PM, Robert Muir rcm...@gmail.com wrote: On Sun, Apr 20, 2014 at 1:53 PM, Shawn Heisey s...@elyograg.org wrote: On 4/20/2014 11:10 AM, Robert Muir wrote:

FilterDirectoryReader and close

I added a test case to TestDirectoryReaderReopen that tests an experiment of mine with a FilterDirectoryReader. It fails in org.apache.lucene.index.TestDirectoryReaderReopen#performDefaultTests at index2_refreshed.close(); assertReaderClosed(index2, true); So it seems that the reader

Re: I may have run into something interesting with luceneutil

-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, April 07, 2014 2:41 AM To: dev@lucene.apache.org Subject: I may have run into something interesting with luceneutil Or I may not. https://code.google.com/a/apache- extras.org/p/luceneutil/wiki/AddToBuildTree

Re: I may have run into something interesting with luceneutil

at 6:27 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Looks like an orphaned ThreadPoolExecutor thread preventing JVM exit. Hard to tell where it came from based on just the name (generic factory). D. On Mon, Apr 7, 2014 at 12:21 PM, Benson Margulies bimargul...@gmail.com wrote

Re: Anticipating a benchmark for direct posting format

at the API, and then we'll see if I can come up with something that people find tolerable in proportion to the benefit. On Thu, Apr 3, 2014 at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote: On Thu, Apr 3, 2014 at 11:37 AM, Michael McCandless luc...@mikemccandless.com wrote

Re: Anticipating a benchmark for direct posting format

On Mon, Apr 7, 2014 at 9:14 AM, Robert Muir rcm...@gmail.com wrote: On Thu, Apr 3, 2014 at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote: My takeaway from the prior conversation was that various people didn't entirely believe that I'd seen a dramatic improvement in query perfo

Re: Anticipating a benchmark for direct posting format

On Mon, Apr 7, 2014 at 9:30 AM, Robert Muir rcm...@gmail.com wrote: On Mon, Apr 7, 2014 at 9:22 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Apr 7, 2014 at 9:14 AM, Robert Muir rcm...@gmail.com wrote: On Thu, Apr 3, 2014 at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote

Re: Anticipating a benchmark for direct posting format

-variant codec. ~ David On Mon, Apr 7, 2014 at 9:22 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Apr 7, 2014 at 9:14 AM, Robert Muir rcm...@gmail.com wrote: On Thu, Apr 3, 2014 at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote: My takeaway from the prior conversation

Re: Anticipating a benchmark for direct posting format

, if implemented, this would be a change to DPF instead of an additional DPF-variant codec. ~ David On Mon, Apr 7, 2014 at 9:22 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Apr 7, 2014 at 9:14 AM, Robert Muir rcm...@gmail.com wrote: On Thu, Apr 3, 2014 at 12:27 PM, Benson Margulies

Re: Anticipating a benchmark for direct posting format

Apr 2014, at 22:19, Benson Margulies wrote: Typically, an app gets a directory reader, which is a composite reader. To get a filter down there into the leaves of the composite reader, does anyone have a suggestion about where to enter the modularity? I sort of want to insert myself

Re: Anticipating a benchmark for direct posting format

. Alan Woodward www.flax.co.uk On 7 Apr 2014, at 22:19, Benson Margulies wrote: Typically, an app gets a directory reader, which is a composite reader. To get a filter down there into the leaves of the composite reader, does anyone have a suggestion about where to enter the modularity? I

Re: Anticipating a benchmark for direct posting format

OK, I'm slow but I'm getting there. A funny wrapping Codec would require messing with how codecs come into being, and it's too late to do that without a lot of changes. On the other hand, the insides of the D-P-F could be used accomplish the same thing out on the filter reader.

I may have run into something interesting with luceneutil

Or I may not. https://code.google.com/a/apache-extras.org/p/luceneutil/wiki/AddToBuildTree?ts=1396830970updated=AddToBuildTree I'm trying to learn something about direct posting format using luceneutil. The above-linked page is what I'm trying on a 160G multicore machine. Using trunk, the

Anticipating a benchmark for direct posting format

Some of you may recall that I started a thread some time ago about wishing for the benefits of the direct posting format without needing to use a codec. The thread landed as a challenge: show a benchmark of the benefit of D-P-F. After a lot of distraction, I'm now in a position to build it. The

Re: Anticipating a benchmark for direct posting format

me try to simulate this situation with luceneutil, I'd be happy to skip the work I was about to do to build another benchmark. http://blog.mikemccandless.com On Thu, Apr 3, 2014 at 8:38 AM, Benson Margulies bimargul...@gmail.com wrote: Some of you may recall that I started a thread some

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

[ https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944920#comment-13944920 ] Benson Margulies commented on SOLR-5228: Allow the person extending the schema

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

[ https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944971#comment-13944971 ] Benson Margulies commented on SOLR-5228: DTD's are useless. We need to pick one

[jira] [Commented] (SOLR-5228) Deprecate fields and types tags in schema.xml

[ https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944636#comment-13944636 ] Benson Margulies commented on SOLR-5228: I apologize for showing up so late

Threads in the LuceneTestCase system

I'm fighting with a test that uses the random analysis chain testing. It does not repro when I pass in the usual collection of -D's. I think that the reason is to do with threads; the failure is always on a big multicore build machine. Are there any more of those Carrot control -D's that change

Re: Threads in the LuceneTestCase system

is working, and i hope it still is, i havent seen anything crazy to indicate otherwise, and i've been in TestRandomChains for a few hours this week) On Fri, Mar 21, 2014 at 1:57 PM, Benson Margulies bimargul...@gmail.com wrote: I'm fighting with a test that uses the random analysis chain testing

Re: Threads in the LuceneTestCase system

I could share it right here, but in any case I just found _another_ stupid mistake where I was doing something in which multiple analyzers would end up sharing something unsharable. build 21-Mar-2014 10:36:59

Re: Threads in the LuceneTestCase system

class a startingGun. On Fri, Mar 21, 2014 at 2:38 PM, Benson Margulies bimargul...@gmail.com wrote: I could share it right here, but in any case I just found _another_ stupid mistake where I was doing something in which multiple analyzers would end up sharing something unsharable. build 21

Re: Threads in the LuceneTestCase system

/reproducing thread safety issues? On Fri, Mar 21, 2014 at 2:48 PM, Benson Margulies bimargul...@gmail.com wrote: Yea, right now I have this failure that repros every time on a big computer and never on my not-so-small MacBook Pro. On Fri, Mar 21, 2014 at 2:43 PM, Robert Muir rcm

Re: Reducing the number of warnings in the codebase

Just because some tool expresses distaste, doesn't imply that everyone here agrees that it's a problem we should fix. In my experience, the default Sonar rulesets contain many things that people here are prone to disagree with. Start with serialVersionUID: do we care? Why would we care? In what

Re: Reducing the number of warnings in the codebase

I think we avoid bikeshed by making incremental changes. If you offer a commit to turn off serial version UID whining, I'll +1 it. And then we iterate, in small doses, agreeing to either spike the warning or change the code. In passing, I will warn you that the IDEs can be very stubborn; in some

Re: [VOTE] Lucene / Solr 4.7.0 RC2

Does this mean that 5449 moves to 4.7? If so, who fiddles with CHANGES.txt? Me as the author or the RM? On Thu, Feb 20, 2014 at 11:03 AM, Simon Willnauer simon.willna...@gmail.com wrote: I agree - I will respin On Thu, Feb 20, 2014 at 4:54 PM, Adrien Grand jpou...@gmail.com wrote: Sorry for

Re: [VOTE] Lucene / Solr 4.7.0 RC2

I get it. You're cherry-picking changes onto the rel branch. No, there's absolutely no reason to imagine grabbing 5449. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail:

I broke a build, but I can't find the email

I see Rob's revert, but I can't find the email about it. The thing passed 'ant precommit' before I committed it. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail:

Re: I broke a build, but I can't find the email

to lucene, running ant compile compile-test test, and I got no compile errors. So why does it fail on Jenkins? On Wed, Feb 19, 2014 at 3:31 PM, Benson Margulies bimargul...@gmail.com wrote: I see Rob's revert, but I can't find the email about it. The thing passed 'ant precommit' before I committed

[jira] [Assigned] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned LUCENE-5449: Assignee: Benson Margulies Two ancient classes renamed to be less peculiar

[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13906174#comment-13906174 ] Benson Margulies commented on LUCENE-5449: -- I'm unable to reconstruct how I laid

[jira] [Comment Edited] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13906174#comment-13906174 ] Benson Margulies edited comment on LUCENE-5449 at 2/19/14 10:02 PM

[jira] [Updated] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated LUCENE-5449: - Fix Version/s: 5.0 4.8 Two ancient classes renamed to be less

[jira] [Resolved] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved LUCENE-5449. -- Resolution: Fixed Two ancient classes renamed to be less peculiar: _TestHelper

[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903983#comment-13903983 ] Benson Margulies commented on LUCENE-5449: -- [~thetaphi], I am not enthusiastic

Re: Refactoring code through Github pull requests

Well, git-svn has a heap of warnings against using it for merges; it's also a really bad idea when renaming a whole package, as it does it one-file-at-a-time. If you have a workflow that works with the ASF mirror and svn, please write it up on the Wiki! On Tue, Feb 18, 2014 at 7:23 AM, Thomas

Re: Refactoring code through Github pull requests

picked patch sets really, not branch merges ? (ie rebased) from there on out you're in svn land. No need to merge. But indeed, it tries to detect it based on the file content, and doesn't work 100% as manual svn moves. On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies bimargul...@gmail.com

[jira] [Commented] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13904004#comment-13904004 ] Benson Margulies commented on LUCENE-5449: -- OK, then this is good to go. (I did

Re: Refactoring code through Github pull requests

, Feb 18, 2014 at 1:27 PM, Benson Margulies bimargul...@gmail.com wrote: Well, git-svn has a heap of warnings against using it for merges; it's also a really bad idea when renaming a whole package, as it does it one-file-at-a-time. If you have a workflow that works with the ASF mirror and svn

Re: Refactoring code through Github pull requests

not track renames, but can show/detect it, the magic options are -C and -M for diff/show etc On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies bimargul...@gmail.com wrote: I tried using git apply on a patch (from github's .patch URL) that included a rename. no sign of a rename; just

Re: Refactoring code through Github pull requests

that this can be arranged with the tools at hand. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Tuesday, February 18, 2014 2:17 PM

Re: Refactoring code through Github pull requests

r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line Changed paths: A /trunk/moo (from /trunk/test:2) D /trunk/test woof On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies bimargul...@gmail.comwrote: Let me

Re: Refactoring code through Github pull requests

See https://wiki.apache.org/lucene-java/BensonMargulies/GitSvnWorkflow for an experiment with git svn. On Tue, Feb 18, 2014 at 1:47 PM, Benson Margulies bimargul...@gmail.com wrote: Once I have transported a change from branch to branch via diff\apply, git stops discussing a rename at all

Exposing random string generation

Down in the bottom of the randomized testing apparatus is some code for generating random stress data. The only public/protected API for it is to push it into an analysis chain. Would anyone object to a patch to allow direct access to methods that just deliver the randomized text? I'd like some

Re: Exposing random string generation

.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, February 17, 2014 1:19 PM To: dev@lucene.apache.org Subject: Exposing random string generation Down in the bottom

Re: Exposing random string generation

- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, February 17, 2014 1:19 PM To: dev@lucene.apache.org Subject: Exposing random string generation Down in the bottom of the randomized testing apparatus is some code for generating random stress data. The only public

[jira] [Created] (LUCENE-5448) Random string generation centralized in _TestUtil

Benson Margulies created LUCENE-5448: Summary: Random string generation centralized in _TestUtil Key: LUCENE-5448 URL: https://issues.apache.org/jira/browse/LUCENE-5448 Project: Lucene - Core

Re: Exposing random string generation

should be very noisy! On Mon, Feb 17, 2014 at 7:48 AM, Benson Margulies bimargul...@gmail.com wrote: Right, that's my target. Might I rename _TestUtil for 5.0 :-? On Mon, Feb 17, 2014 at 7:44 AM, Robert Muir rcm...@gmail.com wrote: There are, but the stuff inside BaseTokenStreamTestCase

[jira] [Resolved] (LUCENE-5448) Random string generation centralized in _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved LUCENE-5448. -- Resolution: Fixed Fix Version/s: 5.0 Assignee: Benson Margulies

[jira] [Updated] (LUCENE-5448) Random string generation centralized in _TestUtil

[ https://issues.apache.org/jira/browse/LUCENE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated LUCENE-5448: - Fix Version/s: 4.7 Random string generation centralized in _TestUtil

Re: Exposing random string generation

static ..._TestUtil.* and use them as simple static external methods in affected tests. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent

RE: Exposing random string generation

it. And maybe use static imports in the future. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, February 17, 2014 2:22 PM To: dev

Edit permission to the wiki

Looks like I lack access to modify https://wiki.apache.org/lucene-java. Could someone fix that. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-5449) Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil

Benson Margulies created LUCENE-5449: Summary: Two ancient classes renamed to be less peculiar: _TestHelper and _TestUtil Key: LUCENE-5449 URL: https://issues.apache.org/jira/browse/LUCENE-5449

RE: Edit permission to the wiki

BensonMargulies On February 17, 2014 5:27:16 PM EST, Uwe Schindler u...@thetaphi.de wrote: Hi Benson, what is your username? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Benson Margulies

Re: Edit permission to the wiki

Tanks On February 17, 2014 7:14:13 PM EST, Erick Erickson erickerick...@gmail.com wrote: You should be set now. Erick On Mon, Feb 17, 2014 at 3:17 PM, Benson Margulies bimargul...@gmail.comwrote: BensonMargulies On February 17, 2014 5:27:16 PM EST, Uwe Schindler u...@thetaphi.de wrote

[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries

[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895706#comment-13895706 ] Benson Margulies commented on LUCENE-4956: -- This is a patch, not an accepted

[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis

[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892049#comment-13892049 ] Benson Margulies commented on SOLR-5623: [~shalinmangar] Apparently I haven't

Why is String.format[] forbidden?

Or, more specifically, what's the minimum JVM for 4.x versus 5.x? I had the idea that even 4.x required 1.6. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Why is String.format[] forbidden?

...@thetaphi.de -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Wednesday, February 05, 2014 1:46 PM To: dev@lucene.apache.org Subject: Why is String.format[] forbidden? Or, more specifically, what's the minimum JVM for 4.x versus 5.x? I had the idea

Having trouble applying a PR to svn

So, I did: wget https://github.com/apache/lucene-solr/pull/18.diff and then: svn patch --dry-run --strip 1 18.diff and some of the pathnames have 2 components stripped -- but not all. Has anyone got another approach? I hesitate to use git-svn, but I'll follow someone else's lead. svn patch

[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis

[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891512#comment-13891512 ] Benson Margulies commented on SOLR-5623: trunk patch 1564584. Better diagnosis

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889406#comment-13889406 ] Benson Margulies commented on LUCENE-5405: -- Will do. Thanks, this is exactly

[jira] [Updated] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated LUCENE-5405: - Fix Version/s: 4.7 Exception strategy for analysis improved

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889424#comment-13889424 ] Benson Margulies commented on LUCENE-5405: -- rev 1563850 provides the backport

[jira] [Resolved] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved LUCENE-5405. -- Resolution: Fixed backported, CHANGES.txt filled in. 'this time for sure' Exception

Re: svn commit: r1563855 - /lucene/dev/trunk/lucene/CHANGES.txt

createComponents. TokenStreams now always get their input + via setReader. (Benson Margulies via Robert Muir - pull request #16) -* LUCENE-5405: Make ShingleAnalzyerWrapper.getWrappedAnalyzer() public final (gsingers) +* LUCENE-5405: If an analysis component throws an exception, Lucene + logs

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888958#comment-13888958 ] Benson Margulies commented on LUCENE-5405: -- I can backport, [~mikemccand

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889051#comment-13889051 ] Benson Margulies commented on LUCENE-5405: -- Somehow the unit test escaped

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889095#comment-13889095 ] Benson Margulies commented on LUCENE-5405: -- Well, svn merge did something I

[jira] [Updated] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated LUCENE-5405: - Attachment: LUCENE-5405-4.x.patch Reviewable port. Exception strategy for analysis

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889101#comment-13889101 ] Benson Margulies commented on LUCENE-5405: -- [~mikemccand] and [~rcmuir

Re: Getting Apache on your GitHub

Mark, is there any possibility of a 1-many mapping from apache ID to github ID? I have two. On Fri, Jan 31, 2014 at 10:51 AM, Mark Miller markrmil...@gmail.com wrote: If your a committer, you might be interested in some stuff I learned about Apache-GitHub recently: If you want to show off

[jira] [Assigned] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis

[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned SOLR-5623: -- Assignee: Benson Margulies Better diagnosis of RuntimeExceptions in analysis

[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886067#comment-13886067 ] Benson Margulies commented on LUCENE-5405: -- Am I good to commit here

[jira] [Assigned] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned LUCENE-5405: Assignee: Benson Margulies Exception strategy for analysis improved

[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis

[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886068#comment-13886068 ] Benson Margulies commented on SOLR-5623: [~hossman_luc...@fucit.org] have you

[jira] [Moved] (SOLR-5677) HaversineConstFunction ignores one of its two values, is this on purpose?

[ https://issues.apache.org/jira/browse/SOLR-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies moved LUCENE-4036 to SOLR-5677: Component/s: (was: core/other

[jira] [Resolved] (SOLR-5677) HaversineConstFunction ignores one of its two values, is this on purpose?

[ https://issues.apache.org/jira/browse/SOLR-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved SOLR-5677. Resolution: Fixed Fix Version/s: 5.0 Assignee: Benson Margulies Well

Closing a PR

As a committer can I get my github ID added so that I can close PR's? bimargulies would be the relevant ID. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Closing a PR

Was that supposed to be my svn commit message :-) On Wed, Jan 29, 2014 at 7:42 PM, Robert Muir rcm...@gmail.com wrote: the way to close is to add closes #x to your commit message On Wed, Jan 29, 2014 at 4:36 PM, Benson Margulies bimargul...@gmail.com wrote: As a committer can I get my

[jira] [Resolved] (LUCENE-5405) Exception strategy for analysis improved

[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved LUCENE-5405. -- Resolution: Fixed Fix Version/s: 5.0 Fixed in rev 1562657. Exception

Re: Liberating DirectPostingFormat from Codec

, Benson Margulies bimargul...@gmail.com wrote: Keeping things in memory and not re-reading them from disk is what really sang the song for us. Even if the initial read-in was more costly due to decompression, the long-term amortized benefit of not re-reading would still be a big winner. On Sat, Jan

  1   2   3   4   5   6   7   8   9   >