Will do. On Sep 9, 2013, at 1:28 AM, Yash Sharma <[email protected]> wrote:
> Oh that is great.. I dint check the mail and did it too.. > You killed it first, put a JIRA for it and attach your patch :) > > Thanks, > Yash Sharma > > > > > -----Original Message----- > From: Nachiketa Mishra [mailto:[email protected]] > Sent: Monday, September 09, 2013 1:09 PM > To: [email protected] > Subject: Re: Contributing > > I have all the java files completed. If it helps, I can create a JIRA issue > and upload a patch for java files. > > Nach > On Sep 9, 2013, at 12:31 AM, Yash Sharma <[email protected]> wrote: > >> Am free for a while. Let me pick this up :) >> >> Thanks, >> Yash Sharma >> >> >> >> -----Original Message----- >> From: Ted Dunning [mailto:[email protected]] >> Sent: Monday, September 09, 2013 11:18 AM >> To: drill >> Subject: Re: Contributing >> >> To the extent that functions fall into families, code generation makes a lot >> of sense. >> >> Explicit code without generation may make sense for some functions, however. >> >> Making things more consistent and generally tidying up will always be >> welcome, btw. >> >> One thing that we are seeing right now is that not all the code has Apache >> license headers. Jumping on that boring task would probably be widely >> appreciated. >> >> >> >> On Sun, Sep 8, 2013 at 10:33 PM, Nachiketa Mishra <[email protected]>wrote: >> >>> Hi, >>> I have been looking at the Drill Functions and the list of functions >>> that need to be implemented here. The ComparisonFunctions is now in >>> the codegen section.But, some of the other scalar functions are not >>> following the code generation template. Are we using Codegen for all >>> future efforts for Scalar function ? >>> >>> I apologize in advance, if this question has been already answered. >>> Nach >>> >>> On Sep 3, 2013, at 11:24 PM, Jacques Nadeau <[email protected]> wrote: >>> >>>> We moved those to template compile time generation. They commented out >>>> ones are the old ones. >>>> On Sep 3, 2013 11:21 PM, "Nachiketa Mishra" <[email protected]> wrote: >>>> >>>>> I got a latest from Master branch in github and I see the >>>>> org.apache.drill.exec.expr.fn.impl.ComparisonFunctions.java (line >>> 19-565) >>>>> being commented out. Is there a separate branch that I should be using ? >>>>> >>>>> Nach >>>>> >>>>> On Aug 28, 2013, at 9:10 PM, Jacques Nadeau <[email protected]> wrote: >>>>> >>>>>> Yes, as is creating new DrillFunc's. Timothy was nice enough to >>>>>> put >>> more >>>>>> information about DrillFunc's on the wiki: See: the 'Where is a >>>>>> good >>>>> place >>>>>> to start' contributing on this page: >>>>>> https://cwiki.apache.org/confluence/display/DRILL/Contributing >>>>>> >>>>>> Thanks, >>>>>> Jacques >>>>>> >>>>>> >>>>>> On Sat, Aug 24, 2013 at 8:10 AM, Nachiketa Mishra >>>>>> <[email protected] >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> I am Nach and I have been looking at Drill. I have been watching >>>>>>> the mailing list for some time. I will like to contribute to >>>>>>> Drill. Is >>> JIRA >>>>> a >>>>>>> good place to get started ? >>>>>>> >>>>>>> Regards, >>>>>>> Nach >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> >> ________________________________ >> >> >> >> >> >> >> NOTE: This message may contain information that is confidential, >> proprietary, privileged or otherwise protected by law. The message is >> intended solely for the named addressee. If received in error, please >> destroy and notify the sender. Any use of this email is prohibited when >> received in error. Impetus does not represent, warrant and/or guarantee, >> that the integrity of this communication has been maintained nor that the >> communication is free of errors, virus, interception or interference. > > > ________________________________ > > > > > > > NOTE: This message may contain information that is confidential, proprietary, > privileged or otherwise protected by law. The message is intended solely for > the named addressee. If received in error, please destroy and notify the > sender. Any use of this email is prohibited when received in error. Impetus > does not represent, warrant and/or guarantee, that the integrity of this > communication has been maintained nor that the communication is free of > errors, virus, interception or interference.
