Return-Path: X-Original-To: apmail-lucenenet-dev-archive@www.apache.org Delivered-To: apmail-lucenenet-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 49D3B108C0 for ; Wed, 7 Aug 2013 15:36:07 +0000 (UTC) Received: (qmail 21643 invoked by uid 500); 7 Aug 2013 15:36:06 -0000 Delivered-To: apmail-lucenenet-dev-archive@lucenenet.apache.org Received: (qmail 21624 invoked by uid 500); 7 Aug 2013 15:36:02 -0000 Mailing-List: contact dev-help@lucenenet.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucenenet.apache.org Delivered-To: mailing list dev@lucenenet.apache.org Received: (qmail 21616 invoked by uid 99); 7 Aug 2013 15:36:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Aug 2013 15:36:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pirwin@feature23.com designates 209.85.219.49 as permitted sender) Received: from [209.85.219.49] (HELO mail-oa0-f49.google.com) (209.85.219.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Aug 2013 15:35:56 +0000 Received: by mail-oa0-f49.google.com with SMTP id n10so1268746oag.8 for ; Wed, 07 Aug 2013 08:35:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fXgQj4uaLRnQMGvIkvDstojLfQQhNVIhjDWi6SJGuWQ=; b=OQhIApzH3r29ygCRMqqXNQPP3qRWImJdb7Se+kiCeIl3E0msAEwX9m9CX+hhyfx9FR SgMvBX6TOBNkPxlu7dDSt9vt1RgWA3znt/8/tpighLBfLDRRx/NT7ZFma33mV7w7G/WP 9+IMLaHqKIyanDSybbnNyl9m+Q+2R6zOAWf3FXk0v4T7pVq9xxn1XSoWxi3vEF/yocBB phW+B49Q1Yd3TnTPWAcfsHwif+bku2l4sD1MfZMLruEDAyTZ3eN4CMGfVqyGeD4hsHZs JZ7OuUil6i5G4GuOUubwx46GNV3GR0lnZdOwkgtFIV+ZUuYA5u1ucjhFiD9V3J7wP3iq fQMw== X-Gm-Message-State: ALoCoQlHtZCKA2s/8B3bu8KTM4Jvo3c1mbsOZeEVtkP+NFtaO++vFdAtUYCbVDtg9JZ1ojgiAWRk MIME-Version: 1.0 X-Received: by 10.50.127.196 with SMTP id ni4mr100035igb.49.1375889735642; Wed, 07 Aug 2013 08:35:35 -0700 (PDT) Received: by 10.42.138.201 with HTTP; Wed, 7 Aug 2013 08:35:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Aug 2013 11:35:35 -0400 Message-ID: Subject: Re: Lucene 4.0 From: Paul Irwin To: dev@lucenenet.apache.org Content-Type: multipart/alternative; boundary=089e0122a988f1856604e35d4a57 X-Virus-Checked: Checked by ClamAV on apache.org --089e0122a988f1856604e35d4a57 Content-Type: text/plain; charset=ISO-8859-1 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 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 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 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 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 >>> > 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 >>> > > 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 >>> > > > >> >>> > > > >> > 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 >>> > > > >> > > > >>> > > > >> > > > > 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 >>> > > > >> >>> > > > > >>> > > > > >>> > > > >>> > > >>> > >>> >> >> > --089e0122a988f1856604e35d4a57--