Re: Looks like I broke Solr 5.2.0 - do we need a 5.2.1?

A user found a nasty DefaultSolrHighlighter performance bug with an easy fix — https://issues.apache.org/jira/browse/SOLR-7655 I’m running tests now. On Tue, Jun 9, 2015 at 2:48 PM [email protected] < [email protected]> wrote: > I’m +1 to this. We can consider changing

Instructions on Solr's website about adding books

Solr’s “Resources” page, by the book section, contains this lead in text: http://lucene.apache.org/solr/resources.html#solr-books If you have a Solr book that you would like to see listed here, please submit a patch via a JIRA with the appropriate cont

Re: official ASF Jenkins Slave moved to Ubuntu 14.04

Thanks for your hard work on keeping Lucene/Solr well tested! On Fri, May 22, 2015 at 5:23 PM Uwe Schindler wrote: > Hi all, > > the old lucene-zones.apache.org machine, running on FreeBSD, was disabled > an hour ago and all Jobs migrated. This old machine was not able to run > Java 8 at all (cr

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 12825 - Failure!

This is not a real bug; it’s the test asserting it finds a minimum number relation types over many random shapes… but that can sometimes be asking too much. I filed an issue to improve, which I’ll get to shortly: LUCENE-6502 - Spatial RectIntersectionTestHelper should only require one of each rela

Re: Moving to git?

+1 to git. Git may not be perfect, but SVN isn’t either. On Fri, May 29, 2015 at 11:59 PM Ishan Chattopadhyaya < [email protected]> wrote: > Life is so much easier on long train/plane journeys with Git. +1. > > On Sat, May 30, 2015 at 9:21 AM, Shai Erera wrote: > >> +1 to moving to git.

Re: [VOTE] 5.2.0 RC2

It’d be nice if something like that failed the build. There’s kind of a soft dependency there for Solr’s logging admin screen, which is optional. ~ David On Sun, May 31, 2015 at 12:45 AM Tomás Fernández Löbbe < [email protected]> wrote: > Unfortunately I imported log4j Logger instead of sl

Re: Moving to git?

Nice! On Sun, May 31, 2015 at 1:31 PM Steve Davids wrote: > bq. Something needs to be done about all those jars in the source > history, I will not let this go. > > I went ahead and used the BFG Repo Cleaner > tool to drop all of the old > jars in the

Re: Moving to git?

I like where this is going! I also think history of source code is very important, but not history of ‘.jar’ files that shouldn’t have been in source control in the first place. I’m fiercely negative about large binaries or ‘jar’ files that can be downloaded by the build system (e.g. ivy) in sour

Re: Moving to git?

27;t so so much going > on there. > > It is git that is totally broken here with respect to history. > > > On Sun, May 31, 2015 at 6:47 PM, Robert Muir wrote: > > On Sun, May 31, 2015 at 4:39 PM, [email protected] > > wrote: > >> > >> If we were

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12734 - Failure!

Woops; I’ll fix. This was a Java 8 / Java 7 issue. On Tue, Jun 2, 2015 at 9:40 AM Policeman Jenkins Server wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12734/ > Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC > > All tests passed > > Build Log: > [...truncate

Re: [JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 4760 - Failure!

I fixed this already. On Tue, Jun 2, 2015 at 10:10 AM Policeman Jenkins Server < [email protected]> wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4760/ > Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC > > All tests passed > > Build Log: > [...truncated 5664 lin

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2377 - Failure!

Can you take a look Karl? At first glance looking at the code, not running it, I’m guessing this is a degenerate path segment that is too short. On Tue, Jun 2, 2015 at 11:19 PM Policeman Jenkins Server < [email protected]> wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/

Re: VOTE: RC0 release apache-solr-ref-guide-5.2.pdf

+1 looks good to me too. I like some of the visual tweaks done to make the formatting/theme similar to the website. On Wed, Jun 3, 2015 at 5:07 PM Cassandra Targett wrote: > +1, it looks good to me. > > Cassandra > > On Wed, Jun 3, 2015 at 12:30 PM, Chris Hostetter > wrote: > >> >> Please VOTE

Re: TokenOrderingFilter

Hi Dmitry, Ideally, the token stream produces tokens that have a startOffset >= the startOffset of the previous token from the stream. Sometime in the past year or so, this was enforced at the indexing layer, I think. There used to be TokenFilters that violated this contract; I think earlier ver

Re: SOLR-7240, java -jar start.jar, and 5.1

+1; more time is needed before start.jar can be deprecated/removed. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Wed, Apr 1, 2015 at 12:37 PM, Timothy Potter wrote: > As Gus points out in the ticket, the cloud-dev scripts are

Re: [DISCUSS] Change Query API to make queries immutable in 6.0

I’m +1 to going all the way (fully immutable) but the proposal stops short by skipping the boost. I agree with Terry’s comments — what a shame to make Queries “more immutable” but not really quite immutable. It kinda misses the point? Otherwise why bother? If this is about progress not perfecti

Re: [DISCUSS] Change Query API to make queries immutable in 6.0

On Thu, Apr 2, 2015 at 3:40 AM, Adrien Grand wrote: > first make queries immutable up to the boost and then discuss > if/how/when we should go fully immutable with a new API to change > boosts? > The “if” part concerns me; I don’t mind it being a separate issue to make the changes more manageabl

Re: [DISCUSS] Change Query API to make queries immutable in 6.0

On Thu, Apr 2, 2015 at 9:45 AM, Robert Muir wrote: > They are also only relevant when scores are needed: > so we can prevent nasty filter caching bugs as a step, by making > everything else immutable. > That’s a good point. +1 to your progress Adrien! ~ David Smiley Freelance Apache Lucene/Sol

CompressingTermVectors; per-field decompress?

I was looking at a JIRA issue someone posted pertaining to optimizing highlighting for when there are term vectors ( SOLR-5855 ). I dug into the details a bit and learned something unexpected: CompressingTermVectorsReader.get(docId) fully loads all term vectors for the document. The client/user

Re: CompressingTermVectors; per-field decompress?

not be) > with vectors would also enable better compression, maybe even > underneath LZ4, like stored fields got in 5.0 too. > > > On Thu, Apr 2, 2015 at 2:51 PM, [email protected] > wrote: > > I was looking at a JIRA issue someone posted pertaining to optimizing

Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12349 - Failure!

I’ll look into it. On Thu, Apr 30, 2015 at 10:17 PM Policeman Jenkins Server < [email protected]> wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12349/ > Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC > > 1 tests failed. > FAILED: > org.apache.lucene.spatial.composite.Co

Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12349 - Failure!

The root cause is that Spatial4j’s DistanceUtils.distHaversineRAD returned NaN for a pair of anti-podal points. I filled a bug in Spatial4j: https://github.com/spatial4j/spatial4j/issues/104 On Thu, Apr 30, 2015 at 10:19 PM [email protected] < [email protected]> wrote: >

<    1   2   3