You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Paul Irwin <pi...@feature23.com> on 2013/08/07 04:52:02 UTC
Re: Lucene 4.0
Hey all, sorry it's been a little while, but I wanted to let you know that
although I took a few weeks off from it, I now have a 4.3.1 equivalent
Lucene.net core building and able to write a simple index in Lucene 4.2
codec and read in things like the number of documents and whatnot. Since
QueryParser has been moved to a separate module in Lucene Java 4.x, I
haven't ported that yet so I haven't done a real search, and I only built
the index using a quick port of KeywordAnalyzer which all those analyzers
have also moved to another module. But this is definitely good progress and
should be a launch point for finishing a 4.3/4.4 port.
You can see my fork/branch here:
https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
said, only core builds now, no modules/tests build, so only open the
Lucene.Net.Core.sln)
I'm sure it's riddled with bugs, but I hope this can help kickstart the
community into finishing the 4.3/4.4 port. Let me know if you have any
questions, thanks!
On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Paul, that's awesome. I will need some more time to go over this thread and
> your work to give actual feedback, SUPER busy at the moment
>
>
> On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com> wrote:
>
> > All,
> >
> > My colleagues and I have made good progress on porting Lucene 4.3's core
> > library before, during, and after the hackathon last week. We now only
> have
> > some remaining items in Search, Index, and Codecs namespaces (plus a few
> > other minor ones here and there). I expect to be done by the end of the
> > weekend. Analysis, Documents, Store, Util (except some FST and Packed),
> and
> > the root Codecs and Codecs.PerField namespaces are all now "done".
> >
> > Again, my goal is to only get a buildable, experimental build of
> Lucene.net
> > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting
> new
> > javadoc comments or unit tests right now, due to the vast amount of code
> > that needs to be written just to get it to compile. If this work ends up
> > becoming a pull request, great, otherwise it should help accelerate a
> port
> > of 4.3.x since the bulk of the work on core will already be done and
> > contributors can use it as a reference. And again, we're taking the
> > pragmatic approach of porting class-by-class, namespace-by-namespace,
> with
> > the understanding that until we're done the project won't build.
> >
> > Once complete, I also will work on updating the Analyzers contrib module
> > and porting the QueryParsers contrib module, which I feel should be
> > included in the core NuGet package for Lucene.net as the core library is
> > now (post-4.0) practically useless (or atleast not turn-key) without
> them.
> > You can check out the code on my fork/branch here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> > In particular, I'd like some feedback on my work on ByteBuffer,
> > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the
> MMap
> > support, I created a ByteBuffer subclass that uses .NET 4's
> > MemoryMappedFile support which should emulate the Java nio stuff pretty
> > well, but required some creative shuffling of the code to make it work
> due
> > to lifecycle management.
> >
> > I'll update again this weekend or next week, when we should have wrapped
> up
> > most of the main hacking on porting the core code.
> >
> > Paul
> > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > Marcos,
> > >
> > > That would be helpful. As far as I can tell, the 3.0 java code is only
> on
> > > SVN here, before the lucene and solr projects were bundled together:
> > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > >
> > > The SVN for 4.3 java is here:
> > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > And the GitHub for 4.3 java is here:
> > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > >
> > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > >
> > > My fork is the "upstream" fork for my team members, and i'm remote
> > merging
> > > their changes in from their forks while they fetch/merge from mine to
> get
> > > everyone else's changes, rather than using pull requests. James and I
> > have
> > > been working the past few days on the Util namespace ahead of tonight's
> > > hackathon since that namespace is in common with the rest of the
> > > namespaces. Tonight, we'll have at least 8 guys that I know of hacking
> on
> > > porting 4.3, each with a different namespace or part of a namespace.
> > Since
> > > we're going class-by-class, namespace-by-namespace, the project does
> not
> > > build as it is. Once we finish doing a translation of each file, then
> > we'll
> > > hammer out any remaining issues and get it to build again. I'm hoping
> > that
> > > we can get at least 75% done with Core tonight. Wish us luck!
> > >
> > > But one thing to keep in mind is it looks like much functionality has
> > been
> > > moved out of core into the contrib modules, especially around analysis,
> > for
> > > 4.0+. For example, there are no built-in analyzers in core anymore. So
> > when
> > > this is all done, we may want to include at least the analysis contrib
> > > module in with the standard core NuGet package, because otherwise it's
> > > practically useless unless you roll your own analyzer.
> > >
> > > Paul
> > >
> > >
> > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <marcoslimagon@gmail.com
> > >wrote:
> > >
> > >> Hi everyone!
> > >>
> > >> Does someone know where can I find the 3.0.3 release from
> Lucene(java)?
> > >>
> > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> > make
> > >> the diff between then and get all changes between releases... I gonna
> > >> publish it here soon. (If you think there is another important
> release,
> > >> let
> > >> me know)
> > >>
> > >> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0
> > >> port
> > >> for .Net on github (last email)?
> > >>
> > >> See you,
> > >>
> > >>
> > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > >>
> > >> > Thanks for the discussion points, Michael.
> > >> >
> > >> > I would vote for not worrying about trying to achieve portable
> > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > >> completed.
> > >> > Otherwise it may delay the project and stall it further. That's just
> > my
> > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > >> >
> > >> > I have started porting the changes from the core library (from the
> > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > branch.
> > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> until
> > >> > there's changes to pull from upstream to work from. Also due to my
> > time
> > >> > constraints, I am not fully documenting new methods that I'm adding.
> > >> But if
> > >> > anyone wants to pull/copy/reference my changes while porting, that's
> > >> > awesome. My branch currently does not build as I'm primarily going
> > >> > class-by-class, starting with the util namespace. Once we get the
> ball
> > >> > rolling on a community effort, I'll stop my rogue work and join in.
> > But
> > >> > hopefully my work will be useful to someone, if not as a pull
> request
> > >> then
> > >> > as a reference. I'm also going to be holding a hackathon this week
> > with
> > >> my
> > >> > colleagues where we're all going to work on the port. I'm comparing
> > >> files
> > >> > and making changes as necessary, rather than starting from scratch.
> My
> > >> > repo/branch is here:
> > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > >> >
> > >> > Paul
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > >> > mherndon@michaelherndon.com> wrote:
> > >> >
> > >> > > the guithub.com repo is a mirror to the git mirror that apache
> > >> > maintains.
> > >> > >
> > >> > > The was some work at one time to move the official svn repository
> to
> > >> > start
> > >> > > using git one instead. Was that actually finalized or not?
> > >> > >
> > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> what
> > >> kind
> > >> > of
> > >> > > work was involved using a portable libraries project. Some of it
> can
> > >> > still
> > >> > > be used but will need to be validated against the current version
> of
> > >> > Java's
> > >> > > Lucene. It was also using .net 4.
> > >> > >
> > >> > > clean branch vs current. Its going to depend on what we
> support.
> > >> If
> > >> > you
> > >> > > support windows mobile 8, win RT, then the current code in trunk
> > will
> > >> not
> > >> > > compile against those versions of the framework which would a
> > >> frustrating
> > >> > > starting point, then you couldn't even run tests, which would make
> > >> taking
> > >> > > patches very difficult. Supporting those can almost mean larger
> > gaps
> > >> in
> > >> > > design between Lucene.Net and its parent project.
> > >> > >
> > >> > > Also the structure has changed significantly between the branches
> > and
> > >> > the
> > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> seems
> > >> > > significantly different. That doesn't mean you can't cherry pick
> > >> stuff
> > >> > > from the other tags/branches that would still work as is. A clean
> > >> branch
> > >> > > would also make it easier to get our build / tool chain in order
> as
> > >> you
> > >> > can
> > >> > > then do them incrementally versus having to do all the stuff that
> I
> > >> did
> > >> > for
> > >> > > the 3x branch which saps energy and desire to code. It could
> also
> > >> make
> > >> > it
> > >> > > easier to see which classes have been ported or not.
> > >> > >
> > >> > > The major downside to a clean branch is extra work it requires and
> > the
> > >> > > start up cost in time and energy of getting it in order, which can
> > be
> > >> > > daunting / intimidating and lower morale. And generally you want
> to
> > >> use
> > >> > > take your legacy code and refactor instead of in someways starting
> > >> over.
> > >> > >
> > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do something
> > >> similar
> > >> > > to
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > >> > > where it tracks what needs to get ported / what has been ported.
> > >> > >
> > >> > > What are we going to support in the next version?
> > >> > >
> > >> > > Who is going to work on the next version?
> > >> > >
> > >> > > What would make the most sense and what would invigorate the
> > >> community to
> > >> > > get involved more and lower the barrier to entry?
> > >> > >
> > >> > > I think those are the questions that would make a lot of the
> > decisions
> > >> > for
> > >> > > us so that we can get back to work on lucene.net.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > marcoslimagon@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > >> > > >
> > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > >> > > > https://github.com/apache/lucene.net points to the same
> > repository?
> > >> > > (This
> > >> > > > is new for me, pretty good) Which of them do you recommend (i'm
> > used
> > >> > with
> > >> > > > SVN and its patterns).
> > >> > > >
> > >> > > > I'm checking the subversion right now.
> > >> > > >
> > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > branch,
> > >> i`m
> > >> > > not
> > >> > > > sure about its current status.
> > >> > > >
> > >> > > > Will we wipe the current solution from /trunk and start a new
> one?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > >> > > >
> > >> > > > > We may be forced to start with a clean/empty branch if people
> > >> still
> > >> > > want
> > >> > > > to
> > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> etc.
> > >> The
> > >> > are
> > >> > > > > many
> > >> > > > > classes that Lucene.net uses from the full framework that
> would
> > >> not
> > >> > be
> > >> > > > > accessible in other versions of the .NET Framework. It also
> > might
> > >> > > > require
> > >> > > > > a design that differs even more from its parent project.
> > >> > > > >
> > >> > > > > It might be wise to poll what users most desire in the next
> > >> version
> > >> > > > through
> > >> > > > > jira or user voice.
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > >> > itamar@code972.com
> > >> > > > > >wrote:
> > >> > > > >
> > >> > > > > > inline
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > >> pirwin@feature23.com>
> > >> > > > wrote:
> > >> > > > > >
> > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS
> guy
> > >> for
> > >> > so
> > >> > > > > long
> > >> > > > > > > :-)
> > >> > > > > > >
> > >> > > > > > > So to recap, the branch_3x will be used for any patches or
> > >> > anything
> > >> > > > to
> > >> > > > > > the
> > >> > > > > > > current 3.0.3 release, while trunk is what we will branch
> > from
> > >> > for
> > >> > > 4x
> > >> > > > > > dev.
> > >> > > > > > > Correct?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Yes - we can branch from it for 3.6 development if anyone
> will
> > >> be
> > >> > > > > > interested in that
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > Thanks for pushing the Version.cs. What's the deal with
> the
> > >> > github
> > >> > > > > sync?
> > >> > > > > > > Who could diagnose that?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Not sure, Apache Infra, basically. Just use the apache repo
> > for
> > >> now
> > >> > > > while
> > >> > > > > > we get that sorted out.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > >> > > > itamar@code972.com
> > >> > > > > > > >wrote:
> > >> > > > > > >
> > >> > > > > > > > Ok, haven't noticed that branch. Just use it then for
> 3.x
> > >> > > > > development.
> > >> > > > > > > WRT
> > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> branch.
> > >> When
> > >> > > you
> > >> > > > > > send
> > >> > > > > > > us
> > >> > > > > > > > PRs we will merge either to master or to a dedicated
> repo.
> > >> For
> > >> > > now
> > >> > > > it
> > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > >> > > > > > > >
> > >> > > > > > > > I pushed a new Version.cs file, you should see it on the
> > >> apache
> > >> > > > > servers
> > >> > > > > > > > (github sync seems to be off)
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > >> > > pirwin@feature23.com>
> > >> > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> version
> > >> of
> > >> > the
> > >> > > > > > > Analysis
> > >> > > > > > > > > namespace.
> > >> > > > > > > > >
> > >> > > > > > > > > Not sure the checkout command is what you intended --
> > you
> > >> > might
> > >> > > > > have
> > >> > > > > > > > meant
> > >> > > > > > > > > trunk instead of master, and that would create a new
> > "3x"
> > >> > > branch,
> > >> > > > > > when
> > >> > > > > > > > > there's already a "branch_3x" and that would be
> > >> misnamed...
> > >> > so
> > >> > > > > maybe
> > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming for
> > >> lucene
> > >> > > > 4.3.x
> > >> > > > > > > > > compatibility?
> > >> > > > > > > > >
> > >> > > > > > > > > Also, does someone with commit rights to the upstream
> > >> want to
> > >> > > > > create
> > >> > > > > > > the
> > >> > > > > > > > > necessary Version.cs entries, so that we're not all
> > >> trying to
> > >> > > > > create
> > >> > > > > > > them
> > >> > > > > > > > > and dealing with a merge?
> > >> > > > > > > > >
> > >> > > > > > > > > Paul
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > >> > > > > > itamar@code972.com
> > >> > > > > > > > > >wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > > Unless people here have a specific reason to use
> > 3.6.2 I
> > >> > > would
> > >> > > > > > highly
> > >> > > > > > > > > > recommed putting all the efforts we can towards v4
> > >> > otherwise
> > >> > > we
> > >> > > > > > will
> > >> > > > > > > > > never
> > >> > > > > > > > > > make it...
> > >> > > > > > > > > >
> > >> > > > > > > > > > Fork the repo from apache servers or github (same
> > repo,
> > >> > > > different
> > >> > > > > > > > > remotes)
> > >> > > > > > > > > > and checkout -b 3x -t origin/master , that should
> work
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > >> > > > > pirwin@feature23.com>
> > >> > > > > > > > > wrote:
> > >> > > > > > > > > >
> > >> > > > > > > > > > > Itamar,
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > I agree that from scratch is not the best way to
> do
> > >> it, I
> > >> > > > just
> > >> > > > > > > > thought
> > >> > > > > > > > > > that
> > >> > > > > > > > > > > was the "decision" that was made from the
> discussion
> > >> > > > previously
> > >> > > > > > for
> > >> > > > > > > > the
> > >> > > > > > > > > > 4.x
> > >> > > > > > > > > > > work. An incremental approach will be much better.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > I've created a branch of the branch_3x branch on
> my
> > >> fork
> > >> > > and
> > >> > > > > will
> > >> > > > > > > > begin
> > >> > > > > > > > > > > working on bringing the Analysis namespace up to
> > >> speed to
> > >> > > > > 3.6.2.
> > >> > > > > > If
> > >> > > > > > > > > > anyone
> > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> done,
> > >> have
> > >> > at
> > >> > > > it.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > branch,
> > >> > > please
> > >> > > > > let
> > >> > > > > > > me
> > >> > > > > > > > > know
> > >> > > > > > > > > > > what I should have branched from (trunk?)
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Paul
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> Syn-Hershko <
> > >> > > > > > > > itamar@code972.com
> > >> > > > > > > > > > > >wrote:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Paul, the problem is no one can really know what
> > it
> > >> > would
> > >> > > > > take
> > >> > > > > > > > until
> > >> > > > > > > > > > they
> > >> > > > > > > > > > > > have deep dived into the work, and even then
> > >> decisions
> > >> > > > could
> > >> > > > > > and
> > >> > > > > > > > will
> > >> > > > > > > > > > > > change. I will strongly advise against starting
> > from
> > >> > > > scratch,
> > >> > > > > > > > > although
> > >> > > > > > > > > > I
> > >> > > > > > > > > > > do
> > >> > > > > > > > > > > > think a lot in the current structure should
> > change,
> > >> but
> > >> > > its
> > >> > > > > > going
> > >> > > > > > > > to
> > >> > > > > > > > > be
> > >> > > > > > > > > > > > much easier to change it in place, refactoring
> > where
> > >> > > > needed,
> > >> > > > > > than
> > >> > > > > > > > > > > starting
> > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > personally
> > >> > will
> > >> > > > be
> > >> > > > > > > happy
> > >> > > > > > > > > with
> > >> > > > > > > > > > > you
> > >> > > > > > > > > > > > taking the analysis part of Lucene and porting
> it,
> > >> its
> > >> > > > pretty
> > >> > > > > > > much
> > >> > > > > > > > > self
> > >> > > > > > > > > > > > contained.
> > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork
> and
> > >> send
> > >> > > us
> > >> > > > > PRs,
> > >> > > > > > > its
> > >> > > > > > > > > > much
> > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Marcos, porting class by class is the fastest
> way
> > >> to do
> > >> > > > this,
> > >> > > > > > we
> > >> > > > > > > > can
> > >> > > > > > > > > > then
> > >> > > > > > > > > > > > concentrate on .NETifying and optimizing using
> > .NET
> > >> > > > > constructs.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > That said, I think the way to go is create a
> > branch
> > >> out
> > >> > > of
> > >> > > > > the
> > >> > > > > > > > > current
> > >> > > > > > > > > > > git
> > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> working
> > on
> > >> > > master
> > >> > > > > > > > towards a
> > >> > > > > > > > > > 4.3
> > >> > > > > > > > > > > > compatible version. The actual port should be
> > using
> > >> a
> > >> > > > process
> > >> > > > > > > that
> > >> > > > > > > > > > > ensures
> > >> > > > > > > > > > > > all Java classes are ported with their tests,
> and
> > >> that
> > >> > > > those
> > >> > > > > > > tests
> > >> > > > > > > > > > pass -
> > >> > > > > > > > > > > > but I'm against committing any Java code to our
> > >> > > > repositories.
> > >> > > > > > The
> > >> > > > > > > > > > process
> > >> > > > > > > > > > > > should probably be working on classes in some
> > order
> > >> > > > > > > > (alphabetically,
> > >> > > > > > > > > or
> > >> > > > > > > > > > > > core classes first) and getting each class to
> > >> compile
> > >> > > > before
> > >> > > > > > > moving
> > >> > > > > > > > > > > > forward. I don't mind about the project not
> being
> > >> > > > compilable
> > >> > > > > > for
> > >> > > > > > > a
> > >> > > > > > > > > > month
> > >> > > > > > > > > > > or
> > >> > > > > > > > > > > > two.
> > >> > > > > > > > > > > > Once this is done a process of .NETifying and
> > >> proofing
> > >> > > the
> > >> > > > > code
> > >> > > > > > > can
> > >> > > > > > > > > be
> > >> > > > > > > > > > > > started, at which point we will already have a
> > >> working
> > >> > v4
> > >> > > > > > version
> > >> > > > > > > > so
> > >> > > > > > > > > it
> > >> > > > > > > > > > > > will be easier to keep up with the Java project.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> suite
> > so
> > >> > > tests
> > >> > > > > > could
> > >> > > > > > > > more
> > >> > > > > > > > > > or
> > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > >> Java-like
> > >> > > > > > > assertEquals
> > >> > > > > > > > > > > methods
> > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work with
> > >> than
> > >> > > > > NUnit). I
> > >> > > > > > > > > already
> > >> > > > > > > > > > > did
> > >> > > > > > > > > > > > some work there but there's still a lot to do.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself at
> this
> > >> > point,
> > >> > > > > but I
> > >> > > > > > > > > should
> > >> > > > > > > > > > be
> > >> > > > > > > > > > > > back in business in August, at which point I can
> > >> > dedicate
> > >> > > > > > several
> > >> > > > > > > > > > hours a
> > >> > > > > > > > > > > > week. Until then I'll be happy to watch closely
> > and
> > >> > even
> > >> > > > > > > coordinate
> > >> > > > > > > > > the
> > >> > > > > > > > > > > > work to some extent.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > >> > > > > > > > > marcoslimagon@gmail.com
> > >> > > > > > > > > > > > >wrote:
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > > It really sounds good to me, this is a kick
> > start
> > >> > =). I
> > >> > > > > > haven't
> > >> > > > > > > > > > > > contributed
> > >> > > > > > > > > > > > > anything
> > >> > > > > > > > > > > > > yet, but I would like to help you all to get
> > this
> > >> job
> > >> > > > done.
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > I know that there is a high commitment for
> keep
> > >> the
> > >> > > > > > > > > > retrocompatibility
> > >> > > > > > > > > > > on
> > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes
> > >> every
> > >> > > > > release?
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable version
> > >> from a
> > >> > > > > Lucene
> > >> > > > > > > > > version,
> > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> changes
> > >> > every
> > >> > > > > stable
> > >> > > > > > > > > release
> > >> > > > > > > > > > > (or
> > >> > > > > > > > > > > > > keep most of its source-code), we could
> compare
> > >> the
> > >> > > > > versions,
> > >> > > > > > > > check
> > >> > > > > > > > > > the
> > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > Again, I
> > >> > > > haven't
> > >> > > > > > > > > > contributed
> > >> > > > > > > > > > > > with
> > >> > > > > > > > > > > > > yet, so I don't know how it is (just an idea).
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > What's your approach for implement simple
> > >> performance
> > >> > > > > > > > improvements
> > >> > > > > > > > > > > > (without
> > >> > > > > > > > > > > > > adding references or changing methods
> > signatures)?
> > >> > Does
> > >> > > > it
> > >> > > > > > > could
> > >> > > > > > > > be
> > >> > > > > > > > > > > done,
> > >> > > > > > > > > > > > > or "follow the java version only"?
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> > >> haven't
> > >> > > > > > > contributed
> > >> > > > > > > > > > > anything
> > >> > > > > > > > > > > > > > yet, although I will definitely help with
> the
> > >> 4.x
> > >> > > work
> > >> > > > > as I
> > >> > > > > > > > have
> > >> > > > > > > > > a
> > >> > > > > > > > > > > > vested
> > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> think
> > >> > there
> > >> > > > > should
> > >> > > > > > > be
> > >> > > > > > > > > one
> > >> > > > > > > > > > > > person
> > >> > > > > > > > > > > > > > (or perhaps two) guiding what the structure
> > and
> > >> > > > workflow
> > >> > > > > > will
> > >> > > > > > > > > look
> > >> > > > > > > > > > > like
> > >> > > > > > > > > > > > > to
> > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
> > >> > starting
> > >> > > > from
> > >> > > > > > > > scratch
> > >> > > > > > > > > > as
> > >> > > > > > > > > > > a
> > >> > > > > > > > > > > > > > fresh port, that person should set up the
> > >> project,
> > >> > > get
> > >> > > > > > > > everything
> > >> > > > > > > > > > > going
> > >> > > > > > > > > > > > > in
> > >> > > > > > > > > > > > > > source control, create the folder structure,
> > >> maybe
> > >> > > stub
> > >> > > > > out
> > >> > > > > > > > some
> > >> > > > > > > > > > > > classes,
> > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > >> interested
> > >> > > in
> > >> > > > > > > > > > contributing,
> > >> > > > > > > > > > > > > > perhaps by namespace.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > I like the idea of throwing the java code in
> > >> there
> > >> > so
> > >> > > > > it's
> > >> > > > > > > easy
> > >> > > > > > > > > to
> > >> > > > > > > > > > > > > > reference.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > >> > > > > > > Lucene.Net.Analysis,
> > >> > > > > > > > > or
> > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are
> > >> just
> > >> > the
> > >> > > > > ones
> > >> > > > > > > I'm
> > >> > > > > > > > > most
> > >> > > > > > > > > > > > > > familiar with the inner workings. Tell me
> what
> > >> to
> > >> > do
> > >> > > > and
> > >> > > > > > I'll
> > >> > > > > > > > get
> > >> > > > > > > > > > > > started
> > >> > > > > > > > > > > > > > on my fork.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > Paul Irwin
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > Nasser
> > >> <
> > >> > > > > > > > > > > geobmx540@hotmail.com
> > >> > > > > > > > > > > > > > >wrote:
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > > Hey guys -
> > >> > > > > > > > > > > > > > > I know I've been MIA a little while. We
> > have a
> > >> > > board
> > >> > > > > > report
> > >> > > > > > > > due
> > >> > > > > > > > > > > soon
> > >> > > > > > > > > > > > -
> > >> > > > > > > > > > > > > I
> > >> > > > > > > > > > > > > > > think it prudent that we advise them that
> we
> > >> seem
> > >> > > to
> > >> > > > > have
> > >> > > > > > > > > stalled
> > >> > > > > > > > > > > > > > somewhat.
> > >> > > > > > > > > > > > > > > We've got a few low hanging items out of
> of
> > >> jira
> > >> > > and
> > >> > > > > have
> > >> > > > > > > > been
> > >> > > > > > > > > > > > > responsive
> > >> > > > > > > > > > > > > > > on the mailing list to community
> questions,
> > >> but I
> > >> > > > don't
> > >> > > > > > > think
> > >> > > > > > > > > > we've
> > >> > > > > > > > > > > > > done
> > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and start
> us
> > >> back
> > >> > > up
> > >> > > > > > moving
> > >> > > > > > > > > > > forward.
> > >> > > > > > > > > > > > > What
> > >> > > > > > > > > > > > > > > is the best way to accomplish this? If we
> > took
> > >> > the
> > >> > > > java
> > >> > > > > > > > lucene
> > >> > > > > > > > > > 4.0
> > >> > > > > > > > > > > > code
> > >> > > > > > > > > > > > > > and
> > >> > > > > > > > > > > > > > > committed that java to our branch and then
> > >> just
> > >> > let
> > >> > > > > > people
> > >> > > > > > > > pull
> > >> > > > > > > > > > > that
> > >> > > > > > > > > > > > > down
> > >> > > > > > > > > > > > > > > and being changing / modifying is that one
> > >> way to
> > >> > > > maybe
> > >> > > > > > > make
> > >> > > > > > > > > some
> > >> > > > > > > > > > > > > forward
> > >> > > > > > > > > > > > > > > progress?
> > >> > > > > > > > > > > > > > > ~P
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > Marcos Lima
> > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > --
> > >> > > > Marcos Lima
> > >> > > > Software Developer/Tech Lead
> > >> > > > marcoslimagon@gmail.com
> > >> > > > tel: +55 (19) 9798-9335
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> --
> > >> Marcos Lima
> > >> Software Developer/Tech Lead
> > >> marcoslimagon@gmail.com
> > >> tel: +55 (19) 9798-9335
> > >>
> > >
> > >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
This has been ported in my fork/branch, but has not been tested. Please
test away!
Also, I got the classic QueryParser from 4.3 to compile in the new
Contrib.QueryParsers DLL, but it gets stuck in an infinite loop when using
the default field and exceptions when specifying a field in the query.
Anyone with experience with scanners/lexers should debug into this and take
a look. I have a feeling the bug is in the complex scanner code of
QueryParser or QueryParserTokenManager.
On Thu, Aug 8, 2013 at 8:53 PM, Michael Mitiaguin <
mitiaguinm@optusnet.com.au> wrote:
> Paul,
>
> I am greatly interested in trying Lucene 4.0 FuzzyQuery
>
> http://blog.mikemccandless.**com/2011/03/lucenes-**
> fuzzyquery-is-100-times-**faster.html<http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html>
> Any plans to port this part ?
>
>
> On 8/9/2013 5:31 AM, Paul Irwin wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers
>> DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/**
>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Athrun Saga was working on the TestFramework assembly this weekend, he
might be able to give an update there. I had just started porting some of
it but didn't finish. I haven't finished any test assemblies. He brought up
the point about the tests assembly missing a reference to testframework as
well and was going to correct that in a pull request.
I mainly have been using Lucene.Net.All, again without running any tests.
And I only build the projects that will compile, which right now is Core,
Analyzers (since i've excluded the old ones), and QueryParser (which is
incomplete, only the classic queryparser is ported).
While my trivial "hello lucene" app worked fine with the new code, I hit an
"already finished" exception in the FST code when I tried using my domain's
indexer code. I'm going to try to isolate this to a failing test case and
see if some of the Java guys that worked on the FST code could help out, as
I have no clue what's going on there.
I am throwing a little conference this weekend (
http://www.codeonthebeach.com/) so I will be pretty preoccupied this week,
next week I should be able to hack more on it.
Paul
On Mon, Aug 12, 2013 at 2:36 AM, Simon Svensson <si...@devhost.se> wrote:
> Hi,
>
> I took a look into porting the Hunspell part of Contrib.Analyzers (mostly
> because I initiated the port from java some time ago) but ran into some
> problems.
>
> 1) BaseTokenStreamTestCase (in Lucene.Net.TestFramework) references a
> missing RandomIndexWriter, and wont compile. Is this something that's
> missed in a commit, or something we need to port?
>
> 2) What solution file are you using to open everything, including the test
> projects? Lucene.Net.All does not contain any test projects, and the
> Contrib.All.Tests is missing a referece to Lucene.Net.TestFramework.
>
> // Simon
>
>
> On 2013-08-09 15:08, Paul Irwin wrote:
>
>> We mostly ported the code manually, copying and pasting the java method by
>> method and fixing the differences, since C# and Java are so similar. That
>> allowed us to see areas where using C# conventions would be better, such
>> as
>> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
>> However, there were a few bits of code that were too intense to port
>> manually, such as the BulkOperationPacked* classes under Util.Packed, and
>> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
>> quick one-off C# app in each case to do some regexes and whatnot to make
>> it
>> port easier.
>>
>> If you speak a language other than english, porting that language's
>> Analyzer classes would be helpful. Also we didn't port the javadoc
>> comments
>> as that was tedious, so those need to be done, and the unit tests need to
>> be ported. I'm currently trying to figure out why QueryParser didn't port
>> successfully. If I can get that to work, I'll probably move on to
>> EnglishAnalyzer.
>>
>> Paul
>>
>> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>>
>> Hi,
>>>
>>> I'm unsure how the porting is done. Are you using any tools to convert
>>> java to c#, or is it done manually by just showing both code
>>> side-by-side?
>>>
>>> I can squeeze out a few coding hours this weekend, where do you want me
>>> to
>>> start?
>>>
>>> // Simon
>>>
>>>
>>> On 2013-08-08 21:31, Paul Irwin wrote:
>>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>>> compatibility thanks to the help of my colleagues. We just need to round
>>>> out the contrib modules, unit tests, and documentation as a community
>>>> and
>>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>>> 3.0.3
>>>> was packaged in December 2010!
>>>>
>>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>>> SimpleAnalyzer,
>>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>>> (where they now live in Lucene java, they were moved from core) and
>>>> their
>>>> associated filters and tokenizers. I've briefly tested each and they
>>>> seem
>>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>>> language analyzers until we can forward-port them. So now the Analyzers
>>>> DLL
>>>> compiles with those analyzers only. Also, I fixed the bug that was
>>>> causing
>>>> NumericRangeQuery to not work.
>>>>
>>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>>> moved
>>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>>> test a pretty common real-world use case (the prototypical "hello
>>>> lucene"
>>>> tutorial). After that, it might be worth forward-porting what we have so
>>>> far to 4.4 and use that as the latest point to finish out the port. The
>>>> changes shouldn't be too dramatic to core from what I can tell.
>>>>
>>>> My fork/branch: https://github.com/paulirwin/****<https://github.com/paulirwin/**>
>>>> lucene.net/tree/lucene_4_3_0<h**ttps://github.com/paulirwin/**
>>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>> >
>>>>
>>>>
>>>> I'll keep updating as I go, but if anyone wants to jump in, there's not
>>>> a
>>>> better time than now...
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>> that
>>>>
>>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>>> needed
>>>>> to
>>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces...
>>>>> duh.
>>>>>
>>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>>> can
>>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>>> on
>>>>> to
>>>>> find out why NumericRangeQuery isn't working.
>>>>>
>>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>>> spending time hunting down my mistake!
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>> Java's
>>>>>
>>>>>> byte being signed is a pain.
>>>>>>
>>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>>> tried
>>>>>> a
>>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>>> it
>>>>>> didn't find any results that way either. So right now only
>>>>>> MatchAllDocsQuery seems to work.
>>>>>>
>>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>>> look
>>>>>> into it, let me know.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>> I realized after I sent that email last night that I could do as you
>>>>>>
>>>>>>> described. When you've been debugging through
>>>>>>> CorruptedIndexExceptions, you
>>>>>>> get a little bit of tunnel vision... haha
>>>>>>>
>>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>>> .ToString()'ing
>>>>>>> the matching documents prints the fields to the console, so it's
>>>>>>> loading in
>>>>>>> the stored fields data correctly.
>>>>>>>
>>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>>> that
>>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>>> operations
>>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>>> that
>>>>>>> would be great. Here's example index writing and then reading code
>>>>>>> (also
>>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>>> https://gist.github.com/****anonymous/6174164<https://gist.github.com/**anonymous/6174164>
>>>>>>> <https://**gist.github.com/anonymous/**6174164<https://gist.github.com/anonymous/6174164>
>>>>>>> >
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Lucene 4.0
Posted by Simon Svensson <si...@devhost.se>.
Hi,
I took a look into porting the Hunspell part of Contrib.Analyzers
(mostly because I initiated the port from java some time ago) but ran
into some problems.
1) BaseTokenStreamTestCase (in Lucene.Net.TestFramework) references a
missing RandomIndexWriter, and wont compile. Is this something that's
missed in a commit, or something we need to port?
2) What solution file are you using to open everything, including the
test projects? Lucene.Net.All does not contain any test projects, and
the Contrib.All.Tests is missing a referece to Lucene.Net.TestFramework.
// Simon
On 2013-08-09 15:08, Paul Irwin wrote:
> We mostly ported the code manually, copying and pasting the java method by
> method and fixing the differences, since C# and Java are so similar. That
> allowed us to see areas where using C# conventions would be better, such as
> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
> However, there were a few bits of code that were too intense to port
> manually, such as the BulkOperationPacked* classes under Util.Packed, and
> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
> quick one-off C# app in each case to do some regexes and whatnot to make it
> port easier.
>
> If you speak a language other than english, porting that language's
> Analyzer classes would be helpful. Also we didn't port the javadoc comments
> as that was tedious, so those need to be done, and the unit tests need to
> be ported. I'm currently trying to figure out why QueryParser didn't port
> successfully. If I can get that to work, I'll probably move on to
> EnglishAnalyzer.
>
> Paul
>
> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>
>> Hi,
>>
>> I'm unsure how the porting is done. Are you using any tools to convert
>> java to c#, or is it done manually by just showing both code side-by-side?
>>
>> I can squeeze out a few coding hours this weekend, where do you want me to
>> start?
>>
>> // Simon
>>
>>
>> On 2013-08-08 21:31, Paul Irwin wrote:
>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>> compatibility thanks to the help of my colleagues. We just need to round
>>> out the contrib modules, unit tests, and documentation as a community and
>>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>>> was packaged in December 2010!
>>>
>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>> (where they now live in Lucene java, they were moved from core) and their
>>> associated filters and tokenizers. I've briefly tested each and they seem
>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>> language analyzers until we can forward-port them. So now the Analyzers
>>> DLL
>>> compiles with those analyzers only. Also, I fixed the bug that was causing
>>> NumericRangeQuery to not work.
>>>
>>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>> test a pretty common real-world use case (the prototypical "hello lucene"
>>> tutorial). After that, it might be worth forward-porting what we have so
>>> far to 4.4 and use that as the latest point to finish out the port. The
>>> changes shouldn't be too dramatic to core from what I can tell.
>>>
>>> My fork/branch: https://github.com/paulirwin/**
>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>
>>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>>> better time than now...
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>>>> to
>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>>
>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>>>> to
>>>> find out why NumericRangeQuery isn't working.
>>>>
>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>> spending time hunting down my mistake!
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>>> byte being signed is a pain.
>>>>>
>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>> results. It doesn't find any terms when scanning for them. I also tried
>>>>> a
>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>>> didn't find any results that way either. So right now only
>>>>> MatchAllDocsQuery seems to work.
>>>>>
>>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>>> into it, let me know.
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>>> described. When you've been debugging through
>>>>>> CorruptedIndexExceptions, you
>>>>>> get a little bit of tunnel vision... haha
>>>>>>
>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>> .ToString()'ing
>>>>>> the matching documents prints the fields to the console, so it's
>>>>>> loading in
>>>>>> the stored fields data correctly.
>>>>>>
>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>> that
>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>> operations
>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>>> would be great. Here's example index writing and then reading code
>>>>>> (also
>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
While it works for a simple "hello lucene" index for me, I tried using it
with my existing domain indexer app and I get an exception saying "already
finished" inside FST.cs when IndexWriter.Commit is called. I really don't
understand when debugging through it what the FSTs are doing exactly... If
anyone understands this concept and can help hunt down the bug, that would
be great. Or let me know if you don't encounter the same exception.
http://blog.mikemccandless.com/2010/12/using-finite-state-transducers-in.html
On Fri, Aug 9, 2013 at 2:39 PM, Paul Irwin <pi...@feature23.com> wrote:
> QueryParser is now working. Java's octal literals and that Reader.Read
> returns -1 at EOF bit me. It's now working, so the prototypical "hello
> lucene" now works in Lucene.net 4.3.1. Please grab it and let me know if
> you have any issues.
>
>
> On Fri, Aug 9, 2013 at 9:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> We mostly ported the code manually, copying and pasting the java method
>> by method and fixing the differences, since C# and Java are so similar.
>> That allowed us to see areas where using C# conventions would be better,
>> such as properties and mild LINQ to Objects, and usage of IEnumerable<T>,
>> etc.. However, there were a few bits of code that were too intense to port
>> manually, such as the BulkOperationPacked* classes under Util.Packed, and
>> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
>> quick one-off C# app in each case to do some regexes and whatnot to make it
>> port easier.
>>
>> If you speak a language other than english, porting that language's
>> Analyzer classes would be helpful. Also we didn't port the javadoc comments
>> as that was tedious, so those need to be done, and the unit tests need to
>> be ported. I'm currently trying to figure out why QueryParser didn't port
>> successfully. If I can get that to work, I'll probably move on to
>> EnglishAnalyzer.
>>
>> Paul
>>
>>
>> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>>
>>> Hi,
>>>
>>> I'm unsure how the porting is done. Are you using any tools to convert
>>> java to c#, or is it done manually by just showing both code side-by-side?
>>>
>>> I can squeeze out a few coding hours this weekend, where do you want me
>>> to start?
>>>
>>> // Simon
>>>
>>>
>>> On 2013-08-08 21:31, Paul Irwin wrote:
>>>
>>>> Is this mailing list dead?! If anyone is interested in releasing an
>>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>>> compatibility thanks to the help of my colleagues. We just need to round
>>>> out the contrib modules, unit tests, and documentation as a community
>>>> and
>>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>>> 3.0.3
>>>> was packaged in December 2010!
>>>>
>>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>>> SimpleAnalyzer,
>>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>>> (where they now live in Lucene java, they were moved from core) and
>>>> their
>>>> associated filters and tokenizers. I've briefly tested each and they
>>>> seem
>>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>>> language analyzers until we can forward-port them. So now the Analyzers
>>>> DLL
>>>> compiles with those analyzers only. Also, I fixed the bug that was
>>>> causing
>>>> NumericRangeQuery to not work.
>>>>
>>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>>> moved
>>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>>> test a pretty common real-world use case (the prototypical "hello
>>>> lucene"
>>>> tutorial). After that, it might be worth forward-porting what we have so
>>>> far to 4.4 and use that as the latest point to finish out the port. The
>>>> changes shouldn't be too dramatic to core from what I can tell.
>>>>
>>>> My fork/branch: https://github.com/paulirwin/**
>>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>>
>>>> I'll keep updating as I go, but if anyone wants to jump in, there's not
>>>> a
>>>> better time than now...
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>>> that
>>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>>> needed to
>>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces...
>>>>> duh.
>>>>>
>>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>>> can
>>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>>> on to
>>>>> find out why NumericRangeQuery isn't working.
>>>>>
>>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>>> spending time hunting down my mistake!
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>>> Java's
>>>>>> byte being signed is a pain.
>>>>>>
>>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>>> tried a
>>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>>> it
>>>>>> didn't find any results that way either. So right now only
>>>>>> MatchAllDocsQuery seems to work.
>>>>>>
>>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>>> look
>>>>>> into it, let me know.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>> I realized after I sent that email last night that I could do as you
>>>>>>> described. When you've been debugging through
>>>>>>> CorruptedIndexExceptions, you
>>>>>>> get a little bit of tunnel vision... haha
>>>>>>>
>>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>>> .ToString()'ing
>>>>>>> the matching documents prints the fields to the console, so it's
>>>>>>> loading in
>>>>>>> the stored fields data correctly.
>>>>>>>
>>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>>> that
>>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>>> operations
>>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>>> that
>>>>>>> would be great. Here's example index writing and then reading code
>>>>>>> (also
>>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
QueryParser is now working. Java's octal literals and that Reader.Read
returns -1 at EOF bit me. It's now working, so the prototypical "hello
lucene" now works in Lucene.net 4.3.1. Please grab it and let me know if
you have any issues.
On Fri, Aug 9, 2013 at 9:08 AM, Paul Irwin <pi...@feature23.com> wrote:
> We mostly ported the code manually, copying and pasting the java method by
> method and fixing the differences, since C# and Java are so similar. That
> allowed us to see areas where using C# conventions would be better, such as
> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
> However, there were a few bits of code that were too intense to port
> manually, such as the BulkOperationPacked* classes under Util.Packed, and
> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
> quick one-off C# app in each case to do some regexes and whatnot to make it
> port easier.
>
> If you speak a language other than english, porting that language's
> Analyzer classes would be helpful. Also we didn't port the javadoc comments
> as that was tedious, so those need to be done, and the unit tests need to
> be ported. I'm currently trying to figure out why QueryParser didn't port
> successfully. If I can get that to work, I'll probably move on to
> EnglishAnalyzer.
>
> Paul
>
>
> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>
>> Hi,
>>
>> I'm unsure how the porting is done. Are you using any tools to convert
>> java to c#, or is it done manually by just showing both code side-by-side?
>>
>> I can squeeze out a few coding hours this weekend, where do you want me
>> to start?
>>
>> // Simon
>>
>>
>> On 2013-08-08 21:31, Paul Irwin wrote:
>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>> compatibility thanks to the help of my colleagues. We just need to round
>>> out the contrib modules, unit tests, and documentation as a community and
>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>> 3.0.3
>>> was packaged in December 2010!
>>>
>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>> SimpleAnalyzer,
>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>> (where they now live in Lucene java, they were moved from core) and their
>>> associated filters and tokenizers. I've briefly tested each and they seem
>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>> language analyzers until we can forward-port them. So now the Analyzers
>>> DLL
>>> compiles with those analyzers only. Also, I fixed the bug that was
>>> causing
>>> NumericRangeQuery to not work.
>>>
>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>> moved
>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>> test a pretty common real-world use case (the prototypical "hello lucene"
>>> tutorial). After that, it might be worth forward-porting what we have so
>>> far to 4.4 and use that as the latest point to finish out the port. The
>>> changes shouldn't be too dramatic to core from what I can tell.
>>>
>>> My fork/branch: https://github.com/paulirwin/**
>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>
>>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>>> better time than now...
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>> wrote:
>>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>> that
>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>> needed to
>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>>
>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>> can
>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>> on to
>>>> find out why NumericRangeQuery isn't working.
>>>>
>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>> spending time hunting down my mistake!
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>> Java's
>>>>> byte being signed is a pain.
>>>>>
>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>> tried a
>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>> it
>>>>> didn't find any results that way either. So right now only
>>>>> MatchAllDocsQuery seems to work.
>>>>>
>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>> look
>>>>> into it, let me know.
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>>> described. When you've been debugging through
>>>>>> CorruptedIndexExceptions, you
>>>>>> get a little bit of tunnel vision... haha
>>>>>>
>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>> .ToString()'ing
>>>>>> the matching documents prints the fields to the console, so it's
>>>>>> loading in
>>>>>> the stored fields data correctly.
>>>>>>
>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>> that
>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>> operations
>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>> that
>>>>>> would be great. Here's example index writing and then reading code
>>>>>> (also
>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
We mostly ported the code manually, copying and pasting the java method by
method and fixing the differences, since C# and Java are so similar. That
allowed us to see areas where using C# conventions would be better, such as
properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
However, there were a few bits of code that were too intense to port
manually, such as the BulkOperationPacked* classes under Util.Packed, and
the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
quick one-off C# app in each case to do some regexes and whatnot to make it
port easier.
If you speak a language other than english, porting that language's
Analyzer classes would be helpful. Also we didn't port the javadoc comments
as that was tedious, so those need to be done, and the unit tests need to
be ported. I'm currently trying to figure out why QueryParser didn't port
successfully. If I can get that to work, I'll probably move on to
EnglishAnalyzer.
Paul
On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
> Hi,
>
> I'm unsure how the porting is done. Are you using any tools to convert
> java to c#, or is it done manually by just showing both code side-by-side?
>
> I can squeeze out a few coding hours this weekend, where do you want me to
> start?
>
> // Simon
>
>
> On 2013-08-08 21:31, Paul Irwin wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers
>> DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/**
>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>>> to
>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>
>>> Now it works after re-indexing with a quick, dirty implementation of
>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>>> to
>>> find out why NumericRangeQuery isn't working.
>>>
>>> Sorry for the blast of emails, but I wanted to prevent people from
>>> spending time hunting down my mistake!
>>>
>>>
>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>> wrote:
>>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>> byte being signed is a pain.
>>>>
>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>> results. It doesn't find any terms when scanning for them. I also tried
>>>> a
>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>> didn't find any results that way either. So right now only
>>>> MatchAllDocsQuery seems to work.
>>>>
>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>> into it, let me know.
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I realized after I sent that email last night that I could do as you
>>>>> described. When you've been debugging through
>>>>> CorruptedIndexExceptions, you
>>>>> get a little bit of tunnel vision... haha
>>>>>
>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>> .ToString()'ing
>>>>> the matching documents prints the fields to the console, so it's
>>>>> loading in
>>>>> the stored fields data correctly.
>>>>>
>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>> that
>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>> operations
>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>> would be great. Here's example index writing and then reading code
>>>>> (also
>>>>> included is a quick port of KeywordAnalyzer):
>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>
Re: Lucene 4.0
Posted by Simon Svensson <si...@devhost.se>.
Hi,
I'm unsure how the porting is done. Are you using any tools to convert
java to c#, or is it done manually by just showing both code side-by-side?
I can squeeze out a few coding hours this weekend, where do you want me
to start?
// Simon
On 2013-08-08 21:31, Paul Irwin wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>>> the matching documents prints the fields to the console, so it's loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look that
>>>> would be great. Here's example index writing and then reading code (also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
RE: Lucene 4.0
Posted by Prescott Nasser <ge...@hotmail.com>.
Hey Paul -
If you can help us out by filling out the ICLA (http://www.apache.org/licenses/icla.txt). This will allow us to pull this into the official repo.
I also can't thank you enough for taking the initiative to being the port - hopefully we can all pitch in and finish it.
~Prescott
> Date: Thu, 8 Aug 2013 21:02:00 -0400
> Subject: Re: Lucene 4.0
> From: pirwin@feature23.com
> To: dev@lucenenet.apache.org
>
> This has been ported in my fork/branch, but has not been tested. Please
> test away!
>
> Also, I got the classic QueryParser from 4.3 to compile in the new
> Contrib.QueryParsers DLL, but it gets stuck in an infinite loop when using
> the default field and exceptions when specifying a field in the query.
> Anyone with experience with scanners/lexers should debug into this and take
> a look. I have a feeling the bug is in the complex scanner code of
> QueryParser or QueryParserTokenManager.
>
>
> On Thu, Aug 8, 2013 at 8:53 PM, Michael Mitiaguin <
> mitiaguinm@optusnet.com.au> wrote:
>
> > Paul,
> >
> > I am greatly interested in trying Lucene 4.0 FuzzyQuery
> >
> > http://blog.mikemccandless.**com/2011/03/lucenes-**
> > fuzzyquery-is-100-times-**faster.html<http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html>
> > Any plans to port this part ?
> >
> >
> > On 8/9/2013 5:31 AM, Paul Irwin wrote:
> >
> >> Is this mailing list dead?! If anyone is interested in releasing an
> >> up-to-date build of Lucene.net, please write back! If you didn't read my
> >> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> >> compatibility thanks to the help of my colleagues. We just need to round
> >> out the contrib modules, unit tests, and documentation as a community and
> >> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> >> was packaged in December 2010!
> >>
> >> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> >> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> >> (where they now live in Lucene java, they were moved from core) and their
> >> associated filters and tokenizers. I've briefly tested each and they seem
> >> to work correctly. I've purposefully "Exclude[d] from Project" the other
> >> language analyzers until we can forward-port them. So now the Analyzers
> >> DLL
> >> compiles with those analyzers only. Also, I fixed the bug that was causing
> >> NumericRangeQuery to not work.
> >>
> >> Next on my list is the QueryParsers contrib library (QueryParser was moved
> >> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> >> test a pretty common real-world use case (the prototypical "hello lucene"
> >> tutorial). After that, it might be worth forward-porting what we have so
> >> far to 4.4 and use that as the latest point to finish out the port. The
> >> changes shouldn't be too dramatic to core from what I can tell.
> >>
> >> My fork/branch: https://github.com/paulirwin/**
> >> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
> >>
> >> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> >> better time than now...
> >>
> >>
> >>
> >>
> >>
> >
Re: Lucene 4.0
Posted by Michael Mitiaguin <mi...@optusnet.com.au>.
Paul,
I am greatly interested in trying Lucene 4.0 FuzzyQuery
http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html
Any plans to port this part ?
On 8/9/2013 5:31 AM, Paul Irwin wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Athrun,
You can do what I did before you become an "official" contributor, which is
to fork the lucene.net repo on Github at
https://github.com/apache/lucene.net, or if you want to work off of my
latest changes before it's pulled into the main repo, you can pull from
here: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
If you speak Chinese, you could jump in and help port the ChineseAnalyzer
in Contrib.Analyzers. When referencing the Java source, we're currently
referencing the code in the lucene_solr_4_3 branch as when we started, 4.4
wasn't out yet. Don't reference trunk/master, as that's where 5.0 dev is
taking place if i'm not mistaken.
On Fri, Aug 9, 2013 at 12:08 AM, 许鹏 <xu...@188.com> wrote:
> Hi Paul,
>
>
> I am a developer from China, I currently using Solr 4.3.0 to construct our
> own
> data system for search and analysis. I am very interested in the work that
> porting
> Lucene java 4.3.1, and I want to join this team to work on this. But I
> have never
> been involved in open source projects, Can you give me some suggestion to
> join
> the team and start contributing.
> Additional, I am not good at English writing, but reading is ok. Also, I
> am now learning English,
> I believe it will be more smooth communication.
>
>
>
>
> Athrun Saga
> 8/9/2013
>
>
>
>
>
>
> At 2013-08-09 03:31:47,"Paul Irwin" <pi...@feature23.com> wrote:
>
> >Is this mailing list dead?! If anyone is interested in releasing an
> >up-to-date build of Lucene.net, please write back! If you didn't read my
> >other messages, I have Lucene.net Core working with Lucene java 4.3.1
> >compatibility thanks to the help of my colleagues. We just need to round
> >out the contrib modules, unit tests, and documentation as a community and
> >we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> >was packaged in December 2010!
> >
> >I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> >ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> >(where they now live in Lucene java, they were moved from core) and their
> >associated filters and tokenizers. I've briefly tested each and they seem
> >to work correctly. I've purposefully "Exclude[d] from Project" the other
> >language analyzers until we can forward-port them. So now the Analyzers
> DLL
> >compiles with those analyzers only. Also, I fixed the bug that was causing
> >NumericRangeQuery to not work.
> >
> >Next on my list is the QueryParsers contrib library (QueryParser was moved
> >out of Lucene java core) so that, combined with StandardAnalyzer, we can
> >test a pretty common real-world use case (the prototypical "hello lucene"
> >tutorial). After that, it might be worth forward-porting what we have so
> >far to 4.4 and use that as the latest point to finish out the port. The
> >changes shouldn't be too dramatic to core from what I can tell.
> >
> >My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> >I'll keep updating as I go, but if anyone wants to jump in, there's not a
> >better time than now...
> >
> >
> >
> >On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
> >
> >> I made a dumb mistake... I have worked with StandardAnalyzer so long
> that
> >> I forgot that KeywordAnalyzer is not what I needed to be using, I
> needed to
> >> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
> >>
> >> Now it works after re-indexing with a quick, dirty implementation of
> >> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
> can
> >> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
> on to
> >> find out why NumericRangeQuery isn't working.
> >>
> >> Sorry for the blast of emails, but I wanted to prevent people from
> >> spending time hunting down my mistake!
> >>
> >>
> >> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>
> >>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
> Java's
> >>> byte being signed is a pain.
> >>>
> >>> Now there's no exception doing a TermQuery, but I also don't get any
> >>> results. It doesn't find any terms when scanning for them. I also
> tried a
> >>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
> it
> >>> didn't find any results that way either. So right now only
> >>> MatchAllDocsQuery seems to work.
> >>>
> >>> If anyone would like to do a Google Hangout or anything sometime to
> look
> >>> into it, let me know.
> >>>
> >>>
> >>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>>
> >>>> I realized after I sent that email last night that I could do as you
> >>>> described. When you've been debugging through
> CorruptedIndexExceptions, you
> >>>> get a little bit of tunnel vision... haha
> >>>>
> >>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> >>>> IndexSearcher and TopScoreDocsCollector and get hits! And
> .ToString()'ing
> >>>> the matching documents prints the fields to the console, so it's
> loading in
> >>>> the stored fields data correctly.
> >>>>
> >>>> I tried doing a TermQuery and now I get a "read past EOF" exception
> that
> >>>> I can't figure out. There's a whole bunch of buffered byte array
> operations
> >>>> going on and I can't determine where the issue came from. I'll keep
> >>>> looking, but if someone could grab my fork/branch and help me look
> that
> >>>> would be great. Here's example index writing and then reading code
> (also
> >>>> included is a quick port of KeywordAnalyzer):
> >>>> https://gist.github.com/anonymous/6174164
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
> itamar@code972.com>wrote:
> >>>>
> >>>>> Great
> >>>>>
> >>>>> You can build you Query objects on your own to execute a search, you
> >>>>> don't
> >>>>> actually have to use QueryParser for that
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
> >>>>> wrote:
> >>>>>
> >>>>> > Hey all, sorry it's been a little while, but I wanted to let you
> know
> >>>>> that
> >>>>> > although I took a few weeks off from it, I now have a 4.3.1
> equivalent
> >>>>> > Lucene.net core building and able to write a simple index in Lucene
> >>>>> 4.2
> >>>>> > codec and read in things like the number of documents and whatnot.
> >>>>> Since
> >>>>> > QueryParser has been moved to a separate module in Lucene Java
> 4.x, I
> >>>>> > haven't ported that yet so I haven't done a real search, and I only
> >>>>> built
> >>>>> > the index using a quick port of KeywordAnalyzer which all those
> >>>>> analyzers
> >>>>> > have also moved to another module. But this is definitely good
> >>>>> progress and
> >>>>> > should be a launch point for finishing a 4.3/4.4 port.
> >>>>> >
> >>>>> > You can see my fork/branch here:
> >>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
> >>>>> like I
> >>>>> > said, only core builds now, no modules/tests build, so only open
> the
> >>>>> > Lucene.Net.Core.sln)
> >>>>> >
> >>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
> >>>>> the
> >>>>> > community into finishing the 4.3/4.4 port. Let me know if you have
> any
> >>>>> > questions, thanks!
> >>>>> >
> >>>>> >
> >>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
> >>>>> itamar@code972.com
> >>>>> > >wrote:
> >>>>> >
> >>>>> > > Paul, that's awesome. I will need some more time to go over this
> >>>>> thread
> >>>>> > and
> >>>>> > > your work to give actual feedback, SUPER busy at the moment
> >>>>> > >
> >>>>> > >
> >>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <
> pirwin@feature23.com>
> >>>>> > wrote:
> >>>>> > >
> >>>>> > > > All,
> >>>>> > > >
> >>>>> > > > My colleagues and I have made good progress on porting Lucene
> >>>>> 4.3's
> >>>>> > core
> >>>>> > > > library before, during, and after the hackathon last week. We
> now
> >>>>> only
> >>>>> > > have
> >>>>> > > > some remaining items in Search, Index, and Codecs namespaces
> >>>>> (plus a
> >>>>> > few
> >>>>> > > > other minor ones here and there). I expect to be done by the
> end
> >>>>> of the
> >>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> >>>>> Packed),
> >>>>> > > and
> >>>>> > > > the root Codecs and Codecs.PerField namespaces are all now
> "done".
> >>>>> > > >
> >>>>> > > > Again, my goal is to only get a buildable, experimental build
> of
> >>>>> > > Lucene.net
> >>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> >>>>> porting
> >>>>> > > new
> >>>>> > > > javadoc comments or unit tests right now, due to the vast
> amount
> >>>>> of
> >>>>> > code
> >>>>> > > > that needs to be written just to get it to compile. If this
> work
> >>>>> ends
> >>>>> > up
> >>>>> > > > becoming a pull request, great, otherwise it should help
> >>>>> accelerate a
> >>>>> > > port
> >>>>> > > > of 4.3.x since the bulk of the work on core will already be
> done
> >>>>> and
> >>>>> > > > contributors can use it as a reference. And again, we're taking
> >>>>> the
> >>>>> > > > pragmatic approach of porting class-by-class,
> >>>>> namespace-by-namespace,
> >>>>> > > with
> >>>>> > > > the understanding that until we're done the project won't
> build.
> >>>>> > > >
> >>>>> > > > Once complete, I also will work on updating the Analyzers
> contrib
> >>>>> > module
> >>>>> > > > and porting the QueryParsers contrib module, which I feel
> should
> >>>>> be
> >>>>> > > > included in the core NuGet package for Lucene.net as the core
> >>>>> library
> >>>>> > is
> >>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
> >>>>> without
> >>>>> > > them.
> >>>>> > > > You can check out the code on my fork/branch here:
> >>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>>> > > >
> >>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> >>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
> >>>>> For the
> >>>>> > > MMap
> >>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> >>>>> > > > MemoryMappedFile support which should emulate the Java nio
> stuff
> >>>>> pretty
> >>>>> > > > well, but required some creative shuffling of the code to make
> it
> >>>>> work
> >>>>> > > due
> >>>>> > > > to lifecycle management.
> >>>>> > > >
> >>>>> > > > I'll update again this weekend or next week, when we should
> have
> >>>>> > wrapped
> >>>>> > > up
> >>>>> > > > most of the main hacking on porting the core code.
> >>>>> > > >
> >>>>> > > > Paul
> >>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
> pirwin@feature23.com
> >>>>> >
> >>>>> > > wrote:
> >>>>> > > >
> >>>>> > > > > Marcos,
> >>>>> > > > >
> >>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java
> code
> >>>>> is
> >>>>> > only
> >>>>> > > on
> >>>>> > > > > SVN here, before the lucene and solr projects were bundled
> >>>>> together:
> >>>>> > > > >
> >>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >>>>> > > > >
> >>>>> > > > > The SVN for 4.3 java is here:
> >>>>> > > > >
> >>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> >>>>> > > > > And the GitHub for 4.3 java is here:
> >>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >>>>> > > > >
> >>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> >>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >>>>> > > > >
> >>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
> >>>>> remote
> >>>>> > > > merging
> >>>>> > > > > their changes in from their forks while they fetch/merge from
> >>>>> mine to
> >>>>> > > get
> >>>>> > > > > everyone else's changes, rather than using pull requests.
> James
> >>>>> and I
> >>>>> > > > have
> >>>>> > > > > been working the past few days on the Util namespace ahead of
> >>>>> > tonight's
> >>>>> > > > > hackathon since that namespace is in common with the rest of
> the
> >>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know
> of
> >>>>> > hacking
> >>>>> > > on
> >>>>> > > > > porting 4.3, each with a different namespace or part of a
> >>>>> namespace.
> >>>>> > > > Since
> >>>>> > > > > we're going class-by-class, namespace-by-namespace, the
> project
> >>>>> does
> >>>>> > > not
> >>>>> > > > > build as it is. Once we finish doing a translation of each
> >>>>> file, then
> >>>>> > > > we'll
> >>>>> > > > > hammer out any remaining issues and get it to build again.
> I'm
> >>>>> hoping
> >>>>> > > > that
> >>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> >>>>> > > > >
> >>>>> > > > > But one thing to keep in mind is it looks like much
> >>>>> functionality has
> >>>>> > > > been
> >>>>> > > > > moved out of core into the contrib modules, especially around
> >>>>> > analysis,
> >>>>> > > > for
> >>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
> >>>>> anymore.
> >>>>> > So
> >>>>> > > > when
> >>>>> > > > > this is all done, we may want to include at least the
> analysis
> >>>>> > contrib
> >>>>> > > > > module in with the standard core NuGet package, because
> >>>>> otherwise
> >>>>> > it's
> >>>>> > > > > practically useless unless you roll your own analyzer.
> >>>>> > > > >
> >>>>> > > > > Paul
> >>>>> > > > >
> >>>>> > > > >
> >>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> >>>>> > marcoslimagon@gmail.com
> >>>>> > > > >wrote:
> >>>>> > > > >
> >>>>> > > > >> Hi everyone!
> >>>>> > > > >>
> >>>>> > > > >> Does someone know where can I find the 3.0.3 release from
> >>>>> > > Lucene(java)?
> >>>>> > > > >>
> >>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
> >>>>> 4.3.0 and
> >>>>> > > > make
> >>>>> > > > >> the diff between then and get all changes between
> releases... I
> >>>>> > gonna
> >>>>> > > > >> publish it here soon. (If you think there is another
> important
> >>>>> > > release,
> >>>>> > > > >> let
> >>>>> > > > >> me know)
> >>>>> > > > >>
> >>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
> >>>>> with
> >>>>> > 4.3.0
> >>>>> > > > >> port
> >>>>> > > > >> for .Net on github (last email)?
> >>>>> > > > >>
> >>>>> > > > >> See you,
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> >>>>> > > > >>
> >>>>> > > > >> > Thanks for the discussion points, Michael.
> >>>>> > > > >> >
> >>>>> > > > >> > I would vote for not worrying about trying to achieve
> >>>>> portable
> >>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
> 4.3+
> >>>>> is
> >>>>> > > > >> completed.
> >>>>> > > > >> > Otherwise it may delay the project and stall it further.
> >>>>> That's
> >>>>> > just
> >>>>> > > > my
> >>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x
> features.
> >>>>> > > > >> >
> >>>>> > > > >> > I have started porting the changes from the core library
> >>>>> (from the
> >>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
> >>>>> separate
> >>>>> > > > branch.
> >>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
> >>>>> port
> >>>>> > > until
> >>>>> > > > >> > there's changes to pull from upstream to work from. Also
> due
> >>>>> to my
> >>>>> > > > time
> >>>>> > > > >> > constraints, I am not fully documenting new methods that
> I'm
> >>>>> > adding.
> >>>>> > > > >> But if
> >>>>> > > > >> > anyone wants to pull/copy/reference my changes while
> porting,
> >>>>> > that's
> >>>>> > > > >> > awesome. My branch currently does not build as I'm
> primarily
> >>>>> going
> >>>>> > > > >> > class-by-class, starting with the util namespace. Once we
> >>>>> get the
> >>>>> > > ball
> >>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
> >>>>> join
> >>>>> > in.
> >>>>> > > > But
> >>>>> > > > >> > hopefully my work will be useful to someone, if not as a
> pull
> >>>>> > > request
> >>>>> > > > >> then
> >>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
> >>>>> this week
> >>>>> > > > with
> >>>>> > > > >> my
> >>>>> > > > >> > colleagues where we're all going to work on the port. I'm
> >>>>> > comparing
> >>>>> > > > >> files
> >>>>> > > > >> > and making changes as necessary, rather than starting from
> >>>>> > scratch.
> >>>>> > > My
> >>>>> > > > >> > repo/branch is here:
> >>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>>> > > > >> >
> >>>>> > > > >> > Paul
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >>>>> > > > >> > mherndon@michaelherndon.com> wrote:
> >>>>> > > > >> >
> >>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> >>>>> apache
> >>>>> > > > >> > maintains.
> >>>>> > > > >> > >
> >>>>> > > > >> > > The was some work at one time to move the official svn
> >>>>> > repository
> >>>>> > > to
> >>>>> > > > >> > start
> >>>>> > > > >> > > using git one instead. Was that actually finalized or
> not?
> >>>>> > > > >> > >
> >>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
> to
> >>>>> see
> >>>>> > > what
> >>>>> > > > >> kind
> >>>>> > > > >> > of
> >>>>> > > > >> > > work was involved using a portable libraries project.
> Some
> >>>>> of it
> >>>>> > > can
> >>>>> > > > >> > still
> >>>>> > > > >> > > be used but will need to be validated against the
> current
> >>>>> > version
> >>>>> > > of
> >>>>> > > > >> > Java's
> >>>>> > > > >> > > Lucene. It was also using .net 4.
> >>>>> > > > >> > >
> >>>>> > > > >> > > clean branch vs current. Its going to depend on
> what we
> >>>>> > > support.
> >>>>> > > > >> If
> >>>>> > > > >> > you
> >>>>> > > > >> > > support windows mobile 8, win RT, then the current code
> in
> >>>>> trunk
> >>>>> > > > will
> >>>>> > > > >> not
> >>>>> > > > >> > > compile against those versions of the framework which
> >>>>> would a
> >>>>> > > > >> frustrating
> >>>>> > > > >> > > starting point, then you couldn't even run tests, which
> >>>>> would
> >>>>> > make
> >>>>> > > > >> taking
> >>>>> > > > >> > > patches very difficult. Supporting those can almost
> mean
> >>>>> larger
> >>>>> > > > gaps
> >>>>> > > > >> in
> >>>>> > > > >> > > design between Lucene.Net and its parent project.
> >>>>> > > > >> > >
> >>>>> > > > >> > > Also the structure has changed significantly between
> the
> >>>>> > branches
> >>>>> > > > and
> >>>>> > > > >> > the
> >>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java
> 6,
> >>>>> and
> >>>>> > > seems
> >>>>> > > > >> > > significantly different. That doesn't mean you can't
> >>>>> cherry
> >>>>> > pick
> >>>>> > > > >> stuff
> >>>>> > > > >> > > from the other tags/branches that would still work as
> is.
> >>>>> A
> >>>>> > clean
> >>>>> > > > >> branch
> >>>>> > > > >> > > would also make it easier to get our build / tool chain
> in
> >>>>> order
> >>>>> > > as
> >>>>> > > > >> you
> >>>>> > > > >> > can
> >>>>> > > > >> > > then do them incrementally versus having to do all the
> >>>>> stuff
> >>>>> > that
> >>>>> > > I
> >>>>> > > > >> did
> >>>>> > > > >> > for
> >>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
> >>>>> could
> >>>>> > > also
> >>>>> > > > >> make
> >>>>> > > > >> > it
> >>>>> > > > >> > > easier to see which classes have been ported or not.
> >>>>> > > > >> > >
> >>>>> > > > >> > > The major downside to a clean branch is extra work it
> >>>>> requires
> >>>>> > and
> >>>>> > > > the
> >>>>> > > > >> > > start up cost in time and energy of getting it in order,
> >>>>> which
> >>>>> > can
> >>>>> > > > be
> >>>>> > > > >> > > daunting / intimidating and lower morale. And generally
> >>>>> you want
> >>>>> > > to
> >>>>> > > > >> use
> >>>>> > > > >> > > take your legacy code and refactor instead of in
> someways
> >>>>> > starting
> >>>>> > > > >> over.
> >>>>> > > > >> > >
> >>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> >>>>> > something
> >>>>> > > > >> similar
> >>>>> > > > >> > > to
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> >
> >>>>> > > > >>
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >>>>> > > > >> > > where it tracks what needs to get ported / what has been
> >>>>> ported.
> >>>>> > > > >> > >
> >>>>> > > > >> > > What are we going to support in the next version?
> >>>>> > > > >> > >
> >>>>> > > > >> > > Who is going to work on the next version?
> >>>>> > > > >> > >
> >>>>> > > > >> > > What would make the most sense and what would invigorate
> >>>>> the
> >>>>> > > > >> community to
> >>>>> > > > >> > > get involved more and lower the barrier to entry?
> >>>>> > > > >> > >
> >>>>> > > > >> > > I think those are the questions that would make a lot of
> >>>>> the
> >>>>> > > > decisions
> >>>>> > > > >> > for
> >>>>> > > > >> > > us so that we can get back to work on lucene.net.
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> >>>>> > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > >wrote:
> >>>>> > > > >> > >
> >>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
> >>>>> projects...
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >>>>> > > > >> > > > https://github.com/apache/lucene.net points to the
> same
> >>>>> > > > repository?
> >>>>> > > > >> > > (This
> >>>>> > > > >> > > > is new for me, pretty good) Which of them do you
> >>>>> recommend
> >>>>> > (i'm
> >>>>> > > > used
> >>>>> > > > >> > with
> >>>>> > > > >> > > > SVN and its patterns).
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > I'm checking the subversion right now.
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is
> a
> >>>>> old
> >>>>> > > > branch,
> >>>>> > > > >> i`m
> >>>>> > > > >> > > not
> >>>>> > > > >> > > > sure about its current status.
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > Will we wipe the current solution from /trunk and
> start
> >>>>> a new
> >>>>> > > one?
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > Thanks,
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > 2013/6/6 mherndon michael <
> mherndon@michaelherndon.com>
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > > We may be forced to start with a clean/empty branch
> if
> >>>>> > people
> >>>>> > > > >> still
> >>>>> > > > >> > > want
> >>>>> > > > >> > > > to
> >>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
> win
> >>>>> RT,
> >>>>> > > etc.
> >>>>> > > > >> The
> >>>>> > > > >> > are
> >>>>> > > > >> > > > > many
> >>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
> >>>>> that
> >>>>> > > would
> >>>>> > > > >> not
> >>>>> > > > >> > be
> >>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
> >>>>> It also
> >>>>> > > > might
> >>>>> > > > >> > > > require
> >>>>> > > > >> > > > > a design that differs even more from its parent
> >>>>> project.
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > It might be wise to poll what users most desire in
> the
> >>>>> next
> >>>>> > > > >> version
> >>>>> > > > >> > > > through
> >>>>> > > > >> > > > > jira or user voice.
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >>>>> > > > >> > itamar@code972.com
> >>>>> > > > >> > > > > >wrote:
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > > inline
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> >>>>> > > > >> pirwin@feature23.com>
> >>>>> > > > >> > > > wrote:
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
> been
> >>>>> a TFS
> >>>>> > > guy
> >>>>> > > > >> for
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > long
> >>>>> > > > >> > > > > > > :-)
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> >>>>> patches
> >>>>> > or
> >>>>> > > > >> > anything
> >>>>> > > > >> > > > to
> >>>>> > > > >> > > > > > the
> >>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
> will
> >>>>> > branch
> >>>>> > > > from
> >>>>> > > > >> > for
> >>>>> > > > >> > > 4x
> >>>>> > > > >> > > > > > dev.
> >>>>> > > > >> > > > > > > Correct?
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> >>>>> anyone
> >>>>> > > will
> >>>>> > > > >> be
> >>>>> > > > >> > > > > > interested in that
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
> deal
> >>>>> with
> >>>>> > > the
> >>>>> > > > >> > github
> >>>>> > > > >> > > > > sync?
> >>>>> > > > >> > > > > > > Who could diagnose that?
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
> >>>>> apache
> >>>>> > repo
> >>>>> > > > for
> >>>>> > > > >> now
> >>>>> > > > >> > > > while
> >>>>> > > > >> > > > > > we get that sorted out.
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
> Syn-Hershko
> >>>>> <
> >>>>> > > > >> > > > itamar@code972.com
> >>>>> > > > >> > > > > > > >wrote:
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
> >>>>> then for
> >>>>> > > 3.x
> >>>>> > > > >> > > > > development.
> >>>>> > > > >> > > > > > > WRT
> >>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
> >>>>> whatever
> >>>>> > > branch.
> >>>>> > > > >> When
> >>>>> > > > >> > > you
> >>>>> > > > >> > > > > > send
> >>>>> > > > >> > > > > > > us
> >>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
> >>>>> dedicated
> >>>>> > > repo.
> >>>>> > > > >> For
> >>>>> > > > >> > > now
> >>>>> > > > >> > > > it
> >>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of
> git.
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
> >>>>> it on
> >>>>> > the
> >>>>> > > > >> apache
> >>>>> > > > >> > > > > servers
> >>>>> > > > >> > > > > > > > (github sync seems to be off)
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> >>>>> > > > >> > > pirwin@feature23.com>
> >>>>> > > > >> > > > > > > wrote:
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
> >>>>> 4.3
> >>>>> > > version
> >>>>> > > > >> of
> >>>>> > > > >> > the
> >>>>> > > > >> > > > > > > Analysis
> >>>>> > > > >> > > > > > > > > namespace.
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
> >>>>> intended
> >>>>> > --
> >>>>> > > > you
> >>>>> > > > >> > might
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > meant
> >>>>> > > > >> > > > > > > > > trunk instead of master, and that would
> create
> >>>>> a new
> >>>>> > > > "3x"
> >>>>> > > > >> > > branch,
> >>>>> > > > >> > > > > > when
> >>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that
> would be
> >>>>> > > > >> misnamed...
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > maybe
> >>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
> >>>>> aiming
> >>>>> > for
> >>>>> > > > >> lucene
> >>>>> > > > >> > > > 4.3.x
> >>>>> > > > >> > > > > > > > > compatibility?
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
> >>>>> > upstream
> >>>>> > > > >> want to
> >>>>> > > > >> > > > > create
> >>>>> > > > >> > > > > > > the
> >>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
> >>>>> not all
> >>>>> > > > >> trying to
> >>>>> > > > >> > > > > create
> >>>>> > > > >> > > > > > > them
> >>>>> > > > >> > > > > > > > > and dealing with a merge?
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Paul
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> >>>>> Syn-Hershko <
> >>>>> > > > >> > > > > > itamar@code972.com
> >>>>> > > > >> > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > > Unless people here have a specific reason
> to
> >>>>> use
> >>>>> > > > 3.6.2 I
> >>>>> > > > >> > > would
> >>>>> > > > >> > > > > > highly
> >>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
> >>>>> towards v4
> >>>>> > > > >> > otherwise
> >>>>> > > > >> > > we
> >>>>> > > > >> > > > > > will
> >>>>> > > > >> > > > > > > > > never
> >>>>> > > > >> > > > > > > > > > make it...
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or
> github
> >>>>> (same
> >>>>> > > > repo,
> >>>>> > > > >> > > > different
> >>>>> > > > >> > > > > > > > > remotes)
> >>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> >>>>> should
> >>>>> > > work
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
> Irwin <
> >>>>> > > > >> > > > > pirwin@feature23.com>
> >>>>> > > > >> > > > > > > > > wrote:
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > Itamar,
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the
> best
> >>>>> way to
> >>>>> > > do
> >>>>> > > > >> it, I
> >>>>> > > > >> > > > just
> >>>>> > > > >> > > > > > > > thought
> >>>>> > > > >> > > > > > > > > > that
> >>>>> > > > >> > > > > > > > > > > was the "decision" that was made from
> the
> >>>>> > > discussion
> >>>>> > > > >> > > > previously
> >>>>> > > > >> > > > > > for
> >>>>> > > > >> > > > > > > > the
> >>>>> > > > >> > > > > > > > > > 4.x
> >>>>> > > > >> > > > > > > > > > > work. An incremental approach will be
> much
> >>>>> > better.
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
> >>>>> branch on
> >>>>> > > my
> >>>>> > > > >> fork
> >>>>> > > > >> > > and
> >>>>> > > > >> > > > > will
> >>>>> > > > >> > > > > > > > begin
> >>>>> > > > >> > > > > > > > > > > working on bringing the Analysis
> namespace
> >>>>> up to
> >>>>> > > > >> speed to
> >>>>> > > > >> > > > > 3.6.2.
> >>>>> > > > >> > > > > > If
> >>>>> > > > >> > > > > > > > > > anyone
> >>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts
> once
> >>>>> I'm
> >>>>> > > done,
> >>>>> > > > >> have
> >>>>> > > > >> > at
> >>>>> > > > >> > > > it.
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
> >>>>> branch_3x
> >>>>> > > > branch,
> >>>>> > > > >> > > please
> >>>>> > > > >> > > > > let
> >>>>> > > > >> > > > > > > me
> >>>>> > > > >> > > > > > > > > know
> >>>>> > > > >> > > > > > > > > > > what I should have branched from
> (trunk?)
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > Paul
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> >>>>> > > Syn-Hershko <
> >>>>> > > > >> > > > > > > > itamar@code972.com
> >>>>> > > > >> > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
> >>>>> again :)
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
> >>>>> know
> >>>>> > what
> >>>>> > > > it
> >>>>> > > > >> > would
> >>>>> > > > >> > > > > take
> >>>>> > > > >> > > > > > > > until
> >>>>> > > > >> > > > > > > > > > they
> >>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and
> even
> >>>>> then
> >>>>> > > > >> decisions
> >>>>> > > > >> > > > could
> >>>>> > > > >> > > > > > and
> >>>>> > > > >> > > > > > > > will
> >>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
> >>>>> > starting
> >>>>> > > > from
> >>>>> > > > >> > > > scratch,
> >>>>> > > > >> > > > > > > > > although
> >>>>> > > > >> > > > > > > > > > I
> >>>>> > > > >> > > > > > > > > > > do
> >>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
> >>>>> should
> >>>>> > > > change,
> >>>>> > > > >> but
> >>>>> > > > >> > > its
> >>>>> > > > >> > > > > > going
> >>>>> > > > >> > > > > > > > to
> >>>>> > > > >> > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
> >>>>> refactoring
> >>>>> > > > where
> >>>>> > > > >> > > > needed,
> >>>>> > > > >> > > > > > than
> >>>>> > > > >> > > > > > > > > > > starting
> >>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
> off I
> >>>>> > > > personally
> >>>>> > > > >> > will
> >>>>> > > > >> > > > be
> >>>>> > > > >> > > > > > > happy
> >>>>> > > > >> > > > > > > > > with
> >>>>> > > > >> > > > > > > > > > > you
> >>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> >>>>> porting
> >>>>> > > it,
> >>>>> > > > >> its
> >>>>> > > > >> > > > pretty
> >>>>> > > > >> > > > > > > much
> >>>>> > > > >> > > > > > > > > self
> >>>>> > > > >> > > > > > > > > > > > contained.
> >>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that
> on
> >>>>> a fork
> >>>>> > > and
> >>>>> > > > >> send
> >>>>> > > > >> > > us
> >>>>> > > > >> > > > > PRs,
> >>>>> > > > >> > > > > > > its
> >>>>> > > > >> > > > > > > > > > much
> >>>>> > > > >> > > > > > > > > > > > more straight forward than the v4
> upgrade
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> >>>>> fastest
> >>>>> > > way
> >>>>> > > > >> to do
> >>>>> > > > >> > > > this,
> >>>>> > > > >> > > > > > we
> >>>>> > > > >> > > > > > > > can
> >>>>> > > > >> > > > > > > > > > then
> >>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
> optimizing
> >>>>> using
> >>>>> > > > .NET
> >>>>> > > > >> > > > > constructs.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
> >>>>> create a
> >>>>> > > > branch
> >>>>> > > > >> out
> >>>>> > > > >> > > of
> >>>>> > > > >> > > > > the
> >>>>> > > > >> > > > > > > > > current
> >>>>> > > > >> > > > > > > > > > > git
> >>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
> start
> >>>>> > > working
> >>>>> > > > on
> >>>>> > > > >> > > master
> >>>>> > > > >> > > > > > > > towards a
> >>>>> > > > >> > > > > > > > > > 4.3
> >>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
> >>>>> should be
> >>>>> > > > using
> >>>>> > > > >> a
> >>>>> > > > >> > > > process
> >>>>> > > > >> > > > > > > that
> >>>>> > > > >> > > > > > > > > > > ensures
> >>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
> >>>>> tests,
> >>>>> > > and
> >>>>> > > > >> that
> >>>>> > > > >> > > > those
> >>>>> > > > >> > > > > > > tests
> >>>>> > > > >> > > > > > > > > > pass -
> >>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
> code
> >>>>> to
> >>>>> > our
> >>>>> > > > >> > > > repositories.
> >>>>> > > > >> > > > > > The
> >>>>> > > > >> > > > > > > > > > process
> >>>>> > > > >> > > > > > > > > > > > should probably be working on classes
> in
> >>>>> some
> >>>>> > > > order
> >>>>> > > > >> > > > > > > > (alphabetically,
> >>>>> > > > >> > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
> >>>>> class to
> >>>>> > > > >> compile
> >>>>> > > > >> > > > before
> >>>>> > > > >> > > > > > > moving
> >>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the
> project
> >>>>> not
> >>>>> > > being
> >>>>> > > > >> > > > compilable
> >>>>> > > > >> > > > > > for
> >>>>> > > > >> > > > > > > a
> >>>>> > > > >> > > > > > > > > > month
> >>>>> > > > >> > > > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > two.
> >>>>> > > > >> > > > > > > > > > > > Once this is done a process of
> >>>>> .NETifying and
> >>>>> > > > >> proofing
> >>>>> > > > >> > > the
> >>>>> > > > >> > > > > code
> >>>>> > > > >> > > > > > > can
> >>>>> > > > >> > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > started, at which point we will
> already
> >>>>> have a
> >>>>> > > > >> working
> >>>>> > > > >> > v4
> >>>>> > > > >> > > > > > version
> >>>>> > > > >> > > > > > > > so
> >>>>> > > > >> > > > > > > > > it
> >>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the
> Java
> >>>>> > project.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
> >>>>> test
> >>>>> > > suite
> >>>>> > > > so
> >>>>> > > > >> > > tests
> >>>>> > > > >> > > > > > could
> >>>>> > > > >> > > > > > > > more
> >>>>> > > > >> > > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
> >>>>> implementing
> >>>>> > > > >> Java-like
> >>>>> > > > >> > > > > > > assertEquals
> >>>>> > > > >> > > > > > > > > > > methods
> >>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
> >>>>> work
> >>>>> > with
> >>>>> > > > >> than
> >>>>> > > > >> > > > > NUnit). I
> >>>>> > > > >> > > > > > > > > already
> >>>>> > > > >> > > > > > > > > > > did
> >>>>> > > > >> > > > > > > > > > > > some work there but there's still a
> lot
> >>>>> to do.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
> >>>>> myself at
> >>>>> > > this
> >>>>> > > > >> > point,
> >>>>> > > > >> > > > > but I
> >>>>> > > > >> > > > > > > > > should
> >>>>> > > > >> > > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > back in business in August, at which
> >>>>> point I
> >>>>> > can
> >>>>> > > > >> > dedicate
> >>>>> > > > >> > > > > > several
> >>>>> > > > >> > > > > > > > > > hours a
> >>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to
> watch
> >>>>> > closely
> >>>>> > > > and
> >>>>> > > > >> > even
> >>>>> > > > >> > > > > > > coordinate
> >>>>> > > > >> > > > > > > > > the
> >>>>> > > > >> > > > > > > > > > > > work to some extent.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM,
> Marcos
> >>>>> Lima <
> >>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this
> is a
> >>>>> kick
> >>>>> > > > start
> >>>>> > > > >> > =). I
> >>>>> > > > >> > > > > > haven't
> >>>>> > > > >> > > > > > > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > > > anything
> >>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you
> all
> >>>>> to get
> >>>>> > > > this
> >>>>> > > > >> job
> >>>>> > > > >> > > > done.
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> >>>>> Prescott.
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > I know that there is a high
> commitment
> >>>>> for
> >>>>> > > keep
> >>>>> > > > >> the
> >>>>> > > > >> > > > > > > > > > retrocompatibility
> >>>>> > > > >> > > > > > > > > > > on
> >>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets
> big
> >>>>> > changes
> >>>>> > > > >> every
> >>>>> > > > >> > > > > release?
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
> stable
> >>>>> > version
> >>>>> > > > >> from a
> >>>>> > > > >> > > > > Lucene
> >>>>> > > > >> > > > > > > > > version,
> >>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
> >>>>> minor
> >>>>> > > changes
> >>>>> > > > >> > every
> >>>>> > > > >> > > > > stable
> >>>>> > > > >> > > > > > > > > release
> >>>>> > > > >> > > > > > > > > > > (or
> >>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
> could
> >>>>> > > compare
> >>>>> > > > >> the
> >>>>> > > > >> > > > > versions,
> >>>>> > > > >> > > > > > > > check
> >>>>> > > > >> > > > > > > > > > the
> >>>>> > > > >> > > > > > > > > > > > > differences and bring them to
> >>>>> Lucene.Net.
> >>>>> > > > Again, I
> >>>>> > > > >> > > > haven't
> >>>>> > > > >> > > > > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > > with
> >>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is
> (just an
> >>>>> > idea).
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
> >>>>> simple
> >>>>> > > > >> performance
> >>>>> > > > >> > > > > > > > improvements
> >>>>> > > > >> > > > > > > > > > > > (without
> >>>>> > > > >> > > > > > > > > > > > > adding references or changing
> methods
> >>>>> > > > signatures)?
> >>>>> > > > >> > Does
> >>>>> > > > >> > > > it
> >>>>> > > > >> > > > > > > could
> >>>>> > > > >> > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > done,
> >>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
> >>>>> pirwin@feature23.com>
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
> >>>>> suggestion as I
> >>>>> > > > >> haven't
> >>>>> > > > >> > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > anything
> >>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
> help
> >>>>> with
> >>>>> > > the
> >>>>> > > > >> 4.x
> >>>>> > > > >> > > work
> >>>>> > > > >> > > > > as I
> >>>>> > > > >> > > > > > > > have
> >>>>> > > > >> > > > > > > > > a
> >>>>> > > > >> > > > > > > > > > > > vested
> >>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
> >>>>> completed. I
> >>>>> > > think
> >>>>> > > > >> > there
> >>>>> > > > >> > > > > should
> >>>>> > > > >> > > > > > > be
> >>>>> > > > >> > > > > > > > > one
> >>>>> > > > >> > > > > > > > > > > > person
> >>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> >>>>> > structure
> >>>>> > > > and
> >>>>> > > > >> > > > workflow
> >>>>> > > > >> > > > > > will
> >>>>> > > > >> > > > > > > > > look
> >>>>> > > > >> > > > > > > > > > > like
> >>>>> > > > >> > > > > > > > > > > > > to
> >>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
> >>>>> going to
> >>>>> > be
> >>>>> > > > >> > starting
> >>>>> > > > >> > > > from
> >>>>> > > > >> > > > > > > > scratch
> >>>>> > > > >> > > > > > > > > > as
> >>>>> > > > >> > > > > > > > > > > a
> >>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
> >>>>> up the
> >>>>> > > > >> project,
> >>>>> > > > >> > > get
> >>>>> > > > >> > > > > > > > everything
> >>>>> > > > >> > > > > > > > > > > going
> >>>>> > > > >> > > > > > > > > > > > > in
> >>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
> >>>>> > structure,
> >>>>> > > > >> maybe
> >>>>> > > > >> > > stub
> >>>>> > > > >> > > > > out
> >>>>> > > > >> > > > > > > > some
> >>>>> > > > >> > > > > > > > > > > > classes,
> >>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
> >>>>> anyone
> >>>>> > > > >> interested
> >>>>> > > > >> > > in
> >>>>> > > > >> > > > > > > > > > contributing,
> >>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
> java
> >>>>> code
> >>>>> > in
> >>>>> > > > >> there
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > it's
> >>>>> > > > >> > > > > > > easy
> >>>>> > > > >> > > > > > > > > to
> >>>>> > > > >> > > > > > > > > > > > > > reference.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
> >>>>> Lucene.Net.Documents,
> >>>>> > > > >> > > > > > > Lucene.Net.Analysis,
> >>>>> > > > >> > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
> >>>>> those
> >>>>> > are
> >>>>> > > > >> just
> >>>>> > > > >> > the
> >>>>> > > > >> > > > > ones
> >>>>> > > > >> > > > > > > I'm
> >>>>> > > > >> > > > > > > > > most
> >>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
> >>>>> Tell me
> >>>>> > > what
> >>>>> > > > >> to
> >>>>> > > > >> > do
> >>>>> > > > >> > > > and
> >>>>> > > > >> > > > > > I'll
> >>>>> > > > >> > > > > > > > get
> >>>>> > > > >> > > > > > > > > > > > started
> >>>>> > > > >> > > > > > > > > > > > > > on my fork.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
> >>>>> Prescott
> >>>>> > > > Nasser
> >>>>> > > > >> <
> >>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> >>>>> > > > >> > > > > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
> >>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
> >>>>> while. We
> >>>>> > > > have a
> >>>>> > > > >> > > board
> >>>>> > > > >> > > > > > report
> >>>>> > > > >> > > > > > > > due
> >>>>> > > > >> > > > > > > > > > > soon
> >>>>> > > > >> > > > > > > > > > > > -
> >>>>> > > > >> > > > > > > > > > > > > I
> >>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
> >>>>> them
> >>>>> > that
> >>>>> > > we
> >>>>> > > > >> seem
> >>>>> > > > >> > > to
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > > stalled
> >>>>> > > > >> > > > > > > > > > > > > > somewhat.
> >>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging
> items
> >>>>> out of
> >>>>> > > of
> >>>>> > > > >> jira
> >>>>> > > > >> > > and
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > been
> >>>>> > > > >> > > > > > > > > > > > > responsive
> >>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> >>>>> > > questions,
> >>>>> > > > >> but I
> >>>>> > > > >> > > > don't
> >>>>> > > > >> > > > > > > think
> >>>>> > > > >> > > > > > > > > > we've
> >>>>> > > > >> > > > > > > > > > > > > done
> >>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
> 4.0.
> >>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
> and
> >>>>> > start
> >>>>> > > us
> >>>>> > > > >> back
> >>>>> > > > >> > > up
> >>>>> > > > >> > > > > > moving
> >>>>> > > > >> > > > > > > > > > > forward.
> >>>>> > > > >> > > > > > > > > > > > > What
> >>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
> >>>>> this? If
> >>>>> > we
> >>>>> > > > took
> >>>>> > > > >> > the
> >>>>> > > > >> > > > java
> >>>>> > > > >> > > > > > > > lucene
> >>>>> > > > >> > > > > > > > > > 4.0
> >>>>> > > > >> > > > > > > > > > > > code
> >>>>> > > > >> > > > > > > > > > > > > > and
> >>>>> > > > >> > > > > > > > > > > > > > > committed that java to our
> branch
> >>>>> and
> >>>>> > then
> >>>>> > > > >> just
> >>>>> > > > >> > let
> >>>>> > > > >> > > > > > people
> >>>>> > > > >> > > > > > > > pull
> >>>>> > > > >> > > > > > > > > > > that
> >>>>> > > > >> > > > > > > > > > > > > down
> >>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying
> is
> >>>>> that
> >>>>> > one
> >>>>> > > > >> way to
> >>>>> > > > >> > > > maybe
> >>>>> > > > >> > > > > > > make
> >>>>> > > > >> > > > > > > > > some
> >>>>> > > > >> > > > > > > > > > > > > forward
> >>>>> > > > >> > > > > > > > > > > > > > > progress?
> >>>>> > > > >> > > > > > > > > > > > > > > ~P
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > --
> >>>>> > > > >> > > > > > > > > > > > > --
> >>>>> > > > >> > > > > > > > > > > > > Marcos Lima
> >>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> >>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > --
> >>>>> > > > >> > > > --
> >>>>> > > > >> > > > Marcos Lima
> >>>>> > > > >> > > > Software Developer/Tech Lead
> >>>>> > > > >> > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > tel: +55 (19) 9798-9335
> >>>>> > > > >> > > >
> >>>>> > > > >> > >
> >>>>> > > > >> >
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >> --
> >>>>> > > > >> --
> >>>>> > > > >> Marcos Lima
> >>>>> > > > >> Software Developer/Tech Lead
> >>>>> > > > >> marcoslimagon@gmail.com
> >>>>> > > > >> tel: +55 (19) 9798-9335
> >>>>> > > > >>
> >>>>> > > > >
> >>>>> > > > >
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
Re: Lucene 4.0
Posted by 许鹏 <xu...@188.com>.
Hi Paul,
I am a developer from China, I currently using Solr 4.3.0 to construct our own
data system for search and analysis. I am very interested in the work that porting
Lucene java 4.3.1, and I want to join this team to work on this. But I have never
been involved in open source projects, Can you give me some suggestion to join
the team and start contributing.
Additional, I am not good at English writing, but reading is ok. Also, I am now learning English,
I believe it will be more smooth communication.
Athrun Saga
8/9/2013
At 2013-08-09 03:31:47,"Paul Irwin" <pi...@feature23.com> wrote:
>Is this mailing list dead?! If anyone is interested in releasing an
>up-to-date build of Lucene.net, please write back! If you didn't read my
>other messages, I have Lucene.net Core working with Lucene java 4.3.1
>compatibility thanks to the help of my colleagues. We just need to round
>out the contrib modules, unit tests, and documentation as a community and
>we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>was packaged in December 2010!
>
>I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>(where they now live in Lucene java, they were moved from core) and their
>associated filters and tokenizers. I've briefly tested each and they seem
>to work correctly. I've purposefully "Exclude[d] from Project" the other
>language analyzers until we can forward-port them. So now the Analyzers DLL
>compiles with those analyzers only. Also, I fixed the bug that was causing
>NumericRangeQuery to not work.
>
>Next on my list is the QueryParsers contrib library (QueryParser was moved
>out of Lucene java core) so that, combined with StandardAnalyzer, we can
>test a pretty common real-world use case (the prototypical "hello lucene"
>tutorial). After that, it might be worth forward-porting what we have so
>far to 4.4 and use that as the latest point to finish out the port. The
>changes shouldn't be too dramatic to core from what I can tell.
>
>My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
>I'll keep updating as I go, but if anyone wants to jump in, there's not a
>better time than now...
>
>
>
>On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>>> the matching documents prints the fields to the console, so it's loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look that
>>>> would be great. Here's example index writing and then reading code (also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>>>
>>>>> Great
>>>>>
>>>>> You can build you Query objects on your own to execute a search, you
>>>>> don't
>>>>> actually have to use QueryParser for that
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>>>> that
>>>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>>> 4.2
>>>>> > codec and read in things like the number of documents and whatnot.
>>>>> Since
>>>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>>> built
>>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>>> analyzers
>>>>> > have also moved to another module. But this is definitely good
>>>>> progress and
>>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>>> >
>>>>> > You can see my fork/branch here:
>>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>> like I
>>>>> > said, only core builds now, no modules/tests build, so only open the
>>>>> > Lucene.Net.Core.sln)
>>>>> >
>>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>> the
>>>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>>>> > questions, thanks!
>>>>> >
>>>>> >
>>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>> itamar@code972.com
>>>>> > >wrote:
>>>>> >
>>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>>> thread
>>>>> > and
>>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > > All,
>>>>> > > >
>>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>>> 4.3's
>>>>> > core
>>>>> > > > library before, during, and after the hackathon last week. We now
>>>>> only
>>>>> > > have
>>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>>> (plus a
>>>>> > few
>>>>> > > > other minor ones here and there). I expect to be done by the end
>>>>> of the
>>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>>> Packed),
>>>>> > > and
>>>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>>>> > > >
>>>>> > > > Again, my goal is to only get a buildable, experimental build of
>>>>> > > Lucene.net
>>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>> porting
>>>>> > > new
>>>>> > > > javadoc comments or unit tests right now, due to the vast amount
>>>>> of
>>>>> > code
>>>>> > > > that needs to be written just to get it to compile. If this work
>>>>> ends
>>>>> > up
>>>>> > > > becoming a pull request, great, otherwise it should help
>>>>> accelerate a
>>>>> > > port
>>>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>>>> and
>>>>> > > > contributors can use it as a reference. And again, we're taking
>>>>> the
>>>>> > > > pragmatic approach of porting class-by-class,
>>>>> namespace-by-namespace,
>>>>> > > with
>>>>> > > > the understanding that until we're done the project won't build.
>>>>> > > >
>>>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>>>> > module
>>>>> > > > and porting the QueryParsers contrib module, which I feel should
>>>>> be
>>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>>> library
>>>>> > is
>>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>>> without
>>>>> > > them.
>>>>> > > > You can check out the code on my fork/branch here:
>>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > >
>>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>> For the
>>>>> > > MMap
>>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>>>> pretty
>>>>> > > > well, but required some creative shuffling of the code to make it
>>>>> work
>>>>> > > due
>>>>> > > > to lifecycle management.
>>>>> > > >
>>>>> > > > I'll update again this weekend or next week, when we should have
>>>>> > wrapped
>>>>> > > up
>>>>> > > > most of the main hacking on porting the core code.
>>>>> > > >
>>>>> > > > Paul
>>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pirwin@feature23.com
>>>>> >
>>>>> > > wrote:
>>>>> > > >
>>>>> > > > > Marcos,
>>>>> > > > >
>>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
>>>>> is
>>>>> > only
>>>>> > > on
>>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>>> together:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>> > > > >
>>>>> > > > > The SVN for 4.3 java is here:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>> > > > > And the GitHub for 4.3 java is here:
>>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>> > > > >
>>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>> > > > >
>>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>>> remote
>>>>> > > > merging
>>>>> > > > > their changes in from their forks while they fetch/merge from
>>>>> mine to
>>>>> > > get
>>>>> > > > > everyone else's changes, rather than using pull requests. James
>>>>> and I
>>>>> > > > have
>>>>> > > > > been working the past few days on the Util namespace ahead of
>>>>> > tonight's
>>>>> > > > > hackathon since that namespace is in common with the rest of the
>>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>>>> > hacking
>>>>> > > on
>>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>>> namespace.
>>>>> > > > Since
>>>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>>>> does
>>>>> > > not
>>>>> > > > > build as it is. Once we finish doing a translation of each
>>>>> file, then
>>>>> > > > we'll
>>>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>>>> hoping
>>>>> > > > that
>>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>>> > > > >
>>>>> > > > > But one thing to keep in mind is it looks like much
>>>>> functionality has
>>>>> > > > been
>>>>> > > > > moved out of core into the contrib modules, especially around
>>>>> > analysis,
>>>>> > > > for
>>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>>> anymore.
>>>>> > So
>>>>> > > > when
>>>>> > > > > this is all done, we may want to include at least the analysis
>>>>> > contrib
>>>>> > > > > module in with the standard core NuGet package, because
>>>>> otherwise
>>>>> > it's
>>>>> > > > > practically useless unless you roll your own analyzer.
>>>>> > > > >
>>>>> > > > > Paul
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>> > marcoslimagon@gmail.com
>>>>> > > > >wrote:
>>>>> > > > >
>>>>> > > > >> Hi everyone!
>>>>> > > > >>
>>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>>> > > Lucene(java)?
>>>>> > > > >>
>>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>> 4.3.0 and
>>>>> > > > make
>>>>> > > > >> the diff between then and get all changes between releases... I
>>>>> > gonna
>>>>> > > > >> publish it here soon. (If you think there is another important
>>>>> > > release,
>>>>> > > > >> let
>>>>> > > > >> me know)
>>>>> > > > >>
>>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>> with
>>>>> > 4.3.0
>>>>> > > > >> port
>>>>> > > > >> for .Net on github (last email)?
>>>>> > > > >>
>>>>> > > > >> See you,
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>> > > > >>
>>>>> > > > >> > Thanks for the discussion points, Michael.
>>>>> > > > >> >
>>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>>> portable
>>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>>>> is
>>>>> > > > >> completed.
>>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>>> That's
>>>>> > just
>>>>> > > > my
>>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>>>> > > > >> >
>>>>> > > > >> > I have started porting the changes from the core library
>>>>> (from the
>>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>>> separate
>>>>> > > > branch.
>>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>>> port
>>>>> > > until
>>>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>>>> to my
>>>>> > > > time
>>>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>>>> > adding.
>>>>> > > > >> But if
>>>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>>>> > that's
>>>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>>>> going
>>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>>> get the
>>>>> > > ball
>>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>>> join
>>>>> > in.
>>>>> > > > But
>>>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>>>> > > request
>>>>> > > > >> then
>>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>>> this week
>>>>> > > > with
>>>>> > > > >> my
>>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>>> > comparing
>>>>> > > > >> files
>>>>> > > > >> > and making changes as necessary, rather than starting from
>>>>> > scratch.
>>>>> > > My
>>>>> > > > >> > repo/branch is here:
>>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > > >> >
>>>>> > > > >> > Paul
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>>> > > > >> >
>>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>>> apache
>>>>> > > > >> > maintains.
>>>>> > > > >> > >
>>>>> > > > >> > > The was some work at one time to move the official svn
>>>>> > repository
>>>>> > > to
>>>>> > > > >> > start
>>>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>>>> > > > >> > >
>>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>>>> see
>>>>> > > what
>>>>> > > > >> kind
>>>>> > > > >> > of
>>>>> > > > >> > > work was involved using a portable libraries project. Some
>>>>> of it
>>>>> > > can
>>>>> > > > >> > still
>>>>> > > > >> > > be used but will need to be validated against the current
>>>>> > version
>>>>> > > of
>>>>> > > > >> > Java's
>>>>> > > > >> > > Lucene. It was also using .net 4.
>>>>> > > > >> > >
>>>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>>>> > > support.
>>>>> > > > >> If
>>>>> > > > >> > you
>>>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>>>> trunk
>>>>> > > > will
>>>>> > > > >> not
>>>>> > > > >> > > compile against those versions of the framework which
>>>>> would a
>>>>> > > > >> frustrating
>>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>>> would
>>>>> > make
>>>>> > > > >> taking
>>>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>>>> larger
>>>>> > > > gaps
>>>>> > > > >> in
>>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>>> > > > >> > >
>>>>> > > > >> > > Also the structure has changed significantly between the
>>>>> > branches
>>>>> > > > and
>>>>> > > > >> > the
>>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>>>> and
>>>>> > > seems
>>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>>> cherry
>>>>> > pick
>>>>> > > > >> stuff
>>>>> > > > >> > > from the other tags/branches that would still work as is.
>>>>> A
>>>>> > clean
>>>>> > > > >> branch
>>>>> > > > >> > > would also make it easier to get our build / tool chain in
>>>>> order
>>>>> > > as
>>>>> > > > >> you
>>>>> > > > >> > can
>>>>> > > > >> > > then do them incrementally versus having to do all the
>>>>> stuff
>>>>> > that
>>>>> > > I
>>>>> > > > >> did
>>>>> > > > >> > for
>>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>>> could
>>>>> > > also
>>>>> > > > >> make
>>>>> > > > >> > it
>>>>> > > > >> > > easier to see which classes have been ported or not.
>>>>> > > > >> > >
>>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>>> requires
>>>>> > and
>>>>> > > > the
>>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>>> which
>>>>> > can
>>>>> > > > be
>>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>>> you want
>>>>> > > to
>>>>> > > > >> use
>>>>> > > > >> > > take your legacy code and refactor instead of in someways
>>>>> > starting
>>>>> > > > >> over.
>>>>> > > > >> > >
>>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>> > something
>>>>> > > > >> similar
>>>>> > > > >> > > to
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>>> ported.
>>>>> > > > >> > >
>>>>> > > > >> > > What are we going to support in the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > Who is going to work on the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > What would make the most sense and what would invigorate
>>>>> the
>>>>> > > > >> community to
>>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>>> > > > >> > >
>>>>> > > > >> > > I think those are the questions that would make a lot of
>>>>> the
>>>>> > > > decisions
>>>>> > > > >> > for
>>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > >wrote:
>>>>> > > > >> > >
>>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>>> projects...
>>>>> > > > >> > > >
>>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>>>> > > > repository?
>>>>> > > > >> > > (This
>>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>>> recommend
>>>>> > (i'm
>>>>> > > > used
>>>>> > > > >> > with
>>>>> > > > >> > > > SVN and its patterns).
>>>>> > > > >> > > >
>>>>> > > > >> > > > I'm checking the subversion right now.
>>>>> > > > >> > > >
>>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>>>> old
>>>>> > > > branch,
>>>>> > > > >> i`m
>>>>> > > > >> > > not
>>>>> > > > >> > > > sure about its current status.
>>>>> > > > >> > > >
>>>>> > > > >> > > > Will we wipe the current solution from /trunk and start
>>>>> a new
>>>>> > > one?
>>>>> > > > >> > > >
>>>>> > > > >> > > > Thanks,
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>>>> > > > >> > > >
>>>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>>>> > people
>>>>> > > > >> still
>>>>> > > > >> > > want
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>>>> RT,
>>>>> > > etc.
>>>>> > > > >> The
>>>>> > > > >> > are
>>>>> > > > >> > > > > many
>>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>>> that
>>>>> > > would
>>>>> > > > >> not
>>>>> > > > >> > be
>>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>>> It also
>>>>> > > > might
>>>>> > > > >> > > > require
>>>>> > > > >> > > > > a design that differs even more from its parent
>>>>> project.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>>>> next
>>>>> > > > >> version
>>>>> > > > >> > > > through
>>>>> > > > >> > > > > jira or user voice.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>> > > > >> > itamar@code972.com
>>>>> > > > >> > > > > >wrote:
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > > inline
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>> > > > >> pirwin@feature23.com>
>>>>> > > > >> > > > wrote:
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>>>> a TFS
>>>>> > > guy
>>>>> > > > >> for
>>>>> > > > >> > so
>>>>> > > > >> > > > > long
>>>>> > > > >> > > > > > > :-)
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>>> patches
>>>>> > or
>>>>> > > > >> > anything
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > > the
>>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>>>> > branch
>>>>> > > > from
>>>>> > > > >> > for
>>>>> > > > >> > > 4x
>>>>> > > > >> > > > > > dev.
>>>>> > > > >> > > > > > > Correct?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>>> anyone
>>>>> > > will
>>>>> > > > >> be
>>>>> > > > >> > > > > > interested in that
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>>>> with
>>>>> > > the
>>>>> > > > >> > github
>>>>> > > > >> > > > > sync?
>>>>> > > > >> > > > > > > Who could diagnose that?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>>> apache
>>>>> > repo
>>>>> > > > for
>>>>> > > > >> now
>>>>> > > > >> > > > while
>>>>> > > > >> > > > > > we get that sorted out.
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko
>>>>> <
>>>>> > > > >> > > > itamar@code972.com
>>>>> > > > >> > > > > > > >wrote:
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>>> then for
>>>>> > > 3.x
>>>>> > > > >> > > > > development.
>>>>> > > > >> > > > > > > WRT
>>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>>> whatever
>>>>> > > branch.
>>>>> > > > >> When
>>>>> > > > >> > > you
>>>>> > > > >> > > > > > send
>>>>> > > > >> > > > > > > us
>>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>>> dedicated
>>>>> > > repo.
>>>>> > > > >> For
>>>>> > > > >> > > now
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>>> it on
>>>>> > the
>>>>> > > > >> apache
>>>>> > > > >> > > > > servers
>>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>> > > > >> > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > wrote:
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>>> 4.3
>>>>> > > version
>>>>> > > > >> of
>>>>> > > > >> > the
>>>>> > > > >> > > > > > > Analysis
>>>>> > > > >> > > > > > > > > namespace.
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>>> intended
>>>>> > --
>>>>> > > > you
>>>>> > > > >> > might
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > meant
>>>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>>>> a new
>>>>> > > > "3x"
>>>>> > > > >> > > branch,
>>>>> > > > >> > > > > > when
>>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>>>> > > > >> misnamed...
>>>>> > > > >> > so
>>>>> > > > >> > > > > maybe
>>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>>> aiming
>>>>> > for
>>>>> > > > >> lucene
>>>>> > > > >> > > > 4.3.x
>>>>> > > > >> > > > > > > > > compatibility?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>>> > upstream
>>>>> > > > >> want to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > the
>>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>>> not all
>>>>> > > > >> trying to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > them
>>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Paul
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>> Syn-Hershko <
>>>>> > > > >> > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>>>> use
>>>>> > > > 3.6.2 I
>>>>> > > > >> > > would
>>>>> > > > >> > > > > > highly
>>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>>> towards v4
>>>>> > > > >> > otherwise
>>>>> > > > >> > > we
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > never
>>>>> > > > >> > > > > > > > > > make it...
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>>>> (same
>>>>> > > > repo,
>>>>> > > > >> > > > different
>>>>> > > > >> > > > > > > > > remotes)
>>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>>> should
>>>>> > > work
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>>>> > > > >> > > > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > wrote:
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Itamar,
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>>>> way to
>>>>> > > do
>>>>> > > > >> it, I
>>>>> > > > >> > > > just
>>>>> > > > >> > > > > > > > thought
>>>>> > > > >> > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>>>> > > discussion
>>>>> > > > >> > > > previously
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > > the
>>>>> > > > >> > > > > > > > > > 4.x
>>>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>>>> > better.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>>> branch on
>>>>> > > my
>>>>> > > > >> fork
>>>>> > > > >> > > and
>>>>> > > > >> > > > > will
>>>>> > > > >> > > > > > > > begin
>>>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>>>> up to
>>>>> > > > >> speed to
>>>>> > > > >> > > > > 3.6.2.
>>>>> > > > >> > > > > > If
>>>>> > > > >> > > > > > > > > > anyone
>>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>>>> I'm
>>>>> > > done,
>>>>> > > > >> have
>>>>> > > > >> > at
>>>>> > > > >> > > > it.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>>> branch_3x
>>>>> > > > branch,
>>>>> > > > >> > > please
>>>>> > > > >> > > > > let
>>>>> > > > >> > > > > > > me
>>>>> > > > >> > > > > > > > > know
>>>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Paul
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>> > > Syn-Hershko <
>>>>> > > > >> > > > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>>> again :)
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>>> know
>>>>> > what
>>>>> > > > it
>>>>> > > > >> > would
>>>>> > > > >> > > > > take
>>>>> > > > >> > > > > > > > until
>>>>> > > > >> > > > > > > > > > they
>>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>>>> then
>>>>> > > > >> decisions
>>>>> > > > >> > > > could
>>>>> > > > >> > > > > > and
>>>>> > > > >> > > > > > > > will
>>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>>> > starting
>>>>> > > > from
>>>>> > > > >> > > > scratch,
>>>>> > > > >> > > > > > > > > although
>>>>> > > > >> > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > do
>>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>>> should
>>>>> > > > change,
>>>>> > > > >> but
>>>>> > > > >> > > its
>>>>> > > > >> > > > > > going
>>>>> > > > >> > > > > > > > to
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>>> refactoring
>>>>> > > > where
>>>>> > > > >> > > > needed,
>>>>> > > > >> > > > > > than
>>>>> > > > >> > > > > > > > > > > starting
>>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>>>> > > > personally
>>>>> > > > >> > will
>>>>> > > > >> > > > be
>>>>> > > > >> > > > > > > happy
>>>>> > > > >> > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > you
>>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>>> porting
>>>>> > > it,
>>>>> > > > >> its
>>>>> > > > >> > > > pretty
>>>>> > > > >> > > > > > > much
>>>>> > > > >> > > > > > > > > self
>>>>> > > > >> > > > > > > > > > > > contained.
>>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
>>>>> a fork
>>>>> > > and
>>>>> > > > >> send
>>>>> > > > >> > > us
>>>>> > > > >> > > > > PRs,
>>>>> > > > >> > > > > > > its
>>>>> > > > >> > > > > > > > > > much
>>>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>>> fastest
>>>>> > > way
>>>>> > > > >> to do
>>>>> > > > >> > > > this,
>>>>> > > > >> > > > > > we
>>>>> > > > >> > > > > > > > can
>>>>> > > > >> > > > > > > > > > then
>>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>>>> using
>>>>> > > > .NET
>>>>> > > > >> > > > > constructs.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>>> create a
>>>>> > > > branch
>>>>> > > > >> out
>>>>> > > > >> > > of
>>>>> > > > >> > > > > the
>>>>> > > > >> > > > > > > > > current
>>>>> > > > >> > > > > > > > > > > git
>>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>>>> > > working
>>>>> > > > on
>>>>> > > > >> > > master
>>>>> > > > >> > > > > > > > towards a
>>>>> > > > >> > > > > > > > > > 4.3
>>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>>> should be
>>>>> > > > using
>>>>> > > > >> a
>>>>> > > > >> > > > process
>>>>> > > > >> > > > > > > that
>>>>> > > > >> > > > > > > > > > > ensures
>>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>>> tests,
>>>>> > > and
>>>>> > > > >> that
>>>>> > > > >> > > > those
>>>>> > > > >> > > > > > > tests
>>>>> > > > >> > > > > > > > > > pass -
>>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>>>> to
>>>>> > our
>>>>> > > > >> > > > repositories.
>>>>> > > > >> > > > > > The
>>>>> > > > >> > > > > > > > > > process
>>>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>>>> some
>>>>> > > > order
>>>>> > > > >> > > > > > > > (alphabetically,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>>> class to
>>>>> > > > >> compile
>>>>> > > > >> > > > before
>>>>> > > > >> > > > > > > moving
>>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>>>> not
>>>>> > > being
>>>>> > > > >> > > > compilable
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > a
>>>>> > > > >> > > > > > > > > > month
>>>>> > > > >> > > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > two.
>>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>>> .NETifying and
>>>>> > > > >> proofing
>>>>> > > > >> > > the
>>>>> > > > >> > > > > code
>>>>> > > > >> > > > > > > can
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>>>> have a
>>>>> > > > >> working
>>>>> > > > >> > v4
>>>>> > > > >> > > > > > version
>>>>> > > > >> > > > > > > > so
>>>>> > > > >> > > > > > > > > it
>>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>>>> > project.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>>> test
>>>>> > > suite
>>>>> > > > so
>>>>> > > > >> > > tests
>>>>> > > > >> > > > > > could
>>>>> > > > >> > > > > > > > more
>>>>> > > > >> > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>>> implementing
>>>>> > > > >> Java-like
>>>>> > > > >> > > > > > > assertEquals
>>>>> > > > >> > > > > > > > > > > methods
>>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>>> work
>>>>> > with
>>>>> > > > >> than
>>>>> > > > >> > > > > NUnit). I
>>>>> > > > >> > > > > > > > > already
>>>>> > > > >> > > > > > > > > > > did
>>>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>>>> to do.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>>> myself at
>>>>> > > this
>>>>> > > > >> > point,
>>>>> > > > >> > > > > but I
>>>>> > > > >> > > > > > > > > should
>>>>> > > > >> > > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>>> point I
>>>>> > can
>>>>> > > > >> > dedicate
>>>>> > > > >> > > > > > several
>>>>> > > > >> > > > > > > > > > hours a
>>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>>>> > closely
>>>>> > > > and
>>>>> > > > >> > even
>>>>> > > > >> > > > > > > coordinate
>>>>> > > > >> > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>>> Lima <
>>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>>>> kick
>>>>> > > > start
>>>>> > > > >> > =). I
>>>>> > > > >> > > > > > haven't
>>>>> > > > >> > > > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>>>> to get
>>>>> > > > this
>>>>> > > > >> job
>>>>> > > > >> > > > done.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>>> Prescott.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>>>> for
>>>>> > > keep
>>>>> > > > >> the
>>>>> > > > >> > > > > > > > > > retrocompatibility
>>>>> > > > >> > > > > > > > > > > on
>>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>>>> > changes
>>>>> > > > >> every
>>>>> > > > >> > > > > release?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>>>> > version
>>>>> > > > >> from a
>>>>> > > > >> > > > > Lucene
>>>>> > > > >> > > > > > > > > version,
>>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>>> minor
>>>>> > > changes
>>>>> > > > >> > every
>>>>> > > > >> > > > > stable
>>>>> > > > >> > > > > > > > > release
>>>>> > > > >> > > > > > > > > > > (or
>>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>>>> > > compare
>>>>> > > > >> the
>>>>> > > > >> > > > > versions,
>>>>> > > > >> > > > > > > > check
>>>>> > > > >> > > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>>> Lucene.Net.
>>>>> > > > Again, I
>>>>> > > > >> > > > haven't
>>>>> > > > >> > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>>>> > idea).
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>>> simple
>>>>> > > > >> performance
>>>>> > > > >> > > > > > > > improvements
>>>>> > > > >> > > > > > > > > > > > (without
>>>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>>>> > > > signatures)?
>>>>> > > > >> > Does
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > could
>>>>> > > > >> > > > > > > > be
>>>>> > > > >> > > > > > > > > > > done,
>>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>>> pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>>> suggestion as I
>>>>> > > > >> haven't
>>>>> > > > >> > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>>>> with
>>>>> > > the
>>>>> > > > >> 4.x
>>>>> > > > >> > > work
>>>>> > > > >> > > > > as I
>>>>> > > > >> > > > > > > > have
>>>>> > > > >> > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > vested
>>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>>> completed. I
>>>>> > > think
>>>>> > > > >> > there
>>>>> > > > >> > > > > should
>>>>> > > > >> > > > > > > be
>>>>> > > > >> > > > > > > > > one
>>>>> > > > >> > > > > > > > > > > > person
>>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>>> > structure
>>>>> > > > and
>>>>> > > > >> > > > workflow
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > look
>>>>> > > > >> > > > > > > > > > > like
>>>>> > > > >> > > > > > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>>> going to
>>>>> > be
>>>>> > > > >> > starting
>>>>> > > > >> > > > from
>>>>> > > > >> > > > > > > > scratch
>>>>> > > > >> > > > > > > > > > as
>>>>> > > > >> > > > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>>> up the
>>>>> > > > >> project,
>>>>> > > > >> > > get
>>>>> > > > >> > > > > > > > everything
>>>>> > > > >> > > > > > > > > > > going
>>>>> > > > >> > > > > > > > > > > > > in
>>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>>> > structure,
>>>>> > > > >> maybe
>>>>> > > > >> > > stub
>>>>> > > > >> > > > > out
>>>>> > > > >> > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > classes,
>>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>>> anyone
>>>>> > > > >> interested
>>>>> > > > >> > > in
>>>>> > > > >> > > > > > > > > > contributing,
>>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>>>> code
>>>>> > in
>>>>> > > > >> there
>>>>> > > > >> > so
>>>>> > > > >> > > > > it's
>>>>> > > > >> > > > > > > easy
>>>>> > > > >> > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > reference.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>>> Lucene.Net.Documents,
>>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>>> those
>>>>> > are
>>>>> > > > >> just
>>>>> > > > >> > the
>>>>> > > > >> > > > > ones
>>>>> > > > >> > > > > > > I'm
>>>>> > > > >> > > > > > > > > most
>>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>>> Tell me
>>>>> > > what
>>>>> > > > >> to
>>>>> > > > >> > do
>>>>> > > > >> > > > and
>>>>> > > > >> > > > > > I'll
>>>>> > > > >> > > > > > > > get
>>>>> > > > >> > > > > > > > > > > > started
>>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>>> Prescott
>>>>> > > > Nasser
>>>>> > > > >> <
>>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>>> while. We
>>>>> > > > have a
>>>>> > > > >> > > board
>>>>> > > > >> > > > > > report
>>>>> > > > >> > > > > > > > due
>>>>> > > > >> > > > > > > > > > > soon
>>>>> > > > >> > > > > > > > > > > > -
>>>>> > > > >> > > > > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>>> them
>>>>> > that
>>>>> > > we
>>>>> > > > >> seem
>>>>> > > > >> > > to
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > > stalled
>>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>>>> out of
>>>>> > > of
>>>>> > > > >> jira
>>>>> > > > >> > > and
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > been
>>>>> > > > >> > > > > > > > > > > > > responsive
>>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>>> > > questions,
>>>>> > > > >> but I
>>>>> > > > >> > > > don't
>>>>> > > > >> > > > > > > think
>>>>> > > > >> > > > > > > > > > we've
>>>>> > > > >> > > > > > > > > > > > > done
>>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>>>> > start
>>>>> > > us
>>>>> > > > >> back
>>>>> > > > >> > > up
>>>>> > > > >> > > > > > moving
>>>>> > > > >> > > > > > > > > > > forward.
>>>>> > > > >> > > > > > > > > > > > > What
>>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>>> this? If
>>>>> > we
>>>>> > > > took
>>>>> > > > >> > the
>>>>> > > > >> > > > java
>>>>> > > > >> > > > > > > > lucene
>>>>> > > > >> > > > > > > > > > 4.0
>>>>> > > > >> > > > > > > > > > > > code
>>>>> > > > >> > > > > > > > > > > > > > and
>>>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>>>> and
>>>>> > then
>>>>> > > > >> just
>>>>> > > > >> > let
>>>>> > > > >> > > > > > people
>>>>> > > > >> > > > > > > > pull
>>>>> > > > >> > > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > > > down
>>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>>>> that
>>>>> > one
>>>>> > > > >> way to
>>>>> > > > >> > > > maybe
>>>>> > > > >> > > > > > > make
>>>>> > > > >> > > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > > forward
>>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > --
>>>>> > > > >> > > > --
>>>>> > > > >> > > > Marcos Lima
>>>>> > > > >> > > > Software Developer/Tech Lead
>>>>> > > > >> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> --
>>>>> > > > >> --
>>>>> > > > >> Marcos Lima
>>>>> > > > >> Software Developer/Tech Lead
>>>>> > > > >> marcoslimagon@gmail.com
>>>>> > > > >> tel: +55 (19) 9798-9335
>>>>> > > > >>
>>>>> > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
Re: Lucene 4.0
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Paul
You are doing great and much needed work and I look forward to eventually
being able to consume it in my projects that rely on Lucene.Net 3.0.3
currently.
I'm afraid the mailing list and more generally the project does appear to
be dead right now. I keep an eye on general goings on at Apache that I am
interested in such as Lucene.Net and I did see that the Lucene.Net project
had its board report rejected in July. I'm afraid I don't know why the
report was rejected as meetings don't become public record until the
following month when the next board meeting approves the minutes from the
previous meeting.
Rob
On 8/8/13 12:31 PM, "Paul Irwin" <pi...@feature23.com> wrote:
>Is this mailing list dead?! If anyone is interested in releasing an
>up-to-date build of Lucene.net, please write back! If you didn't read my
>other messages, I have Lucene.net Core working with Lucene java 4.3.1
>compatibility thanks to the help of my colleagues. We just need to round
>out the contrib modules, unit tests, and documentation as a community and
>we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>was packaged in December 2010!
>
>I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>(where they now live in Lucene java, they were moved from core) and their
>associated filters and tokenizers. I've briefly tested each and they seem
>to work correctly. I've purposefully "Exclude[d] from Project" the other
>language analyzers until we can forward-port them. So now the Analyzers
>DLL
>compiles with those analyzers only. Also, I fixed the bug that was causing
>NumericRangeQuery to not work.
>
>Next on my list is the QueryParsers contrib library (QueryParser was moved
>out of Lucene java core) so that, combined with StandardAnalyzer, we can
>test a pretty common real-world use case (the prototypical "hello lucene"
>tutorial). After that, it might be worth forward-porting what we have so
>far to 4.4 and use that as the latest point to finish out the port. The
>changes shouldn't be too dramatic to core from what I can tell.
>
>My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
>I'll keep updating as I go, but if anyone wants to jump in, there's not a
>better time than now...
>
>
>
>On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also
>>>tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to
>>>look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through
>>>>CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>.ToString()'ing
>>>> the matching documents prints the fields to the console, so it's
>>>>loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>that
>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look
>>>>that
>>>> would be great. Here's example index writing and then reading code
>>>>(also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko
>>>><it...@code972.com>wrote:
>>>>
>>>>> Great
>>>>>
>>>>> You can build you Query objects on your own to execute a search, you
>>>>> don't
>>>>> actually have to use QueryParser for that
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> > Hey all, sorry it's been a little while, but I wanted to let you
>>>>>know
>>>>> that
>>>>> > although I took a few weeks off from it, I now have a 4.3.1
>>>>>equivalent
>>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>>> 4.2
>>>>> > codec and read in things like the number of documents and whatnot.
>>>>> Since
>>>>> > QueryParser has been moved to a separate module in Lucene Java
>>>>>4.x, I
>>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>>> built
>>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>>> analyzers
>>>>> > have also moved to another module. But this is definitely good
>>>>> progress and
>>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>>> >
>>>>> > You can see my fork/branch here:
>>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>> like I
>>>>> > said, only core builds now, no modules/tests build, so only open
>>>>>the
>>>>> > Lucene.Net.Core.sln)
>>>>> >
>>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>> the
>>>>> > community into finishing the 4.3/4.4 port. Let me know if you have
>>>>>any
>>>>> > questions, thanks!
>>>>> >
>>>>> >
>>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>> itamar@code972.com
>>>>> > >wrote:
>>>>> >
>>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>>> thread
>>>>> > and
>>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin
>>>>><pi...@feature23.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > > All,
>>>>> > > >
>>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>>> 4.3's
>>>>> > core
>>>>> > > > library before, during, and after the hackathon last week. We
>>>>>now
>>>>> only
>>>>> > > have
>>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>>> (plus a
>>>>> > few
>>>>> > > > other minor ones here and there). I expect to be done by the
>>>>>end
>>>>> of the
>>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>>> Packed),
>>>>> > > and
>>>>> > > > the root Codecs and Codecs.PerField namespaces are all now
>>>>>"done".
>>>>> > > >
>>>>> > > > Again, my goal is to only get a buildable, experimental build
>>>>>of
>>>>> > > Lucene.net
>>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>> porting
>>>>> > > new
>>>>> > > > javadoc comments or unit tests right now, due to the vast
>>>>>amount
>>>>> of
>>>>> > code
>>>>> > > > that needs to be written just to get it to compile. If this
>>>>>work
>>>>> ends
>>>>> > up
>>>>> > > > becoming a pull request, great, otherwise it should help
>>>>> accelerate a
>>>>> > > port
>>>>> > > > of 4.3.x since the bulk of the work on core will already be
>>>>>done
>>>>> and
>>>>> > > > contributors can use it as a reference. And again, we're taking
>>>>> the
>>>>> > > > pragmatic approach of porting class-by-class,
>>>>> namespace-by-namespace,
>>>>> > > with
>>>>> > > > the understanding that until we're done the project won't
>>>>>build.
>>>>> > > >
>>>>> > > > Once complete, I also will work on updating the Analyzers
>>>>>contrib
>>>>> > module
>>>>> > > > and porting the QueryParsers contrib module, which I feel
>>>>>should
>>>>> be
>>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>>> library
>>>>> > is
>>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>>> without
>>>>> > > them.
>>>>> > > > You can check out the code on my fork/branch here:
>>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > >
>>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>> For the
>>>>> > > MMap
>>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>>> > > > MemoryMappedFile support which should emulate the Java nio
>>>>>stuff
>>>>> pretty
>>>>> > > > well, but required some creative shuffling of the code to make
>>>>>it
>>>>> work
>>>>> > > due
>>>>> > > > to lifecycle management.
>>>>> > > >
>>>>> > > > I'll update again this weekend or next week, when we should
>>>>>have
>>>>> > wrapped
>>>>> > > up
>>>>> > > > most of the main hacking on porting the core code.
>>>>> > > >
>>>>> > > > Paul
>>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin
>>>>><pirwin@feature23.com
>>>>> >
>>>>> > > wrote:
>>>>> > > >
>>>>> > > > > Marcos,
>>>>> > > > >
>>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java
>>>>>code
>>>>> is
>>>>> > only
>>>>> > > on
>>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>>> together:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>> > > > >
>>>>> > > > > The SVN for 4.3 java is here:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>> > > > > And the GitHub for 4.3 java is here:
>>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>> > > > >
>>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>> > > > >
>>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>>> remote
>>>>> > > > merging
>>>>> > > > > their changes in from their forks while they fetch/merge from
>>>>> mine to
>>>>> > > get
>>>>> > > > > everyone else's changes, rather than using pull requests.
>>>>>James
>>>>> and I
>>>>> > > > have
>>>>> > > > > been working the past few days on the Util namespace ahead of
>>>>> > tonight's
>>>>> > > > > hackathon since that namespace is in common with the rest of
>>>>>the
>>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know
>>>>>of
>>>>> > hacking
>>>>> > > on
>>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>>> namespace.
>>>>> > > > Since
>>>>> > > > > we're going class-by-class, namespace-by-namespace, the
>>>>>project
>>>>> does
>>>>> > > not
>>>>> > > > > build as it is. Once we finish doing a translation of each
>>>>> file, then
>>>>> > > > we'll
>>>>> > > > > hammer out any remaining issues and get it to build again.
>>>>>I'm
>>>>> hoping
>>>>> > > > that
>>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>>> > > > >
>>>>> > > > > But one thing to keep in mind is it looks like much
>>>>> functionality has
>>>>> > > > been
>>>>> > > > > moved out of core into the contrib modules, especially around
>>>>> > analysis,
>>>>> > > > for
>>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>>> anymore.
>>>>> > So
>>>>> > > > when
>>>>> > > > > this is all done, we may want to include at least the
>>>>>analysis
>>>>> > contrib
>>>>> > > > > module in with the standard core NuGet package, because
>>>>> otherwise
>>>>> > it's
>>>>> > > > > practically useless unless you roll your own analyzer.
>>>>> > > > >
>>>>> > > > > Paul
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>> > marcoslimagon@gmail.com
>>>>> > > > >wrote:
>>>>> > > > >
>>>>> > > > >> Hi everyone!
>>>>> > > > >>
>>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>>> > > Lucene(java)?
>>>>> > > > >>
>>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>> 4.3.0 and
>>>>> > > > make
>>>>> > > > >> the diff between then and get all changes between
>>>>>releases... I
>>>>> > gonna
>>>>> > > > >> publish it here soon. (If you think there is another
>>>>>important
>>>>> > > release,
>>>>> > > > >> let
>>>>> > > > >> me know)
>>>>> > > > >>
>>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>> with
>>>>> > 4.3.0
>>>>> > > > >> port
>>>>> > > > >> for .Net on github (last email)?
>>>>> > > > >>
>>>>> > > > >> See you,
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>> > > > >>
>>>>> > > > >> > Thanks for the discussion points, Michael.
>>>>> > > > >> >
>>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>>> portable
>>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
>>>>>4.3+
>>>>> is
>>>>> > > > >> completed.
>>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>>> That's
>>>>> > just
>>>>> > > > my
>>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x
>>>>>features.
>>>>> > > > >> >
>>>>> > > > >> > I have started porting the changes from the core library
>>>>> (from the
>>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>>> separate
>>>>> > > > branch.
>>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>>> port
>>>>> > > until
>>>>> > > > >> > there's changes to pull from upstream to work from. Also
>>>>>due
>>>>> to my
>>>>> > > > time
>>>>> > > > >> > constraints, I am not fully documenting new methods that
>>>>>I'm
>>>>> > adding.
>>>>> > > > >> But if
>>>>> > > > >> > anyone wants to pull/copy/reference my changes while
>>>>>porting,
>>>>> > that's
>>>>> > > > >> > awesome. My branch currently does not build as I'm
>>>>>primarily
>>>>> going
>>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>>> get the
>>>>> > > ball
>>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>>> join
>>>>> > in.
>>>>> > > > But
>>>>> > > > >> > hopefully my work will be useful to someone, if not as a
>>>>>pull
>>>>> > > request
>>>>> > > > >> then
>>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>>> this week
>>>>> > > > with
>>>>> > > > >> my
>>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>>> > comparing
>>>>> > > > >> files
>>>>> > > > >> > and making changes as necessary, rather than starting from
>>>>> > scratch.
>>>>> > > My
>>>>> > > > >> > repo/branch is here:
>>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > > >> >
>>>>> > > > >> > Paul
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>>> > > > >> >
>>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>>> apache
>>>>> > > > >> > maintains.
>>>>> > > > >> > >
>>>>> > > > >> > > The was some work at one time to move the official svn
>>>>> > repository
>>>>> > > to
>>>>> > > > >> > start
>>>>> > > > >> > > using git one instead. Was that actually finalized or
>>>>>not?
>>>>> > > > >> > >
>>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
>>>>>to
>>>>> see
>>>>> > > what
>>>>> > > > >> kind
>>>>> > > > >> > of
>>>>> > > > >> > > work was involved using a portable libraries project.
>>>>>Some
>>>>> of it
>>>>> > > can
>>>>> > > > >> > still
>>>>> > > > >> > > be used but will need to be validated against the
>>>>>current
>>>>> > version
>>>>> > > of
>>>>> > > > >> > Java's
>>>>> > > > >> > > Lucene. It was also using .net 4.
>>>>> > > > >> > >
>>>>> > > > >> > > clean branch vs current. Its going to depend on
>>>>>what we
>>>>> > > support.
>>>>> > > > >> If
>>>>> > > > >> > you
>>>>> > > > >> > > support windows mobile 8, win RT, then the current code
>>>>>in
>>>>> trunk
>>>>> > > > will
>>>>> > > > >> not
>>>>> > > > >> > > compile against those versions of the framework which
>>>>> would a
>>>>> > > > >> frustrating
>>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>>> would
>>>>> > make
>>>>> > > > >> taking
>>>>> > > > >> > > patches very difficult. Supporting those can almost
>>>>>mean
>>>>> larger
>>>>> > > > gaps
>>>>> > > > >> in
>>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>>> > > > >> > >
>>>>> > > > >> > > Also the structure has changed significantly between
>>>>>the
>>>>> > branches
>>>>> > > > and
>>>>> > > > >> > the
>>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java
>>>>>6,
>>>>> and
>>>>> > > seems
>>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>>> cherry
>>>>> > pick
>>>>> > > > >> stuff
>>>>> > > > >> > > from the other tags/branches that would still work as
>>>>>is.
>>>>> A
>>>>> > clean
>>>>> > > > >> branch
>>>>> > > > >> > > would also make it easier to get our build / tool chain
>>>>>in
>>>>> order
>>>>> > > as
>>>>> > > > >> you
>>>>> > > > >> > can
>>>>> > > > >> > > then do them incrementally versus having to do all the
>>>>> stuff
>>>>> > that
>>>>> > > I
>>>>> > > > >> did
>>>>> > > > >> > for
>>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>>> could
>>>>> > > also
>>>>> > > > >> make
>>>>> > > > >> > it
>>>>> > > > >> > > easier to see which classes have been ported or not.
>>>>> > > > >> > >
>>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>>> requires
>>>>> > and
>>>>> > > > the
>>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>>> which
>>>>> > can
>>>>> > > > be
>>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>>> you want
>>>>> > > to
>>>>> > > > >> use
>>>>> > > > >> > > take your legacy code and refactor instead of in
>>>>>someways
>>>>> > starting
>>>>> > > > >> over.
>>>>> > > > >> > >
>>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>> > something
>>>>> > > > >> similar
>>>>> > > > >> > > to
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>>https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene
>>>>>4xPortProgress-Lucene.NetCoreFolders
>>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>>> ported.
>>>>> > > > >> > >
>>>>> > > > >> > > What are we going to support in the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > Who is going to work on the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > What would make the most sense and what would invigorate
>>>>> the
>>>>> > > > >> community to
>>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>>> > > > >> > >
>>>>> > > > >> > > I think those are the questions that would make a lot of
>>>>> the
>>>>> > > > decisions
>>>>> > > > >> > for
>>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > >wrote:
>>>>> > > > >> > >
>>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>>> projects...
>>>>> > > > >> > > >
>>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>> > > > >> > > > https://github.com/apache/lucene.net points to the
>>>>>same
>>>>> > > > repository?
>>>>> > > > >> > > (This
>>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>>> recommend
>>>>> > (i'm
>>>>> > > > used
>>>>> > > > >> > with
>>>>> > > > >> > > > SVN and its patterns).
>>>>> > > > >> > > >
>>>>> > > > >> > > > I'm checking the subversion right now.
>>>>> > > > >> > > >
>>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is
>>>>>a
>>>>> old
>>>>> > > > branch,
>>>>> > > > >> i`m
>>>>> > > > >> > > not
>>>>> > > > >> > > > sure about its current status.
>>>>> > > > >> > > >
>>>>> > > > >> > > > Will we wipe the current solution from /trunk and
>>>>>start
>>>>> a new
>>>>> > > one?
>>>>> > > > >> > > >
>>>>> > > > >> > > > Thanks,
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > 2013/6/6 mherndon michael
>>>>><mh...@michaelherndon.com>
>>>>> > > > >> > > >
>>>>> > > > >> > > > > We may be forced to start with a clean/empty branch
>>>>>if
>>>>> > people
>>>>> > > > >> still
>>>>> > > > >> > > want
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
>>>>>win
>>>>> RT,
>>>>> > > etc.
>>>>> > > > >> The
>>>>> > > > >> > are
>>>>> > > > >> > > > > many
>>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>>> that
>>>>> > > would
>>>>> > > > >> not
>>>>> > > > >> > be
>>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>>> It also
>>>>> > > > might
>>>>> > > > >> > > > require
>>>>> > > > >> > > > > a design that differs even more from its parent
>>>>> project.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > It might be wise to poll what users most desire in
>>>>>the
>>>>> next
>>>>> > > > >> version
>>>>> > > > >> > > > through
>>>>> > > > >> > > > > jira or user voice.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>> > > > >> > itamar@code972.com
>>>>> > > > >> > > > > >wrote:
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > > inline
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>> > > > >> pirwin@feature23.com>
>>>>> > > > >> > > > wrote:
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
>>>>>been
>>>>> a TFS
>>>>> > > guy
>>>>> > > > >> for
>>>>> > > > >> > so
>>>>> > > > >> > > > > long
>>>>> > > > >> > > > > > > :-)
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>>> patches
>>>>> > or
>>>>> > > > >> > anything
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > > the
>>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
>>>>>will
>>>>> > branch
>>>>> > > > from
>>>>> > > > >> > for
>>>>> > > > >> > > 4x
>>>>> > > > >> > > > > > dev.
>>>>> > > > >> > > > > > > Correct?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>>> anyone
>>>>> > > will
>>>>> > > > >> be
>>>>> > > > >> > > > > > interested in that
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
>>>>>deal
>>>>> with
>>>>> > > the
>>>>> > > > >> > github
>>>>> > > > >> > > > > sync?
>>>>> > > > >> > > > > > > Who could diagnose that?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>>> apache
>>>>> > repo
>>>>> > > > for
>>>>> > > > >> now
>>>>> > > > >> > > > while
>>>>> > > > >> > > > > > we get that sorted out.
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
>>>>>Syn-Hershko
>>>>> <
>>>>> > > > >> > > > itamar@code972.com
>>>>> > > > >> > > > > > > >wrote:
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>>> then for
>>>>> > > 3.x
>>>>> > > > >> > > > > development.
>>>>> > > > >> > > > > > > WRT
>>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>>> whatever
>>>>> > > branch.
>>>>> > > > >> When
>>>>> > > > >> > > you
>>>>> > > > >> > > > > > send
>>>>> > > > >> > > > > > > us
>>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>>> dedicated
>>>>> > > repo.
>>>>> > > > >> For
>>>>> > > > >> > > now
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of
>>>>>git.
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>>> it on
>>>>> > the
>>>>> > > > >> apache
>>>>> > > > >> > > > > servers
>>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>> > > > >> > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > wrote:
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>>> 4.3
>>>>> > > version
>>>>> > > > >> of
>>>>> > > > >> > the
>>>>> > > > >> > > > > > > Analysis
>>>>> > > > >> > > > > > > > > namespace.
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>>> intended
>>>>> > --
>>>>> > > > you
>>>>> > > > >> > might
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > meant
>>>>> > > > >> > > > > > > > > trunk instead of master, and that would
>>>>>create
>>>>> a new
>>>>> > > > "3x"
>>>>> > > > >> > > branch,
>>>>> > > > >> > > > > > when
>>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that
>>>>>would be
>>>>> > > > >> misnamed...
>>>>> > > > >> > so
>>>>> > > > >> > > > > maybe
>>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>>> aiming
>>>>> > for
>>>>> > > > >> lucene
>>>>> > > > >> > > > 4.3.x
>>>>> > > > >> > > > > > > > > compatibility?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>>> > upstream
>>>>> > > > >> want to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > the
>>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>>> not all
>>>>> > > > >> trying to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > them
>>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Paul
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>> Syn-Hershko <
>>>>> > > > >> > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > > Unless people here have a specific reason
>>>>>to
>>>>> use
>>>>> > > > 3.6.2 I
>>>>> > > > >> > > would
>>>>> > > > >> > > > > > highly
>>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>>> towards v4
>>>>> > > > >> > otherwise
>>>>> > > > >> > > we
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > never
>>>>> > > > >> > > > > > > > > > make it...
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or
>>>>>github
>>>>> (same
>>>>> > > > repo,
>>>>> > > > >> > > > different
>>>>> > > > >> > > > > > > > > remotes)
>>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>>> should
>>>>> > > work
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
>>>>>Irwin <
>>>>> > > > >> > > > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > wrote:
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Itamar,
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the
>>>>>best
>>>>> way to
>>>>> > > do
>>>>> > > > >> it, I
>>>>> > > > >> > > > just
>>>>> > > > >> > > > > > > > thought
>>>>> > > > >> > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > was the "decision" that was made from
>>>>>the
>>>>> > > discussion
>>>>> > > > >> > > > previously
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > > the
>>>>> > > > >> > > > > > > > > > 4.x
>>>>> > > > >> > > > > > > > > > > work. An incremental approach will be
>>>>>much
>>>>> > better.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>>> branch on
>>>>> > > my
>>>>> > > > >> fork
>>>>> > > > >> > > and
>>>>> > > > >> > > > > will
>>>>> > > > >> > > > > > > > begin
>>>>> > > > >> > > > > > > > > > > working on bringing the Analysis
>>>>>namespace
>>>>> up to
>>>>> > > > >> speed to
>>>>> > > > >> > > > > 3.6.2.
>>>>> > > > >> > > > > > If
>>>>> > > > >> > > > > > > > > > anyone
>>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts
>>>>>once
>>>>> I'm
>>>>> > > done,
>>>>> > > > >> have
>>>>> > > > >> > at
>>>>> > > > >> > > > it.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>>> branch_3x
>>>>> > > > branch,
>>>>> > > > >> > > please
>>>>> > > > >> > > > > let
>>>>> > > > >> > > > > > > me
>>>>> > > > >> > > > > > > > > know
>>>>> > > > >> > > > > > > > > > > what I should have branched from
>>>>>(trunk?)
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Paul
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>> > > Syn-Hershko <
>>>>> > > > >> > > > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>>> again :)
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>>> know
>>>>> > what
>>>>> > > > it
>>>>> > > > >> > would
>>>>> > > > >> > > > > take
>>>>> > > > >> > > > > > > > until
>>>>> > > > >> > > > > > > > > > they
>>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and
>>>>>even
>>>>> then
>>>>> > > > >> decisions
>>>>> > > > >> > > > could
>>>>> > > > >> > > > > > and
>>>>> > > > >> > > > > > > > will
>>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>>> > starting
>>>>> > > > from
>>>>> > > > >> > > > scratch,
>>>>> > > > >> > > > > > > > > although
>>>>> > > > >> > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > do
>>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>>> should
>>>>> > > > change,
>>>>> > > > >> but
>>>>> > > > >> > > its
>>>>> > > > >> > > > > > going
>>>>> > > > >> > > > > > > > to
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>>> refactoring
>>>>> > > > where
>>>>> > > > >> > > > needed,
>>>>> > > > >> > > > > > than
>>>>> > > > >> > > > > > > > > > > starting
>>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
>>>>>off I
>>>>> > > > personally
>>>>> > > > >> > will
>>>>> > > > >> > > > be
>>>>> > > > >> > > > > > > happy
>>>>> > > > >> > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > you
>>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>>> porting
>>>>> > > it,
>>>>> > > > >> its
>>>>> > > > >> > > > pretty
>>>>> > > > >> > > > > > > much
>>>>> > > > >> > > > > > > > > self
>>>>> > > > >> > > > > > > > > > > > contained.
>>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that
>>>>>on
>>>>> a fork
>>>>> > > and
>>>>> > > > >> send
>>>>> > > > >> > > us
>>>>> > > > >> > > > > PRs,
>>>>> > > > >> > > > > > > its
>>>>> > > > >> > > > > > > > > > much
>>>>> > > > >> > > > > > > > > > > > more straight forward than the v4
>>>>>upgrade
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>>> fastest
>>>>> > > way
>>>>> > > > >> to do
>>>>> > > > >> > > > this,
>>>>> > > > >> > > > > > we
>>>>> > > > >> > > > > > > > can
>>>>> > > > >> > > > > > > > > > then
>>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
>>>>>optimizing
>>>>> using
>>>>> > > > .NET
>>>>> > > > >> > > > > constructs.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>>> create a
>>>>> > > > branch
>>>>> > > > >> out
>>>>> > > > >> > > of
>>>>> > > > >> > > > > the
>>>>> > > > >> > > > > > > > > current
>>>>> > > > >> > > > > > > > > > > git
>>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
>>>>>start
>>>>> > > working
>>>>> > > > on
>>>>> > > > >> > > master
>>>>> > > > >> > > > > > > > towards a
>>>>> > > > >> > > > > > > > > > 4.3
>>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>>> should be
>>>>> > > > using
>>>>> > > > >> a
>>>>> > > > >> > > > process
>>>>> > > > >> > > > > > > that
>>>>> > > > >> > > > > > > > > > > ensures
>>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>>> tests,
>>>>> > > and
>>>>> > > > >> that
>>>>> > > > >> > > > those
>>>>> > > > >> > > > > > > tests
>>>>> > > > >> > > > > > > > > > pass -
>>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
>>>>>code
>>>>> to
>>>>> > our
>>>>> > > > >> > > > repositories.
>>>>> > > > >> > > > > > The
>>>>> > > > >> > > > > > > > > > process
>>>>> > > > >> > > > > > > > > > > > should probably be working on classes
>>>>>in
>>>>> some
>>>>> > > > order
>>>>> > > > >> > > > > > > > (alphabetically,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>>> class to
>>>>> > > > >> compile
>>>>> > > > >> > > > before
>>>>> > > > >> > > > > > > moving
>>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the
>>>>>project
>>>>> not
>>>>> > > being
>>>>> > > > >> > > > compilable
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > a
>>>>> > > > >> > > > > > > > > > month
>>>>> > > > >> > > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > two.
>>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>>> .NETifying and
>>>>> > > > >> proofing
>>>>> > > > >> > > the
>>>>> > > > >> > > > > code
>>>>> > > > >> > > > > > > can
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > started, at which point we will
>>>>>already
>>>>> have a
>>>>> > > > >> working
>>>>> > > > >> > v4
>>>>> > > > >> > > > > > version
>>>>> > > > >> > > > > > > > so
>>>>> > > > >> > > > > > > > > it
>>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the
>>>>>Java
>>>>> > project.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>>> test
>>>>> > > suite
>>>>> > > > so
>>>>> > > > >> > > tests
>>>>> > > > >> > > > > > could
>>>>> > > > >> > > > > > > > more
>>>>> > > > >> > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>>> implementing
>>>>> > > > >> Java-like
>>>>> > > > >> > > > > > > assertEquals
>>>>> > > > >> > > > > > > > > > > methods
>>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>>> work
>>>>> > with
>>>>> > > > >> than
>>>>> > > > >> > > > > NUnit). I
>>>>> > > > >> > > > > > > > > already
>>>>> > > > >> > > > > > > > > > > did
>>>>> > > > >> > > > > > > > > > > > some work there but there's still a
>>>>>lot
>>>>> to do.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>>> myself at
>>>>> > > this
>>>>> > > > >> > point,
>>>>> > > > >> > > > > but I
>>>>> > > > >> > > > > > > > > should
>>>>> > > > >> > > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>>> point I
>>>>> > can
>>>>> > > > >> > dedicate
>>>>> > > > >> > > > > > several
>>>>> > > > >> > > > > > > > > > hours a
>>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to
>>>>>watch
>>>>> > closely
>>>>> > > > and
>>>>> > > > >> > even
>>>>> > > > >> > > > > > > coordinate
>>>>> > > > >> > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM,
>>>>>Marcos
>>>>> Lima <
>>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this
>>>>>is a
>>>>> kick
>>>>> > > > start
>>>>> > > > >> > =). I
>>>>> > > > >> > > > > > haven't
>>>>> > > > >> > > > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you
>>>>>all
>>>>> to get
>>>>> > > > this
>>>>> > > > >> job
>>>>> > > > >> > > > done.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>>> Prescott.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I know that there is a high
>>>>>commitment
>>>>> for
>>>>> > > keep
>>>>> > > > >> the
>>>>> > > > >> > > > > > > > > > retrocompatibility
>>>>> > > > >> > > > > > > > > > > on
>>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets
>>>>>big
>>>>> > changes
>>>>> > > > >> every
>>>>> > > > >> > > > > release?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
>>>>>stable
>>>>> > version
>>>>> > > > >> from a
>>>>> > > > >> > > > > Lucene
>>>>> > > > >> > > > > > > > > version,
>>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>>> minor
>>>>> > > changes
>>>>> > > > >> > every
>>>>> > > > >> > > > > stable
>>>>> > > > >> > > > > > > > > release
>>>>> > > > >> > > > > > > > > > > (or
>>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
>>>>>could
>>>>> > > compare
>>>>> > > > >> the
>>>>> > > > >> > > > > versions,
>>>>> > > > >> > > > > > > > check
>>>>> > > > >> > > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>>> Lucene.Net.
>>>>> > > > Again, I
>>>>> > > > >> > > > haven't
>>>>> > > > >> > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is
>>>>>(just an
>>>>> > idea).
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>>> simple
>>>>> > > > >> performance
>>>>> > > > >> > > > > > > > improvements
>>>>> > > > >> > > > > > > > > > > > (without
>>>>> > > > >> > > > > > > > > > > > > adding references or changing
>>>>>methods
>>>>> > > > signatures)?
>>>>> > > > >> > Does
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > could
>>>>> > > > >> > > > > > > > be
>>>>> > > > >> > > > > > > > > > > done,
>>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>>> pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>>> suggestion as I
>>>>> > > > >> haven't
>>>>> > > > >> > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
>>>>>help
>>>>> with
>>>>> > > the
>>>>> > > > >> 4.x
>>>>> > > > >> > > work
>>>>> > > > >> > > > > as I
>>>>> > > > >> > > > > > > > have
>>>>> > > > >> > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > vested
>>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>>> completed. I
>>>>> > > think
>>>>> > > > >> > there
>>>>> > > > >> > > > > should
>>>>> > > > >> > > > > > > be
>>>>> > > > >> > > > > > > > > one
>>>>> > > > >> > > > > > > > > > > > person
>>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>>> > structure
>>>>> > > > and
>>>>> > > > >> > > > workflow
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > look
>>>>> > > > >> > > > > > > > > > > like
>>>>> > > > >> > > > > > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>>> going to
>>>>> > be
>>>>> > > > >> > starting
>>>>> > > > >> > > > from
>>>>> > > > >> > > > > > > > scratch
>>>>> > > > >> > > > > > > > > > as
>>>>> > > > >> > > > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>>> up the
>>>>> > > > >> project,
>>>>> > > > >> > > get
>>>>> > > > >> > > > > > > > everything
>>>>> > > > >> > > > > > > > > > > going
>>>>> > > > >> > > > > > > > > > > > > in
>>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>>> > structure,
>>>>> > > > >> maybe
>>>>> > > > >> > > stub
>>>>> > > > >> > > > > out
>>>>> > > > >> > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > classes,
>>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>>> anyone
>>>>> > > > >> interested
>>>>> > > > >> > > in
>>>>> > > > >> > > > > > > > > > contributing,
>>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
>>>>>java
>>>>> code
>>>>> > in
>>>>> > > > >> there
>>>>> > > > >> > so
>>>>> > > > >> > > > > it's
>>>>> > > > >> > > > > > > easy
>>>>> > > > >> > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > reference.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>>> Lucene.Net.Documents,
>>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>>> those
>>>>> > are
>>>>> > > > >> just
>>>>> > > > >> > the
>>>>> > > > >> > > > > ones
>>>>> > > > >> > > > > > > I'm
>>>>> > > > >> > > > > > > > > most
>>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>>> Tell me
>>>>> > > what
>>>>> > > > >> to
>>>>> > > > >> > do
>>>>> > > > >> > > > and
>>>>> > > > >> > > > > > I'll
>>>>> > > > >> > > > > > > > get
>>>>> > > > >> > > > > > > > > > > > started
>>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>>> Prescott
>>>>> > > > Nasser
>>>>> > > > >> <
>>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>>> while. We
>>>>> > > > have a
>>>>> > > > >> > > board
>>>>> > > > >> > > > > > report
>>>>> > > > >> > > > > > > > due
>>>>> > > > >> > > > > > > > > > > soon
>>>>> > > > >> > > > > > > > > > > > -
>>>>> > > > >> > > > > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>>> them
>>>>> > that
>>>>> > > we
>>>>> > > > >> seem
>>>>> > > > >> > > to
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > > stalled
>>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging
>>>>>items
>>>>> out of
>>>>> > > of
>>>>> > > > >> jira
>>>>> > > > >> > > and
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > been
>>>>> > > > >> > > > > > > > > > > > > responsive
>>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>>> > > questions,
>>>>> > > > >> but I
>>>>> > > > >> > > > don't
>>>>> > > > >> > > > > > > think
>>>>> > > > >> > > > > > > > > > we've
>>>>> > > > >> > > > > > > > > > > > > done
>>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
>>>>>4.0.
>>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
>>>>>and
>>>>> > start
>>>>> > > us
>>>>> > > > >> back
>>>>> > > > >> > > up
>>>>> > > > >> > > > > > moving
>>>>> > > > >> > > > > > > > > > > forward.
>>>>> > > > >> > > > > > > > > > > > > What
>>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>>> this? If
>>>>> > we
>>>>> > > > took
>>>>> > > > >> > the
>>>>> > > > >> > > > java
>>>>> > > > >> > > > > > > > lucene
>>>>> > > > >> > > > > > > > > > 4.0
>>>>> > > > >> > > > > > > > > > > > code
>>>>> > > > >> > > > > > > > > > > > > > and
>>>>> > > > >> > > > > > > > > > > > > > > committed that java to our
>>>>>branch
>>>>> and
>>>>> > then
>>>>> > > > >> just
>>>>> > > > >> > let
>>>>> > > > >> > > > > > people
>>>>> > > > >> > > > > > > > pull
>>>>> > > > >> > > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > > > down
>>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying
>>>>>is
>>>>> that
>>>>> > one
>>>>> > > > >> way to
>>>>> > > > >> > > > maybe
>>>>> > > > >> > > > > > > make
>>>>> > > > >> > > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > > forward
>>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > --
>>>>> > > > >> > > > --
>>>>> > > > >> > > > Marcos Lima
>>>>> > > > >> > > > Software Developer/Tech Lead
>>>>> > > > >> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> --
>>>>> > > > >> --
>>>>> > > > >> Marcos Lima
>>>>> > > > >> Software Developer/Tech Lead
>>>>> > > > >> marcoslimagon@gmail.com
>>>>> > > > >> tel: +55 (19) 9798-9335
>>>>> > > > >>
>>>>> > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
Re: Lucene 4.0
Posted by lo...@gmail.com.
Paul,
Paul,
I will work with you to integrate your code into the project repository. Do you have a contributor's agreement filed with the apache foundation?
Do you have a status of where you are and what else needs to get done? Also is there any specific help you need?
Scott
On Aug 8, 2013, at 4:54 PM, Itamar Syn-Hershko <it...@code972.com> wrote:
> Paul, people in the list are busy or in vacation. This doesn't mean the
> project is dead, especially since users like you keep lending a hand and
> help it move forward.
>
> I'll try to jump in soon, but you and your colleagues seem to be doing just
> fine. If you need anything from the project's resources, or when you think
> you are ready for a release, let us know.
>
>
> On Thu, Aug 8, 2013 at 10:31 PM, Paul Irwin <pi...@feature23.com> wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>> to
>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>
>>> Now it works after re-indexing with a quick, dirty implementation of
>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>> to
>>> find out why NumericRangeQuery isn't working.
>>>
>>> Sorry for the blast of emails, but I wanted to prevent people from
>>> spending time hunting down my mistake!
>>>
>>>
>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>> wrote:
>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>> byte being signed is a pain.
>>>>
>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>> results. It doesn't find any terms when scanning for them. I also tried
>> a
>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>> didn't find any results that way either. So right now only
>>>> MatchAllDocsQuery seems to work.
>>>>
>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>> into it, let me know.
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>> wrote:
>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>> described. When you've been debugging through
>> CorruptedIndexExceptions, you
>>>>> get a little bit of tunnel vision... haha
>>>>>
>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>> .ToString()'ing
>>>>> the matching documents prints the fields to the console, so it's
>> loading in
>>>>> the stored fields data correctly.
>>>>>
>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>> that
>>>>> I can't figure out. There's a whole bunch of buffered byte array
>> operations
>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>> would be great. Here's example index writing and then reading code
>> (also
>>>>> included is a quick port of KeywordAnalyzer):
>>>>> https://gist.github.com/anonymous/6174164
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
>> itamar@code972.com>wrote:
>>>>>
>>>>>> Great
>>>>>>
>>>>>> You can build you Query objects on your own to execute a search, you
>>>>>> don't
>>>>>> actually have to use QueryParser for that
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey all, sorry it's been a little while, but I wanted to let you
>> know
>>>>>> that
>>>>>>> although I took a few weeks off from it, I now have a 4.3.1
>> equivalent
>>>>>>> Lucene.net core building and able to write a simple index in Lucene
>>>>>> 4.2
>>>>>>> codec and read in things like the number of documents and whatnot.
>>>>>> Since
>>>>>>> QueryParser has been moved to a separate module in Lucene Java 4.x,
>> I
>>>>>>> haven't ported that yet so I haven't done a real search, and I only
>>>>>> built
>>>>>>> the index using a quick port of KeywordAnalyzer which all those
>>>>>> analyzers
>>>>>>> have also moved to another module. But this is definitely good
>>>>>> progress and
>>>>>>> should be a launch point for finishing a 4.3/4.4 port.
>>>>>>>
>>>>>>> You can see my fork/branch here:
>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>>> like I
>>>>>>> said, only core builds now, no modules/tests build, so only open the
>>>>>>> Lucene.Net.Core.sln)
>>>>>>>
>>>>>>> I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>>> the
>>>>>>> community into finishing the 4.3/4.4 port. Let me know if you have
>> any
>>>>>>> questions, thanks!
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>>> itamar@code972.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Paul, that's awesome. I will need some more time to go over this
>>>>>> thread
>>>>>>> and
>>>>>>>> your work to give actual feedback, SUPER busy at the moment
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pirwin@feature23.com
>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> My colleagues and I have made good progress on porting Lucene
>>>>>> 4.3's
>>>>>>> core
>>>>>>>>> library before, during, and after the hackathon last week. We
>> now
>>>>>> only
>>>>>>>> have
>>>>>>>>> some remaining items in Search, Index, and Codecs namespaces
>>>>>> (plus a
>>>>>>> few
>>>>>>>>> other minor ones here and there). I expect to be done by the end
>>>>>> of the
>>>>>>>>> weekend. Analysis, Documents, Store, Util (except some FST and
>>>>>> Packed),
>>>>>>>> and
>>>>>>>>> the root Codecs and Codecs.PerField namespaces are all now
>> "done".
>>>>>>>>>
>>>>>>>>> Again, my goal is to only get a buildable, experimental build of
>>>>>>>> Lucene.net
>>>>>>>>> with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>>> porting
>>>>>>>> new
>>>>>>>>> javadoc comments or unit tests right now, due to the vast amount
>>>>>> of
>>>>>>> code
>>>>>>>>> that needs to be written just to get it to compile. If this work
>>>>>> ends
>>>>>>> up
>>>>>>>>> becoming a pull request, great, otherwise it should help
>>>>>> accelerate a
>>>>>>>> port
>>>>>>>>> of 4.3.x since the bulk of the work on core will already be done
>>>>>> and
>>>>>>>>> contributors can use it as a reference. And again, we're taking
>>>>>> the
>>>>>>>>> pragmatic approach of porting class-by-class,
>>>>>> namespace-by-namespace,
>>>>>>>> with
>>>>>>>>> the understanding that until we're done the project won't build.
>>>>>>>>>
>>>>>>>>> Once complete, I also will work on updating the Analyzers
>> contrib
>>>>>>> module
>>>>>>>>> and porting the QueryParsers contrib module, which I feel should
>>>>>> be
>>>>>>>>> included in the core NuGet package for Lucene.net as the core
>>>>>> library
>>>>>>> is
>>>>>>>>> now (post-4.0) practically useless (or atleast not turn-key)
>>>>>> without
>>>>>>>> them.
>>>>>>>>> You can check out the code on my fork/branch here:
>>>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>>>>>>
>>>>>>>>> In particular, I'd like some feedback on my work on ByteBuffer,
>>>>>>>>> MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>>> For the
>>>>>>>> MMap
>>>>>>>>> support, I created a ByteBuffer subclass that uses .NET 4's
>>>>>>>>> MemoryMappedFile support which should emulate the Java nio stuff
>>>>>> pretty
>>>>>>>>> well, but required some creative shuffling of the code to make
>> it
>>>>>> work
>>>>>>>> due
>>>>>>>>> to lifecycle management.
>>>>>>>>>
>>>>>>>>> I'll update again this weekend or next week, when we should have
>>>>>>> wrapped
>>>>>>>> up
>>>>>>>>> most of the main hacking on porting the core code.
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>> On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
>> pirwin@feature23.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Marcos,
>>>>>>>>>>
>>>>>>>>>> That would be helpful. As far as I can tell, the 3.0 java code
>>>>>> is
>>>>>>> only
>>>>>>>> on
>>>>>>>>>> SVN here, before the lucene and solr projects were bundled
>>>>>> together:
>>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>>>>>>>
>>>>>>>>>> The SVN for 4.3 java is here:
>>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>>>>>>> And the GitHub for 4.3 java is here:
>>>>>>>>>> https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>>>>>>>
>>>>>>>>>> My fork/branch of Lucene.net for the 4.3 port is here:
>>>>>>>>>> https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>>>>>>>
>>>>>>>>>> My fork is the "upstream" fork for my team members, and i'm
>>>>>> remote
>>>>>>>>> merging
>>>>>>>>>> their changes in from their forks while they fetch/merge from
>>>>>> mine to
>>>>>>>> get
>>>>>>>>>> everyone else's changes, rather than using pull requests.
>> James
>>>>>> and I
>>>>>>>>> have
>>>>>>>>>> been working the past few days on the Util namespace ahead of
>>>>>>> tonight's
>>>>>>>>>> hackathon since that namespace is in common with the rest of
>> the
>>>>>>>>>> namespaces. Tonight, we'll have at least 8 guys that I know of
>>>>>>> hacking
>>>>>>>> on
>>>>>>>>>> porting 4.3, each with a different namespace or part of a
>>>>>> namespace.
>>>>>>>>> Since
>>>>>>>>>> we're going class-by-class, namespace-by-namespace, the
>> project
>>>>>> does
>>>>>>>> not
>>>>>>>>>> build as it is. Once we finish doing a translation of each
>>>>>> file, then
>>>>>>>>> we'll
>>>>>>>>>> hammer out any remaining issues and get it to build again. I'm
>>>>>> hoping
>>>>>>>>> that
>>>>>>>>>> we can get at least 75% done with Core tonight. Wish us luck!
>>>>>>>>>>
>>>>>>>>>> But one thing to keep in mind is it looks like much
>>>>>> functionality has
>>>>>>>>> been
>>>>>>>>>> moved out of core into the contrib modules, especially around
>>>>>>> analysis,
>>>>>>>>> for
>>>>>>>>>> 4.0+. For example, there are no built-in analyzers in core
>>>>>> anymore.
>>>>>>> So
>>>>>>>>> when
>>>>>>>>>> this is all done, we may want to include at least the analysis
>>>>>>> contrib
>>>>>>>>>> module in with the standard core NuGet package, because
>>>>>> otherwise
>>>>>>> it's
>>>>>>>>>> practically useless unless you roll your own analyzer.
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi everyone!
>>>>>>>>>>>
>>>>>>>>>>> Does someone know where can I find the 3.0.3 release from
>>>>>>>> Lucene(java)?
>>>>>>>>>>>
>>>>>>>>>>> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>>> 4.3.0 and
>>>>>>>>> make
>>>>>>>>>>> the diff between then and get all changes between
>> releases... I
>>>>>>> gonna
>>>>>>>>>>> publish it here soon. (If you think there is another
>> important
>>>>>>>> release,
>>>>>>>>>>> let
>>>>>>>>>>> me know)
>>>>>>>>>>>
>>>>>>>>>>> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>>> with
>>>>>>> 4.3.0
>>>>>>>>>>> port
>>>>>>>>>>> for .Net on github (last email)?
>>>>>>>>>>>
>>>>>>>>>>> See you,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the discussion points, Michael.
>>>>>>>>>>>>
>>>>>>>>>>>> I would vote for not worrying about trying to achieve
>>>>>> portable
>>>>>>>>>>>> compatibility for WP8/WinRT/etc until *after* a port to
>> 4.3+
>>>>>> is
>>>>>>>>>>> completed.
>>>>>>>>>>>> Otherwise it may delay the project and stall it further.
>>>>>> That's
>>>>>>> just
>>>>>>>>> my
>>>>>>>>>>>> $0.02 based on my admittedly selfish need for 4.x features.
>>>>>>>>>>>>
>>>>>>>>>>>> I have started porting the changes from the core library
>>>>>> (from the
>>>>>>>>>>>> java lucene_solr_4_3 branch) in my fork on github in a
>>>>>> separate
>>>>>>>>> branch.
>>>>>>>>>>>> Since I need 4.3 ASAP, I am just going to keep going on my
>>>>>> port
>>>>>>>> until
>>>>>>>>>>>> there's changes to pull from upstream to work from. Also
>> due
>>>>>> to my
>>>>>>>>> time
>>>>>>>>>>>> constraints, I am not fully documenting new methods that
>> I'm
>>>>>>> adding.
>>>>>>>>>>> But if
>>>>>>>>>>>> anyone wants to pull/copy/reference my changes while
>> porting,
>>>>>>> that's
>>>>>>>>>>>> awesome. My branch currently does not build as I'm
>> primarily
>>>>>> going
>>>>>>>>>>>> class-by-class, starting with the util namespace. Once we
>>>>>> get the
>>>>>>>> ball
>>>>>>>>>>>> rolling on a community effort, I'll stop my rogue work and
>>>>>> join
>>>>>>> in.
>>>>>>>>> But
>>>>>>>>>>>> hopefully my work will be useful to someone, if not as a
>> pull
>>>>>>>> request
>>>>>>>>>>> then
>>>>>>>>>>>> as a reference. I'm also going to be holding a hackathon
>>>>>> this week
>>>>>>>>> with
>>>>>>>>>>> my
>>>>>>>>>>>> colleagues where we're all going to work on the port. I'm
>>>>>>> comparing
>>>>>>>>>>> files
>>>>>>>>>>>> and making changes as necessary, rather than starting from
>>>>>>> scratch.
>>>>>>>> My
>>>>>>>>>>>> repo/branch is here:
>>>>>>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>>>>>>>>>
>>>>>>>>>>>> Paul
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>>>>>>>>> mherndon@michaelherndon.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> the guithub.com repo is a mirror to the git mirror that
>>>>>> apache
>>>>>>>>>>>> maintains.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The was some work at one time to move the official svn
>>>>>>> repository
>>>>>>>> to
>>>>>>>>>>>> start
>>>>>>>>>>>>> using git one instead. Was that actually finalized or
>> not?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Lucene.Net_4e (e for experimental) is an old branch
>> to
>>>>>> see
>>>>>>>> what
>>>>>>>>>>> kind
>>>>>>>>>>>> of
>>>>>>>>>>>>> work was involved using a portable libraries project.
>> Some
>>>>>> of it
>>>>>>>> can
>>>>>>>>>>>> still
>>>>>>>>>>>>> be used but will need to be validated against the current
>>>>>>> version
>>>>>>>> of
>>>>>>>>>>>> Java's
>>>>>>>>>>>>> Lucene. It was also using .net 4.
>>>>>>>>>>>>>
>>>>>>>>>>>>> clean branch vs current. Its going to depend on what
>> we
>>>>>>>> support.
>>>>>>>>>>> If
>>>>>>>>>>>> you
>>>>>>>>>>>>> support windows mobile 8, win RT, then the current code
>> in
>>>>>> trunk
>>>>>>>>> will
>>>>>>>>>>> not
>>>>>>>>>>>>> compile against those versions of the framework which
>>>>>> would a
>>>>>>>>>>> frustrating
>>>>>>>>>>>>> starting point, then you couldn't even run tests, which
>>>>>> would
>>>>>>> make
>>>>>>>>>>> taking
>>>>>>>>>>>>> patches very difficult. Supporting those can almost mean
>>>>>> larger
>>>>>>>>> gaps
>>>>>>>>>>> in
>>>>>>>>>>>>> design between Lucene.Net and its parent project.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also the structure has changed significantly between the
>>>>>>> branches
>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>>> side of the code base of Lucene 4 is bigger, uses Java 6,
>>>>>> and
>>>>>>>> seems
>>>>>>>>>>>>> significantly different. That doesn't mean you can't
>>>>>> cherry
>>>>>>> pick
>>>>>>>>>>> stuff
>>>>>>>>>>>>> from the other tags/branches that would still work as is.
>>>>>> A
>>>>>>> clean
>>>>>>>>>>> branch
>>>>>>>>>>>>> would also make it easier to get our build / tool chain
>> in
>>>>>> order
>>>>>>>> as
>>>>>>>>>>> you
>>>>>>>>>>>> can
>>>>>>>>>>>>> then do them incrementally versus having to do all the
>>>>>> stuff
>>>>>>> that
>>>>>>>> I
>>>>>>>>>>> did
>>>>>>>>>>>> for
>>>>>>>>>>>>> the 3x branch which saps energy and desire to code. It
>>>>>> could
>>>>>>>> also
>>>>>>>>>>> make
>>>>>>>>>>>> it
>>>>>>>>>>>>> easier to see which classes have been ported or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The major downside to a clean branch is extra work it
>>>>>> requires
>>>>>>> and
>>>>>>>>> the
>>>>>>>>>>>>> start up cost in time and energy of getting it in order,
>>>>>> which
>>>>>>> can
>>>>>>>>> be
>>>>>>>>>>>>> daunting / intimidating and lower morale. And generally
>>>>>> you want
>>>>>>>> to
>>>>>>>>>>> use
>>>>>>>>>>>>> take your legacy code and refactor instead of in someways
>>>>>>> starting
>>>>>>>>>>> over.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>>>> something
>>>>>>>>>>> similar
>>>>>>>>>>>>> to
>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>>>>>>>>>>> where it tracks what needs to get ported / what has been
>>>>>> ported.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are we going to support in the next version?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Who is going to work on the next version?
>>>>>>>>>>>>>
>>>>>>>>>>>>> What would make the most sense and what would invigorate
>>>>>> the
>>>>>>>>>>> community to
>>>>>>>>>>>>> get involved more and lower the barrier to entry?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think those are the questions that would make a lot of
>>>>>> the
>>>>>>>>> decisions
>>>>>>>>>>>> for
>>>>>>>>>>>>> us so that we can get back to work on lucene.net.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding the new branch, I'm a rookie with ASF
>>>>>> projects...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>>>>>>>>>>> https://github.com/apache/lucene.net points to the
>> same
>>>>>>>>> repository?
>>>>>>>>>>>>> (This
>>>>>>>>>>>>>> is new for me, pretty good) Which of them do you
>>>>>> recommend
>>>>>>> (i'm
>>>>>>>>> used
>>>>>>>>>>>> with
>>>>>>>>>>>>>> SVN and its patterns).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm checking the subversion right now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can see the branches/Lucene.Net_4e. I think this is a
>>>>>> old
>>>>>>>>> branch,
>>>>>>>>>>> i`m
>>>>>>>>>>>>> not
>>>>>>>>>>>>>> sure about its current status.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Will we wipe the current solution from /trunk and start
>>>>>> a new
>>>>>>>> one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2013/6/6 mherndon michael <mherndon@michaelherndon.com
>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We may be forced to start with a clean/empty branch
>> if
>>>>>>> people
>>>>>>>>>>> still
>>>>>>>>>>>>> want
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> attempt supporting lucene.net for mobile devices,
>> win
>>>>>> RT,
>>>>>>>> etc.
>>>>>>>>>>> The
>>>>>>>>>>>> are
>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>> classes that Lucene.net uses from the full framework
>>>>>> that
>>>>>>>> would
>>>>>>>>>>> not
>>>>>>>>>>>> be
>>>>>>>>>>>>>>> accessible in other versions of the .NET Framework.
>>>>>> It also
>>>>>>>>> might
>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>> a design that differs even more from its parent
>>>>>> project.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It might be wise to poll what users most desire in
>> the
>>>>>> next
>>>>>>>>>>> version
>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>> jira or user voice.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> inline
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ah, I gotcha. Still getting used to git, I've
>> been
>>>>>> a TFS
>>>>>>>> guy
>>>>>>>>>>> for
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So to recap, the branch_3x will be used for any
>>>>>> patches
>>>>>>> or
>>>>>>>>>>>> anything
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> current 3.0.3 release, while trunk is what we
>> will
>>>>>>> branch
>>>>>>>>> from
>>>>>>>>>>>> for
>>>>>>>>>>>>> 4x
>>>>>>>>>>>>>>>> dev.
>>>>>>>>>>>>>>>>> Correct?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes - we can branch from it for 3.6 development if
>>>>>> anyone
>>>>>>>> will
>>>>>>>>>>> be
>>>>>>>>>>>>>>>> interested in that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for pushing the Version.cs. What's the
>> deal
>>>>>> with
>>>>>>>> the
>>>>>>>>>>>> github
>>>>>>>>>>>>>>> sync?
>>>>>>>>>>>>>>>>> Who could diagnose that?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure, Apache Infra, basically. Just use the
>>>>>> apache
>>>>>>> repo
>>>>>>>>> for
>>>>>>>>>>> now
>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>> we get that sorted out.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 6:00 PM, Itamar
>> Syn-Hershko
>>>>>> <
>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ok, haven't noticed that branch. Just use it
>>>>>> then for
>>>>>>>> 3.x
>>>>>>>>>>>>>>> development.
>>>>>>>>>>>>>>>>> WRT
>>>>>>>>>>>>>>>>>> v4, yeah - just fork the repo and work on
>>>>>> whatever
>>>>>>>> branch.
>>>>>>>>>>> When
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>> PRs we will merge either to master or to a
>>>>>> dedicated
>>>>>>>> repo.
>>>>>>>>>>> For
>>>>>>>>>>>>> now
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> doesn't really matter, thats the beauty of git.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I pushed a new Version.cs file, you should see
>>>>>> it on
>>>>>>> the
>>>>>>>>>>> apache
>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>>>> (github sync seems to be off)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Itamar. I can certainly start work on
>>>>>> 4.3
>>>>>>>> version
>>>>>>>>>>> of
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> Analysis
>>>>>>>>>>>>>>>>>>> namespace.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Not sure the checkout command is what you
>>>>>> intended
>>>>>>> --
>>>>>>>>> you
>>>>>>>>>>>> might
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> meant
>>>>>>>>>>>>>>>>>>> trunk instead of master, and that would
>> create
>>>>>> a new
>>>>>>>>> "3x"
>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> there's already a "branch_3x" and that would
>> be
>>>>>>>>>>> misnamed...
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>> checkout -b branch_4x trunk and start there
>>>>>> aiming
>>>>>>> for
>>>>>>>>>>> lucene
>>>>>>>>>>>>>> 4.3.x
>>>>>>>>>>>>>>>>>>> compatibility?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, does someone with commit rights to the
>>>>>>> upstream
>>>>>>>>>>> want to
>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> necessary Version.cs entries, so that we're
>>>>>> not all
>>>>>>>>>>> trying to
>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>> and dealing with a merge?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>>> Syn-Hershko <
>>>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unless people here have a specific reason
>> to
>>>>>> use
>>>>>>>>> 3.6.2 I
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> highly
>>>>>>>>>>>>>>>>>>>> recommed putting all the efforts we can
>>>>>> towards v4
>>>>>>>>>>>> otherwise
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>>>>>> make it...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Fork the repo from apache servers or github
>>>>>> (same
>>>>>>>>> repo,
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>> remotes)
>>>>>>>>>>>>>>>>>>>> and checkout -b 3x -t origin/master , that
>>>>>> should
>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 12:20 AM, Paul
>> Irwin <
>>>>>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Itamar,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I agree that from scratch is not the best
>>>>>> way to
>>>>>>>> do
>>>>>>>>>>> it, I
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> thought
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> was the "decision" that was made from the
>>>>>>>> discussion
>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> 4.x
>>>>>>>>>>>>>>>>>>>>> work. An incremental approach will be
>> much
>>>>>>> better.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've created a branch of the branch_3x
>>>>>> branch on
>>>>>>>> my
>>>>>>>>>>> fork
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> begin
>>>>>>>>>>>>>>>>>>>>> working on bringing the Analysis
>> namespace
>>>>>> up to
>>>>>>>>>>> speed to
>>>>>>>>>>>>>>> 3.6.2.
>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>>> anyone
>>>>>>>>>>>>>>>>>>>>> wants to pull it or just reuse parts once
>>>>>> I'm
>>>>>>>> done,
>>>>>>>>>>> have
>>>>>>>>>>>> at
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If I shouldn't have branched off the
>>>>>> branch_3x
>>>>>>>>> branch,
>>>>>>>>>>>>> please
>>>>>>>>>>>>>>> let
>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>> what I should have branched from (trunk?)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>>>>> Syn-Hershko <
>>>>>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks Prescott for bringing this up
>>>>>> again :)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Paul, the problem is no one can really
>>>>>> know
>>>>>>> what
>>>>>>>>> it
>>>>>>>>>>>> would
>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>> have deep dived into the work, and even
>>>>>> then
>>>>>>>>>>> decisions
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>> change. I will strongly advise against
>>>>>>> starting
>>>>>>>>> from
>>>>>>>>>>>>>> scratch,
>>>>>>>>>>>>>>>>>>> although
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>>> think a lot in the current structure
>>>>>> should
>>>>>>>>> change,
>>>>>>>>>>> but
>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> much easier to change it in place,
>>>>>> refactoring
>>>>>>>>> where
>>>>>>>>>>>>>> needed,
>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>>> starting
>>>>>>>>>>>>>>>>>>>>>> all over again. Once we kicked this
>> off I
>>>>>>>>> personally
>>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> happy
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>> taking the analysis part of Lucene and
>>>>>> porting
>>>>>>>> it,
>>>>>>>>>>> its
>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>> self
>>>>>>>>>>>>>>>>>>>>>> contained.
>>>>>>>>>>>>>>>>>>>>>> Re 3.6.2 work - you can just do that on
>>>>>> a fork
>>>>>>>> and
>>>>>>>>>>> send
>>>>>>>>>>>>> us
>>>>>>>>>>>>>>> PRs,
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>> more straight forward than the v4
>> upgrade
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Marcos, porting class by class is the
>>>>>> fastest
>>>>>>>> way
>>>>>>>>>>> to do
>>>>>>>>>>>>>> this,
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>> concentrate on .NETifying and
>> optimizing
>>>>>> using
>>>>>>>>> .NET
>>>>>>>>>>>>>>> constructs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That said, I think the way to go is
>>>>>> create a
>>>>>>>>> branch
>>>>>>>>>>> out
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>> git
>>>>>>>>>>>>>>>>>>>>>> master HEAD and label it "3.x", and
>> start
>>>>>>>> working
>>>>>>>>> on
>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>> towards a
>>>>>>>>>>>>>>>>>>>> 4.3
>>>>>>>>>>>>>>>>>>>>>> compatible version. The actual port
>>>>>> should be
>>>>>>>>> using
>>>>>>>>>>> a
>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> ensures
>>>>>>>>>>>>>>>>>>>>>> all Java classes are ported with their
>>>>>> tests,
>>>>>>>> and
>>>>>>>>>>> that
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>> pass -
>>>>>>>>>>>>>>>>>>>>>> but I'm against committing any Java
>> code
>>>>>> to
>>>>>>> our
>>>>>>>>>>>>>> repositories.
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>> should probably be working on classes
>> in
>>>>>> some
>>>>>>>>> order
>>>>>>>>>>>>>>>>>> (alphabetically,
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> core classes first) and getting each
>>>>>> class to
>>>>>>>>>>> compile
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>>>> moving
>>>>>>>>>>>>>>>>>>>>>> forward. I don't mind about the project
>>>>>> not
>>>>>>>> being
>>>>>>>>>>>>>> compilable
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> month
>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> two.
>>>>>>>>>>>>>>>>>>>>>> Once this is done a process of
>>>>>> .NETifying and
>>>>>>>>>>> proofing
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> started, at which point we will already
>>>>>> have a
>>>>>>>>>>> working
>>>>>>>>>>>> v4
>>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> will be easier to keep up with the Java
>>>>>>> project.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The first step IMO is to stabilize the
>>>>>> test
>>>>>>>> suite
>>>>>>>>> so
>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> less be copied and pasted (e.g.
>>>>>> implementing
>>>>>>>>>>> Java-like
>>>>>>>>>>>>>>>>> assertEquals
>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>>> etc; I find xUnit to be much easier to
>>>>>> work
>>>>>>> with
>>>>>>>>>>> than
>>>>>>>>>>>>>>> NUnit). I
>>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>>>>>>>>> some work there but there's still a lot
>>>>>> to do.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Unfortunately I can't dedicate time
>>>>>> myself at
>>>>>>>> this
>>>>>>>>>>>> point,
>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> back in business in August, at which
>>>>>> point I
>>>>>>> can
>>>>>>>>>>>> dedicate
>>>>>>>>>>>>>>>> several
>>>>>>>>>>>>>>>>>>>> hours a
>>>>>>>>>>>>>>>>>>>>>> week. Until then I'll be happy to watch
>>>>>>> closely
>>>>>>>>> and
>>>>>>>>>>>> even
>>>>>>>>>>>>>>>>> coordinate
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> work to some extent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>>>> Lima <
>>>>>>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It really sounds good to me, this is
>> a
>>>>>> kick
>>>>>>>>> start
>>>>>>>>>>>> =). I
>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>> yet, but I would like to help you all
>>>>>> to get
>>>>>>>>> this
>>>>>>>>>>> job
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I'm completely agree with Paul and
>>>>>> Prescott.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I know that there is a high
>> commitment
>>>>>> for
>>>>>>>> keep
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> retrocompatibility
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>> Lucene. Does Java Lucene API gets big
>>>>>>> changes
>>>>>>>>>>> every
>>>>>>>>>>>>>>> release?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Is the Lucene.Net a port from a
>> stable
>>>>>>> version
>>>>>>>>>>> from a
>>>>>>>>>>>>>>> Lucene
>>>>>>>>>>>>>>>>>>> version,
>>>>>>>>>>>>>>>>>>>>>>> right? If the Lucene API gets only
>>>>>> minor
>>>>>>>> changes
>>>>>>>>>>>> every
>>>>>>>>>>>>>>> stable
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>> (or
>>>>>>>>>>>>>>>>>>>>>>> keep most of its source-code), we
>> could
>>>>>>>> compare
>>>>>>>>>>> the
>>>>>>>>>>>>>>> versions,
>>>>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> differences and bring them to
>>>>>> Lucene.Net.
>>>>>>>>> Again, I
>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> yet, so I don't know how it is (just
>> an
>>>>>>> idea).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> What's your approach for implement
>>>>>> simple
>>>>>>>>>>> performance
>>>>>>>>>>>>>>>>>> improvements
>>>>>>>>>>>>>>>>>>>>>> (without
>>>>>>>>>>>>>>>>>>>>>>> adding references or changing methods
>>>>>>>>> signatures)?
>>>>>>>>>>>> Does
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> done,
>>>>>>>>>>>>>>>>>>>>>>> or "follow the java version only"?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2013/6/6 Paul Irwin <
>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is just an "outsider"
>>>>>> suggestion as I
>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>>> yet, although I will definitely
>> help
>>>>>> with
>>>>>>>> the
>>>>>>>>>>> 4.x
>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> as I
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> vested
>>>>>>>>>>>>>>>>>>>>>>>> interest in seeing that get
>>>>>> completed. I
>>>>>>>> think
>>>>>>>>>>>> there
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>>> person
>>>>>>>>>>>>>>>>>>>>>>>> (or perhaps two) guiding what the
>>>>>>> structure
>>>>>>>>> and
>>>>>>>>>>>>>> workflow
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> avoid chaos. If the 4.x work is
>>>>>> going to
>>>>>>> be
>>>>>>>>>>>> starting
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> scratch
>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> fresh port, that person should set
>>>>>> up the
>>>>>>>>>>> project,
>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>> source control, create the folder
>>>>>>> structure,
>>>>>>>>>>> maybe
>>>>>>>>>>>>> stub
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>> classes,
>>>>>>>>>>>>>>>>>>>>>>>> etc. Then divide and conquer with
>>>>>> anyone
>>>>>>>>>>> interested
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> contributing,
>>>>>>>>>>>>>>>>>>>>>>>> perhaps by namespace.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I like the idea of throwing the
>> java
>>>>>> code
>>>>>>> in
>>>>>>>>>>> there
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> reference.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Again, I can work on
>>>>>> Lucene.Net.Documents,
>>>>>>>>>>>>>>>>> Lucene.Net.Analysis,
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> Lucene.Net.Store -- or any others,
>>>>>> those
>>>>>>> are
>>>>>>>>>>> just
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ones
>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> most
>>>>>>>>>>>>>>>>>>>>>>>> familiar with the inner workings.
>>>>>> Tell me
>>>>>>>> what
>>>>>>>>>>> to
>>>>>>>>>>>> do
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>> started
>>>>>>>>>>>>>>>>>>>>>>>> on my fork.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Paul Irwin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 2:38 PM,
>>>>>> Prescott
>>>>>>>>> Nasser
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> geobmx540@hotmail.com
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hey guys -
>>>>>>>>>>>>>>>>>>>>>>>>> I know I've been MIA a little
>>>>>> while. We
>>>>>>>>> have a
>>>>>>>>>>>>> board
>>>>>>>>>>>>>>>> report
>>>>>>>>>>>>>>>>>> due
>>>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>> think it prudent that we advise
>>>>>> them
>>>>>>> that
>>>>>>>> we
>>>>>>>>>>> seem
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> stalled
>>>>>>>>>>>>>>>>>>>>>>>> somewhat.
>>>>>>>>>>>>>>>>>>>>>>>>> We've got a few low hanging items
>>>>>> out of
>>>>>>>> of
>>>>>>>>>>> jira
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>> responsive
>>>>>>>>>>>>>>>>>>>>>>>>> on the mailing list to community
>>>>>>>> questions,
>>>>>>>>>>> but I
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>>>>>>> anything to move forward with
>> 4.0.
>>>>>>>>>>>>>>>>>>>>>>>>> To that end - I'd like to *try*
>> and
>>>>>>> start
>>>>>>>> us
>>>>>>>>>>> back
>>>>>>>>>>>>> up
>>>>>>>>>>>>>>>> moving
>>>>>>>>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>>>>>>>>>>> What
>>>>>>>>>>>>>>>>>>>>>>>>> is the best way to accomplish
>>>>>> this? If
>>>>>>> we
>>>>>>>>> took
>>>>>>>>>>>> the
>>>>>>>>>>>>>> java
>>>>>>>>>>>>>>>>>> lucene
>>>>>>>>>>>>>>>>>>>> 4.0
>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> committed that java to our branch
>>>>>> and
>>>>>>> then
>>>>>>>>>>> just
>>>>>>>>>>>> let
>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>>> pull
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>>>>>>> and being changing / modifying is
>>>>>> that
>>>>>>> one
>>>>>>>>>>> way to
>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>>>>>>>>> progress?
>>>>>>>>>>>>>>>>>>>>>>>>> ~P
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Marcos Lima
>>>>>>>>>>>>>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> tel: +55 (19) 9798-9335
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Marcos Lima
>>>>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>> tel: +55 (19) 9798-9335
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> Marcos Lima
>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>> tel: +55 (19) 9798-9335
>>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Paul, people in the list are busy or in vacation. This doesn't mean the
project is dead, especially since users like you keep lending a hand and
help it move forward.
I'll try to jump in soon, but you and your colleagues seem to be doing just
fine. If you need anything from the project's resources, or when you think
you are ready for a release, let us know.
On Thu, Aug 8, 2013 at 10:31 PM, Paul Irwin <pi...@feature23.com> wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > I made a dumb mistake... I have worked with StandardAnalyzer so long that
> > I forgot that KeywordAnalyzer is not what I needed to be using, I needed
> to
> > use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
> >
> > Now it works after re-indexing with a quick, dirty implementation of
> > WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
> > also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
> to
> > find out why NumericRangeQuery isn't working.
> >
> > Sorry for the blast of emails, but I wanted to prevent people from
> > spending time hunting down my mistake!
> >
> >
> > On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> >> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
> >> byte being signed is a pain.
> >>
> >> Now there's no exception doing a TermQuery, but I also don't get any
> >> results. It doesn't find any terms when scanning for them. I also tried
> a
> >> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
> >> didn't find any results that way either. So right now only
> >> MatchAllDocsQuery seems to work.
> >>
> >> If anyone would like to do a Google Hangout or anything sometime to look
> >> into it, let me know.
> >>
> >>
> >> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>
> >>> I realized after I sent that email last night that I could do as you
> >>> described. When you've been debugging through
> CorruptedIndexExceptions, you
> >>> get a little bit of tunnel vision... haha
> >>>
> >>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> >>> IndexSearcher and TopScoreDocsCollector and get hits! And
> .ToString()'ing
> >>> the matching documents prints the fields to the console, so it's
> loading in
> >>> the stored fields data correctly.
> >>>
> >>> I tried doing a TermQuery and now I get a "read past EOF" exception
> that
> >>> I can't figure out. There's a whole bunch of buffered byte array
> operations
> >>> going on and I can't determine where the issue came from. I'll keep
> >>> looking, but if someone could grab my fork/branch and help me look that
> >>> would be great. Here's example index writing and then reading code
> (also
> >>> included is a quick port of KeywordAnalyzer):
> >>> https://gist.github.com/anonymous/6174164
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
> itamar@code972.com>wrote:
> >>>
> >>>> Great
> >>>>
> >>>> You can build you Query objects on your own to execute a search, you
> >>>> don't
> >>>> actually have to use QueryParser for that
> >>>>
> >>>>
> >>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
> >>>> wrote:
> >>>>
> >>>> > Hey all, sorry it's been a little while, but I wanted to let you
> know
> >>>> that
> >>>> > although I took a few weeks off from it, I now have a 4.3.1
> equivalent
> >>>> > Lucene.net core building and able to write a simple index in Lucene
> >>>> 4.2
> >>>> > codec and read in things like the number of documents and whatnot.
> >>>> Since
> >>>> > QueryParser has been moved to a separate module in Lucene Java 4.x,
> I
> >>>> > haven't ported that yet so I haven't done a real search, and I only
> >>>> built
> >>>> > the index using a quick port of KeywordAnalyzer which all those
> >>>> analyzers
> >>>> > have also moved to another module. But this is definitely good
> >>>> progress and
> >>>> > should be a launch point for finishing a 4.3/4.4 port.
> >>>> >
> >>>> > You can see my fork/branch here:
> >>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
> >>>> like I
> >>>> > said, only core builds now, no modules/tests build, so only open the
> >>>> > Lucene.Net.Core.sln)
> >>>> >
> >>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
> >>>> the
> >>>> > community into finishing the 4.3/4.4 port. Let me know if you have
> any
> >>>> > questions, thanks!
> >>>> >
> >>>> >
> >>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
> >>>> itamar@code972.com
> >>>> > >wrote:
> >>>> >
> >>>> > > Paul, that's awesome. I will need some more time to go over this
> >>>> thread
> >>>> > and
> >>>> > > your work to give actual feedback, SUPER busy at the moment
> >>>> > >
> >>>> > >
> >>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pirwin@feature23.com
> >
> >>>> > wrote:
> >>>> > >
> >>>> > > > All,
> >>>> > > >
> >>>> > > > My colleagues and I have made good progress on porting Lucene
> >>>> 4.3's
> >>>> > core
> >>>> > > > library before, during, and after the hackathon last week. We
> now
> >>>> only
> >>>> > > have
> >>>> > > > some remaining items in Search, Index, and Codecs namespaces
> >>>> (plus a
> >>>> > few
> >>>> > > > other minor ones here and there). I expect to be done by the end
> >>>> of the
> >>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> >>>> Packed),
> >>>> > > and
> >>>> > > > the root Codecs and Codecs.PerField namespaces are all now
> "done".
> >>>> > > >
> >>>> > > > Again, my goal is to only get a buildable, experimental build of
> >>>> > > Lucene.net
> >>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> >>>> porting
> >>>> > > new
> >>>> > > > javadoc comments or unit tests right now, due to the vast amount
> >>>> of
> >>>> > code
> >>>> > > > that needs to be written just to get it to compile. If this work
> >>>> ends
> >>>> > up
> >>>> > > > becoming a pull request, great, otherwise it should help
> >>>> accelerate a
> >>>> > > port
> >>>> > > > of 4.3.x since the bulk of the work on core will already be done
> >>>> and
> >>>> > > > contributors can use it as a reference. And again, we're taking
> >>>> the
> >>>> > > > pragmatic approach of porting class-by-class,
> >>>> namespace-by-namespace,
> >>>> > > with
> >>>> > > > the understanding that until we're done the project won't build.
> >>>> > > >
> >>>> > > > Once complete, I also will work on updating the Analyzers
> contrib
> >>>> > module
> >>>> > > > and porting the QueryParsers contrib module, which I feel should
> >>>> be
> >>>> > > > included in the core NuGet package for Lucene.net as the core
> >>>> library
> >>>> > is
> >>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
> >>>> without
> >>>> > > them.
> >>>> > > > You can check out the code on my fork/branch here:
> >>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>> > > >
> >>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> >>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
> >>>> For the
> >>>> > > MMap
> >>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> >>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
> >>>> pretty
> >>>> > > > well, but required some creative shuffling of the code to make
> it
> >>>> work
> >>>> > > due
> >>>> > > > to lifecycle management.
> >>>> > > >
> >>>> > > > I'll update again this weekend or next week, when we should have
> >>>> > wrapped
> >>>> > > up
> >>>> > > > most of the main hacking on porting the core code.
> >>>> > > >
> >>>> > > > Paul
> >>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
> pirwin@feature23.com
> >>>> >
> >>>> > > wrote:
> >>>> > > >
> >>>> > > > > Marcos,
> >>>> > > > >
> >>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
> >>>> is
> >>>> > only
> >>>> > > on
> >>>> > > > > SVN here, before the lucene and solr projects were bundled
> >>>> together:
> >>>> > > > >
> >>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >>>> > > > >
> >>>> > > > > The SVN for 4.3 java is here:
> >>>> > > > >
> >>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> >>>> > > > > And the GitHub for 4.3 java is here:
> >>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >>>> > > > >
> >>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> >>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >>>> > > > >
> >>>> > > > > My fork is the "upstream" fork for my team members, and i'm
> >>>> remote
> >>>> > > > merging
> >>>> > > > > their changes in from their forks while they fetch/merge from
> >>>> mine to
> >>>> > > get
> >>>> > > > > everyone else's changes, rather than using pull requests.
> James
> >>>> and I
> >>>> > > > have
> >>>> > > > > been working the past few days on the Util namespace ahead of
> >>>> > tonight's
> >>>> > > > > hackathon since that namespace is in common with the rest of
> the
> >>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> >>>> > hacking
> >>>> > > on
> >>>> > > > > porting 4.3, each with a different namespace or part of a
> >>>> namespace.
> >>>> > > > Since
> >>>> > > > > we're going class-by-class, namespace-by-namespace, the
> project
> >>>> does
> >>>> > > not
> >>>> > > > > build as it is. Once we finish doing a translation of each
> >>>> file, then
> >>>> > > > we'll
> >>>> > > > > hammer out any remaining issues and get it to build again. I'm
> >>>> hoping
> >>>> > > > that
> >>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> >>>> > > > >
> >>>> > > > > But one thing to keep in mind is it looks like much
> >>>> functionality has
> >>>> > > > been
> >>>> > > > > moved out of core into the contrib modules, especially around
> >>>> > analysis,
> >>>> > > > for
> >>>> > > > > 4.0+. For example, there are no built-in analyzers in core
> >>>> anymore.
> >>>> > So
> >>>> > > > when
> >>>> > > > > this is all done, we may want to include at least the analysis
> >>>> > contrib
> >>>> > > > > module in with the standard core NuGet package, because
> >>>> otherwise
> >>>> > it's
> >>>> > > > > practically useless unless you roll your own analyzer.
> >>>> > > > >
> >>>> > > > > Paul
> >>>> > > > >
> >>>> > > > >
> >>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> >>>> > marcoslimagon@gmail.com
> >>>> > > > >wrote:
> >>>> > > > >
> >>>> > > > >> Hi everyone!
> >>>> > > > >>
> >>>> > > > >> Does someone know where can I find the 3.0.3 release from
> >>>> > > Lucene(java)?
> >>>> > > > >>
> >>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
> >>>> 4.3.0 and
> >>>> > > > make
> >>>> > > > >> the diff between then and get all changes between
> releases... I
> >>>> > gonna
> >>>> > > > >> publish it here soon. (If you think there is another
> important
> >>>> > > release,
> >>>> > > > >> let
> >>>> > > > >> me know)
> >>>> > > > >>
> >>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
> >>>> with
> >>>> > 4.3.0
> >>>> > > > >> port
> >>>> > > > >> for .Net on github (last email)?
> >>>> > > > >>
> >>>> > > > >> See you,
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> >>>> > > > >>
> >>>> > > > >> > Thanks for the discussion points, Michael.
> >>>> > > > >> >
> >>>> > > > >> > I would vote for not worrying about trying to achieve
> >>>> portable
> >>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
> 4.3+
> >>>> is
> >>>> > > > >> completed.
> >>>> > > > >> > Otherwise it may delay the project and stall it further.
> >>>> That's
> >>>> > just
> >>>> > > > my
> >>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> >>>> > > > >> >
> >>>> > > > >> > I have started porting the changes from the core library
> >>>> (from the
> >>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
> >>>> separate
> >>>> > > > branch.
> >>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
> >>>> port
> >>>> > > until
> >>>> > > > >> > there's changes to pull from upstream to work from. Also
> due
> >>>> to my
> >>>> > > > time
> >>>> > > > >> > constraints, I am not fully documenting new methods that
> I'm
> >>>> > adding.
> >>>> > > > >> But if
> >>>> > > > >> > anyone wants to pull/copy/reference my changes while
> porting,
> >>>> > that's
> >>>> > > > >> > awesome. My branch currently does not build as I'm
> primarily
> >>>> going
> >>>> > > > >> > class-by-class, starting with the util namespace. Once we
> >>>> get the
> >>>> > > ball
> >>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
> >>>> join
> >>>> > in.
> >>>> > > > But
> >>>> > > > >> > hopefully my work will be useful to someone, if not as a
> pull
> >>>> > > request
> >>>> > > > >> then
> >>>> > > > >> > as a reference. I'm also going to be holding a hackathon
> >>>> this week
> >>>> > > > with
> >>>> > > > >> my
> >>>> > > > >> > colleagues where we're all going to work on the port. I'm
> >>>> > comparing
> >>>> > > > >> files
> >>>> > > > >> > and making changes as necessary, rather than starting from
> >>>> > scratch.
> >>>> > > My
> >>>> > > > >> > repo/branch is here:
> >>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>> > > > >> >
> >>>> > > > >> > Paul
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >>>> > > > >> > mherndon@michaelherndon.com> wrote:
> >>>> > > > >> >
> >>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> >>>> apache
> >>>> > > > >> > maintains.
> >>>> > > > >> > >
> >>>> > > > >> > > The was some work at one time to move the official svn
> >>>> > repository
> >>>> > > to
> >>>> > > > >> > start
> >>>> > > > >> > > using git one instead. Was that actually finalized or
> not?
> >>>> > > > >> > >
> >>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
> to
> >>>> see
> >>>> > > what
> >>>> > > > >> kind
> >>>> > > > >> > of
> >>>> > > > >> > > work was involved using a portable libraries project.
> Some
> >>>> of it
> >>>> > > can
> >>>> > > > >> > still
> >>>> > > > >> > > be used but will need to be validated against the current
> >>>> > version
> >>>> > > of
> >>>> > > > >> > Java's
> >>>> > > > >> > > Lucene. It was also using .net 4.
> >>>> > > > >> > >
> >>>> > > > >> > > clean branch vs current. Its going to depend on what
> we
> >>>> > > support.
> >>>> > > > >> If
> >>>> > > > >> > you
> >>>> > > > >> > > support windows mobile 8, win RT, then the current code
> in
> >>>> trunk
> >>>> > > > will
> >>>> > > > >> not
> >>>> > > > >> > > compile against those versions of the framework which
> >>>> would a
> >>>> > > > >> frustrating
> >>>> > > > >> > > starting point, then you couldn't even run tests, which
> >>>> would
> >>>> > make
> >>>> > > > >> taking
> >>>> > > > >> > > patches very difficult. Supporting those can almost mean
> >>>> larger
> >>>> > > > gaps
> >>>> > > > >> in
> >>>> > > > >> > > design between Lucene.Net and its parent project.
> >>>> > > > >> > >
> >>>> > > > >> > > Also the structure has changed significantly between the
> >>>> > branches
> >>>> > > > and
> >>>> > > > >> > the
> >>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
> >>>> and
> >>>> > > seems
> >>>> > > > >> > > significantly different. That doesn't mean you can't
> >>>> cherry
> >>>> > pick
> >>>> > > > >> stuff
> >>>> > > > >> > > from the other tags/branches that would still work as is.
> >>>> A
> >>>> > clean
> >>>> > > > >> branch
> >>>> > > > >> > > would also make it easier to get our build / tool chain
> in
> >>>> order
> >>>> > > as
> >>>> > > > >> you
> >>>> > > > >> > can
> >>>> > > > >> > > then do them incrementally versus having to do all the
> >>>> stuff
> >>>> > that
> >>>> > > I
> >>>> > > > >> did
> >>>> > > > >> > for
> >>>> > > > >> > > the 3x branch which saps energy and desire to code. It
> >>>> could
> >>>> > > also
> >>>> > > > >> make
> >>>> > > > >> > it
> >>>> > > > >> > > easier to see which classes have been ported or not.
> >>>> > > > >> > >
> >>>> > > > >> > > The major downside to a clean branch is extra work it
> >>>> requires
> >>>> > and
> >>>> > > > the
> >>>> > > > >> > > start up cost in time and energy of getting it in order,
> >>>> which
> >>>> > can
> >>>> > > > be
> >>>> > > > >> > > daunting / intimidating and lower morale. And generally
> >>>> you want
> >>>> > > to
> >>>> > > > >> use
> >>>> > > > >> > > take your legacy code and refactor instead of in someways
> >>>> > starting
> >>>> > > > >> over.
> >>>> > > > >> > >
> >>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> >>>> > something
> >>>> > > > >> similar
> >>>> > > > >> > > to
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> >
> >>>> > > > >>
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >>>> > > > >> > > where it tracks what needs to get ported / what has been
> >>>> ported.
> >>>> > > > >> > >
> >>>> > > > >> > > What are we going to support in the next version?
> >>>> > > > >> > >
> >>>> > > > >> > > Who is going to work on the next version?
> >>>> > > > >> > >
> >>>> > > > >> > > What would make the most sense and what would invigorate
> >>>> the
> >>>> > > > >> community to
> >>>> > > > >> > > get involved more and lower the barrier to entry?
> >>>> > > > >> > >
> >>>> > > > >> > > I think those are the questions that would make a lot of
> >>>> the
> >>>> > > > decisions
> >>>> > > > >> > for
> >>>> > > > >> > > us so that we can get back to work on lucene.net.
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> >>>> > > > marcoslimagon@gmail.com
> >>>> > > > >> > > >wrote:
> >>>> > > > >> > >
> >>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
> >>>> projects...
> >>>> > > > >> > > >
> >>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >>>> > > > >> > > > https://github.com/apache/lucene.net points to the
> same
> >>>> > > > repository?
> >>>> > > > >> > > (This
> >>>> > > > >> > > > is new for me, pretty good) Which of them do you
> >>>> recommend
> >>>> > (i'm
> >>>> > > > used
> >>>> > > > >> > with
> >>>> > > > >> > > > SVN and its patterns).
> >>>> > > > >> > > >
> >>>> > > > >> > > > I'm checking the subversion right now.
> >>>> > > > >> > > >
> >>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
> >>>> old
> >>>> > > > branch,
> >>>> > > > >> i`m
> >>>> > > > >> > > not
> >>>> > > > >> > > > sure about its current status.
> >>>> > > > >> > > >
> >>>> > > > >> > > > Will we wipe the current solution from /trunk and start
> >>>> a new
> >>>> > > one?
> >>>> > > > >> > > >
> >>>> > > > >> > > > Thanks,
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > > 2013/6/6 mherndon michael <mherndon@michaelherndon.com
> >
> >>>> > > > >> > > >
> >>>> > > > >> > > > > We may be forced to start with a clean/empty branch
> if
> >>>> > people
> >>>> > > > >> still
> >>>> > > > >> > > want
> >>>> > > > >> > > > to
> >>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
> win
> >>>> RT,
> >>>> > > etc.
> >>>> > > > >> The
> >>>> > > > >> > are
> >>>> > > > >> > > > > many
> >>>> > > > >> > > > > classes that Lucene.net uses from the full framework
> >>>> that
> >>>> > > would
> >>>> > > > >> not
> >>>> > > > >> > be
> >>>> > > > >> > > > > accessible in other versions of the .NET Framework.
> >>>> It also
> >>>> > > > might
> >>>> > > > >> > > > require
> >>>> > > > >> > > > > a design that differs even more from its parent
> >>>> project.
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > It might be wise to poll what users most desire in
> the
> >>>> next
> >>>> > > > >> version
> >>>> > > > >> > > > through
> >>>> > > > >> > > > > jira or user voice.
> >>>> > > > >> > > > >
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >>>> > > > >> > itamar@code972.com
> >>>> > > > >> > > > > >wrote:
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > > inline
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> >>>> > > > >> pirwin@feature23.com>
> >>>> > > > >> > > > wrote:
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
> been
> >>>> a TFS
> >>>> > > guy
> >>>> > > > >> for
> >>>> > > > >> > so
> >>>> > > > >> > > > > long
> >>>> > > > >> > > > > > > :-)
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> >>>> patches
> >>>> > or
> >>>> > > > >> > anything
> >>>> > > > >> > > > to
> >>>> > > > >> > > > > > the
> >>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
> will
> >>>> > branch
> >>>> > > > from
> >>>> > > > >> > for
> >>>> > > > >> > > 4x
> >>>> > > > >> > > > > > dev.
> >>>> > > > >> > > > > > > Correct?
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> >>>> anyone
> >>>> > > will
> >>>> > > > >> be
> >>>> > > > >> > > > > > interested in that
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
> deal
> >>>> with
> >>>> > > the
> >>>> > > > >> > github
> >>>> > > > >> > > > > sync?
> >>>> > > > >> > > > > > > Who could diagnose that?
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
> >>>> apache
> >>>> > repo
> >>>> > > > for
> >>>> > > > >> now
> >>>> > > > >> > > > while
> >>>> > > > >> > > > > > we get that sorted out.
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
> Syn-Hershko
> >>>> <
> >>>> > > > >> > > > itamar@code972.com
> >>>> > > > >> > > > > > > >wrote:
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
> >>>> then for
> >>>> > > 3.x
> >>>> > > > >> > > > > development.
> >>>> > > > >> > > > > > > WRT
> >>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
> >>>> whatever
> >>>> > > branch.
> >>>> > > > >> When
> >>>> > > > >> > > you
> >>>> > > > >> > > > > > send
> >>>> > > > >> > > > > > > us
> >>>> > > > >> > > > > > > > PRs we will merge either to master or to a
> >>>> dedicated
> >>>> > > repo.
> >>>> > > > >> For
> >>>> > > > >> > > now
> >>>> > > > >> > > > it
> >>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
> >>>> it on
> >>>> > the
> >>>> > > > >> apache
> >>>> > > > >> > > > > servers
> >>>> > > > >> > > > > > > > (github sync seems to be off)
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> >>>> > > > >> > > pirwin@feature23.com>
> >>>> > > > >> > > > > > > wrote:
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
> >>>> 4.3
> >>>> > > version
> >>>> > > > >> of
> >>>> > > > >> > the
> >>>> > > > >> > > > > > > Analysis
> >>>> > > > >> > > > > > > > > namespace.
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Not sure the checkout command is what you
> >>>> intended
> >>>> > --
> >>>> > > > you
> >>>> > > > >> > might
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > meant
> >>>> > > > >> > > > > > > > > trunk instead of master, and that would
> create
> >>>> a new
> >>>> > > > "3x"
> >>>> > > > >> > > branch,
> >>>> > > > >> > > > > > when
> >>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would
> be
> >>>> > > > >> misnamed...
> >>>> > > > >> > so
> >>>> > > > >> > > > > maybe
> >>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
> >>>> aiming
> >>>> > for
> >>>> > > > >> lucene
> >>>> > > > >> > > > 4.3.x
> >>>> > > > >> > > > > > > > > compatibility?
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
> >>>> > upstream
> >>>> > > > >> want to
> >>>> > > > >> > > > > create
> >>>> > > > >> > > > > > > the
> >>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
> >>>> not all
> >>>> > > > >> trying to
> >>>> > > > >> > > > > create
> >>>> > > > >> > > > > > > them
> >>>> > > > >> > > > > > > > > and dealing with a merge?
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Paul
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> >>>> Syn-Hershko <
> >>>> > > > >> > > > > > itamar@code972.com
> >>>> > > > >> > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > > Unless people here have a specific reason
> to
> >>>> use
> >>>> > > > 3.6.2 I
> >>>> > > > >> > > would
> >>>> > > > >> > > > > > highly
> >>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
> >>>> towards v4
> >>>> > > > >> > otherwise
> >>>> > > > >> > > we
> >>>> > > > >> > > > > > will
> >>>> > > > >> > > > > > > > > never
> >>>> > > > >> > > > > > > > > > make it...
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
> >>>> (same
> >>>> > > > repo,
> >>>> > > > >> > > > different
> >>>> > > > >> > > > > > > > > remotes)
> >>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> >>>> should
> >>>> > > work
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
> Irwin <
> >>>> > > > >> > > > > pirwin@feature23.com>
> >>>> > > > >> > > > > > > > > wrote:
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > Itamar,
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
> >>>> way to
> >>>> > > do
> >>>> > > > >> it, I
> >>>> > > > >> > > > just
> >>>> > > > >> > > > > > > > thought
> >>>> > > > >> > > > > > > > > > that
> >>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
> >>>> > > discussion
> >>>> > > > >> > > > previously
> >>>> > > > >> > > > > > for
> >>>> > > > >> > > > > > > > the
> >>>> > > > >> > > > > > > > > > 4.x
> >>>> > > > >> > > > > > > > > > > work. An incremental approach will be
> much
> >>>> > better.
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
> >>>> branch on
> >>>> > > my
> >>>> > > > >> fork
> >>>> > > > >> > > and
> >>>> > > > >> > > > > will
> >>>> > > > >> > > > > > > > begin
> >>>> > > > >> > > > > > > > > > > working on bringing the Analysis
> namespace
> >>>> up to
> >>>> > > > >> speed to
> >>>> > > > >> > > > > 3.6.2.
> >>>> > > > >> > > > > > If
> >>>> > > > >> > > > > > > > > > anyone
> >>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
> >>>> I'm
> >>>> > > done,
> >>>> > > > >> have
> >>>> > > > >> > at
> >>>> > > > >> > > > it.
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
> >>>> branch_3x
> >>>> > > > branch,
> >>>> > > > >> > > please
> >>>> > > > >> > > > > let
> >>>> > > > >> > > > > > > me
> >>>> > > > >> > > > > > > > > know
> >>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > Paul
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> >>>> > > Syn-Hershko <
> >>>> > > > >> > > > > > > > itamar@code972.com
> >>>> > > > >> > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
> >>>> again :)
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
> >>>> know
> >>>> > what
> >>>> > > > it
> >>>> > > > >> > would
> >>>> > > > >> > > > > take
> >>>> > > > >> > > > > > > > until
> >>>> > > > >> > > > > > > > > > they
> >>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
> >>>> then
> >>>> > > > >> decisions
> >>>> > > > >> > > > could
> >>>> > > > >> > > > > > and
> >>>> > > > >> > > > > > > > will
> >>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
> >>>> > starting
> >>>> > > > from
> >>>> > > > >> > > > scratch,
> >>>> > > > >> > > > > > > > > although
> >>>> > > > >> > > > > > > > > > I
> >>>> > > > >> > > > > > > > > > > do
> >>>> > > > >> > > > > > > > > > > > think a lot in the current structure
> >>>> should
> >>>> > > > change,
> >>>> > > > >> but
> >>>> > > > >> > > its
> >>>> > > > >> > > > > > going
> >>>> > > > >> > > > > > > > to
> >>>> > > > >> > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > much easier to change it in place,
> >>>> refactoring
> >>>> > > > where
> >>>> > > > >> > > > needed,
> >>>> > > > >> > > > > > than
> >>>> > > > >> > > > > > > > > > > starting
> >>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
> off I
> >>>> > > > personally
> >>>> > > > >> > will
> >>>> > > > >> > > > be
> >>>> > > > >> > > > > > > happy
> >>>> > > > >> > > > > > > > > with
> >>>> > > > >> > > > > > > > > > > you
> >>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> >>>> porting
> >>>> > > it,
> >>>> > > > >> its
> >>>> > > > >> > > > pretty
> >>>> > > > >> > > > > > > much
> >>>> > > > >> > > > > > > > > self
> >>>> > > > >> > > > > > > > > > > > contained.
> >>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
> >>>> a fork
> >>>> > > and
> >>>> > > > >> send
> >>>> > > > >> > > us
> >>>> > > > >> > > > > PRs,
> >>>> > > > >> > > > > > > its
> >>>> > > > >> > > > > > > > > > much
> >>>> > > > >> > > > > > > > > > > > more straight forward than the v4
> upgrade
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> >>>> fastest
> >>>> > > way
> >>>> > > > >> to do
> >>>> > > > >> > > > this,
> >>>> > > > >> > > > > > we
> >>>> > > > >> > > > > > > > can
> >>>> > > > >> > > > > > > > > > then
> >>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
> optimizing
> >>>> using
> >>>> > > > .NET
> >>>> > > > >> > > > > constructs.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
> >>>> create a
> >>>> > > > branch
> >>>> > > > >> out
> >>>> > > > >> > > of
> >>>> > > > >> > > > > the
> >>>> > > > >> > > > > > > > > current
> >>>> > > > >> > > > > > > > > > > git
> >>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
> start
> >>>> > > working
> >>>> > > > on
> >>>> > > > >> > > master
> >>>> > > > >> > > > > > > > towards a
> >>>> > > > >> > > > > > > > > > 4.3
> >>>> > > > >> > > > > > > > > > > > compatible version. The actual port
> >>>> should be
> >>>> > > > using
> >>>> > > > >> a
> >>>> > > > >> > > > process
> >>>> > > > >> > > > > > > that
> >>>> > > > >> > > > > > > > > > > ensures
> >>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
> >>>> tests,
> >>>> > > and
> >>>> > > > >> that
> >>>> > > > >> > > > those
> >>>> > > > >> > > > > > > tests
> >>>> > > > >> > > > > > > > > > pass -
> >>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
> code
> >>>> to
> >>>> > our
> >>>> > > > >> > > > repositories.
> >>>> > > > >> > > > > > The
> >>>> > > > >> > > > > > > > > > process
> >>>> > > > >> > > > > > > > > > > > should probably be working on classes
> in
> >>>> some
> >>>> > > > order
> >>>> > > > >> > > > > > > > (alphabetically,
> >>>> > > > >> > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > core classes first) and getting each
> >>>> class to
> >>>> > > > >> compile
> >>>> > > > >> > > > before
> >>>> > > > >> > > > > > > moving
> >>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
> >>>> not
> >>>> > > being
> >>>> > > > >> > > > compilable
> >>>> > > > >> > > > > > for
> >>>> > > > >> > > > > > > a
> >>>> > > > >> > > > > > > > > > month
> >>>> > > > >> > > > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > two.
> >>>> > > > >> > > > > > > > > > > > Once this is done a process of
> >>>> .NETifying and
> >>>> > > > >> proofing
> >>>> > > > >> > > the
> >>>> > > > >> > > > > code
> >>>> > > > >> > > > > > > can
> >>>> > > > >> > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > started, at which point we will already
> >>>> have a
> >>>> > > > >> working
> >>>> > > > >> > v4
> >>>> > > > >> > > > > > version
> >>>> > > > >> > > > > > > > so
> >>>> > > > >> > > > > > > > > it
> >>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
> >>>> > project.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
> >>>> test
> >>>> > > suite
> >>>> > > > so
> >>>> > > > >> > > tests
> >>>> > > > >> > > > > > could
> >>>> > > > >> > > > > > > > more
> >>>> > > > >> > > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
> >>>> implementing
> >>>> > > > >> Java-like
> >>>> > > > >> > > > > > > assertEquals
> >>>> > > > >> > > > > > > > > > > methods
> >>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
> >>>> work
> >>>> > with
> >>>> > > > >> than
> >>>> > > > >> > > > > NUnit). I
> >>>> > > > >> > > > > > > > > already
> >>>> > > > >> > > > > > > > > > > did
> >>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
> >>>> to do.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
> >>>> myself at
> >>>> > > this
> >>>> > > > >> > point,
> >>>> > > > >> > > > > but I
> >>>> > > > >> > > > > > > > > should
> >>>> > > > >> > > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > back in business in August, at which
> >>>> point I
> >>>> > can
> >>>> > > > >> > dedicate
> >>>> > > > >> > > > > > several
> >>>> > > > >> > > > > > > > > > hours a
> >>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> >>>> > closely
> >>>> > > > and
> >>>> > > > >> > even
> >>>> > > > >> > > > > > > coordinate
> >>>> > > > >> > > > > > > > > the
> >>>> > > > >> > > > > > > > > > > > work to some extent.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
> >>>> Lima <
> >>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is
> a
> >>>> kick
> >>>> > > > start
> >>>> > > > >> > =). I
> >>>> > > > >> > > > > > haven't
> >>>> > > > >> > > > > > > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > > > anything
> >>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
> >>>> to get
> >>>> > > > this
> >>>> > > > >> job
> >>>> > > > >> > > > done.
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> >>>> Prescott.
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > I know that there is a high
> commitment
> >>>> for
> >>>> > > keep
> >>>> > > > >> the
> >>>> > > > >> > > > > > > > > > retrocompatibility
> >>>> > > > >> > > > > > > > > > > on
> >>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> >>>> > changes
> >>>> > > > >> every
> >>>> > > > >> > > > > release?
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
> stable
> >>>> > version
> >>>> > > > >> from a
> >>>> > > > >> > > > > Lucene
> >>>> > > > >> > > > > > > > > version,
> >>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
> >>>> minor
> >>>> > > changes
> >>>> > > > >> > every
> >>>> > > > >> > > > > stable
> >>>> > > > >> > > > > > > > > release
> >>>> > > > >> > > > > > > > > > > (or
> >>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
> could
> >>>> > > compare
> >>>> > > > >> the
> >>>> > > > >> > > > > versions,
> >>>> > > > >> > > > > > > > check
> >>>> > > > >> > > > > > > > > > the
> >>>> > > > >> > > > > > > > > > > > > differences and bring them to
> >>>> Lucene.Net.
> >>>> > > > Again, I
> >>>> > > > >> > > > haven't
> >>>> > > > >> > > > > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > > with
> >>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just
> an
> >>>> > idea).
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > What's your approach for implement
> >>>> simple
> >>>> > > > >> performance
> >>>> > > > >> > > > > > > > improvements
> >>>> > > > >> > > > > > > > > > > > (without
> >>>> > > > >> > > > > > > > > > > > > adding references or changing methods
> >>>> > > > signatures)?
> >>>> > > > >> > Does
> >>>> > > > >> > > > it
> >>>> > > > >> > > > > > > could
> >>>> > > > >> > > > > > > > be
> >>>> > > > >> > > > > > > > > > > done,
> >>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
> >>>> pirwin@feature23.com>
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
> >>>> suggestion as I
> >>>> > > > >> haven't
> >>>> > > > >> > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > anything
> >>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
> help
> >>>> with
> >>>> > > the
> >>>> > > > >> 4.x
> >>>> > > > >> > > work
> >>>> > > > >> > > > > as I
> >>>> > > > >> > > > > > > > have
> >>>> > > > >> > > > > > > > > a
> >>>> > > > >> > > > > > > > > > > > vested
> >>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
> >>>> completed. I
> >>>> > > think
> >>>> > > > >> > there
> >>>> > > > >> > > > > should
> >>>> > > > >> > > > > > > be
> >>>> > > > >> > > > > > > > > one
> >>>> > > > >> > > > > > > > > > > > person
> >>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> >>>> > structure
> >>>> > > > and
> >>>> > > > >> > > > workflow
> >>>> > > > >> > > > > > will
> >>>> > > > >> > > > > > > > > look
> >>>> > > > >> > > > > > > > > > > like
> >>>> > > > >> > > > > > > > > > > > > to
> >>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
> >>>> going to
> >>>> > be
> >>>> > > > >> > starting
> >>>> > > > >> > > > from
> >>>> > > > >> > > > > > > > scratch
> >>>> > > > >> > > > > > > > > > as
> >>>> > > > >> > > > > > > > > > > a
> >>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
> >>>> up the
> >>>> > > > >> project,
> >>>> > > > >> > > get
> >>>> > > > >> > > > > > > > everything
> >>>> > > > >> > > > > > > > > > > going
> >>>> > > > >> > > > > > > > > > > > > in
> >>>> > > > >> > > > > > > > > > > > > > source control, create the folder
> >>>> > structure,
> >>>> > > > >> maybe
> >>>> > > > >> > > stub
> >>>> > > > >> > > > > out
> >>>> > > > >> > > > > > > > some
> >>>> > > > >> > > > > > > > > > > > classes,
> >>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
> >>>> anyone
> >>>> > > > >> interested
> >>>> > > > >> > > in
> >>>> > > > >> > > > > > > > > > contributing,
> >>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
> java
> >>>> code
> >>>> > in
> >>>> > > > >> there
> >>>> > > > >> > so
> >>>> > > > >> > > > > it's
> >>>> > > > >> > > > > > > easy
> >>>> > > > >> > > > > > > > > to
> >>>> > > > >> > > > > > > > > > > > > > reference.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > Again, I can work on
> >>>> Lucene.Net.Documents,
> >>>> > > > >> > > > > > > Lucene.Net.Analysis,
> >>>> > > > >> > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
> >>>> those
> >>>> > are
> >>>> > > > >> just
> >>>> > > > >> > the
> >>>> > > > >> > > > > ones
> >>>> > > > >> > > > > > > I'm
> >>>> > > > >> > > > > > > > > most
> >>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
> >>>> Tell me
> >>>> > > what
> >>>> > > > >> to
> >>>> > > > >> > do
> >>>> > > > >> > > > and
> >>>> > > > >> > > > > > I'll
> >>>> > > > >> > > > > > > > get
> >>>> > > > >> > > > > > > > > > > > started
> >>>> > > > >> > > > > > > > > > > > > > on my fork.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > Paul Irwin
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
> >>>> Prescott
> >>>> > > > Nasser
> >>>> > > > >> <
> >>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> >>>> > > > >> > > > > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > > Hey guys -
> >>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
> >>>> while. We
> >>>> > > > have a
> >>>> > > > >> > > board
> >>>> > > > >> > > > > > report
> >>>> > > > >> > > > > > > > due
> >>>> > > > >> > > > > > > > > > > soon
> >>>> > > > >> > > > > > > > > > > > -
> >>>> > > > >> > > > > > > > > > > > > I
> >>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
> >>>> them
> >>>> > that
> >>>> > > we
> >>>> > > > >> seem
> >>>> > > > >> > > to
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > > stalled
> >>>> > > > >> > > > > > > > > > > > > > somewhat.
> >>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
> >>>> out of
> >>>> > > of
> >>>> > > > >> jira
> >>>> > > > >> > > and
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > been
> >>>> > > > >> > > > > > > > > > > > > responsive
> >>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> >>>> > > questions,
> >>>> > > > >> but I
> >>>> > > > >> > > > don't
> >>>> > > > >> > > > > > > think
> >>>> > > > >> > > > > > > > > > we've
> >>>> > > > >> > > > > > > > > > > > > done
> >>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
> 4.0.
> >>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
> and
> >>>> > start
> >>>> > > us
> >>>> > > > >> back
> >>>> > > > >> > > up
> >>>> > > > >> > > > > > moving
> >>>> > > > >> > > > > > > > > > > forward.
> >>>> > > > >> > > > > > > > > > > > > What
> >>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
> >>>> this? If
> >>>> > we
> >>>> > > > took
> >>>> > > > >> > the
> >>>> > > > >> > > > java
> >>>> > > > >> > > > > > > > lucene
> >>>> > > > >> > > > > > > > > > 4.0
> >>>> > > > >> > > > > > > > > > > > code
> >>>> > > > >> > > > > > > > > > > > > > and
> >>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
> >>>> and
> >>>> > then
> >>>> > > > >> just
> >>>> > > > >> > let
> >>>> > > > >> > > > > > people
> >>>> > > > >> > > > > > > > pull
> >>>> > > > >> > > > > > > > > > > that
> >>>> > > > >> > > > > > > > > > > > > down
> >>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
> >>>> that
> >>>> > one
> >>>> > > > >> way to
> >>>> > > > >> > > > maybe
> >>>> > > > >> > > > > > > make
> >>>> > > > >> > > > > > > > > some
> >>>> > > > >> > > > > > > > > > > > > forward
> >>>> > > > >> > > > > > > > > > > > > > > progress?
> >>>> > > > >> > > > > > > > > > > > > > > ~P
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > --
> >>>> > > > >> > > > > > > > > > > > > --
> >>>> > > > >> > > > > > > > > > > > > Marcos Lima
> >>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> >>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > > --
> >>>> > > > >> > > > --
> >>>> > > > >> > > > Marcos Lima
> >>>> > > > >> > > > Software Developer/Tech Lead
> >>>> > > > >> > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > tel: +55 (19) 9798-9335
> >>>> > > > >> > > >
> >>>> > > > >> > >
> >>>> > > > >> >
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >> --
> >>>> > > > >> --
> >>>> > > > >> Marcos Lima
> >>>> > > > >> Software Developer/Tech Lead
> >>>> > > > >> marcoslimagon@gmail.com
> >>>> > > > >> tel: +55 (19) 9798-9335
> >>>> > > > >>
> >>>> > > > >
> >>>> > > > >
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Is this mailing list dead?! If anyone is interested in releasing an
up-to-date build of Lucene.net, please write back! If you didn't read my
other messages, I have Lucene.net Core working with Lucene java 4.3.1
compatibility thanks to the help of my colleagues. We just need to round
out the contrib modules, unit tests, and documentation as a community and
we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
was packaged in December 2010!
I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
(where they now live in Lucene java, they were moved from core) and their
associated filters and tokenizers. I've briefly tested each and they seem
to work correctly. I've purposefully "Exclude[d] from Project" the other
language analyzers until we can forward-port them. So now the Analyzers DLL
compiles with those analyzers only. Also, I fixed the bug that was causing
NumericRangeQuery to not work.
Next on my list is the QueryParsers contrib library (QueryParser was moved
out of Lucene java core) so that, combined with StandardAnalyzer, we can
test a pretty common real-world use case (the prototypical "hello lucene"
tutorial). After that, it might be worth forward-porting what we have so
far to 4.4 and use that as the latest point to finish out the port. The
changes shouldn't be too dramatic to core from what I can tell.
My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
I'll keep updating as I go, but if anyone wants to jump in, there's not a
better time than now...
On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
> I made a dumb mistake... I have worked with StandardAnalyzer so long that
> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>
> Now it works after re-indexing with a quick, dirty implementation of
> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
> find out why NumericRangeQuery isn't working.
>
> Sorry for the blast of emails, but I wanted to prevent people from
> spending time hunting down my mistake!
>
>
> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>> byte being signed is a pain.
>>
>> Now there's no exception doing a TermQuery, but I also don't get any
>> results. It doesn't find any terms when scanning for them. I also tried a
>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>> didn't find any results that way either. So right now only
>> MatchAllDocsQuery seems to work.
>>
>> If anyone would like to do a Google Hangout or anything sometime to look
>> into it, let me know.
>>
>>
>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I realized after I sent that email last night that I could do as you
>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>> get a little bit of tunnel vision... haha
>>>
>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>> the matching documents prints the fields to the console, so it's loading in
>>> the stored fields data correctly.
>>>
>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>> going on and I can't determine where the issue came from. I'll keep
>>> looking, but if someone could grab my fork/branch and help me look that
>>> would be great. Here's example index writing and then reading code (also
>>> included is a quick port of KeywordAnalyzer):
>>> https://gist.github.com/anonymous/6174164
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>>
>>>> Great
>>>>
>>>> You can build you Query objects on your own to execute a search, you
>>>> don't
>>>> actually have to use QueryParser for that
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>>> that
>>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>> 4.2
>>>> > codec and read in things like the number of documents and whatnot.
>>>> Since
>>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>> built
>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>> analyzers
>>>> > have also moved to another module. But this is definitely good
>>>> progress and
>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>> >
>>>> > You can see my fork/branch here:
>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>> like I
>>>> > said, only core builds now, no modules/tests build, so only open the
>>>> > Lucene.Net.Core.sln)
>>>> >
>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>> the
>>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>>> > questions, thanks!
>>>> >
>>>> >
>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>> itamar@code972.com
>>>> > >wrote:
>>>> >
>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>> thread
>>>> > and
>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>> > >
>>>> > >
>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>>> > wrote:
>>>> > >
>>>> > > > All,
>>>> > > >
>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>> 4.3's
>>>> > core
>>>> > > > library before, during, and after the hackathon last week. We now
>>>> only
>>>> > > have
>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>> (plus a
>>>> > few
>>>> > > > other minor ones here and there). I expect to be done by the end
>>>> of the
>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>> Packed),
>>>> > > and
>>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>>> > > >
>>>> > > > Again, my goal is to only get a buildable, experimental build of
>>>> > > Lucene.net
>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>> porting
>>>> > > new
>>>> > > > javadoc comments or unit tests right now, due to the vast amount
>>>> of
>>>> > code
>>>> > > > that needs to be written just to get it to compile. If this work
>>>> ends
>>>> > up
>>>> > > > becoming a pull request, great, otherwise it should help
>>>> accelerate a
>>>> > > port
>>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>>> and
>>>> > > > contributors can use it as a reference. And again, we're taking
>>>> the
>>>> > > > pragmatic approach of porting class-by-class,
>>>> namespace-by-namespace,
>>>> > > with
>>>> > > > the understanding that until we're done the project won't build.
>>>> > > >
>>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>>> > module
>>>> > > > and porting the QueryParsers contrib module, which I feel should
>>>> be
>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>> library
>>>> > is
>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>> without
>>>> > > them.
>>>> > > > You can check out the code on my fork/branch here:
>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>> > > >
>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>> For the
>>>> > > MMap
>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>>> pretty
>>>> > > > well, but required some creative shuffling of the code to make it
>>>> work
>>>> > > due
>>>> > > > to lifecycle management.
>>>> > > >
>>>> > > > I'll update again this weekend or next week, when we should have
>>>> > wrapped
>>>> > > up
>>>> > > > most of the main hacking on porting the core code.
>>>> > > >
>>>> > > > Paul
>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pirwin@feature23.com
>>>> >
>>>> > > wrote:
>>>> > > >
>>>> > > > > Marcos,
>>>> > > > >
>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
>>>> is
>>>> > only
>>>> > > on
>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>> together:
>>>> > > > >
>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>> > > > >
>>>> > > > > The SVN for 4.3 java is here:
>>>> > > > >
>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>> > > > > And the GitHub for 4.3 java is here:
>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>> > > > >
>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>> > > > >
>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>> remote
>>>> > > > merging
>>>> > > > > their changes in from their forks while they fetch/merge from
>>>> mine to
>>>> > > get
>>>> > > > > everyone else's changes, rather than using pull requests. James
>>>> and I
>>>> > > > have
>>>> > > > > been working the past few days on the Util namespace ahead of
>>>> > tonight's
>>>> > > > > hackathon since that namespace is in common with the rest of the
>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>>> > hacking
>>>> > > on
>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>> namespace.
>>>> > > > Since
>>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>>> does
>>>> > > not
>>>> > > > > build as it is. Once we finish doing a translation of each
>>>> file, then
>>>> > > > we'll
>>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>>> hoping
>>>> > > > that
>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>> > > > >
>>>> > > > > But one thing to keep in mind is it looks like much
>>>> functionality has
>>>> > > > been
>>>> > > > > moved out of core into the contrib modules, especially around
>>>> > analysis,
>>>> > > > for
>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>> anymore.
>>>> > So
>>>> > > > when
>>>> > > > > this is all done, we may want to include at least the analysis
>>>> > contrib
>>>> > > > > module in with the standard core NuGet package, because
>>>> otherwise
>>>> > it's
>>>> > > > > practically useless unless you roll your own analyzer.
>>>> > > > >
>>>> > > > > Paul
>>>> > > > >
>>>> > > > >
>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>> > marcoslimagon@gmail.com
>>>> > > > >wrote:
>>>> > > > >
>>>> > > > >> Hi everyone!
>>>> > > > >>
>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>> > > Lucene(java)?
>>>> > > > >>
>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>> 4.3.0 and
>>>> > > > make
>>>> > > > >> the diff between then and get all changes between releases... I
>>>> > gonna
>>>> > > > >> publish it here soon. (If you think there is another important
>>>> > > release,
>>>> > > > >> let
>>>> > > > >> me know)
>>>> > > > >>
>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>> with
>>>> > 4.3.0
>>>> > > > >> port
>>>> > > > >> for .Net on github (last email)?
>>>> > > > >>
>>>> > > > >> See you,
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>> > > > >>
>>>> > > > >> > Thanks for the discussion points, Michael.
>>>> > > > >> >
>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>> portable
>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>>> is
>>>> > > > >> completed.
>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>> That's
>>>> > just
>>>> > > > my
>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>>> > > > >> >
>>>> > > > >> > I have started porting the changes from the core library
>>>> (from the
>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>> separate
>>>> > > > branch.
>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>> port
>>>> > > until
>>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>>> to my
>>>> > > > time
>>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>>> > adding.
>>>> > > > >> But if
>>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>>> > that's
>>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>>> going
>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>> get the
>>>> > > ball
>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>> join
>>>> > in.
>>>> > > > But
>>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>>> > > request
>>>> > > > >> then
>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>> this week
>>>> > > > with
>>>> > > > >> my
>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>> > comparing
>>>> > > > >> files
>>>> > > > >> > and making changes as necessary, rather than starting from
>>>> > scratch.
>>>> > > My
>>>> > > > >> > repo/branch is here:
>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>> > > > >> >
>>>> > > > >> > Paul
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>> > > > >> >
>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>> apache
>>>> > > > >> > maintains.
>>>> > > > >> > >
>>>> > > > >> > > The was some work at one time to move the official svn
>>>> > repository
>>>> > > to
>>>> > > > >> > start
>>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>>> > > > >> > >
>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>>> see
>>>> > > what
>>>> > > > >> kind
>>>> > > > >> > of
>>>> > > > >> > > work was involved using a portable libraries project. Some
>>>> of it
>>>> > > can
>>>> > > > >> > still
>>>> > > > >> > > be used but will need to be validated against the current
>>>> > version
>>>> > > of
>>>> > > > >> > Java's
>>>> > > > >> > > Lucene. It was also using .net 4.
>>>> > > > >> > >
>>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>>> > > support.
>>>> > > > >> If
>>>> > > > >> > you
>>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>>> trunk
>>>> > > > will
>>>> > > > >> not
>>>> > > > >> > > compile against those versions of the framework which
>>>> would a
>>>> > > > >> frustrating
>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>> would
>>>> > make
>>>> > > > >> taking
>>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>>> larger
>>>> > > > gaps
>>>> > > > >> in
>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>> > > > >> > >
>>>> > > > >> > > Also the structure has changed significantly between the
>>>> > branches
>>>> > > > and
>>>> > > > >> > the
>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>>> and
>>>> > > seems
>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>> cherry
>>>> > pick
>>>> > > > >> stuff
>>>> > > > >> > > from the other tags/branches that would still work as is.
>>>> A
>>>> > clean
>>>> > > > >> branch
>>>> > > > >> > > would also make it easier to get our build / tool chain in
>>>> order
>>>> > > as
>>>> > > > >> you
>>>> > > > >> > can
>>>> > > > >> > > then do them incrementally versus having to do all the
>>>> stuff
>>>> > that
>>>> > > I
>>>> > > > >> did
>>>> > > > >> > for
>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>> could
>>>> > > also
>>>> > > > >> make
>>>> > > > >> > it
>>>> > > > >> > > easier to see which classes have been ported or not.
>>>> > > > >> > >
>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>> requires
>>>> > and
>>>> > > > the
>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>> which
>>>> > can
>>>> > > > be
>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>> you want
>>>> > > to
>>>> > > > >> use
>>>> > > > >> > > take your legacy code and refactor instead of in someways
>>>> > starting
>>>> > > > >> over.
>>>> > > > >> > >
>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>> > something
>>>> > > > >> similar
>>>> > > > >> > > to
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> >
>>>> > > > >>
>>>> > > >
>>>> > >
>>>> >
>>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>> ported.
>>>> > > > >> > >
>>>> > > > >> > > What are we going to support in the next version?
>>>> > > > >> > >
>>>> > > > >> > > Who is going to work on the next version?
>>>> > > > >> > >
>>>> > > > >> > > What would make the most sense and what would invigorate
>>>> the
>>>> > > > >> community to
>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>> > > > >> > >
>>>> > > > >> > > I think those are the questions that would make a lot of
>>>> the
>>>> > > > decisions
>>>> > > > >> > for
>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>> > > > marcoslimagon@gmail.com
>>>> > > > >> > > >wrote:
>>>> > > > >> > >
>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>> projects...
>>>> > > > >> > > >
>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>>> > > > repository?
>>>> > > > >> > > (This
>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>> recommend
>>>> > (i'm
>>>> > > > used
>>>> > > > >> > with
>>>> > > > >> > > > SVN and its patterns).
>>>> > > > >> > > >
>>>> > > > >> > > > I'm checking the subversion right now.
>>>> > > > >> > > >
>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>>> old
>>>> > > > branch,
>>>> > > > >> i`m
>>>> > > > >> > > not
>>>> > > > >> > > > sure about its current status.
>>>> > > > >> > > >
>>>> > > > >> > > > Will we wipe the current solution from /trunk and start
>>>> a new
>>>> > > one?
>>>> > > > >> > > >
>>>> > > > >> > > > Thanks,
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>>> > > > >> > > >
>>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>>> > people
>>>> > > > >> still
>>>> > > > >> > > want
>>>> > > > >> > > > to
>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>>> RT,
>>>> > > etc.
>>>> > > > >> The
>>>> > > > >> > are
>>>> > > > >> > > > > many
>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>> that
>>>> > > would
>>>> > > > >> not
>>>> > > > >> > be
>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>> It also
>>>> > > > might
>>>> > > > >> > > > require
>>>> > > > >> > > > > a design that differs even more from its parent
>>>> project.
>>>> > > > >> > > > >
>>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>>> next
>>>> > > > >> version
>>>> > > > >> > > > through
>>>> > > > >> > > > > jira or user voice.
>>>> > > > >> > > > >
>>>> > > > >> > > > >
>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>> > > > >> > itamar@code972.com
>>>> > > > >> > > > > >wrote:
>>>> > > > >> > > > >
>>>> > > > >> > > > > > inline
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>> > > > >> pirwin@feature23.com>
>>>> > > > >> > > > wrote:
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>>> a TFS
>>>> > > guy
>>>> > > > >> for
>>>> > > > >> > so
>>>> > > > >> > > > > long
>>>> > > > >> > > > > > > :-)
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>> patches
>>>> > or
>>>> > > > >> > anything
>>>> > > > >> > > > to
>>>> > > > >> > > > > > the
>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>>> > branch
>>>> > > > from
>>>> > > > >> > for
>>>> > > > >> > > 4x
>>>> > > > >> > > > > > dev.
>>>> > > > >> > > > > > > Correct?
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>> anyone
>>>> > > will
>>>> > > > >> be
>>>> > > > >> > > > > > interested in that
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>>> with
>>>> > > the
>>>> > > > >> > github
>>>> > > > >> > > > > sync?
>>>> > > > >> > > > > > > Who could diagnose that?
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>> apache
>>>> > repo
>>>> > > > for
>>>> > > > >> now
>>>> > > > >> > > > while
>>>> > > > >> > > > > > we get that sorted out.
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko
>>>> <
>>>> > > > >> > > > itamar@code972.com
>>>> > > > >> > > > > > > >wrote:
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>> then for
>>>> > > 3.x
>>>> > > > >> > > > > development.
>>>> > > > >> > > > > > > WRT
>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>> whatever
>>>> > > branch.
>>>> > > > >> When
>>>> > > > >> > > you
>>>> > > > >> > > > > > send
>>>> > > > >> > > > > > > us
>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>> dedicated
>>>> > > repo.
>>>> > > > >> For
>>>> > > > >> > > now
>>>> > > > >> > > > it
>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>> it on
>>>> > the
>>>> > > > >> apache
>>>> > > > >> > > > > servers
>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>> > > > >> > > pirwin@feature23.com>
>>>> > > > >> > > > > > > wrote:
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>> 4.3
>>>> > > version
>>>> > > > >> of
>>>> > > > >> > the
>>>> > > > >> > > > > > > Analysis
>>>> > > > >> > > > > > > > > namespace.
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>> intended
>>>> > --
>>>> > > > you
>>>> > > > >> > might
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > meant
>>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>>> a new
>>>> > > > "3x"
>>>> > > > >> > > branch,
>>>> > > > >> > > > > > when
>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>>> > > > >> misnamed...
>>>> > > > >> > so
>>>> > > > >> > > > > maybe
>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>> aiming
>>>> > for
>>>> > > > >> lucene
>>>> > > > >> > > > 4.3.x
>>>> > > > >> > > > > > > > > compatibility?
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>> > upstream
>>>> > > > >> want to
>>>> > > > >> > > > > create
>>>> > > > >> > > > > > > the
>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>> not all
>>>> > > > >> trying to
>>>> > > > >> > > > > create
>>>> > > > >> > > > > > > them
>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Paul
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>> Syn-Hershko <
>>>> > > > >> > > > > > itamar@code972.com
>>>> > > > >> > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>>> use
>>>> > > > 3.6.2 I
>>>> > > > >> > > would
>>>> > > > >> > > > > > highly
>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>> towards v4
>>>> > > > >> > otherwise
>>>> > > > >> > > we
>>>> > > > >> > > > > > will
>>>> > > > >> > > > > > > > > never
>>>> > > > >> > > > > > > > > > make it...
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>>> (same
>>>> > > > repo,
>>>> > > > >> > > > different
>>>> > > > >> > > > > > > > > remotes)
>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>> should
>>>> > > work
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>>> > > > >> > > > > pirwin@feature23.com>
>>>> > > > >> > > > > > > > > wrote:
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > > Itamar,
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>>> way to
>>>> > > do
>>>> > > > >> it, I
>>>> > > > >> > > > just
>>>> > > > >> > > > > > > > thought
>>>> > > > >> > > > > > > > > > that
>>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>>> > > discussion
>>>> > > > >> > > > previously
>>>> > > > >> > > > > > for
>>>> > > > >> > > > > > > > the
>>>> > > > >> > > > > > > > > > 4.x
>>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>>> > better.
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>> branch on
>>>> > > my
>>>> > > > >> fork
>>>> > > > >> > > and
>>>> > > > >> > > > > will
>>>> > > > >> > > > > > > > begin
>>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>>> up to
>>>> > > > >> speed to
>>>> > > > >> > > > > 3.6.2.
>>>> > > > >> > > > > > If
>>>> > > > >> > > > > > > > > > anyone
>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>>> I'm
>>>> > > done,
>>>> > > > >> have
>>>> > > > >> > at
>>>> > > > >> > > > it.
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>> branch_3x
>>>> > > > branch,
>>>> > > > >> > > please
>>>> > > > >> > > > > let
>>>> > > > >> > > > > > > me
>>>> > > > >> > > > > > > > > know
>>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > Paul
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>> > > Syn-Hershko <
>>>> > > > >> > > > > > > > itamar@code972.com
>>>> > > > >> > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>> again :)
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>> know
>>>> > what
>>>> > > > it
>>>> > > > >> > would
>>>> > > > >> > > > > take
>>>> > > > >> > > > > > > > until
>>>> > > > >> > > > > > > > > > they
>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>>> then
>>>> > > > >> decisions
>>>> > > > >> > > > could
>>>> > > > >> > > > > > and
>>>> > > > >> > > > > > > > will
>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>> > starting
>>>> > > > from
>>>> > > > >> > > > scratch,
>>>> > > > >> > > > > > > > > although
>>>> > > > >> > > > > > > > > > I
>>>> > > > >> > > > > > > > > > > do
>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>> should
>>>> > > > change,
>>>> > > > >> but
>>>> > > > >> > > its
>>>> > > > >> > > > > > going
>>>> > > > >> > > > > > > > to
>>>> > > > >> > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>> refactoring
>>>> > > > where
>>>> > > > >> > > > needed,
>>>> > > > >> > > > > > than
>>>> > > > >> > > > > > > > > > > starting
>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>>> > > > personally
>>>> > > > >> > will
>>>> > > > >> > > > be
>>>> > > > >> > > > > > > happy
>>>> > > > >> > > > > > > > > with
>>>> > > > >> > > > > > > > > > > you
>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>> porting
>>>> > > it,
>>>> > > > >> its
>>>> > > > >> > > > pretty
>>>> > > > >> > > > > > > much
>>>> > > > >> > > > > > > > > self
>>>> > > > >> > > > > > > > > > > > contained.
>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
>>>> a fork
>>>> > > and
>>>> > > > >> send
>>>> > > > >> > > us
>>>> > > > >> > > > > PRs,
>>>> > > > >> > > > > > > its
>>>> > > > >> > > > > > > > > > much
>>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>> fastest
>>>> > > way
>>>> > > > >> to do
>>>> > > > >> > > > this,
>>>> > > > >> > > > > > we
>>>> > > > >> > > > > > > > can
>>>> > > > >> > > > > > > > > > then
>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>>> using
>>>> > > > .NET
>>>> > > > >> > > > > constructs.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>> create a
>>>> > > > branch
>>>> > > > >> out
>>>> > > > >> > > of
>>>> > > > >> > > > > the
>>>> > > > >> > > > > > > > > current
>>>> > > > >> > > > > > > > > > > git
>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>>> > > working
>>>> > > > on
>>>> > > > >> > > master
>>>> > > > >> > > > > > > > towards a
>>>> > > > >> > > > > > > > > > 4.3
>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>> should be
>>>> > > > using
>>>> > > > >> a
>>>> > > > >> > > > process
>>>> > > > >> > > > > > > that
>>>> > > > >> > > > > > > > > > > ensures
>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>> tests,
>>>> > > and
>>>> > > > >> that
>>>> > > > >> > > > those
>>>> > > > >> > > > > > > tests
>>>> > > > >> > > > > > > > > > pass -
>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>>> to
>>>> > our
>>>> > > > >> > > > repositories.
>>>> > > > >> > > > > > The
>>>> > > > >> > > > > > > > > > process
>>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>>> some
>>>> > > > order
>>>> > > > >> > > > > > > > (alphabetically,
>>>> > > > >> > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>> class to
>>>> > > > >> compile
>>>> > > > >> > > > before
>>>> > > > >> > > > > > > moving
>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>>> not
>>>> > > being
>>>> > > > >> > > > compilable
>>>> > > > >> > > > > > for
>>>> > > > >> > > > > > > a
>>>> > > > >> > > > > > > > > > month
>>>> > > > >> > > > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > two.
>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>> .NETifying and
>>>> > > > >> proofing
>>>> > > > >> > > the
>>>> > > > >> > > > > code
>>>> > > > >> > > > > > > can
>>>> > > > >> > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>>> have a
>>>> > > > >> working
>>>> > > > >> > v4
>>>> > > > >> > > > > > version
>>>> > > > >> > > > > > > > so
>>>> > > > >> > > > > > > > > it
>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>>> > project.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>> test
>>>> > > suite
>>>> > > > so
>>>> > > > >> > > tests
>>>> > > > >> > > > > > could
>>>> > > > >> > > > > > > > more
>>>> > > > >> > > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>> implementing
>>>> > > > >> Java-like
>>>> > > > >> > > > > > > assertEquals
>>>> > > > >> > > > > > > > > > > methods
>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>> work
>>>> > with
>>>> > > > >> than
>>>> > > > >> > > > > NUnit). I
>>>> > > > >> > > > > > > > > already
>>>> > > > >> > > > > > > > > > > did
>>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>>> to do.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>> myself at
>>>> > > this
>>>> > > > >> > point,
>>>> > > > >> > > > > but I
>>>> > > > >> > > > > > > > > should
>>>> > > > >> > > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>> point I
>>>> > can
>>>> > > > >> > dedicate
>>>> > > > >> > > > > > several
>>>> > > > >> > > > > > > > > > hours a
>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>>> > closely
>>>> > > > and
>>>> > > > >> > even
>>>> > > > >> > > > > > > coordinate
>>>> > > > >> > > > > > > > > the
>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>> Lima <
>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>> > > > >> > > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>>> kick
>>>> > > > start
>>>> > > > >> > =). I
>>>> > > > >> > > > > > haven't
>>>> > > > >> > > > > > > > > > > > contributed
>>>> > > > >> > > > > > > > > > > > > anything
>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>>> to get
>>>> > > > this
>>>> > > > >> job
>>>> > > > >> > > > done.
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>> Prescott.
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>>> for
>>>> > > keep
>>>> > > > >> the
>>>> > > > >> > > > > > > > > > retrocompatibility
>>>> > > > >> > > > > > > > > > > on
>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>>> > changes
>>>> > > > >> every
>>>> > > > >> > > > > release?
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>>> > version
>>>> > > > >> from a
>>>> > > > >> > > > > Lucene
>>>> > > > >> > > > > > > > > version,
>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>> minor
>>>> > > changes
>>>> > > > >> > every
>>>> > > > >> > > > > stable
>>>> > > > >> > > > > > > > > release
>>>> > > > >> > > > > > > > > > > (or
>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>>> > > compare
>>>> > > > >> the
>>>> > > > >> > > > > versions,
>>>> > > > >> > > > > > > > check
>>>> > > > >> > > > > > > > > > the
>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>> Lucene.Net.
>>>> > > > Again, I
>>>> > > > >> > > > haven't
>>>> > > > >> > > > > > > > > > contributed
>>>> > > > >> > > > > > > > > > > > with
>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>>> > idea).
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>> simple
>>>> > > > >> performance
>>>> > > > >> > > > > > > > improvements
>>>> > > > >> > > > > > > > > > > > (without
>>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>>> > > > signatures)?
>>>> > > > >> > Does
>>>> > > > >> > > > it
>>>> > > > >> > > > > > > could
>>>> > > > >> > > > > > > > be
>>>> > > > >> > > > > > > > > > > done,
>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>> pirwin@feature23.com>
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>> suggestion as I
>>>> > > > >> haven't
>>>> > > > >> > > > > > > contributed
>>>> > > > >> > > > > > > > > > > anything
>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>>> with
>>>> > > the
>>>> > > > >> 4.x
>>>> > > > >> > > work
>>>> > > > >> > > > > as I
>>>> > > > >> > > > > > > > have
>>>> > > > >> > > > > > > > > a
>>>> > > > >> > > > > > > > > > > > vested
>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>> completed. I
>>>> > > think
>>>> > > > >> > there
>>>> > > > >> > > > > should
>>>> > > > >> > > > > > > be
>>>> > > > >> > > > > > > > > one
>>>> > > > >> > > > > > > > > > > > person
>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>> > structure
>>>> > > > and
>>>> > > > >> > > > workflow
>>>> > > > >> > > > > > will
>>>> > > > >> > > > > > > > > look
>>>> > > > >> > > > > > > > > > > like
>>>> > > > >> > > > > > > > > > > > > to
>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>> going to
>>>> > be
>>>> > > > >> > starting
>>>> > > > >> > > > from
>>>> > > > >> > > > > > > > scratch
>>>> > > > >> > > > > > > > > > as
>>>> > > > >> > > > > > > > > > > a
>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>> up the
>>>> > > > >> project,
>>>> > > > >> > > get
>>>> > > > >> > > > > > > > everything
>>>> > > > >> > > > > > > > > > > going
>>>> > > > >> > > > > > > > > > > > > in
>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>> > structure,
>>>> > > > >> maybe
>>>> > > > >> > > stub
>>>> > > > >> > > > > out
>>>> > > > >> > > > > > > > some
>>>> > > > >> > > > > > > > > > > > classes,
>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>> anyone
>>>> > > > >> interested
>>>> > > > >> > > in
>>>> > > > >> > > > > > > > > > contributing,
>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>>> code
>>>> > in
>>>> > > > >> there
>>>> > > > >> > so
>>>> > > > >> > > > > it's
>>>> > > > >> > > > > > > easy
>>>> > > > >> > > > > > > > > to
>>>> > > > >> > > > > > > > > > > > > > reference.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>> Lucene.Net.Documents,
>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>> > > > >> > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>> those
>>>> > are
>>>> > > > >> just
>>>> > > > >> > the
>>>> > > > >> > > > > ones
>>>> > > > >> > > > > > > I'm
>>>> > > > >> > > > > > > > > most
>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>> Tell me
>>>> > > what
>>>> > > > >> to
>>>> > > > >> > do
>>>> > > > >> > > > and
>>>> > > > >> > > > > > I'll
>>>> > > > >> > > > > > > > get
>>>> > > > >> > > > > > > > > > > > started
>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>> Prescott
>>>> > > > Nasser
>>>> > > > >> <
>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>> while. We
>>>> > > > have a
>>>> > > > >> > > board
>>>> > > > >> > > > > > report
>>>> > > > >> > > > > > > > due
>>>> > > > >> > > > > > > > > > > soon
>>>> > > > >> > > > > > > > > > > > -
>>>> > > > >> > > > > > > > > > > > > I
>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>> them
>>>> > that
>>>> > > we
>>>> > > > >> seem
>>>> > > > >> > > to
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > > stalled
>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>>> out of
>>>> > > of
>>>> > > > >> jira
>>>> > > > >> > > and
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > been
>>>> > > > >> > > > > > > > > > > > > responsive
>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>> > > questions,
>>>> > > > >> but I
>>>> > > > >> > > > don't
>>>> > > > >> > > > > > > think
>>>> > > > >> > > > > > > > > > we've
>>>> > > > >> > > > > > > > > > > > > done
>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>>> > start
>>>> > > us
>>>> > > > >> back
>>>> > > > >> > > up
>>>> > > > >> > > > > > moving
>>>> > > > >> > > > > > > > > > > forward.
>>>> > > > >> > > > > > > > > > > > > What
>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>> this? If
>>>> > we
>>>> > > > took
>>>> > > > >> > the
>>>> > > > >> > > > java
>>>> > > > >> > > > > > > > lucene
>>>> > > > >> > > > > > > > > > 4.0
>>>> > > > >> > > > > > > > > > > > code
>>>> > > > >> > > > > > > > > > > > > > and
>>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>>> and
>>>> > then
>>>> > > > >> just
>>>> > > > >> > let
>>>> > > > >> > > > > > people
>>>> > > > >> > > > > > > > pull
>>>> > > > >> > > > > > > > > > > that
>>>> > > > >> > > > > > > > > > > > > down
>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>>> that
>>>> > one
>>>> > > > >> way to
>>>> > > > >> > > > maybe
>>>> > > > >> > > > > > > make
>>>> > > > >> > > > > > > > > some
>>>> > > > >> > > > > > > > > > > > > forward
>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > --
>>>> > > > >> > > > > > > > > > > > > --
>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > > --
>>>> > > > >> > > > --
>>>> > > > >> > > > Marcos Lima
>>>> > > > >> > > > Software Developer/Tech Lead
>>>> > > > >> > > > marcoslimagon@gmail.com
>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>> > > > >> > > >
>>>> > > > >> > >
>>>> > > > >> >
>>>> > > > >>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> --
>>>> > > > >> --
>>>> > > > >> Marcos Lima
>>>> > > > >> Software Developer/Tech Lead
>>>> > > > >> marcoslimagon@gmail.com
>>>> > > > >> tel: +55 (19) 9798-9335
>>>> > > > >>
>>>> > > > >
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I made a dumb mistake... I have worked with StandardAnalyzer so long that I
forgot that KeywordAnalyzer is not what I needed to be using, I needed to
use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
Now it works after re-indexing with a quick, dirty implementation of
WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
find out why NumericRangeQuery isn't working.
Sorry for the blast of emails, but I wanted to prevent people from spending
time hunting down my mistake!
On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
> byte being signed is a pain.
>
> Now there's no exception doing a TermQuery, but I also don't get any
> results. It doesn't find any terms when scanning for them. I also tried a
> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
> didn't find any results that way either. So right now only
> MatchAllDocsQuery seems to work.
>
> If anyone would like to do a Google Hangout or anything sometime to look
> into it, let me know.
>
>
> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I realized after I sent that email last night that I could do as you
>> described. When you've been debugging through CorruptedIndexExceptions, you
>> get a little bit of tunnel vision... haha
>>
>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>> the matching documents prints the fields to the console, so it's loading in
>> the stored fields data correctly.
>>
>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>> I can't figure out. There's a whole bunch of buffered byte array operations
>> going on and I can't determine where the issue came from. I'll keep
>> looking, but if someone could grab my fork/branch and help me look that
>> would be great. Here's example index writing and then reading code (also
>> included is a quick port of KeywordAnalyzer):
>> https://gist.github.com/anonymous/6174164
>>
>> Thanks!
>>
>>
>>
>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>
>>> Great
>>>
>>> You can build you Query objects on your own to execute a search, you
>>> don't
>>> actually have to use QueryParser for that
>>>
>>>
>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>> that
>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>> > Lucene.net core building and able to write a simple index in Lucene 4.2
>>> > codec and read in things like the number of documents and whatnot.
>>> Since
>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>> > haven't ported that yet so I haven't done a real search, and I only
>>> built
>>> > the index using a quick port of KeywordAnalyzer which all those
>>> analyzers
>>> > have also moved to another module. But this is definitely good
>>> progress and
>>> > should be a launch point for finishing a 4.3/4.4 port.
>>> >
>>> > You can see my fork/branch here:
>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like
>>> I
>>> > said, only core builds now, no modules/tests build, so only open the
>>> > Lucene.Net.Core.sln)
>>> >
>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>> > questions, thanks!
>>> >
>>> >
>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>> itamar@code972.com
>>> > >wrote:
>>> >
>>> > > Paul, that's awesome. I will need some more time to go over this
>>> thread
>>> > and
>>> > > your work to give actual feedback, SUPER busy at the moment
>>> > >
>>> > >
>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>> > wrote:
>>> > >
>>> > > > All,
>>> > > >
>>> > > > My colleagues and I have made good progress on porting Lucene 4.3's
>>> > core
>>> > > > library before, during, and after the hackathon last week. We now
>>> only
>>> > > have
>>> > > > some remaining items in Search, Index, and Codecs namespaces (plus
>>> a
>>> > few
>>> > > > other minor ones here and there). I expect to be done by the end
>>> of the
>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>> Packed),
>>> > > and
>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>> > > >
>>> > > > Again, my goal is to only get a buildable, experimental build of
>>> > > Lucene.net
>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>> porting
>>> > > new
>>> > > > javadoc comments or unit tests right now, due to the vast amount of
>>> > code
>>> > > > that needs to be written just to get it to compile. If this work
>>> ends
>>> > up
>>> > > > becoming a pull request, great, otherwise it should help
>>> accelerate a
>>> > > port
>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>> and
>>> > > > contributors can use it as a reference. And again, we're taking the
>>> > > > pragmatic approach of porting class-by-class,
>>> namespace-by-namespace,
>>> > > with
>>> > > > the understanding that until we're done the project won't build.
>>> > > >
>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>> > module
>>> > > > and porting the QueryParsers contrib module, which I feel should be
>>> > > > included in the core NuGet package for Lucene.net as the core
>>> library
>>> > is
>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>> without
>>> > > them.
>>> > > > You can check out the code on my fork/branch here:
>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>> > > >
>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
>>> the
>>> > > MMap
>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>> pretty
>>> > > > well, but required some creative shuffling of the code to make it
>>> work
>>> > > due
>>> > > > to lifecycle management.
>>> > > >
>>> > > > I'll update again this weekend or next week, when we should have
>>> > wrapped
>>> > > up
>>> > > > most of the main hacking on porting the core code.
>>> > > >
>>> > > > Paul
>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
>>> > > wrote:
>>> > > >
>>> > > > > Marcos,
>>> > > > >
>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
>>> > only
>>> > > on
>>> > > > > SVN here, before the lucene and solr projects were bundled
>>> together:
>>> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>> > > > >
>>> > > > > The SVN for 4.3 java is here:
>>> > > > >
>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>> > > > > And the GitHub for 4.3 java is here:
>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>> > > > >
>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>> > > > >
>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>> remote
>>> > > > merging
>>> > > > > their changes in from their forks while they fetch/merge from
>>> mine to
>>> > > get
>>> > > > > everyone else's changes, rather than using pull requests. James
>>> and I
>>> > > > have
>>> > > > > been working the past few days on the Util namespace ahead of
>>> > tonight's
>>> > > > > hackathon since that namespace is in common with the rest of the
>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>> > hacking
>>> > > on
>>> > > > > porting 4.3, each with a different namespace or part of a
>>> namespace.
>>> > > > Since
>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>> does
>>> > > not
>>> > > > > build as it is. Once we finish doing a translation of each file,
>>> then
>>> > > > we'll
>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>> hoping
>>> > > > that
>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>> > > > >
>>> > > > > But one thing to keep in mind is it looks like much
>>> functionality has
>>> > > > been
>>> > > > > moved out of core into the contrib modules, especially around
>>> > analysis,
>>> > > > for
>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>> anymore.
>>> > So
>>> > > > when
>>> > > > > this is all done, we may want to include at least the analysis
>>> > contrib
>>> > > > > module in with the standard core NuGet package, because otherwise
>>> > it's
>>> > > > > practically useless unless you roll your own analyzer.
>>> > > > >
>>> > > > > Paul
>>> > > > >
>>> > > > >
>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>> > marcoslimagon@gmail.com
>>> > > > >wrote:
>>> > > > >
>>> > > > >> Hi everyone!
>>> > > > >>
>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>> > > Lucene(java)?
>>> > > > >>
>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>> 4.3.0 and
>>> > > > make
>>> > > > >> the diff between then and get all changes between releases... I
>>> > gonna
>>> > > > >> publish it here soon. (If you think there is another important
>>> > > release,
>>> > > > >> let
>>> > > > >> me know)
>>> > > > >>
>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
>>> > 4.3.0
>>> > > > >> port
>>> > > > >> for .Net on github (last email)?
>>> > > > >>
>>> > > > >> See you,
>>> > > > >>
>>> > > > >>
>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>> > > > >>
>>> > > > >> > Thanks for the discussion points, Michael.
>>> > > > >> >
>>> > > > >> > I would vote for not worrying about trying to achieve portable
>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>> is
>>> > > > >> completed.
>>> > > > >> > Otherwise it may delay the project and stall it further.
>>> That's
>>> > just
>>> > > > my
>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>> > > > >> >
>>> > > > >> > I have started porting the changes from the core library
>>> (from the
>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>> separate
>>> > > > branch.
>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>> port
>>> > > until
>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>> to my
>>> > > > time
>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>> > adding.
>>> > > > >> But if
>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>> > that's
>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>> going
>>> > > > >> > class-by-class, starting with the util namespace. Once we get
>>> the
>>> > > ball
>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>> join
>>> > in.
>>> > > > But
>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>> > > request
>>> > > > >> then
>>> > > > >> > as a reference. I'm also going to be holding a hackathon this
>>> week
>>> > > > with
>>> > > > >> my
>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>> > comparing
>>> > > > >> files
>>> > > > >> > and making changes as necessary, rather than starting from
>>> > scratch.
>>> > > My
>>> > > > >> > repo/branch is here:
>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>> > > > >> >
>>> > > > >> > Paul
>>> > > > >> >
>>> > > > >> >
>>> > > > >> >
>>> > > > >> >
>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>> > > > >> >
>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>> apache
>>> > > > >> > maintains.
>>> > > > >> > >
>>> > > > >> > > The was some work at one time to move the official svn
>>> > repository
>>> > > to
>>> > > > >> > start
>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>> > > > >> > >
>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>> see
>>> > > what
>>> > > > >> kind
>>> > > > >> > of
>>> > > > >> > > work was involved using a portable libraries project. Some
>>> of it
>>> > > can
>>> > > > >> > still
>>> > > > >> > > be used but will need to be validated against the current
>>> > version
>>> > > of
>>> > > > >> > Java's
>>> > > > >> > > Lucene. It was also using .net 4.
>>> > > > >> > >
>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>> > > support.
>>> > > > >> If
>>> > > > >> > you
>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>> trunk
>>> > > > will
>>> > > > >> not
>>> > > > >> > > compile against those versions of the framework which would
>>> a
>>> > > > >> frustrating
>>> > > > >> > > starting point, then you couldn't even run tests, which
>>> would
>>> > make
>>> > > > >> taking
>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>> larger
>>> > > > gaps
>>> > > > >> in
>>> > > > >> > > design between Lucene.Net and its parent project.
>>> > > > >> > >
>>> > > > >> > > Also the structure has changed significantly between the
>>> > branches
>>> > > > and
>>> > > > >> > the
>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>> and
>>> > > seems
>>> > > > >> > > significantly different. That doesn't mean you can't cherry
>>> > pick
>>> > > > >> stuff
>>> > > > >> > > from the other tags/branches that would still work as is. A
>>> > clean
>>> > > > >> branch
>>> > > > >> > > would also make it easier to get our build / tool chain in
>>> order
>>> > > as
>>> > > > >> you
>>> > > > >> > can
>>> > > > >> > > then do them incrementally versus having to do all the stuff
>>> > that
>>> > > I
>>> > > > >> did
>>> > > > >> > for
>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>> could
>>> > > also
>>> > > > >> make
>>> > > > >> > it
>>> > > > >> > > easier to see which classes have been ported or not.
>>> > > > >> > >
>>> > > > >> > > The major downside to a clean branch is extra work it
>>> requires
>>> > and
>>> > > > the
>>> > > > >> > > start up cost in time and energy of getting it in order,
>>> which
>>> > can
>>> > > > be
>>> > > > >> > > daunting / intimidating and lower morale. And generally you
>>> want
>>> > > to
>>> > > > >> use
>>> > > > >> > > take your legacy code and refactor instead of in someways
>>> > starting
>>> > > > >> over.
>>> > > > >> > >
>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>> > something
>>> > > > >> similar
>>> > > > >> > > to
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > >
>>> > >
>>> >
>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>> > > > >> > > where it tracks what needs to get ported / what has been
>>> ported.
>>> > > > >> > >
>>> > > > >> > > What are we going to support in the next version?
>>> > > > >> > >
>>> > > > >> > > Who is going to work on the next version?
>>> > > > >> > >
>>> > > > >> > > What would make the most sense and what would invigorate the
>>> > > > >> community to
>>> > > > >> > > get involved more and lower the barrier to entry?
>>> > > > >> > >
>>> > > > >> > > I think those are the questions that would make a lot of the
>>> > > > decisions
>>> > > > >> > for
>>> > > > >> > > us so that we can get back to work on lucene.net.
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>> > > > marcoslimagon@gmail.com
>>> > > > >> > > >wrote:
>>> > > > >> > >
>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>> projects...
>>> > > > >> > > >
>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>> > > > repository?
>>> > > > >> > > (This
>>> > > > >> > > > is new for me, pretty good) Which of them do you recommend
>>> > (i'm
>>> > > > used
>>> > > > >> > with
>>> > > > >> > > > SVN and its patterns).
>>> > > > >> > > >
>>> > > > >> > > > I'm checking the subversion right now.
>>> > > > >> > > >
>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>> old
>>> > > > branch,
>>> > > > >> i`m
>>> > > > >> > > not
>>> > > > >> > > > sure about its current status.
>>> > > > >> > > >
>>> > > > >> > > > Will we wipe the current solution from /trunk and start a
>>> new
>>> > > one?
>>> > > > >> > > >
>>> > > > >> > > > Thanks,
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>> > > > >> > > >
>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>> > people
>>> > > > >> still
>>> > > > >> > > want
>>> > > > >> > > > to
>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>> RT,
>>> > > etc.
>>> > > > >> The
>>> > > > >> > are
>>> > > > >> > > > > many
>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>> that
>>> > > would
>>> > > > >> not
>>> > > > >> > be
>>> > > > >> > > > > accessible in other versions of the .NET Framework. It
>>> also
>>> > > > might
>>> > > > >> > > > require
>>> > > > >> > > > > a design that differs even more from its parent project.
>>> > > > >> > > > >
>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>> next
>>> > > > >> version
>>> > > > >> > > > through
>>> > > > >> > > > > jira or user voice.
>>> > > > >> > > > >
>>> > > > >> > > > >
>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>> > > > >> > itamar@code972.com
>>> > > > >> > > > > >wrote:
>>> > > > >> > > > >
>>> > > > >> > > > > > inline
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>> > > > >> pirwin@feature23.com>
>>> > > > >> > > > wrote:
>>> > > > >> > > > > >
>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>> a TFS
>>> > > guy
>>> > > > >> for
>>> > > > >> > so
>>> > > > >> > > > > long
>>> > > > >> > > > > > > :-)
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>> patches
>>> > or
>>> > > > >> > anything
>>> > > > >> > > > to
>>> > > > >> > > > > > the
>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>> > branch
>>> > > > from
>>> > > > >> > for
>>> > > > >> > > 4x
>>> > > > >> > > > > > dev.
>>> > > > >> > > > > > > Correct?
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>> anyone
>>> > > will
>>> > > > >> be
>>> > > > >> > > > > > interested in that
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>> with
>>> > > the
>>> > > > >> > github
>>> > > > >> > > > > sync?
>>> > > > >> > > > > > > Who could diagnose that?
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
>>> > repo
>>> > > > for
>>> > > > >> now
>>> > > > >> > > > while
>>> > > > >> > > > > > we get that sorted out.
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
>>> > > > >> > > > itamar@code972.com
>>> > > > >> > > > > > > >wrote:
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
>>> for
>>> > > 3.x
>>> > > > >> > > > > development.
>>> > > > >> > > > > > > WRT
>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
>>> > > branch.
>>> > > > >> When
>>> > > > >> > > you
>>> > > > >> > > > > > send
>>> > > > >> > > > > > > us
>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>> dedicated
>>> > > repo.
>>> > > > >> For
>>> > > > >> > > now
>>> > > > >> > > > it
>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it
>>> on
>>> > the
>>> > > > >> apache
>>> > > > >> > > > > servers
>>> > > > >> > > > > > > > (github sync seems to be off)
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>> > > > >> > > pirwin@feature23.com>
>>> > > > >> > > > > > > wrote:
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
>>> > > version
>>> > > > >> of
>>> > > > >> > the
>>> > > > >> > > > > > > Analysis
>>> > > > >> > > > > > > > > namespace.
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>> intended
>>> > --
>>> > > > you
>>> > > > >> > might
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > meant
>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>> a new
>>> > > > "3x"
>>> > > > >> > > branch,
>>> > > > >> > > > > > when
>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>> > > > >> misnamed...
>>> > > > >> > so
>>> > > > >> > > > > maybe
>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>> aiming
>>> > for
>>> > > > >> lucene
>>> > > > >> > > > 4.3.x
>>> > > > >> > > > > > > > > compatibility?
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>> > upstream
>>> > > > >> want to
>>> > > > >> > > > > create
>>> > > > >> > > > > > > the
>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
>>> all
>>> > > > >> trying to
>>> > > > >> > > > > create
>>> > > > >> > > > > > > them
>>> > > > >> > > > > > > > > and dealing with a merge?
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Paul
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>> Syn-Hershko <
>>> > > > >> > > > > > itamar@code972.com
>>> > > > >> > > > > > > > > >wrote:
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>> use
>>> > > > 3.6.2 I
>>> > > > >> > > would
>>> > > > >> > > > > > highly
>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>> towards v4
>>> > > > >> > otherwise
>>> > > > >> > > we
>>> > > > >> > > > > > will
>>> > > > >> > > > > > > > > never
>>> > > > >> > > > > > > > > > make it...
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>> (same
>>> > > > repo,
>>> > > > >> > > > different
>>> > > > >> > > > > > > > > remotes)
>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>> should
>>> > > work
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>> > > > >> > > > > pirwin@feature23.com>
>>> > > > >> > > > > > > > > wrote:
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > > Itamar,
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>> way to
>>> > > do
>>> > > > >> it, I
>>> > > > >> > > > just
>>> > > > >> > > > > > > > thought
>>> > > > >> > > > > > > > > > that
>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>> > > discussion
>>> > > > >> > > > previously
>>> > > > >> > > > > > for
>>> > > > >> > > > > > > > the
>>> > > > >> > > > > > > > > > 4.x
>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>> > better.
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>> branch on
>>> > > my
>>> > > > >> fork
>>> > > > >> > > and
>>> > > > >> > > > > will
>>> > > > >> > > > > > > > begin
>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>> up to
>>> > > > >> speed to
>>> > > > >> > > > > 3.6.2.
>>> > > > >> > > > > > If
>>> > > > >> > > > > > > > > > anyone
>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>> I'm
>>> > > done,
>>> > > > >> have
>>> > > > >> > at
>>> > > > >> > > > it.
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>> branch_3x
>>> > > > branch,
>>> > > > >> > > please
>>> > > > >> > > > > let
>>> > > > >> > > > > > > me
>>> > > > >> > > > > > > > > know
>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > Paul
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>> > > Syn-Hershko <
>>> > > > >> > > > > > > > itamar@code972.com
>>> > > > >> > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>> again :)
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>> know
>>> > what
>>> > > > it
>>> > > > >> > would
>>> > > > >> > > > > take
>>> > > > >> > > > > > > > until
>>> > > > >> > > > > > > > > > they
>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>> then
>>> > > > >> decisions
>>> > > > >> > > > could
>>> > > > >> > > > > > and
>>> > > > >> > > > > > > > will
>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>> > starting
>>> > > > from
>>> > > > >> > > > scratch,
>>> > > > >> > > > > > > > > although
>>> > > > >> > > > > > > > > > I
>>> > > > >> > > > > > > > > > > do
>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>> should
>>> > > > change,
>>> > > > >> but
>>> > > > >> > > its
>>> > > > >> > > > > > going
>>> > > > >> > > > > > > > to
>>> > > > >> > > > > > > > > be
>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>> refactoring
>>> > > > where
>>> > > > >> > > > needed,
>>> > > > >> > > > > > than
>>> > > > >> > > > > > > > > > > starting
>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>> > > > personally
>>> > > > >> > will
>>> > > > >> > > > be
>>> > > > >> > > > > > > happy
>>> > > > >> > > > > > > > > with
>>> > > > >> > > > > > > > > > > you
>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>> porting
>>> > > it,
>>> > > > >> its
>>> > > > >> > > > pretty
>>> > > > >> > > > > > > much
>>> > > > >> > > > > > > > > self
>>> > > > >> > > > > > > > > > > > contained.
>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
>>> fork
>>> > > and
>>> > > > >> send
>>> > > > >> > > us
>>> > > > >> > > > > PRs,
>>> > > > >> > > > > > > its
>>> > > > >> > > > > > > > > > much
>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>> fastest
>>> > > way
>>> > > > >> to do
>>> > > > >> > > > this,
>>> > > > >> > > > > > we
>>> > > > >> > > > > > > > can
>>> > > > >> > > > > > > > > > then
>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>> using
>>> > > > .NET
>>> > > > >> > > > > constructs.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>> create a
>>> > > > branch
>>> > > > >> out
>>> > > > >> > > of
>>> > > > >> > > > > the
>>> > > > >> > > > > > > > > current
>>> > > > >> > > > > > > > > > > git
>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>> > > working
>>> > > > on
>>> > > > >> > > master
>>> > > > >> > > > > > > > towards a
>>> > > > >> > > > > > > > > > 4.3
>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>> should be
>>> > > > using
>>> > > > >> a
>>> > > > >> > > > process
>>> > > > >> > > > > > > that
>>> > > > >> > > > > > > > > > > ensures
>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>> tests,
>>> > > and
>>> > > > >> that
>>> > > > >> > > > those
>>> > > > >> > > > > > > tests
>>> > > > >> > > > > > > > > > pass -
>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>> to
>>> > our
>>> > > > >> > > > repositories.
>>> > > > >> > > > > > The
>>> > > > >> > > > > > > > > > process
>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>> some
>>> > > > order
>>> > > > >> > > > > > > > (alphabetically,
>>> > > > >> > > > > > > > > or
>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>> class to
>>> > > > >> compile
>>> > > > >> > > > before
>>> > > > >> > > > > > > moving
>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>> not
>>> > > being
>>> > > > >> > > > compilable
>>> > > > >> > > > > > for
>>> > > > >> > > > > > > a
>>> > > > >> > > > > > > > > > month
>>> > > > >> > > > > > > > > > > or
>>> > > > >> > > > > > > > > > > > two.
>>> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
>>> and
>>> > > > >> proofing
>>> > > > >> > > the
>>> > > > >> > > > > code
>>> > > > >> > > > > > > can
>>> > > > >> > > > > > > > > be
>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>> have a
>>> > > > >> working
>>> > > > >> > v4
>>> > > > >> > > > > > version
>>> > > > >> > > > > > > > so
>>> > > > >> > > > > > > > > it
>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>> > project.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>> test
>>> > > suite
>>> > > > so
>>> > > > >> > > tests
>>> > > > >> > > > > > could
>>> > > > >> > > > > > > > more
>>> > > > >> > > > > > > > > > or
>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>> implementing
>>> > > > >> Java-like
>>> > > > >> > > > > > > assertEquals
>>> > > > >> > > > > > > > > > > methods
>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>> work
>>> > with
>>> > > > >> than
>>> > > > >> > > > > NUnit). I
>>> > > > >> > > > > > > > > already
>>> > > > >> > > > > > > > > > > did
>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>> to do.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>> myself at
>>> > > this
>>> > > > >> > point,
>>> > > > >> > > > > but I
>>> > > > >> > > > > > > > > should
>>> > > > >> > > > > > > > > > be
>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>> point I
>>> > can
>>> > > > >> > dedicate
>>> > > > >> > > > > > several
>>> > > > >> > > > > > > > > > hours a
>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>> > closely
>>> > > > and
>>> > > > >> > even
>>> > > > >> > > > > > > coordinate
>>> > > > >> > > > > > > > > the
>>> > > > >> > > > > > > > > > > > work to some extent.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>> Lima <
>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>> > > > >> > > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>> kick
>>> > > > start
>>> > > > >> > =). I
>>> > > > >> > > > > > haven't
>>> > > > >> > > > > > > > > > > > contributed
>>> > > > >> > > > > > > > > > > > > anything
>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>> to get
>>> > > > this
>>> > > > >> job
>>> > > > >> > > > done.
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>> Prescott.
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>> for
>>> > > keep
>>> > > > >> the
>>> > > > >> > > > > > > > > > retrocompatibility
>>> > > > >> > > > > > > > > > > on
>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>> > changes
>>> > > > >> every
>>> > > > >> > > > > release?
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>> > version
>>> > > > >> from a
>>> > > > >> > > > > Lucene
>>> > > > >> > > > > > > > > version,
>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
>>> > > changes
>>> > > > >> > every
>>> > > > >> > > > > stable
>>> > > > >> > > > > > > > > release
>>> > > > >> > > > > > > > > > > (or
>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>> > > compare
>>> > > > >> the
>>> > > > >> > > > > versions,
>>> > > > >> > > > > > > > check
>>> > > > >> > > > > > > > > > the
>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>> Lucene.Net.
>>> > > > Again, I
>>> > > > >> > > > haven't
>>> > > > >> > > > > > > > > > contributed
>>> > > > >> > > > > > > > > > > > with
>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>> > idea).
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>> simple
>>> > > > >> performance
>>> > > > >> > > > > > > > improvements
>>> > > > >> > > > > > > > > > > > (without
>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>> > > > signatures)?
>>> > > > >> > Does
>>> > > > >> > > > it
>>> > > > >> > > > > > > could
>>> > > > >> > > > > > > > be
>>> > > > >> > > > > > > > > > > done,
>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>> pirwin@feature23.com>
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
>>> as I
>>> > > > >> haven't
>>> > > > >> > > > > > > contributed
>>> > > > >> > > > > > > > > > > anything
>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>> with
>>> > > the
>>> > > > >> 4.x
>>> > > > >> > > work
>>> > > > >> > > > > as I
>>> > > > >> > > > > > > > have
>>> > > > >> > > > > > > > > a
>>> > > > >> > > > > > > > > > > > vested
>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>> completed. I
>>> > > think
>>> > > > >> > there
>>> > > > >> > > > > should
>>> > > > >> > > > > > > be
>>> > > > >> > > > > > > > > one
>>> > > > >> > > > > > > > > > > > person
>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>> > structure
>>> > > > and
>>> > > > >> > > > workflow
>>> > > > >> > > > > > will
>>> > > > >> > > > > > > > > look
>>> > > > >> > > > > > > > > > > like
>>> > > > >> > > > > > > > > > > > > to
>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going
>>> to
>>> > be
>>> > > > >> > starting
>>> > > > >> > > > from
>>> > > > >> > > > > > > > scratch
>>> > > > >> > > > > > > > > > as
>>> > > > >> > > > > > > > > > > a
>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
>>> the
>>> > > > >> project,
>>> > > > >> > > get
>>> > > > >> > > > > > > > everything
>>> > > > >> > > > > > > > > > > going
>>> > > > >> > > > > > > > > > > > > in
>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>> > structure,
>>> > > > >> maybe
>>> > > > >> > > stub
>>> > > > >> > > > > out
>>> > > > >> > > > > > > > some
>>> > > > >> > > > > > > > > > > > classes,
>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>> anyone
>>> > > > >> interested
>>> > > > >> > > in
>>> > > > >> > > > > > > > > > contributing,
>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>> code
>>> > in
>>> > > > >> there
>>> > > > >> > so
>>> > > > >> > > > > it's
>>> > > > >> > > > > > > easy
>>> > > > >> > > > > > > > > to
>>> > > > >> > > > > > > > > > > > > > reference.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>> Lucene.Net.Documents,
>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>> > > > >> > > > > > > > > or
>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>> those
>>> > are
>>> > > > >> just
>>> > > > >> > the
>>> > > > >> > > > > ones
>>> > > > >> > > > > > > I'm
>>> > > > >> > > > > > > > > most
>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>> Tell me
>>> > > what
>>> > > > >> to
>>> > > > >> > do
>>> > > > >> > > > and
>>> > > > >> > > > > > I'll
>>> > > > >> > > > > > > > get
>>> > > > >> > > > > > > > > > > > started
>>> > > > >> > > > > > > > > > > > > > on my fork.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>> Prescott
>>> > > > Nasser
>>> > > > >> <
>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>> > > > >> > > > > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>> while. We
>>> > > > have a
>>> > > > >> > > board
>>> > > > >> > > > > > report
>>> > > > >> > > > > > > > due
>>> > > > >> > > > > > > > > > > soon
>>> > > > >> > > > > > > > > > > > -
>>> > > > >> > > > > > > > > > > > > I
>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
>>> > that
>>> > > we
>>> > > > >> seem
>>> > > > >> > > to
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > > stalled
>>> > > > >> > > > > > > > > > > > > > somewhat.
>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>> out of
>>> > > of
>>> > > > >> jira
>>> > > > >> > > and
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > been
>>> > > > >> > > > > > > > > > > > > responsive
>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>> > > questions,
>>> > > > >> but I
>>> > > > >> > > > don't
>>> > > > >> > > > > > > think
>>> > > > >> > > > > > > > > > we've
>>> > > > >> > > > > > > > > > > > > done
>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>> > start
>>> > > us
>>> > > > >> back
>>> > > > >> > > up
>>> > > > >> > > > > > moving
>>> > > > >> > > > > > > > > > > forward.
>>> > > > >> > > > > > > > > > > > > What
>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this?
>>> If
>>> > we
>>> > > > took
>>> > > > >> > the
>>> > > > >> > > > java
>>> > > > >> > > > > > > > lucene
>>> > > > >> > > > > > > > > > 4.0
>>> > > > >> > > > > > > > > > > > code
>>> > > > >> > > > > > > > > > > > > > and
>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>> and
>>> > then
>>> > > > >> just
>>> > > > >> > let
>>> > > > >> > > > > > people
>>> > > > >> > > > > > > > pull
>>> > > > >> > > > > > > > > > > that
>>> > > > >> > > > > > > > > > > > > down
>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>> that
>>> > one
>>> > > > >> way to
>>> > > > >> > > > maybe
>>> > > > >> > > > > > > make
>>> > > > >> > > > > > > > > some
>>> > > > >> > > > > > > > > > > > > forward
>>> > > > >> > > > > > > > > > > > > > > progress?
>>> > > > >> > > > > > > > > > > > > > > ~P
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > --
>>> > > > >> > > > > > > > > > > > > --
>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > > --
>>> > > > >> > > > --
>>> > > > >> > > > Marcos Lima
>>> > > > >> > > > Software Developer/Tech Lead
>>> > > > >> > > > marcoslimagon@gmail.com
>>> > > > >> > > > tel: +55 (19) 9798-9335
>>> > > > >> > > >
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >> --
>>> > > > >> --
>>> > > > >> Marcos Lima
>>> > > > >> Software Developer/Tech Lead
>>> > > > >> marcoslimagon@gmail.com
>>> > > > >> tel: +55 (19) 9798-9335
>>> > > > >>
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
byte being signed is a pain.
Now there's no exception doing a TermQuery, but I also don't get any
results. It doesn't find any terms when scanning for them. I also tried a
NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
didn't find any results that way either. So right now only
MatchAllDocsQuery seems to work.
If anyone would like to do a Google Hangout or anything sometime to look
into it, let me know.
On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
> I realized after I sent that email last night that I could do as you
> described. When you've been debugging through CorruptedIndexExceptions, you
> get a little bit of tunnel vision... haha
>
> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
> the matching documents prints the fields to the console, so it's loading in
> the stored fields data correctly.
>
> I tried doing a TermQuery and now I get a "read past EOF" exception that I
> can't figure out. There's a whole bunch of buffered byte array operations
> going on and I can't determine where the issue came from. I'll keep
> looking, but if someone could grab my fork/branch and help me look that
> would be great. Here's example index writing and then reading code (also
> included is a quick port of KeywordAnalyzer):
> https://gist.github.com/anonymous/6174164
>
> Thanks!
>
>
>
> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>
>> Great
>>
>> You can build you Query objects on your own to execute a search, you don't
>> actually have to use QueryParser for that
>>
>>
>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>> > Hey all, sorry it's been a little while, but I wanted to let you know
>> that
>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>> > Lucene.net core building and able to write a simple index in Lucene 4.2
>> > codec and read in things like the number of documents and whatnot. Since
>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>> > haven't ported that yet so I haven't done a real search, and I only
>> built
>> > the index using a quick port of KeywordAnalyzer which all those
>> analyzers
>> > have also moved to another module. But this is definitely good progress
>> and
>> > should be a launch point for finishing a 4.3/4.4 port.
>> >
>> > You can see my fork/branch here:
>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
>> > said, only core builds now, no modules/tests build, so only open the
>> > Lucene.Net.Core.sln)
>> >
>> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>> > questions, thanks!
>> >
>> >
>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
>> > >wrote:
>> >
>> > > Paul, that's awesome. I will need some more time to go over this
>> thread
>> > and
>> > > your work to give actual feedback, SUPER busy at the moment
>> > >
>> > >
>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>> > wrote:
>> > >
>> > > > All,
>> > > >
>> > > > My colleagues and I have made good progress on porting Lucene 4.3's
>> > core
>> > > > library before, during, and after the hackathon last week. We now
>> only
>> > > have
>> > > > some remaining items in Search, Index, and Codecs namespaces (plus a
>> > few
>> > > > other minor ones here and there). I expect to be done by the end of
>> the
>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>> Packed),
>> > > and
>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>> > > >
>> > > > Again, my goal is to only get a buildable, experimental build of
>> > > Lucene.net
>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>> porting
>> > > new
>> > > > javadoc comments or unit tests right now, due to the vast amount of
>> > code
>> > > > that needs to be written just to get it to compile. If this work
>> ends
>> > up
>> > > > becoming a pull request, great, otherwise it should help accelerate
>> a
>> > > port
>> > > > of 4.3.x since the bulk of the work on core will already be done and
>> > > > contributors can use it as a reference. And again, we're taking the
>> > > > pragmatic approach of porting class-by-class,
>> namespace-by-namespace,
>> > > with
>> > > > the understanding that until we're done the project won't build.
>> > > >
>> > > > Once complete, I also will work on updating the Analyzers contrib
>> > module
>> > > > and porting the QueryParsers contrib module, which I feel should be
>> > > > included in the core NuGet package for Lucene.net as the core
>> library
>> > is
>> > > > now (post-4.0) practically useless (or atleast not turn-key) without
>> > > them.
>> > > > You can check out the code on my fork/branch here:
>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>> > > >
>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
>> the
>> > > MMap
>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>> pretty
>> > > > well, but required some creative shuffling of the code to make it
>> work
>> > > due
>> > > > to lifecycle management.
>> > > >
>> > > > I'll update again this weekend or next week, when we should have
>> > wrapped
>> > > up
>> > > > most of the main hacking on porting the core code.
>> > > >
>> > > > Paul
>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
>> > > wrote:
>> > > >
>> > > > > Marcos,
>> > > > >
>> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
>> > only
>> > > on
>> > > > > SVN here, before the lucene and solr projects were bundled
>> together:
>> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>> > > > >
>> > > > > The SVN for 4.3 java is here:
>> > > > >
>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>> > > > > And the GitHub for 4.3 java is here:
>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>> > > > >
>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>> > > > >
>> > > > > My fork is the "upstream" fork for my team members, and i'm remote
>> > > > merging
>> > > > > their changes in from their forks while they fetch/merge from
>> mine to
>> > > get
>> > > > > everyone else's changes, rather than using pull requests. James
>> and I
>> > > > have
>> > > > > been working the past few days on the Util namespace ahead of
>> > tonight's
>> > > > > hackathon since that namespace is in common with the rest of the
>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>> > hacking
>> > > on
>> > > > > porting 4.3, each with a different namespace or part of a
>> namespace.
>> > > > Since
>> > > > > we're going class-by-class, namespace-by-namespace, the project
>> does
>> > > not
>> > > > > build as it is. Once we finish doing a translation of each file,
>> then
>> > > > we'll
>> > > > > hammer out any remaining issues and get it to build again. I'm
>> hoping
>> > > > that
>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>> > > > >
>> > > > > But one thing to keep in mind is it looks like much functionality
>> has
>> > > > been
>> > > > > moved out of core into the contrib modules, especially around
>> > analysis,
>> > > > for
>> > > > > 4.0+. For example, there are no built-in analyzers in core
>> anymore.
>> > So
>> > > > when
>> > > > > this is all done, we may want to include at least the analysis
>> > contrib
>> > > > > module in with the standard core NuGet package, because otherwise
>> > it's
>> > > > > practically useless unless you roll your own analyzer.
>> > > > >
>> > > > > Paul
>> > > > >
>> > > > >
>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>> > marcoslimagon@gmail.com
>> > > > >wrote:
>> > > > >
>> > > > >> Hi everyone!
>> > > > >>
>> > > > >> Does someone know where can I find the 3.0.3 release from
>> > > Lucene(java)?
>> > > > >>
>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0
>> and
>> > > > make
>> > > > >> the diff between then and get all changes between releases... I
>> > gonna
>> > > > >> publish it here soon. (If you think there is another important
>> > > release,
>> > > > >> let
>> > > > >> me know)
>> > > > >>
>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
>> > 4.3.0
>> > > > >> port
>> > > > >> for .Net on github (last email)?
>> > > > >>
>> > > > >> See you,
>> > > > >>
>> > > > >>
>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>> > > > >>
>> > > > >> > Thanks for the discussion points, Michael.
>> > > > >> >
>> > > > >> > I would vote for not worrying about trying to achieve portable
>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
>> > > > >> completed.
>> > > > >> > Otherwise it may delay the project and stall it further. That's
>> > just
>> > > > my
>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>> > > > >> >
>> > > > >> > I have started porting the changes from the core library (from
>> the
>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
>> > > > branch.
>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
>> > > until
>> > > > >> > there's changes to pull from upstream to work from. Also due
>> to my
>> > > > time
>> > > > >> > constraints, I am not fully documenting new methods that I'm
>> > adding.
>> > > > >> But if
>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>> > that's
>> > > > >> > awesome. My branch currently does not build as I'm primarily
>> going
>> > > > >> > class-by-class, starting with the util namespace. Once we get
>> the
>> > > ball
>> > > > >> > rolling on a community effort, I'll stop my rogue work and join
>> > in.
>> > > > But
>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>> > > request
>> > > > >> then
>> > > > >> > as a reference. I'm also going to be holding a hackathon this
>> week
>> > > > with
>> > > > >> my
>> > > > >> > colleagues where we're all going to work on the port. I'm
>> > comparing
>> > > > >> files
>> > > > >> > and making changes as necessary, rather than starting from
>> > scratch.
>> > > My
>> > > > >> > repo/branch is here:
>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>> > > > >> >
>> > > > >> > Paul
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>> > > > >> > mherndon@michaelherndon.com> wrote:
>> > > > >> >
>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>> apache
>> > > > >> > maintains.
>> > > > >> > >
>> > > > >> > > The was some work at one time to move the official svn
>> > repository
>> > > to
>> > > > >> > start
>> > > > >> > > using git one instead. Was that actually finalized or not?
>> > > > >> > >
>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>> see
>> > > what
>> > > > >> kind
>> > > > >> > of
>> > > > >> > > work was involved using a portable libraries project. Some
>> of it
>> > > can
>> > > > >> > still
>> > > > >> > > be used but will need to be validated against the current
>> > version
>> > > of
>> > > > >> > Java's
>> > > > >> > > Lucene. It was also using .net 4.
>> > > > >> > >
>> > > > >> > > clean branch vs current. Its going to depend on what we
>> > > support.
>> > > > >> If
>> > > > >> > you
>> > > > >> > > support windows mobile 8, win RT, then the current code in
>> trunk
>> > > > will
>> > > > >> not
>> > > > >> > > compile against those versions of the framework which would a
>> > > > >> frustrating
>> > > > >> > > starting point, then you couldn't even run tests, which would
>> > make
>> > > > >> taking
>> > > > >> > > patches very difficult. Supporting those can almost mean
>> larger
>> > > > gaps
>> > > > >> in
>> > > > >> > > design between Lucene.Net and its parent project.
>> > > > >> > >
>> > > > >> > > Also the structure has changed significantly between the
>> > branches
>> > > > and
>> > > > >> > the
>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
>> > > seems
>> > > > >> > > significantly different. That doesn't mean you can't cherry
>> > pick
>> > > > >> stuff
>> > > > >> > > from the other tags/branches that would still work as is. A
>> > clean
>> > > > >> branch
>> > > > >> > > would also make it easier to get our build / tool chain in
>> order
>> > > as
>> > > > >> you
>> > > > >> > can
>> > > > >> > > then do them incrementally versus having to do all the stuff
>> > that
>> > > I
>> > > > >> did
>> > > > >> > for
>> > > > >> > > the 3x branch which saps energy and desire to code. It
>> could
>> > > also
>> > > > >> make
>> > > > >> > it
>> > > > >> > > easier to see which classes have been ported or not.
>> > > > >> > >
>> > > > >> > > The major downside to a clean branch is extra work it
>> requires
>> > and
>> > > > the
>> > > > >> > > start up cost in time and energy of getting it in order,
>> which
>> > can
>> > > > be
>> > > > >> > > daunting / intimidating and lower morale. And generally you
>> want
>> > > to
>> > > > >> use
>> > > > >> > > take your legacy code and refactor instead of in someways
>> > starting
>> > > > >> over.
>> > > > >> > >
>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>> > something
>> > > > >> similar
>> > > > >> > > to
>> > > > >> > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>> > > > >> > > where it tracks what needs to get ported / what has been
>> ported.
>> > > > >> > >
>> > > > >> > > What are we going to support in the next version?
>> > > > >> > >
>> > > > >> > > Who is going to work on the next version?
>> > > > >> > >
>> > > > >> > > What would make the most sense and what would invigorate the
>> > > > >> community to
>> > > > >> > > get involved more and lower the barrier to entry?
>> > > > >> > >
>> > > > >> > > I think those are the questions that would make a lot of the
>> > > > decisions
>> > > > >> > for
>> > > > >> > > us so that we can get back to work on lucene.net.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>> > > > marcoslimagon@gmail.com
>> > > > >> > > >wrote:
>> > > > >> > >
>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
>> > > > >> > > >
>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>> > > > repository?
>> > > > >> > > (This
>> > > > >> > > > is new for me, pretty good) Which of them do you recommend
>> > (i'm
>> > > > used
>> > > > >> > with
>> > > > >> > > > SVN and its patterns).
>> > > > >> > > >
>> > > > >> > > > I'm checking the subversion right now.
>> > > > >> > > >
>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
>> > > > branch,
>> > > > >> i`m
>> > > > >> > > not
>> > > > >> > > > sure about its current status.
>> > > > >> > > >
>> > > > >> > > > Will we wipe the current solution from /trunk and start a
>> new
>> > > one?
>> > > > >> > > >
>> > > > >> > > > Thanks,
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>> > > > >> > > >
>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>> > people
>> > > > >> still
>> > > > >> > > want
>> > > > >> > > > to
>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>> RT,
>> > > etc.
>> > > > >> The
>> > > > >> > are
>> > > > >> > > > > many
>> > > > >> > > > > classes that Lucene.net uses from the full framework that
>> > > would
>> > > > >> not
>> > > > >> > be
>> > > > >> > > > > accessible in other versions of the .NET Framework. It
>> also
>> > > > might
>> > > > >> > > > require
>> > > > >> > > > > a design that differs even more from its parent project.
>> > > > >> > > > >
>> > > > >> > > > > It might be wise to poll what users most desire in the
>> next
>> > > > >> version
>> > > > >> > > > through
>> > > > >> > > > > jira or user voice.
>> > > > >> > > > >
>> > > > >> > > > >
>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>> > > > >> > itamar@code972.com
>> > > > >> > > > > >wrote:
>> > > > >> > > > >
>> > > > >> > > > > > inline
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>> > > > >> pirwin@feature23.com>
>> > > > >> > > > wrote:
>> > > > >> > > > > >
>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a
>> TFS
>> > > guy
>> > > > >> for
>> > > > >> > so
>> > > > >> > > > > long
>> > > > >> > > > > > > :-)
>> > > > >> > > > > > >
>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>> patches
>> > or
>> > > > >> > anything
>> > > > >> > > > to
>> > > > >> > > > > > the
>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>> > branch
>> > > > from
>> > > > >> > for
>> > > > >> > > 4x
>> > > > >> > > > > > dev.
>> > > > >> > > > > > > Correct?
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>> anyone
>> > > will
>> > > > >> be
>> > > > >> > > > > > interested in that
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>> with
>> > > the
>> > > > >> > github
>> > > > >> > > > > sync?
>> > > > >> > > > > > > Who could diagnose that?
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
>> > repo
>> > > > for
>> > > > >> now
>> > > > >> > > > while
>> > > > >> > > > > > we get that sorted out.
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
>> > > > >> > > > itamar@code972.com
>> > > > >> > > > > > > >wrote:
>> > > > >> > > > > > >
>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
>> for
>> > > 3.x
>> > > > >> > > > > development.
>> > > > >> > > > > > > WRT
>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
>> > > branch.
>> > > > >> When
>> > > > >> > > you
>> > > > >> > > > > > send
>> > > > >> > > > > > > us
>> > > > >> > > > > > > > PRs we will merge either to master or to a
>> dedicated
>> > > repo.
>> > > > >> For
>> > > > >> > > now
>> > > > >> > > > it
>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it
>> on
>> > the
>> > > > >> apache
>> > > > >> > > > > servers
>> > > > >> > > > > > > > (github sync seems to be off)
>> > > > >> > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>> > > > >> > > pirwin@feature23.com>
>> > > > >> > > > > > > wrote:
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
>> > > version
>> > > > >> of
>> > > > >> > the
>> > > > >> > > > > > > Analysis
>> > > > >> > > > > > > > > namespace.
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Not sure the checkout command is what you
>> intended
>> > --
>> > > > you
>> > > > >> > might
>> > > > >> > > > > have
>> > > > >> > > > > > > > meant
>> > > > >> > > > > > > > > trunk instead of master, and that would create a
>> new
>> > > > "3x"
>> > > > >> > > branch,
>> > > > >> > > > > > when
>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>> > > > >> misnamed...
>> > > > >> > so
>> > > > >> > > > > maybe
>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>> aiming
>> > for
>> > > > >> lucene
>> > > > >> > > > 4.3.x
>> > > > >> > > > > > > > > compatibility?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>> > upstream
>> > > > >> want to
>> > > > >> > > > > create
>> > > > >> > > > > > > the
>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
>> all
>> > > > >> trying to
>> > > > >> > > > > create
>> > > > >> > > > > > > them
>> > > > >> > > > > > > > > and dealing with a merge?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Paul
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>> Syn-Hershko <
>> > > > >> > > > > > itamar@code972.com
>> > > > >> > > > > > > > > >wrote:
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>> use
>> > > > 3.6.2 I
>> > > > >> > > would
>> > > > >> > > > > > highly
>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>> towards v4
>> > > > >> > otherwise
>> > > > >> > > we
>> > > > >> > > > > > will
>> > > > >> > > > > > > > > never
>> > > > >> > > > > > > > > > make it...
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>> (same
>> > > > repo,
>> > > > >> > > > different
>> > > > >> > > > > > > > > remotes)
>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>> should
>> > > work
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>> > > > >> > > > > pirwin@feature23.com>
>> > > > >> > > > > > > > > wrote:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > > Itamar,
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>> way to
>> > > do
>> > > > >> it, I
>> > > > >> > > > just
>> > > > >> > > > > > > > thought
>> > > > >> > > > > > > > > > that
>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>> > > discussion
>> > > > >> > > > previously
>> > > > >> > > > > > for
>> > > > >> > > > > > > > the
>> > > > >> > > > > > > > > > 4.x
>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>> > better.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>> branch on
>> > > my
>> > > > >> fork
>> > > > >> > > and
>> > > > >> > > > > will
>> > > > >> > > > > > > > begin
>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>> up to
>> > > > >> speed to
>> > > > >> > > > > 3.6.2.
>> > > > >> > > > > > If
>> > > > >> > > > > > > > > > anyone
>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
>> > > done,
>> > > > >> have
>> > > > >> > at
>> > > > >> > > > it.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>> branch_3x
>> > > > branch,
>> > > > >> > > please
>> > > > >> > > > > let
>> > > > >> > > > > > > me
>> > > > >> > > > > > > > > know
>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > Paul
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>> > > Syn-Hershko <
>> > > > >> > > > > > > > itamar@code972.com
>> > > > >> > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again
>> :)
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really know
>> > what
>> > > > it
>> > > > >> > would
>> > > > >> > > > > take
>> > > > >> > > > > > > > until
>> > > > >> > > > > > > > > > they
>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>> then
>> > > > >> decisions
>> > > > >> > > > could
>> > > > >> > > > > > and
>> > > > >> > > > > > > > will
>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>> > starting
>> > > > from
>> > > > >> > > > scratch,
>> > > > >> > > > > > > > > although
>> > > > >> > > > > > > > > > I
>> > > > >> > > > > > > > > > > do
>> > > > >> > > > > > > > > > > > think a lot in the current structure should
>> > > > change,
>> > > > >> but
>> > > > >> > > its
>> > > > >> > > > > > going
>> > > > >> > > > > > > > to
>> > > > >> > > > > > > > > be
>> > > > >> > > > > > > > > > > > much easier to change it in place,
>> refactoring
>> > > > where
>> > > > >> > > > needed,
>> > > > >> > > > > > than
>> > > > >> > > > > > > > > > > starting
>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>> > > > personally
>> > > > >> > will
>> > > > >> > > > be
>> > > > >> > > > > > > happy
>> > > > >> > > > > > > > > with
>> > > > >> > > > > > > > > > > you
>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>> porting
>> > > it,
>> > > > >> its
>> > > > >> > > > pretty
>> > > > >> > > > > > > much
>> > > > >> > > > > > > > > self
>> > > > >> > > > > > > > > > > > contained.
>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
>> fork
>> > > and
>> > > > >> send
>> > > > >> > > us
>> > > > >> > > > > PRs,
>> > > > >> > > > > > > its
>> > > > >> > > > > > > > > > much
>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>> fastest
>> > > way
>> > > > >> to do
>> > > > >> > > > this,
>> > > > >> > > > > > we
>> > > > >> > > > > > > > can
>> > > > >> > > > > > > > > > then
>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>> using
>> > > > .NET
>> > > > >> > > > > constructs.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > That said, I think the way to go is create
>> a
>> > > > branch
>> > > > >> out
>> > > > >> > > of
>> > > > >> > > > > the
>> > > > >> > > > > > > > > current
>> > > > >> > > > > > > > > > > git
>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>> > > working
>> > > > on
>> > > > >> > > master
>> > > > >> > > > > > > > towards a
>> > > > >> > > > > > > > > > 4.3
>> > > > >> > > > > > > > > > > > compatible version. The actual port should
>> be
>> > > > using
>> > > > >> a
>> > > > >> > > > process
>> > > > >> > > > > > > that
>> > > > >> > > > > > > > > > > ensures
>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>> tests,
>> > > and
>> > > > >> that
>> > > > >> > > > those
>> > > > >> > > > > > > tests
>> > > > >> > > > > > > > > > pass -
>> > > > >> > > > > > > > > > > > but I'm against committing any Java code to
>> > our
>> > > > >> > > > repositories.
>> > > > >> > > > > > The
>> > > > >> > > > > > > > > > process
>> > > > >> > > > > > > > > > > > should probably be working on classes in
>> some
>> > > > order
>> > > > >> > > > > > > > (alphabetically,
>> > > > >> > > > > > > > > or
>> > > > >> > > > > > > > > > > > core classes first) and getting each class
>> to
>> > > > >> compile
>> > > > >> > > > before
>> > > > >> > > > > > > moving
>> > > > >> > > > > > > > > > > > forward. I don't mind about the project not
>> > > being
>> > > > >> > > > compilable
>> > > > >> > > > > > for
>> > > > >> > > > > > > a
>> > > > >> > > > > > > > > > month
>> > > > >> > > > > > > > > > > or
>> > > > >> > > > > > > > > > > > two.
>> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
>> and
>> > > > >> proofing
>> > > > >> > > the
>> > > > >> > > > > code
>> > > > >> > > > > > > can
>> > > > >> > > > > > > > > be
>> > > > >> > > > > > > > > > > > started, at which point we will already
>> have a
>> > > > >> working
>> > > > >> > v4
>> > > > >> > > > > > version
>> > > > >> > > > > > > > so
>> > > > >> > > > > > > > > it
>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>> > project.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
>> > > suite
>> > > > so
>> > > > >> > > tests
>> > > > >> > > > > > could
>> > > > >> > > > > > > > more
>> > > > >> > > > > > > > > > or
>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>> implementing
>> > > > >> Java-like
>> > > > >> > > > > > > assertEquals
>> > > > >> > > > > > > > > > > methods
>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
>> > with
>> > > > >> than
>> > > > >> > > > > NUnit). I
>> > > > >> > > > > > > > > already
>> > > > >> > > > > > > > > > > did
>> > > > >> > > > > > > > > > > > some work there but there's still a lot to
>> do.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself
>> at
>> > > this
>> > > > >> > point,
>> > > > >> > > > > but I
>> > > > >> > > > > > > > > should
>> > > > >> > > > > > > > > > be
>> > > > >> > > > > > > > > > > > back in business in August, at which point
>> I
>> > can
>> > > > >> > dedicate
>> > > > >> > > > > > several
>> > > > >> > > > > > > > > > hours a
>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>> > closely
>> > > > and
>> > > > >> > even
>> > > > >> > > > > > > coordinate
>> > > > >> > > > > > > > > the
>> > > > >> > > > > > > > > > > > work to some extent.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>> Lima <
>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>> > > > >> > > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>> kick
>> > > > start
>> > > > >> > =). I
>> > > > >> > > > > > haven't
>> > > > >> > > > > > > > > > > > contributed
>> > > > >> > > > > > > > > > > > > anything
>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all to
>> get
>> > > > this
>> > > > >> job
>> > > > >> > > > done.
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>> Prescott.
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>> for
>> > > keep
>> > > > >> the
>> > > > >> > > > > > > > > > retrocompatibility
>> > > > >> > > > > > > > > > > on
>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>> > changes
>> > > > >> every
>> > > > >> > > > > release?
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>> > version
>> > > > >> from a
>> > > > >> > > > > Lucene
>> > > > >> > > > > > > > > version,
>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
>> > > changes
>> > > > >> > every
>> > > > >> > > > > stable
>> > > > >> > > > > > > > > release
>> > > > >> > > > > > > > > > > (or
>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>> > > compare
>> > > > >> the
>> > > > >> > > > > versions,
>> > > > >> > > > > > > > check
>> > > > >> > > > > > > > > > the
>> > > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
>> > > > Again, I
>> > > > >> > > > haven't
>> > > > >> > > > > > > > > > contributed
>> > > > >> > > > > > > > > > > > with
>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>> > idea).
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > What's your approach for implement simple
>> > > > >> performance
>> > > > >> > > > > > > > improvements
>> > > > >> > > > > > > > > > > > (without
>> > > > >> > > > > > > > > > > > > adding references or changing methods
>> > > > signatures)?
>> > > > >> > Does
>> > > > >> > > > it
>> > > > >> > > > > > > could
>> > > > >> > > > > > > > be
>> > > > >> > > > > > > > > > > done,
>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>> pirwin@feature23.com>
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
>> as I
>> > > > >> haven't
>> > > > >> > > > > > > contributed
>> > > > >> > > > > > > > > > > anything
>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>> with
>> > > the
>> > > > >> 4.x
>> > > > >> > > work
>> > > > >> > > > > as I
>> > > > >> > > > > > > > have
>> > > > >> > > > > > > > > a
>> > > > >> > > > > > > > > > > > vested
>> > > > >> > > > > > > > > > > > > > interest in seeing that get completed.
>> I
>> > > think
>> > > > >> > there
>> > > > >> > > > > should
>> > > > >> > > > > > > be
>> > > > >> > > > > > > > > one
>> > > > >> > > > > > > > > > > > person
>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>> > structure
>> > > > and
>> > > > >> > > > workflow
>> > > > >> > > > > > will
>> > > > >> > > > > > > > > look
>> > > > >> > > > > > > > > > > like
>> > > > >> > > > > > > > > > > > > to
>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going
>> to
>> > be
>> > > > >> > starting
>> > > > >> > > > from
>> > > > >> > > > > > > > scratch
>> > > > >> > > > > > > > > > as
>> > > > >> > > > > > > > > > > a
>> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
>> the
>> > > > >> project,
>> > > > >> > > get
>> > > > >> > > > > > > > everything
>> > > > >> > > > > > > > > > > going
>> > > > >> > > > > > > > > > > > > in
>> > > > >> > > > > > > > > > > > > > source control, create the folder
>> > structure,
>> > > > >> maybe
>> > > > >> > > stub
>> > > > >> > > > > out
>> > > > >> > > > > > > > some
>> > > > >> > > > > > > > > > > > classes,
>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>> anyone
>> > > > >> interested
>> > > > >> > > in
>> > > > >> > > > > > > > > > contributing,
>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>> code
>> > in
>> > > > >> there
>> > > > >> > so
>> > > > >> > > > > it's
>> > > > >> > > > > > > easy
>> > > > >> > > > > > > > > to
>> > > > >> > > > > > > > > > > > > > reference.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > Again, I can work on
>> Lucene.Net.Documents,
>> > > > >> > > > > > > Lucene.Net.Analysis,
>> > > > >> > > > > > > > > or
>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>> those
>> > are
>> > > > >> just
>> > > > >> > the
>> > > > >> > > > > ones
>> > > > >> > > > > > > I'm
>> > > > >> > > > > > > > > most
>> > > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell
>> me
>> > > what
>> > > > >> to
>> > > > >> > do
>> > > > >> > > > and
>> > > > >> > > > > > I'll
>> > > > >> > > > > > > > get
>> > > > >> > > > > > > > > > > > started
>> > > > >> > > > > > > > > > > > > > on my fork.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > Paul Irwin
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>> Prescott
>> > > > Nasser
>> > > > >> <
>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>> > > > >> > > > > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > > Hey guys -
>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little while.
>> We
>> > > > have a
>> > > > >> > > board
>> > > > >> > > > > > report
>> > > > >> > > > > > > > due
>> > > > >> > > > > > > > > > > soon
>> > > > >> > > > > > > > > > > > -
>> > > > >> > > > > > > > > > > > > I
>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
>> > that
>> > > we
>> > > > >> seem
>> > > > >> > > to
>> > > > >> > > > > have
>> > > > >> > > > > > > > > stalled
>> > > > >> > > > > > > > > > > > > > somewhat.
>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>> out of
>> > > of
>> > > > >> jira
>> > > > >> > > and
>> > > > >> > > > > have
>> > > > >> > > > > > > > been
>> > > > >> > > > > > > > > > > > > responsive
>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>> > > questions,
>> > > > >> but I
>> > > > >> > > > don't
>> > > > >> > > > > > > think
>> > > > >> > > > > > > > > > we've
>> > > > >> > > > > > > > > > > > > done
>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>> > start
>> > > us
>> > > > >> back
>> > > > >> > > up
>> > > > >> > > > > > moving
>> > > > >> > > > > > > > > > > forward.
>> > > > >> > > > > > > > > > > > > What
>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this?
>> If
>> > we
>> > > > took
>> > > > >> > the
>> > > > >> > > > java
>> > > > >> > > > > > > > lucene
>> > > > >> > > > > > > > > > 4.0
>> > > > >> > > > > > > > > > > > code
>> > > > >> > > > > > > > > > > > > > and
>> > > > >> > > > > > > > > > > > > > > committed that java to our branch and
>> > then
>> > > > >> just
>> > > > >> > let
>> > > > >> > > > > > people
>> > > > >> > > > > > > > pull
>> > > > >> > > > > > > > > > > that
>> > > > >> > > > > > > > > > > > > down
>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>> that
>> > one
>> > > > >> way to
>> > > > >> > > > maybe
>> > > > >> > > > > > > make
>> > > > >> > > > > > > > > some
>> > > > >> > > > > > > > > > > > > forward
>> > > > >> > > > > > > > > > > > > > > progress?
>> > > > >> > > > > > > > > > > > > > > ~P
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > --
>> > > > >> > > > > > > > > > > > > --
>> > > > >> > > > > > > > > > > > > Marcos Lima
>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > --
>> > > > >> > > > --
>> > > > >> > > > Marcos Lima
>> > > > >> > > > Software Developer/Tech Lead
>> > > > >> > > > marcoslimagon@gmail.com
>> > > > >> > > > tel: +55 (19) 9798-9335
>> > > > >> > > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> --
>> > > > >> Marcos Lima
>> > > > >> Software Developer/Tech Lead
>> > > > >> marcoslimagon@gmail.com
>> > > > >> tel: +55 (19) 9798-9335
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I realized after I sent that email last night that I could do as you
described. When you've been debugging through CorruptedIndexExceptions, you
get a little bit of tunnel vision... haha
I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
the matching documents prints the fields to the console, so it's loading in
the stored fields data correctly.
I tried doing a TermQuery and now I get a "read past EOF" exception that I
can't figure out. There's a whole bunch of buffered byte array operations
going on and I can't determine where the issue came from. I'll keep
looking, but if someone could grab my fork/branch and help me look that
would be great. Here's example index writing and then reading code (also
included is a quick port of KeywordAnalyzer):
https://gist.github.com/anonymous/6174164
Thanks!
On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Great
>
> You can build you Query objects on your own to execute a search, you don't
> actually have to use QueryParser for that
>
>
> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Hey all, sorry it's been a little while, but I wanted to let you know
> that
> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
> > Lucene.net core building and able to write a simple index in Lucene 4.2
> > codec and read in things like the number of documents and whatnot. Since
> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
> > haven't ported that yet so I haven't done a real search, and I only built
> > the index using a quick port of KeywordAnalyzer which all those analyzers
> > have also moved to another module. But this is definitely good progress
> and
> > should be a launch point for finishing a 4.3/4.4 port.
> >
> > You can see my fork/branch here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
> > said, only core builds now, no modules/tests build, so only open the
> > Lucene.Net.Core.sln)
> >
> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
> > community into finishing the 4.3/4.4 port. Let me know if you have any
> > questions, thanks!
> >
> >
> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Paul, that's awesome. I will need some more time to go over this thread
> > and
> > > your work to give actual feedback, SUPER busy at the moment
> > >
> > >
> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > All,
> > > >
> > > > My colleagues and I have made good progress on porting Lucene 4.3's
> > core
> > > > library before, during, and after the hackathon last week. We now
> only
> > > have
> > > > some remaining items in Search, Index, and Codecs namespaces (plus a
> > few
> > > > other minor ones here and there). I expect to be done by the end of
> the
> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> Packed),
> > > and
> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
> > > >
> > > > Again, my goal is to only get a buildable, experimental build of
> > > Lucene.net
> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> porting
> > > new
> > > > javadoc comments or unit tests right now, due to the vast amount of
> > code
> > > > that needs to be written just to get it to compile. If this work ends
> > up
> > > > becoming a pull request, great, otherwise it should help accelerate a
> > > port
> > > > of 4.3.x since the bulk of the work on core will already be done and
> > > > contributors can use it as a reference. And again, we're taking the
> > > > pragmatic approach of porting class-by-class, namespace-by-namespace,
> > > with
> > > > the understanding that until we're done the project won't build.
> > > >
> > > > Once complete, I also will work on updating the Analyzers contrib
> > module
> > > > and porting the QueryParsers contrib module, which I feel should be
> > > > included in the core NuGet package for Lucene.net as the core library
> > is
> > > > now (post-4.0) practically useless (or atleast not turn-key) without
> > > them.
> > > > You can check out the code on my fork/branch here:
> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > >
> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
> the
> > > MMap
> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> > > > MemoryMappedFile support which should emulate the Java nio stuff
> pretty
> > > > well, but required some creative shuffling of the code to make it
> work
> > > due
> > > > to lifecycle management.
> > > >
> > > > I'll update again this weekend or next week, when we should have
> > wrapped
> > > up
> > > > most of the main hacking on porting the core code.
> > > >
> > > > Paul
> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> > > wrote:
> > > >
> > > > > Marcos,
> > > > >
> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
> > only
> > > on
> > > > > SVN here, before the lucene and solr projects were bundled
> together:
> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > > > >
> > > > > The SVN for 4.3 java is here:
> > > > >
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > > > And the GitHub for 4.3 java is here:
> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > > > >
> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > > > >
> > > > > My fork is the "upstream" fork for my team members, and i'm remote
> > > > merging
> > > > > their changes in from their forks while they fetch/merge from mine
> to
> > > get
> > > > > everyone else's changes, rather than using pull requests. James
> and I
> > > > have
> > > > > been working the past few days on the Util namespace ahead of
> > tonight's
> > > > > hackathon since that namespace is in common with the rest of the
> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> > hacking
> > > on
> > > > > porting 4.3, each with a different namespace or part of a
> namespace.
> > > > Since
> > > > > we're going class-by-class, namespace-by-namespace, the project
> does
> > > not
> > > > > build as it is. Once we finish doing a translation of each file,
> then
> > > > we'll
> > > > > hammer out any remaining issues and get it to build again. I'm
> hoping
> > > > that
> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> > > > >
> > > > > But one thing to keep in mind is it looks like much functionality
> has
> > > > been
> > > > > moved out of core into the contrib modules, especially around
> > analysis,
> > > > for
> > > > > 4.0+. For example, there are no built-in analyzers in core anymore.
> > So
> > > > when
> > > > > this is all done, we may want to include at least the analysis
> > contrib
> > > > > module in with the standard core NuGet package, because otherwise
> > it's
> > > > > practically useless unless you roll your own analyzer.
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> > marcoslimagon@gmail.com
> > > > >wrote:
> > > > >
> > > > >> Hi everyone!
> > > > >>
> > > > >> Does someone know where can I find the 3.0.3 release from
> > > Lucene(java)?
> > > > >>
> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0
> and
> > > > make
> > > > >> the diff between then and get all changes between releases... I
> > gonna
> > > > >> publish it here soon. (If you think there is another important
> > > release,
> > > > >> let
> > > > >> me know)
> > > > >>
> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
> > 4.3.0
> > > > >> port
> > > > >> for .Net on github (last email)?
> > > > >>
> > > > >> See you,
> > > > >>
> > > > >>
> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > > > >>
> > > > >> > Thanks for the discussion points, Michael.
> > > > >> >
> > > > >> > I would vote for not worrying about trying to achieve portable
> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > > > >> completed.
> > > > >> > Otherwise it may delay the project and stall it further. That's
> > just
> > > > my
> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > > > >> >
> > > > >> > I have started porting the changes from the core library (from
> the
> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > > > branch.
> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> > > until
> > > > >> > there's changes to pull from upstream to work from. Also due to
> my
> > > > time
> > > > >> > constraints, I am not fully documenting new methods that I'm
> > adding.
> > > > >> But if
> > > > >> > anyone wants to pull/copy/reference my changes while porting,
> > that's
> > > > >> > awesome. My branch currently does not build as I'm primarily
> going
> > > > >> > class-by-class, starting with the util namespace. Once we get
> the
> > > ball
> > > > >> > rolling on a community effort, I'll stop my rogue work and join
> > in.
> > > > But
> > > > >> > hopefully my work will be useful to someone, if not as a pull
> > > request
> > > > >> then
> > > > >> > as a reference. I'm also going to be holding a hackathon this
> week
> > > > with
> > > > >> my
> > > > >> > colleagues where we're all going to work on the port. I'm
> > comparing
> > > > >> files
> > > > >> > and making changes as necessary, rather than starting from
> > scratch.
> > > My
> > > > >> > repo/branch is here:
> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > > >> >
> > > > >> > Paul
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > > > >> > mherndon@michaelherndon.com> wrote:
> > > > >> >
> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> apache
> > > > >> > maintains.
> > > > >> > >
> > > > >> > > The was some work at one time to move the official svn
> > repository
> > > to
> > > > >> > start
> > > > >> > > using git one instead. Was that actually finalized or not?
> > > > >> > >
> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> > > what
> > > > >> kind
> > > > >> > of
> > > > >> > > work was involved using a portable libraries project. Some of
> it
> > > can
> > > > >> > still
> > > > >> > > be used but will need to be validated against the current
> > version
> > > of
> > > > >> > Java's
> > > > >> > > Lucene. It was also using .net 4.
> > > > >> > >
> > > > >> > > clean branch vs current. Its going to depend on what we
> > > support.
> > > > >> If
> > > > >> > you
> > > > >> > > support windows mobile 8, win RT, then the current code in
> trunk
> > > > will
> > > > >> not
> > > > >> > > compile against those versions of the framework which would a
> > > > >> frustrating
> > > > >> > > starting point, then you couldn't even run tests, which would
> > make
> > > > >> taking
> > > > >> > > patches very difficult. Supporting those can almost mean
> larger
> > > > gaps
> > > > >> in
> > > > >> > > design between Lucene.Net and its parent project.
> > > > >> > >
> > > > >> > > Also the structure has changed significantly between the
> > branches
> > > > and
> > > > >> > the
> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> > > seems
> > > > >> > > significantly different. That doesn't mean you can't cherry
> > pick
> > > > >> stuff
> > > > >> > > from the other tags/branches that would still work as is. A
> > clean
> > > > >> branch
> > > > >> > > would also make it easier to get our build / tool chain in
> order
> > > as
> > > > >> you
> > > > >> > can
> > > > >> > > then do them incrementally versus having to do all the stuff
> > that
> > > I
> > > > >> did
> > > > >> > for
> > > > >> > > the 3x branch which saps energy and desire to code. It could
> > > also
> > > > >> make
> > > > >> > it
> > > > >> > > easier to see which classes have been ported or not.
> > > > >> > >
> > > > >> > > The major downside to a clean branch is extra work it requires
> > and
> > > > the
> > > > >> > > start up cost in time and energy of getting it in order, which
> > can
> > > > be
> > > > >> > > daunting / intimidating and lower morale. And generally you
> want
> > > to
> > > > >> use
> > > > >> > > take your legacy code and refactor instead of in someways
> > starting
> > > > >> over.
> > > > >> > >
> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> > something
> > > > >> similar
> > > > >> > > to
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > > >> > > where it tracks what needs to get ported / what has been
> ported.
> > > > >> > >
> > > > >> > > What are we going to support in the next version?
> > > > >> > >
> > > > >> > > Who is going to work on the next version?
> > > > >> > >
> > > > >> > > What would make the most sense and what would invigorate the
> > > > >> community to
> > > > >> > > get involved more and lower the barrier to entry?
> > > > >> > >
> > > > >> > > I think those are the questions that would make a lot of the
> > > > decisions
> > > > >> > for
> > > > >> > > us so that we can get back to work on lucene.net.
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > > > marcoslimagon@gmail.com
> > > > >> > > >wrote:
> > > > >> > >
> > > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > > >> > > >
> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > > >> > > > https://github.com/apache/lucene.net points to the same
> > > > repository?
> > > > >> > > (This
> > > > >> > > > is new for me, pretty good) Which of them do you recommend
> > (i'm
> > > > used
> > > > >> > with
> > > > >> > > > SVN and its patterns).
> > > > >> > > >
> > > > >> > > > I'm checking the subversion right now.
> > > > >> > > >
> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > > > branch,
> > > > >> i`m
> > > > >> > > not
> > > > >> > > > sure about its current status.
> > > > >> > > >
> > > > >> > > > Will we wipe the current solution from /trunk and start a
> new
> > > one?
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > > > >> > > >
> > > > >> > > > > We may be forced to start with a clean/empty branch if
> > people
> > > > >> still
> > > > >> > > want
> > > > >> > > > to
> > > > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> > > etc.
> > > > >> The
> > > > >> > are
> > > > >> > > > > many
> > > > >> > > > > classes that Lucene.net uses from the full framework that
> > > would
> > > > >> not
> > > > >> > be
> > > > >> > > > > accessible in other versions of the .NET Framework. It
> also
> > > > might
> > > > >> > > > require
> > > > >> > > > > a design that differs even more from its parent project.
> > > > >> > > > >
> > > > >> > > > > It might be wise to poll what users most desire in the
> next
> > > > >> version
> > > > >> > > > through
> > > > >> > > > > jira or user voice.
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > > > >> > itamar@code972.com
> > > > >> > > > > >wrote:
> > > > >> > > > >
> > > > >> > > > > > inline
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > > > >> pirwin@feature23.com>
> > > > >> > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a
> TFS
> > > guy
> > > > >> for
> > > > >> > so
> > > > >> > > > > long
> > > > >> > > > > > > :-)
> > > > >> > > > > > >
> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> patches
> > or
> > > > >> > anything
> > > > >> > > > to
> > > > >> > > > > > the
> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
> > branch
> > > > from
> > > > >> > for
> > > > >> > > 4x
> > > > >> > > > > > dev.
> > > > >> > > > > > > Correct?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> anyone
> > > will
> > > > >> be
> > > > >> > > > > > interested in that
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
> with
> > > the
> > > > >> > github
> > > > >> > > > > sync?
> > > > >> > > > > > > Who could diagnose that?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
> > repo
> > > > for
> > > > >> now
> > > > >> > > > while
> > > > >> > > > > > we get that sorted out.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > > >> > > > itamar@code972.com
> > > > >> > > > > > > >wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
> for
> > > 3.x
> > > > >> > > > > development.
> > > > >> > > > > > > WRT
> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> > > branch.
> > > > >> When
> > > > >> > > you
> > > > >> > > > > > send
> > > > >> > > > > > > us
> > > > >> > > > > > > > PRs we will merge either to master or to a dedicated
> > > repo.
> > > > >> For
> > > > >> > > now
> > > > >> > > > it
> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it on
> > the
> > > > >> apache
> > > > >> > > > > servers
> > > > >> > > > > > > > (github sync seems to be off)
> > > > >> > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > > >> > > pirwin@feature23.com>
> > > > >> > > > > > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> > > version
> > > > >> of
> > > > >> > the
> > > > >> > > > > > > Analysis
> > > > >> > > > > > > > > namespace.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Not sure the checkout command is what you intended
> > --
> > > > you
> > > > >> > might
> > > > >> > > > > have
> > > > >> > > > > > > > meant
> > > > >> > > > > > > > > trunk instead of master, and that would create a
> new
> > > > "3x"
> > > > >> > > branch,
> > > > >> > > > > > when
> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
> > > > >> misnamed...
> > > > >> > so
> > > > >> > > > > maybe
> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming
> > for
> > > > >> lucene
> > > > >> > > > 4.3.x
> > > > >> > > > > > > > > compatibility?
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Also, does someone with commit rights to the
> > upstream
> > > > >> want to
> > > > >> > > > > create
> > > > >> > > > > > > the
> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
> all
> > > > >> trying to
> > > > >> > > > > create
> > > > >> > > > > > > them
> > > > >> > > > > > > > > and dealing with a merge?
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Paul
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> Syn-Hershko <
> > > > >> > > > > > itamar@code972.com
> > > > >> > > > > > > > > >wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > > Unless people here have a specific reason to use
> > > > 3.6.2 I
> > > > >> > > would
> > > > >> > > > > > highly
> > > > >> > > > > > > > > > recommed putting all the efforts we can towards
> v4
> > > > >> > otherwise
> > > > >> > > we
> > > > >> > > > > > will
> > > > >> > > > > > > > > never
> > > > >> > > > > > > > > > make it...
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Fork the repo from apache servers or github
> (same
> > > > repo,
> > > > >> > > > different
> > > > >> > > > > > > > > remotes)
> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> should
> > > work
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > > >> > > > > pirwin@feature23.com>
> > > > >> > > > > > > > > wrote:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > Itamar,
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > I agree that from scratch is not the best way
> to
> > > do
> > > > >> it, I
> > > > >> > > > just
> > > > >> > > > > > > > thought
> > > > >> > > > > > > > > > that
> > > > >> > > > > > > > > > > was the "decision" that was made from the
> > > discussion
> > > > >> > > > previously
> > > > >> > > > > > for
> > > > >> > > > > > > > the
> > > > >> > > > > > > > > > 4.x
> > > > >> > > > > > > > > > > work. An incremental approach will be much
> > better.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > I've created a branch of the branch_3x branch
> on
> > > my
> > > > >> fork
> > > > >> > > and
> > > > >> > > > > will
> > > > >> > > > > > > > begin
> > > > >> > > > > > > > > > > working on bringing the Analysis namespace up
> to
> > > > >> speed to
> > > > >> > > > > 3.6.2.
> > > > >> > > > > > If
> > > > >> > > > > > > > > > anyone
> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> > > done,
> > > > >> have
> > > > >> > at
> > > > >> > > > it.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > > > branch,
> > > > >> > > please
> > > > >> > > > > let
> > > > >> > > > > > > me
> > > > >> > > > > > > > > know
> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > Paul
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> > > Syn-Hershko <
> > > > >> > > > > > > > itamar@code972.com
> > > > >> > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again
> :)
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Paul, the problem is no one can really know
> > what
> > > > it
> > > > >> > would
> > > > >> > > > > take
> > > > >> > > > > > > > until
> > > > >> > > > > > > > > > they
> > > > >> > > > > > > > > > > > have deep dived into the work, and even then
> > > > >> decisions
> > > > >> > > > could
> > > > >> > > > > > and
> > > > >> > > > > > > > will
> > > > >> > > > > > > > > > > > change. I will strongly advise against
> > starting
> > > > from
> > > > >> > > > scratch,
> > > > >> > > > > > > > > although
> > > > >> > > > > > > > > > I
> > > > >> > > > > > > > > > > do
> > > > >> > > > > > > > > > > > think a lot in the current structure should
> > > > change,
> > > > >> but
> > > > >> > > its
> > > > >> > > > > > going
> > > > >> > > > > > > > to
> > > > >> > > > > > > > > be
> > > > >> > > > > > > > > > > > much easier to change it in place,
> refactoring
> > > > where
> > > > >> > > > needed,
> > > > >> > > > > > than
> > > > >> > > > > > > > > > > starting
> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > > > personally
> > > > >> > will
> > > > >> > > > be
> > > > >> > > > > > > happy
> > > > >> > > > > > > > > with
> > > > >> > > > > > > > > > > you
> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> porting
> > > it,
> > > > >> its
> > > > >> > > > pretty
> > > > >> > > > > > > much
> > > > >> > > > > > > > > self
> > > > >> > > > > > > > > > > > contained.
> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
> fork
> > > and
> > > > >> send
> > > > >> > > us
> > > > >> > > > > PRs,
> > > > >> > > > > > > its
> > > > >> > > > > > > > > > much
> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> fastest
> > > way
> > > > >> to do
> > > > >> > > > this,
> > > > >> > > > > > we
> > > > >> > > > > > > > can
> > > > >> > > > > > > > > > then
> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
> using
> > > > .NET
> > > > >> > > > > constructs.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > That said, I think the way to go is create a
> > > > branch
> > > > >> out
> > > > >> > > of
> > > > >> > > > > the
> > > > >> > > > > > > > > current
> > > > >> > > > > > > > > > > git
> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> > > working
> > > > on
> > > > >> > > master
> > > > >> > > > > > > > towards a
> > > > >> > > > > > > > > > 4.3
> > > > >> > > > > > > > > > > > compatible version. The actual port should
> be
> > > > using
> > > > >> a
> > > > >> > > > process
> > > > >> > > > > > > that
> > > > >> > > > > > > > > > > ensures
> > > > >> > > > > > > > > > > > all Java classes are ported with their
> tests,
> > > and
> > > > >> that
> > > > >> > > > those
> > > > >> > > > > > > tests
> > > > >> > > > > > > > > > pass -
> > > > >> > > > > > > > > > > > but I'm against committing any Java code to
> > our
> > > > >> > > > repositories.
> > > > >> > > > > > The
> > > > >> > > > > > > > > > process
> > > > >> > > > > > > > > > > > should probably be working on classes in
> some
> > > > order
> > > > >> > > > > > > > (alphabetically,
> > > > >> > > > > > > > > or
> > > > >> > > > > > > > > > > > core classes first) and getting each class
> to
> > > > >> compile
> > > > >> > > > before
> > > > >> > > > > > > moving
> > > > >> > > > > > > > > > > > forward. I don't mind about the project not
> > > being
> > > > >> > > > compilable
> > > > >> > > > > > for
> > > > >> > > > > > > a
> > > > >> > > > > > > > > > month
> > > > >> > > > > > > > > > > or
> > > > >> > > > > > > > > > > > two.
> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
> and
> > > > >> proofing
> > > > >> > > the
> > > > >> > > > > code
> > > > >> > > > > > > can
> > > > >> > > > > > > > > be
> > > > >> > > > > > > > > > > > started, at which point we will already
> have a
> > > > >> working
> > > > >> > v4
> > > > >> > > > > > version
> > > > >> > > > > > > > so
> > > > >> > > > > > > > > it
> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
> > project.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> > > suite
> > > > so
> > > > >> > > tests
> > > > >> > > > > > could
> > > > >> > > > > > > > more
> > > > >> > > > > > > > > > or
> > > > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > > > >> Java-like
> > > > >> > > > > > > assertEquals
> > > > >> > > > > > > > > > > methods
> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
> > with
> > > > >> than
> > > > >> > > > > NUnit). I
> > > > >> > > > > > > > > already
> > > > >> > > > > > > > > > > did
> > > > >> > > > > > > > > > > > some work there but there's still a lot to
> do.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself
> at
> > > this
> > > > >> > point,
> > > > >> > > > > but I
> > > > >> > > > > > > > > should
> > > > >> > > > > > > > > > be
> > > > >> > > > > > > > > > > > back in business in August, at which point I
> > can
> > > > >> > dedicate
> > > > >> > > > > > several
> > > > >> > > > > > > > > > hours a
> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> > closely
> > > > and
> > > > >> > even
> > > > >> > > > > > > coordinate
> > > > >> > > > > > > > > the
> > > > >> > > > > > > > > > > > work to some extent.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
> Lima <
> > > > >> > > > > > > > > marcoslimagon@gmail.com
> > > > >> > > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
> kick
> > > > start
> > > > >> > =). I
> > > > >> > > > > > haven't
> > > > >> > > > > > > > > > > > contributed
> > > > >> > > > > > > > > > > > > anything
> > > > >> > > > > > > > > > > > > yet, but I would like to help you all to
> get
> > > > this
> > > > >> job
> > > > >> > > > done.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> Prescott.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > I know that there is a high commitment for
> > > keep
> > > > >> the
> > > > >> > > > > > > > > > retrocompatibility
> > > > >> > > > > > > > > > > on
> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> > changes
> > > > >> every
> > > > >> > > > > release?
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
> > version
> > > > >> from a
> > > > >> > > > > Lucene
> > > > >> > > > > > > > > version,
> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> > > changes
> > > > >> > every
> > > > >> > > > > stable
> > > > >> > > > > > > > > release
> > > > >> > > > > > > > > > > (or
> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
> > > compare
> > > > >> the
> > > > >> > > > > versions,
> > > > >> > > > > > > > check
> > > > >> > > > > > > > > > the
> > > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > > > Again, I
> > > > >> > > > haven't
> > > > >> > > > > > > > > > contributed
> > > > >> > > > > > > > > > > > with
> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
> > idea).
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > What's your approach for implement simple
> > > > >> performance
> > > > >> > > > > > > > improvements
> > > > >> > > > > > > > > > > > (without
> > > > >> > > > > > > > > > > > > adding references or changing methods
> > > > signatures)?
> > > > >> > Does
> > > > >> > > > it
> > > > >> > > > > > > could
> > > > >> > > > > > > > be
> > > > >> > > > > > > > > > > done,
> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pirwin@feature23.com
> >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
> as I
> > > > >> haven't
> > > > >> > > > > > > contributed
> > > > >> > > > > > > > > > > anything
> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
> with
> > > the
> > > > >> 4.x
> > > > >> > > work
> > > > >> > > > > as I
> > > > >> > > > > > > > have
> > > > >> > > > > > > > > a
> > > > >> > > > > > > > > > > > vested
> > > > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> > > think
> > > > >> > there
> > > > >> > > > > should
> > > > >> > > > > > > be
> > > > >> > > > > > > > > one
> > > > >> > > > > > > > > > > > person
> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> > structure
> > > > and
> > > > >> > > > workflow
> > > > >> > > > > > will
> > > > >> > > > > > > > > look
> > > > >> > > > > > > > > > > like
> > > > >> > > > > > > > > > > > > to
> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to
> > be
> > > > >> > starting
> > > > >> > > > from
> > > > >> > > > > > > > scratch
> > > > >> > > > > > > > > > as
> > > > >> > > > > > > > > > > a
> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
> the
> > > > >> project,
> > > > >> > > get
> > > > >> > > > > > > > everything
> > > > >> > > > > > > > > > > going
> > > > >> > > > > > > > > > > > > in
> > > > >> > > > > > > > > > > > > > source control, create the folder
> > structure,
> > > > >> maybe
> > > > >> > > stub
> > > > >> > > > > out
> > > > >> > > > > > > > some
> > > > >> > > > > > > > > > > > classes,
> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > > > >> interested
> > > > >> > > in
> > > > >> > > > > > > > > > contributing,
> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
> code
> > in
> > > > >> there
> > > > >> > so
> > > > >> > > > > it's
> > > > >> > > > > > > easy
> > > > >> > > > > > > > > to
> > > > >> > > > > > > > > > > > > > reference.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > Again, I can work on
> Lucene.Net.Documents,
> > > > >> > > > > > > Lucene.Net.Analysis,
> > > > >> > > > > > > > > or
> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those
> > are
> > > > >> just
> > > > >> > the
> > > > >> > > > > ones
> > > > >> > > > > > > I'm
> > > > >> > > > > > > > > most
> > > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell
> me
> > > what
> > > > >> to
> > > > >> > do
> > > > >> > > > and
> > > > >> > > > > > I'll
> > > > >> > > > > > > > get
> > > > >> > > > > > > > > > > > started
> > > > >> > > > > > > > > > > > > > on my fork.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > Paul Irwin
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > > > Nasser
> > > > >> <
> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> > > > >> > > > > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > > Hey guys -
> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little while.
> We
> > > > have a
> > > > >> > > board
> > > > >> > > > > > report
> > > > >> > > > > > > > due
> > > > >> > > > > > > > > > > soon
> > > > >> > > > > > > > > > > > -
> > > > >> > > > > > > > > > > > > I
> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
> > that
> > > we
> > > > >> seem
> > > > >> > > to
> > > > >> > > > > have
> > > > >> > > > > > > > > stalled
> > > > >> > > > > > > > > > > > > > somewhat.
> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items out
> of
> > > of
> > > > >> jira
> > > > >> > > and
> > > > >> > > > > have
> > > > >> > > > > > > > been
> > > > >> > > > > > > > > > > > > responsive
> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> > > questions,
> > > > >> but I
> > > > >> > > > don't
> > > > >> > > > > > > think
> > > > >> > > > > > > > > > we've
> > > > >> > > > > > > > > > > > > done
> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
> > start
> > > us
> > > > >> back
> > > > >> > > up
> > > > >> > > > > > moving
> > > > >> > > > > > > > > > > forward.
> > > > >> > > > > > > > > > > > > What
> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this? If
> > we
> > > > took
> > > > >> > the
> > > > >> > > > java
> > > > >> > > > > > > > lucene
> > > > >> > > > > > > > > > 4.0
> > > > >> > > > > > > > > > > > code
> > > > >> > > > > > > > > > > > > > and
> > > > >> > > > > > > > > > > > > > > committed that java to our branch and
> > then
> > > > >> just
> > > > >> > let
> > > > >> > > > > > people
> > > > >> > > > > > > > pull
> > > > >> > > > > > > > > > > that
> > > > >> > > > > > > > > > > > > down
> > > > >> > > > > > > > > > > > > > > and being changing / modifying is that
> > one
> > > > >> way to
> > > > >> > > > maybe
> > > > >> > > > > > > make
> > > > >> > > > > > > > > some
> > > > >> > > > > > > > > > > > > forward
> > > > >> > > > > > > > > > > > > > > progress?
> > > > >> > > > > > > > > > > > > > > ~P
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > --
> > > > >> > > > > > > > > > > > > --
> > > > >> > > > > > > > > > > > > Marcos Lima
> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > --
> > > > >> > > > Marcos Lima
> > > > >> > > > Software Developer/Tech Lead
> > > > >> > > > marcoslimagon@gmail.com
> > > > >> > > > tel: +55 (19) 9798-9335
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> --
> > > > >> Marcos Lima
> > > > >> Software Developer/Tech Lead
> > > > >> marcoslimagon@gmail.com
> > > > >> tel: +55 (19) 9798-9335
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Great
You can build you Query objects on your own to execute a search, you don't
actually have to use QueryParser for that
On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
> Hey all, sorry it's been a little while, but I wanted to let you know that
> although I took a few weeks off from it, I now have a 4.3.1 equivalent
> Lucene.net core building and able to write a simple index in Lucene 4.2
> codec and read in things like the number of documents and whatnot. Since
> QueryParser has been moved to a separate module in Lucene Java 4.x, I
> haven't ported that yet so I haven't done a real search, and I only built
> the index using a quick port of KeywordAnalyzer which all those analyzers
> have also moved to another module. But this is definitely good progress and
> should be a launch point for finishing a 4.3/4.4 port.
>
> You can see my fork/branch here:
> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
> said, only core builds now, no modules/tests build, so only open the
> Lucene.Net.Core.sln)
>
> I'm sure it's riddled with bugs, but I hope this can help kickstart the
> community into finishing the 4.3/4.4 port. Let me know if you have any
> questions, thanks!
>
>
> On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Paul, that's awesome. I will need some more time to go over this thread
> and
> > your work to give actual feedback, SUPER busy at the moment
> >
> >
> > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > All,
> > >
> > > My colleagues and I have made good progress on porting Lucene 4.3's
> core
> > > library before, during, and after the hackathon last week. We now only
> > have
> > > some remaining items in Search, Index, and Codecs namespaces (plus a
> few
> > > other minor ones here and there). I expect to be done by the end of the
> > > weekend. Analysis, Documents, Store, Util (except some FST and Packed),
> > and
> > > the root Codecs and Codecs.PerField namespaces are all now "done".
> > >
> > > Again, my goal is to only get a buildable, experimental build of
> > Lucene.net
> > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting
> > new
> > > javadoc comments or unit tests right now, due to the vast amount of
> code
> > > that needs to be written just to get it to compile. If this work ends
> up
> > > becoming a pull request, great, otherwise it should help accelerate a
> > port
> > > of 4.3.x since the bulk of the work on core will already be done and
> > > contributors can use it as a reference. And again, we're taking the
> > > pragmatic approach of porting class-by-class, namespace-by-namespace,
> > with
> > > the understanding that until we're done the project won't build.
> > >
> > > Once complete, I also will work on updating the Analyzers contrib
> module
> > > and porting the QueryParsers contrib module, which I feel should be
> > > included in the core NuGet package for Lucene.net as the core library
> is
> > > now (post-4.0) practically useless (or atleast not turn-key) without
> > them.
> > > You can check out the code on my fork/branch here:
> > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > >
> > > In particular, I'd like some feedback on my work on ByteBuffer,
> > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the
> > MMap
> > > support, I created a ByteBuffer subclass that uses .NET 4's
> > > MemoryMappedFile support which should emulate the Java nio stuff pretty
> > > well, but required some creative shuffling of the code to make it work
> > due
> > > to lifecycle management.
> > >
> > > I'll update again this weekend or next week, when we should have
> wrapped
> > up
> > > most of the main hacking on porting the core code.
> > >
> > > Paul
> > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > Marcos,
> > > >
> > > > That would be helpful. As far as I can tell, the 3.0 java code is
> only
> > on
> > > > SVN here, before the lucene and solr projects were bundled together:
> > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > > >
> > > > The SVN for 4.3 java is here:
> > > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > > And the GitHub for 4.3 java is here:
> > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > > >
> > > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > > >
> > > > My fork is the "upstream" fork for my team members, and i'm remote
> > > merging
> > > > their changes in from their forks while they fetch/merge from mine to
> > get
> > > > everyone else's changes, rather than using pull requests. James and I
> > > have
> > > > been working the past few days on the Util namespace ahead of
> tonight's
> > > > hackathon since that namespace is in common with the rest of the
> > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> hacking
> > on
> > > > porting 4.3, each with a different namespace or part of a namespace.
> > > Since
> > > > we're going class-by-class, namespace-by-namespace, the project does
> > not
> > > > build as it is. Once we finish doing a translation of each file, then
> > > we'll
> > > > hammer out any remaining issues and get it to build again. I'm hoping
> > > that
> > > > we can get at least 75% done with Core tonight. Wish us luck!
> > > >
> > > > But one thing to keep in mind is it looks like much functionality has
> > > been
> > > > moved out of core into the contrib modules, especially around
> analysis,
> > > for
> > > > 4.0+. For example, there are no built-in analyzers in core anymore.
> So
> > > when
> > > > this is all done, we may want to include at least the analysis
> contrib
> > > > module in with the standard core NuGet package, because otherwise
> it's
> > > > practically useless unless you roll your own analyzer.
> > > >
> > > > Paul
> > > >
> > > >
> > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> marcoslimagon@gmail.com
> > > >wrote:
> > > >
> > > >> Hi everyone!
> > > >>
> > > >> Does someone know where can I find the 3.0.3 release from
> > Lucene(java)?
> > > >>
> > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> > > make
> > > >> the diff between then and get all changes between releases... I
> gonna
> > > >> publish it here soon. (If you think there is another important
> > release,
> > > >> let
> > > >> me know)
> > > >>
> > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
> 4.3.0
> > > >> port
> > > >> for .Net on github (last email)?
> > > >>
> > > >> See you,
> > > >>
> > > >>
> > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > > >>
> > > >> > Thanks for the discussion points, Michael.
> > > >> >
> > > >> > I would vote for not worrying about trying to achieve portable
> > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > > >> completed.
> > > >> > Otherwise it may delay the project and stall it further. That's
> just
> > > my
> > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > > >> >
> > > >> > I have started porting the changes from the core library (from the
> > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > > branch.
> > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> > until
> > > >> > there's changes to pull from upstream to work from. Also due to my
> > > time
> > > >> > constraints, I am not fully documenting new methods that I'm
> adding.
> > > >> But if
> > > >> > anyone wants to pull/copy/reference my changes while porting,
> that's
> > > >> > awesome. My branch currently does not build as I'm primarily going
> > > >> > class-by-class, starting with the util namespace. Once we get the
> > ball
> > > >> > rolling on a community effort, I'll stop my rogue work and join
> in.
> > > But
> > > >> > hopefully my work will be useful to someone, if not as a pull
> > request
> > > >> then
> > > >> > as a reference. I'm also going to be holding a hackathon this week
> > > with
> > > >> my
> > > >> > colleagues where we're all going to work on the port. I'm
> comparing
> > > >> files
> > > >> > and making changes as necessary, rather than starting from
> scratch.
> > My
> > > >> > repo/branch is here:
> > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > >> >
> > > >> > Paul
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > > >> > mherndon@michaelherndon.com> wrote:
> > > >> >
> > > >> > > the guithub.com repo is a mirror to the git mirror that apache
> > > >> > maintains.
> > > >> > >
> > > >> > > The was some work at one time to move the official svn
> repository
> > to
> > > >> > start
> > > >> > > using git one instead. Was that actually finalized or not?
> > > >> > >
> > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> > what
> > > >> kind
> > > >> > of
> > > >> > > work was involved using a portable libraries project. Some of it
> > can
> > > >> > still
> > > >> > > be used but will need to be validated against the current
> version
> > of
> > > >> > Java's
> > > >> > > Lucene. It was also using .net 4.
> > > >> > >
> > > >> > > clean branch vs current. Its going to depend on what we
> > support.
> > > >> If
> > > >> > you
> > > >> > > support windows mobile 8, win RT, then the current code in trunk
> > > will
> > > >> not
> > > >> > > compile against those versions of the framework which would a
> > > >> frustrating
> > > >> > > starting point, then you couldn't even run tests, which would
> make
> > > >> taking
> > > >> > > patches very difficult. Supporting those can almost mean larger
> > > gaps
> > > >> in
> > > >> > > design between Lucene.Net and its parent project.
> > > >> > >
> > > >> > > Also the structure has changed significantly between the
> branches
> > > and
> > > >> > the
> > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> > seems
> > > >> > > significantly different. That doesn't mean you can't cherry
> pick
> > > >> stuff
> > > >> > > from the other tags/branches that would still work as is. A
> clean
> > > >> branch
> > > >> > > would also make it easier to get our build / tool chain in order
> > as
> > > >> you
> > > >> > can
> > > >> > > then do them incrementally versus having to do all the stuff
> that
> > I
> > > >> did
> > > >> > for
> > > >> > > the 3x branch which saps energy and desire to code. It could
> > also
> > > >> make
> > > >> > it
> > > >> > > easier to see which classes have been ported or not.
> > > >> > >
> > > >> > > The major downside to a clean branch is extra work it requires
> and
> > > the
> > > >> > > start up cost in time and energy of getting it in order, which
> can
> > > be
> > > >> > > daunting / intimidating and lower morale. And generally you want
> > to
> > > >> use
> > > >> > > take your legacy code and refactor instead of in someways
> starting
> > > >> over.
> > > >> > >
> > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> something
> > > >> similar
> > > >> > > to
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > >> > > where it tracks what needs to get ported / what has been ported.
> > > >> > >
> > > >> > > What are we going to support in the next version?
> > > >> > >
> > > >> > > Who is going to work on the next version?
> > > >> > >
> > > >> > > What would make the most sense and what would invigorate the
> > > >> community to
> > > >> > > get involved more and lower the barrier to entry?
> > > >> > >
> > > >> > > I think those are the questions that would make a lot of the
> > > decisions
> > > >> > for
> > > >> > > us so that we can get back to work on lucene.net.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > > marcoslimagon@gmail.com
> > > >> > > >wrote:
> > > >> > >
> > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > >> > > >
> > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > >> > > > https://github.com/apache/lucene.net points to the same
> > > repository?
> > > >> > > (This
> > > >> > > > is new for me, pretty good) Which of them do you recommend
> (i'm
> > > used
> > > >> > with
> > > >> > > > SVN and its patterns).
> > > >> > > >
> > > >> > > > I'm checking the subversion right now.
> > > >> > > >
> > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > > branch,
> > > >> i`m
> > > >> > > not
> > > >> > > > sure about its current status.
> > > >> > > >
> > > >> > > > Will we wipe the current solution from /trunk and start a new
> > one?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > > >> > > >
> > > >> > > > > We may be forced to start with a clean/empty branch if
> people
> > > >> still
> > > >> > > want
> > > >> > > > to
> > > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> > etc.
> > > >> The
> > > >> > are
> > > >> > > > > many
> > > >> > > > > classes that Lucene.net uses from the full framework that
> > would
> > > >> not
> > > >> > be
> > > >> > > > > accessible in other versions of the .NET Framework. It also
> > > might
> > > >> > > > require
> > > >> > > > > a design that differs even more from its parent project.
> > > >> > > > >
> > > >> > > > > It might be wise to poll what users most desire in the next
> > > >> version
> > > >> > > > through
> > > >> > > > > jira or user voice.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > > >> > itamar@code972.com
> > > >> > > > > >wrote:
> > > >> > > > >
> > > >> > > > > > inline
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > > >> pirwin@feature23.com>
> > > >> > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS
> > guy
> > > >> for
> > > >> > so
> > > >> > > > > long
> > > >> > > > > > > :-)
> > > >> > > > > > >
> > > >> > > > > > > So to recap, the branch_3x will be used for any patches
> or
> > > >> > anything
> > > >> > > > to
> > > >> > > > > > the
> > > >> > > > > > > current 3.0.3 release, while trunk is what we will
> branch
> > > from
> > > >> > for
> > > >> > > 4x
> > > >> > > > > > dev.
> > > >> > > > > > > Correct?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Yes - we can branch from it for 3.6 development if anyone
> > will
> > > >> be
> > > >> > > > > > interested in that
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > >
> > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal with
> > the
> > > >> > github
> > > >> > > > > sync?
> > > >> > > > > > > Who could diagnose that?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
> repo
> > > for
> > > >> now
> > > >> > > > while
> > > >> > > > > > we get that sorted out.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > >> > > > itamar@code972.com
> > > >> > > > > > > >wrote:
> > > >> > > > > > >
> > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then for
> > 3.x
> > > >> > > > > development.
> > > >> > > > > > > WRT
> > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> > branch.
> > > >> When
> > > >> > > you
> > > >> > > > > > send
> > > >> > > > > > > us
> > > >> > > > > > > > PRs we will merge either to master or to a dedicated
> > repo.
> > > >> For
> > > >> > > now
> > > >> > > > it
> > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > > >> > > > > > > >
> > > >> > > > > > > > I pushed a new Version.cs file, you should see it on
> the
> > > >> apache
> > > >> > > > > servers
> > > >> > > > > > > > (github sync seems to be off)
> > > >> > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > >> > > pirwin@feature23.com>
> > > >> > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> > version
> > > >> of
> > > >> > the
> > > >> > > > > > > Analysis
> > > >> > > > > > > > > namespace.
> > > >> > > > > > > > >
> > > >> > > > > > > > > Not sure the checkout command is what you intended
> --
> > > you
> > > >> > might
> > > >> > > > > have
> > > >> > > > > > > > meant
> > > >> > > > > > > > > trunk instead of master, and that would create a new
> > > "3x"
> > > >> > > branch,
> > > >> > > > > > when
> > > >> > > > > > > > > there's already a "branch_3x" and that would be
> > > >> misnamed...
> > > >> > so
> > > >> > > > > maybe
> > > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming
> for
> > > >> lucene
> > > >> > > > 4.3.x
> > > >> > > > > > > > > compatibility?
> > > >> > > > > > > > >
> > > >> > > > > > > > > Also, does someone with commit rights to the
> upstream
> > > >> want to
> > > >> > > > > create
> > > >> > > > > > > the
> > > >> > > > > > > > > necessary Version.cs entries, so that we're not all
> > > >> trying to
> > > >> > > > > create
> > > >> > > > > > > them
> > > >> > > > > > > > > and dealing with a merge?
> > > >> > > > > > > > >
> > > >> > > > > > > > > Paul
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > >> > > > > > itamar@code972.com
> > > >> > > > > > > > > >wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > > Unless people here have a specific reason to use
> > > 3.6.2 I
> > > >> > > would
> > > >> > > > > > highly
> > > >> > > > > > > > > > recommed putting all the efforts we can towards v4
> > > >> > otherwise
> > > >> > > we
> > > >> > > > > > will
> > > >> > > > > > > > > never
> > > >> > > > > > > > > > make it...
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Fork the repo from apache servers or github (same
> > > repo,
> > > >> > > > different
> > > >> > > > > > > > > remotes)
> > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that should
> > work
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > >> > > > > pirwin@feature23.com>
> > > >> > > > > > > > > wrote:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > Itamar,
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > I agree that from scratch is not the best way to
> > do
> > > >> it, I
> > > >> > > > just
> > > >> > > > > > > > thought
> > > >> > > > > > > > > > that
> > > >> > > > > > > > > > > was the "decision" that was made from the
> > discussion
> > > >> > > > previously
> > > >> > > > > > for
> > > >> > > > > > > > the
> > > >> > > > > > > > > > 4.x
> > > >> > > > > > > > > > > work. An incremental approach will be much
> better.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > I've created a branch of the branch_3x branch on
> > my
> > > >> fork
> > > >> > > and
> > > >> > > > > will
> > > >> > > > > > > > begin
> > > >> > > > > > > > > > > working on bringing the Analysis namespace up to
> > > >> speed to
> > > >> > > > > 3.6.2.
> > > >> > > > > > If
> > > >> > > > > > > > > > anyone
> > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> > done,
> > > >> have
> > > >> > at
> > > >> > > > it.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > > branch,
> > > >> > > please
> > > >> > > > > let
> > > >> > > > > > > me
> > > >> > > > > > > > > know
> > > >> > > > > > > > > > > what I should have branched from (trunk?)
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > Paul
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> > Syn-Hershko <
> > > >> > > > > > > > itamar@code972.com
> > > >> > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Paul, the problem is no one can really know
> what
> > > it
> > > >> > would
> > > >> > > > > take
> > > >> > > > > > > > until
> > > >> > > > > > > > > > they
> > > >> > > > > > > > > > > > have deep dived into the work, and even then
> > > >> decisions
> > > >> > > > could
> > > >> > > > > > and
> > > >> > > > > > > > will
> > > >> > > > > > > > > > > > change. I will strongly advise against
> starting
> > > from
> > > >> > > > scratch,
> > > >> > > > > > > > > although
> > > >> > > > > > > > > > I
> > > >> > > > > > > > > > > do
> > > >> > > > > > > > > > > > think a lot in the current structure should
> > > change,
> > > >> but
> > > >> > > its
> > > >> > > > > > going
> > > >> > > > > > > > to
> > > >> > > > > > > > > be
> > > >> > > > > > > > > > > > much easier to change it in place, refactoring
> > > where
> > > >> > > > needed,
> > > >> > > > > > than
> > > >> > > > > > > > > > > starting
> > > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > > personally
> > > >> > will
> > > >> > > > be
> > > >> > > > > > > happy
> > > >> > > > > > > > > with
> > > >> > > > > > > > > > > you
> > > >> > > > > > > > > > > > taking the analysis part of Lucene and porting
> > it,
> > > >> its
> > > >> > > > pretty
> > > >> > > > > > > much
> > > >> > > > > > > > > self
> > > >> > > > > > > > > > > > contained.
> > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork
> > and
> > > >> send
> > > >> > > us
> > > >> > > > > PRs,
> > > >> > > > > > > its
> > > >> > > > > > > > > > much
> > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Marcos, porting class by class is the fastest
> > way
> > > >> to do
> > > >> > > > this,
> > > >> > > > > > we
> > > >> > > > > > > > can
> > > >> > > > > > > > > > then
> > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing using
> > > .NET
> > > >> > > > > constructs.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > That said, I think the way to go is create a
> > > branch
> > > >> out
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > > > > current
> > > >> > > > > > > > > > > git
> > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> > working
> > > on
> > > >> > > master
> > > >> > > > > > > > towards a
> > > >> > > > > > > > > > 4.3
> > > >> > > > > > > > > > > > compatible version. The actual port should be
> > > using
> > > >> a
> > > >> > > > process
> > > >> > > > > > > that
> > > >> > > > > > > > > > > ensures
> > > >> > > > > > > > > > > > all Java classes are ported with their tests,
> > and
> > > >> that
> > > >> > > > those
> > > >> > > > > > > tests
> > > >> > > > > > > > > > pass -
> > > >> > > > > > > > > > > > but I'm against committing any Java code to
> our
> > > >> > > > repositories.
> > > >> > > > > > The
> > > >> > > > > > > > > > process
> > > >> > > > > > > > > > > > should probably be working on classes in some
> > > order
> > > >> > > > > > > > (alphabetically,
> > > >> > > > > > > > > or
> > > >> > > > > > > > > > > > core classes first) and getting each class to
> > > >> compile
> > > >> > > > before
> > > >> > > > > > > moving
> > > >> > > > > > > > > > > > forward. I don't mind about the project not
> > being
> > > >> > > > compilable
> > > >> > > > > > for
> > > >> > > > > > > a
> > > >> > > > > > > > > > month
> > > >> > > > > > > > > > > or
> > > >> > > > > > > > > > > > two.
> > > >> > > > > > > > > > > > Once this is done a process of .NETifying and
> > > >> proofing
> > > >> > > the
> > > >> > > > > code
> > > >> > > > > > > can
> > > >> > > > > > > > > be
> > > >> > > > > > > > > > > > started, at which point we will already have a
> > > >> working
> > > >> > v4
> > > >> > > > > > version
> > > >> > > > > > > > so
> > > >> > > > > > > > > it
> > > >> > > > > > > > > > > > will be easier to keep up with the Java
> project.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> > suite
> > > so
> > > >> > > tests
> > > >> > > > > > could
> > > >> > > > > > > > more
> > > >> > > > > > > > > > or
> > > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > > >> Java-like
> > > >> > > > > > > assertEquals
> > > >> > > > > > > > > > > methods
> > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
> with
> > > >> than
> > > >> > > > > NUnit). I
> > > >> > > > > > > > > already
> > > >> > > > > > > > > > > did
> > > >> > > > > > > > > > > > some work there but there's still a lot to do.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself at
> > this
> > > >> > point,
> > > >> > > > > but I
> > > >> > > > > > > > > should
> > > >> > > > > > > > > > be
> > > >> > > > > > > > > > > > back in business in August, at which point I
> can
> > > >> > dedicate
> > > >> > > > > > several
> > > >> > > > > > > > > > hours a
> > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> closely
> > > and
> > > >> > even
> > > >> > > > > > > coordinate
> > > >> > > > > > > > > the
> > > >> > > > > > > > > > > > work to some extent.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > >> > > > > > > > > marcoslimagon@gmail.com
> > > >> > > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > > It really sounds good to me, this is a kick
> > > start
> > > >> > =). I
> > > >> > > > > > haven't
> > > >> > > > > > > > > > > > contributed
> > > >> > > > > > > > > > > > > anything
> > > >> > > > > > > > > > > > > yet, but I would like to help you all to get
> > > this
> > > >> job
> > > >> > > > done.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > I know that there is a high commitment for
> > keep
> > > >> the
> > > >> > > > > > > > > > retrocompatibility
> > > >> > > > > > > > > > > on
> > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> changes
> > > >> every
> > > >> > > > > release?
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
> version
> > > >> from a
> > > >> > > > > Lucene
> > > >> > > > > > > > > version,
> > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> > changes
> > > >> > every
> > > >> > > > > stable
> > > >> > > > > > > > > release
> > > >> > > > > > > > > > > (or
> > > >> > > > > > > > > > > > > keep most of its source-code), we could
> > compare
> > > >> the
> > > >> > > > > versions,
> > > >> > > > > > > > check
> > > >> > > > > > > > > > the
> > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > > Again, I
> > > >> > > > haven't
> > > >> > > > > > > > > > contributed
> > > >> > > > > > > > > > > > with
> > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
> idea).
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > What's your approach for implement simple
> > > >> performance
> > > >> > > > > > > > improvements
> > > >> > > > > > > > > > > > (without
> > > >> > > > > > > > > > > > > adding references or changing methods
> > > signatures)?
> > > >> > Does
> > > >> > > > it
> > > >> > > > > > > could
> > > >> > > > > > > > be
> > > >> > > > > > > > > > > done,
> > > >> > > > > > > > > > > > > or "follow the java version only"?
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> > > >> haven't
> > > >> > > > > > > contributed
> > > >> > > > > > > > > > > anything
> > > >> > > > > > > > > > > > > > yet, although I will definitely help with
> > the
> > > >> 4.x
> > > >> > > work
> > > >> > > > > as I
> > > >> > > > > > > > have
> > > >> > > > > > > > > a
> > > >> > > > > > > > > > > > vested
> > > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> > think
> > > >> > there
> > > >> > > > > should
> > > >> > > > > > > be
> > > >> > > > > > > > > one
> > > >> > > > > > > > > > > > person
> > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> structure
> > > and
> > > >> > > > workflow
> > > >> > > > > > will
> > > >> > > > > > > > > look
> > > >> > > > > > > > > > > like
> > > >> > > > > > > > > > > > > to
> > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to
> be
> > > >> > starting
> > > >> > > > from
> > > >> > > > > > > > scratch
> > > >> > > > > > > > > > as
> > > >> > > > > > > > > > > a
> > > >> > > > > > > > > > > > > > fresh port, that person should set up the
> > > >> project,
> > > >> > > get
> > > >> > > > > > > > everything
> > > >> > > > > > > > > > > going
> > > >> > > > > > > > > > > > > in
> > > >> > > > > > > > > > > > > > source control, create the folder
> structure,
> > > >> maybe
> > > >> > > stub
> > > >> > > > > out
> > > >> > > > > > > > some
> > > >> > > > > > > > > > > > classes,
> > > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > > >> interested
> > > >> > > in
> > > >> > > > > > > > > > contributing,
> > > >> > > > > > > > > > > > > > perhaps by namespace.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > I like the idea of throwing the java code
> in
> > > >> there
> > > >> > so
> > > >> > > > > it's
> > > >> > > > > > > easy
> > > >> > > > > > > > > to
> > > >> > > > > > > > > > > > > > reference.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > >> > > > > > > Lucene.Net.Analysis,
> > > >> > > > > > > > > or
> > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those
> are
> > > >> just
> > > >> > the
> > > >> > > > > ones
> > > >> > > > > > > I'm
> > > >> > > > > > > > > most
> > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell me
> > what
> > > >> to
> > > >> > do
> > > >> > > > and
> > > >> > > > > > I'll
> > > >> > > > > > > > get
> > > >> > > > > > > > > > > > started
> > > >> > > > > > > > > > > > > > on my fork.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > Paul Irwin
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > > Nasser
> > > >> <
> > > >> > > > > > > > > > > geobmx540@hotmail.com
> > > >> > > > > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > > Hey guys -
> > > >> > > > > > > > > > > > > > > I know I've been MIA a little while. We
> > > have a
> > > >> > > board
> > > >> > > > > > report
> > > >> > > > > > > > due
> > > >> > > > > > > > > > > soon
> > > >> > > > > > > > > > > > -
> > > >> > > > > > > > > > > > > I
> > > >> > > > > > > > > > > > > > > think it prudent that we advise them
> that
> > we
> > > >> seem
> > > >> > > to
> > > >> > > > > have
> > > >> > > > > > > > > stalled
> > > >> > > > > > > > > > > > > > somewhat.
> > > >> > > > > > > > > > > > > > > We've got a few low hanging items out of
> > of
> > > >> jira
> > > >> > > and
> > > >> > > > > have
> > > >> > > > > > > > been
> > > >> > > > > > > > > > > > > responsive
> > > >> > > > > > > > > > > > > > > on the mailing list to community
> > questions,
> > > >> but I
> > > >> > > > don't
> > > >> > > > > > > think
> > > >> > > > > > > > > > we've
> > > >> > > > > > > > > > > > > done
> > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
> start
> > us
> > > >> back
> > > >> > > up
> > > >> > > > > > moving
> > > >> > > > > > > > > > > forward.
> > > >> > > > > > > > > > > > > What
> > > >> > > > > > > > > > > > > > > is the best way to accomplish this? If
> we
> > > took
> > > >> > the
> > > >> > > > java
> > > >> > > > > > > > lucene
> > > >> > > > > > > > > > 4.0
> > > >> > > > > > > > > > > > code
> > > >> > > > > > > > > > > > > > and
> > > >> > > > > > > > > > > > > > > committed that java to our branch and
> then
> > > >> just
> > > >> > let
> > > >> > > > > > people
> > > >> > > > > > > > pull
> > > >> > > > > > > > > > > that
> > > >> > > > > > > > > > > > > down
> > > >> > > > > > > > > > > > > > > and being changing / modifying is that
> one
> > > >> way to
> > > >> > > > maybe
> > > >> > > > > > > make
> > > >> > > > > > > > > some
> > > >> > > > > > > > > > > > > forward
> > > >> > > > > > > > > > > > > > > progress?
> > > >> > > > > > > > > > > > > > > ~P
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > Marcos Lima
> > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > --
> > > >> > > > Marcos Lima
> > > >> > > > Software Developer/Tech Lead
> > > >> > > > marcoslimagon@gmail.com
> > > >> > > > tel: +55 (19) 9798-9335
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> --
> > > >> Marcos Lima
> > > >> Software Developer/Tech Lead
> > > >> marcoslimagon@gmail.com
> > > >> tel: +55 (19) 9798-9335
> > > >>
> > > >
> > > >
> > >
> >
>