Changing the subject line to have a focused discussion. I understand that travis is fixing the issue. But in the meanwhile, I was wondering if there is a better way of approaching this rather than cutting down the output of tests. For e.g., changing log level for tests to WARN?
Please share your thoughts. Thanks, Chinmay. On Fri, Jan 15, 2016 at 10:18 PM, Timothy Farkas <[email protected]> wrote: > Travis limits the log size. There is an issue open to allow overriding the > default but I guess the feature hasn't been added yet. > > https://github.com/travis-ci/travis-ci/issues/3865 > > The only way to reduce the log size I can think of is to reduce the output > of tests. I'll try cutting down on the output of the tests I've added. > Maybe other people can pitch in trimming down their test output. > > Thanks, > Tim > > On Fri, Jan 15, 2016 at 5:58 AM, Chinmay Kolhatkar < > [email protected]> > wrote: > > > Hi All, > > > > I've updated the ExpressionEvaluator interface as suggested. The pull > > request is updated. Please review the pull request: > > https://github.com/apache/incubator-apex-malhar/pull/170 > > > > > > But, the Travis build is failing for this pull request for unknown > reason. > > > > I verified that the the command that is failing in travis is passing in > my > > local machine: > > This command is *mvn apache-rat:check verify -Dlicense.skip=false > > -Pall-modules* > > > > The last log line in Travis build is as follows: > > > > "The log length has exceeded the limit of 4 Megabytes (this usually means > > that test suite is raising the same exception over and over). > > The build has been terminated." > > > > I checked the Travis log and I could not see any test suite which was > > raising any exception over and over. > > > > Can you please suggest how to address Travis build failing issue? > > > > Thanks, > > Chinmay. > > > > > > > > On Fri, Jan 15, 2016 at 12:15 PM, Tushar Gosavi <[email protected]> > > wrote: > > > > > looks good, looking forward for an updated pull request > > > > > > - Tushar. > > > > > > > > > On Fri, Jan 15, 2016 at 12:03 PM, Timothy Farkas <[email protected]> > > > wrote: > > > > > > > +1 looks good to me. > > > > > > > > Thanks, > > > > Tim > > > > > > > > On Thu, Jan 14, 2016 at 10:06 AM, Chinmay Kolhatkar < > > > > [email protected] > > > > > wrote: > > > > > > > > > Considering Tim's suggestiom, I'm thinking about modifying the > > > interface > > > > in > > > > > following way: > > > > > > > > > > So there will be 3 interfaces: > > > > > > > > > > public interface Expression<O> > > > > > { > > > > > O execute(Object... obj); > > > > > } > > > > > > > > > > public interface ExpressionEvaluator > > > > > { > > > > > <O> ExpressionEvaluator.Expression<O> > > createExecutableFunction(String > > > > > expression, Class<?> returnType); > > > > > > > > > > <O> ExpressionEvaluator.Expression<O> > > > createExecutableExpression(String > > > > > expression, Class<?> returnType); > > > > > > > > > > void setExpressionParser(ExpressionParser parser); > > > > > } > > > > > > > > > > public interface ExpressionParser > > > > > { > > > > > String convertToCompilableExpression(String expression, Class<?> > > > > > returnType, boolean containsReturnStatement); > > > > > } > > > > > > > > > > Description of interfaces: > > > > > 1. Expression interface is the final output which will have > > executable > > > > code > > > > > of expression. > > > > > 2. ExpressionEvaluator interface will be implemented for specific > > type > > > if > > > > > implementation. For eg. In this case the concrete implementation > will > > > be > > > > > JavaExpressionEvaluator which will evaluate quasi-Java expression > > > > > 3. ExpressionParser interface will defined how expression need to > be > > > > parsed > > > > > and can be plugin to ExpressionEvaluator interface via > > > > setExpressionParser > > > > > method. > > > > > > > > > > This way, > > > > > 1. One can override parsing logic for specific evaluator. > > > > > 2. Override the expression evaluation logic all together. > > > > > 3. Sticking to a common interface of ExpressionEvaluator & > Expression > > > > will > > > > > make the user code not to change even if parser or evaluator > changes. > > > > > > > > > > Thoughts? > > > > > > > > > > Thanks, > > > > > Chinmay. > > > > > > > > > > On Thu, Jan 14, 2016 at 2:17 PM, Chinmay Kolhatkar < > > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > I think think is doable. > > > > > > I'll take a look. > > > > > > > > > > > > Thanks, > > > > > > Chinmay. > > > > > > > > > > > > On Thu, Jan 14, 2016 at 1:59 PM, Timothy Farkas < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > >> Haven't gone though you're PR, so I'm not sure how this would > fit > > > in. > > > > > But > > > > > >> I > > > > > >> think introducing an interface like below, and allowing it to be > > set > > > > may > > > > > >> be > > > > > >> sufficient. > > > > > >> > > > > > >> public interface ExpressionParser > > > > > >> { > > > > > >> public String convertToJavaExpression(String expression); > > > > > >> } > > > > > >> > > > > > >> Thanks, > > > > > >> Tim > > > > > >> > > > > > >> On Thu, Jan 14, 2016 at 12:19 AM, Chinmay Kolhatkar < > > > > > >> [email protected] > > > > > >> > wrote: > > > > > >> > > > > > >> > Ah got it. That's a good point. Maybe its good to separate the > > > > parsing > > > > > >> and > > > > > >> > compilation part of the evaluation. > > > > > >> > And let one override the parsing logic. > > > > > >> > > > > > > >> > I'll see how to incorporate that, but if you have idea about > > > > achieving > > > > > >> it, > > > > > >> > please share it. > > > > > >> > > > > > > >> > Thanks, > > > > > >> > Chinmay. > > > > > >> > > > > > > >> > > > > > > >> > On Thu, Jan 14, 2016 at 1:43 PM, Timothy Farkas < > > > > [email protected]> > > > > > >> > wrote: > > > > > >> > > > > > > >> > > Hey Chinmay, > > > > > >> > > > > > > > >> > > It is possible the user may want to define a syntax > radically > > > > > >> different > > > > > >> > > from Java style syntax. I've proposed a syntax similar to > > yours > > > to > > > > > >> one of > > > > > >> > > our users for expression evaluation but they didn't like it > > > > because > > > > > >> the > > > > > >> > > syntax needs to be something easily validated by a UI. It > may > > be > > > > > >> possible > > > > > >> > > that the user wants expressions to be sent to an operator as > > > json, > > > > > >> > because > > > > > >> > > that is easy to parse and validate in javascript: > > > > > >> > > > > > > > >> > > {"param":"myField1","operation":">","threshold":"1"} > > > > > >> > > > > > > > >> > > If the syntax is pluggable then an implementation of this > > syntax > > > > > >> could be > > > > > >> > > swapped with with an implementation of the syntax you've > > already > > > > > >> provided > > > > > >> > > without changing operator code. > > > > > >> > > > > > > > >> > > Thanks, > > > > > >> > > Tim > > > > > >> > > > > > > > >> > > On Wed, Jan 13, 2016 at 11:34 PM, Chinmay Kolhatkar < > > > > > >> > > [email protected] > > > > > >> > > > wrote: > > > > > >> > > > > > > > >> > > > Hi tim, > > > > > >> > > > > > > > > >> > > > I agree with you. The expression here we're talking about > is > > > > > really > > > > > >> a > > > > > >> > > > quasi-Java expression. One can do anything which java > does. > > > > > >> > > > Only change with java syntax here is how variables are > > > accessed. > > > > > >> > > > > > > > > >> > > > They're by default accessed as ${...}. > > > > > >> > > > > > > > > >> > > > But this is also made configurable via a setter property > on > > > > > >> > > > ExpressionEvaluator. The pull request has it. > > > > > >> > > > > > > > > >> > > > If this is what you're talking about then this is taken > care > > > of. > > > > > >> > > > > > > > > >> > > > Thanks, > > > > > >> > > > Chinmay. > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > On Thu, Jan 14, 2016 at 1:00 PM, Timothy Farkas < > > > > > >> [email protected]> > > > > > >> > > > wrote: > > > > > >> > > > > > > > > >> > > > > Hi Chinmay, > > > > > >> > > > > > > > > > >> > > > > I think this is a very good first implementation. My > only > > > > > concern > > > > > >> is > > > > > >> > > that > > > > > >> > > > > people will get caught up in the details of the syntax > for > > > > this > > > > > >> > > > expression > > > > > >> > > > > language. I think a way to avoid that is to make the > > syntax > > > > > >> > pluggable. > > > > > >> > > > For > > > > > >> > > > > example is there an interface for expression evaluation > > > which > > > > > can > > > > > >> be > > > > > >> > > > > implemented by different syntaxes? This would allow > > > operators > > > > > >> which > > > > > >> > use > > > > > >> > > > > expression evaluation to have the syntax configured via > a > > > > > >> property. > > > > > >> > > That > > > > > >> > > > > way if someone discovers a limitation in the syntax down > > the > > > > > >> line, a > > > > > >> > > new > > > > > >> > > > > syntax can be introduced without breaking backwards > > > > > compatibility > > > > > >> and > > > > > >> > > > > without requiring operator code to be changed. > > > > > >> > > > > > > > > > >> > > > > Thanks, > > > > > >> > > > > Tim > > > > > >> > > > > > > > > > >> > > > > On Wed, Jan 13, 2016 at 10:52 PM, Chinmay Kolhatkar < > > > > > >> > > > > [email protected] > > > > > >> > > > > > wrote: > > > > > >> > > > > > > > > > >> > > > > > Hi All, > > > > > >> > > > > > > > > > > >> > > > > > I'm working on APEXCORE-1972 which adds support for a > > > > > quasi-Java > > > > > >> > > > > Expression > > > > > >> > > > > > Language and its expression evaluator. > > > > > >> > > > > > > > > > > >> > > > > > All the detailed functionality and design details > along > > > with > > > > > >> > examples > > > > > >> > > > are > > > > > >> > > > > > present in Jira. > > > > > >> > > > > > > > > > > >> > > > > > I've summarized the ExpressionEvaluator feature & > > > Expression > > > > > >> > language > > > > > >> > > > > > below. > > > > > >> > > > > > > > > > > >> > > > > > The pull request created for this at here: > > > > > >> > > > > > > > https://github.com/apache/incubator-apex-malhar/pull/170 > > > > > >> > > > > > > > > > > >> > > > > > Please share your thought on this. > > > > > >> > > > > > > > > > > >> > > > > > Thanks, > > > > > >> > > > > > Chinmay. > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > *Summary of functionality of ExpressionEvaluator:* > > > > > >> > > > > > > > > > > >> > > > > > 1. Support quasi-Java Expression which defines a > > single > > > > > line > > > > > >> > > > > executable > > > > > >> > > > > > expression > > > > > >> > > > > > 2. Support for quasi-Java expression based function > > > code, > > > > > >> which > > > > > >> > > will > > > > > >> > > > > be > > > > > >> > > > > > compiled on the fly and made available for > execution. > > > > > >> > > > > > 3. Should support accessing multiple fields from > > > > multiples > > > > > >> input > > > > > >> > > > POJOs > > > > > >> > > > > > while addressing the conversion of private > variables > > to > > > > > >> public > > > > > >> > > > getter > > > > > >> > > > > > method for all levels. > > > > > >> > > > > > 4. Should support nested field support > > > > > >> > > > > > 5. quasi-Java expressions should support operands > to > > be > > > > > >> > mentioned > > > > > >> > > in > > > > > >> > > > > > following ways: > > > > > >> > > > > > - ${input.fieldName} > > > > > >> > > > > > - Access fieldName via a object name. > > > > > >> > > > > > - ${fieldName} > > > > > >> > > > > > - Accessing fieldName directly when a single > > > object > > > > > is > > > > > >> > > > > registered > > > > > >> > > > > > for operation. > > > > > >> > > > > > - ${input} > > > > > >> > > > > > - Accessing object variable directly > > > > > >> > > > > > - ${input.fieldName.internalField} > > > > > >> > > > > > - Accessing nested fields > > > > > >> > > > > > 6. There should be some predefined function > > provided > > > > to > > > > > >> > > > expression > > > > > >> > > > > > writer which one can directly use in expression for > > > > > invoking > > > > > >> > > certain > > > > > >> > > > > > functionality. > > > > > >> > > > > > 7. These are simple String based, Date time based > etc > > > > > >> functions. > > > > > >> > > > > > 8. On-need-basic one should be able to easily > update > > > > > >> Expression > > > > > >> > > > > > Evaluator to easily add new predefined functions to > > be > > > > made > > > > > >> > > > available > > > > > >> > > > > > for > > > > > >> > > > > > expression writer. > > > > > >> > > > > > 9. User of ExpressionEvaluator should be able to > add > > a > > > > > custom > > > > > >> > > method > > > > > >> > > > > > externally to be made available to in expression. > > > > > >> > > > > > 10. Though operands are defined, placeholder for > the > > > > > operand > > > > > >> in > > > > > >> > > > > > expression should be allowed to be overridden. By > > > > default, > > > > > >> > > > expression > > > > > >> > > > > > language should support bash type syntax for > operand > > - > > > > {…} > > > > > >> > > > > > 11. The library should not introduce any > > serialization > > > > > >> related > > > > > >> > > > issues. > > > > > >> > > > > > 12. All the java operators should be supported. > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > *The examples of quasi-Java Expression:* > > > > > >> > > > > > > > > > > >> > > > > > - ${inp.field1} > > > > > >> > > > > > - Will return value of field1 from registered > > input > > > > > POJO. > > > > > >> > > > > > - ${inp.field1} + ${inp.field2} > > > > > >> > > > > > - Will return sum of field1 & field2 from given > > POJO > > > > > >> > > > > > - ${field1} + ${field2} > > > > > >> > > > > > - Equivalent to above > > > > > >> > > > > > - ${inpA.field1} > ${inpA.field2} ? ${inpA.field3} > : > > > > > >> > > ${inpB.field3} > > > > > >> > > > > > - Executes ternary expression and returns value > > > > > >> accordingly. > > > > > >> > > > Works > > > > > >> > > > > on > > > > > >> > > > > > 2 POJOs. inpA & inpB are two placeholder > > registered > > > > for > > > > > >> given > > > > > >> > > > POJO > > > > > >> > > > > > with > > > > > >> > > > > > ExpressionEvaluator library. > > > > > >> > > > > > - pow(${inpA.field1}, ${inpB.field2}) > > > > > >> > > > > > - Executes pow function coming from > java.lang.Math > > > > > >> library. > > > > > >> > > This > > > > > >> > > > > and > > > > > >> > > > > > other with lot other basic functions is > available > > to > > > > > >> > expression > > > > > >> > > > > > writer out > > > > > >> > > > > > of the box to use in expression. > > > > > >> > > > > > - ${inpA.field1} > 0 ? ${inpB.innerPOJO.field3} : > > > > > >> > > > > > ${inpA.innerPOJO.field3} > > > > > >> > > > > > - Shows how nested POJOs can be accessed in > > > > expression. > > > > > >> The > > > > > >> > > > > variables > > > > > >> > > > > > will evaluate to correct public getter method is > > > > > required. > > > > > >> > > > > > - ${inp.firstname} + “ “ + ${inp.lastname} > > > > > >> > > > > > - Generate the full name as per given expression > > > from > > > > > >> > firstname > > > > > >> > > > and > > > > > >> > > > > > lastname field. > > > > > >> > > > > > - long retVal=1; for (int i=0; ${inpF.value1}; i++) > > > > > {retVal = > > > > > >> > > > retVal * > > > > > >> > > > > > ${inpF.value1}; } return retVal; > > > > > >> > > > > > - This tells a complete method content to > > > > > >> > ExpressionEvaluator. > > > > > >> > > > The > > > > > >> > > > > > library create an executable and compiled method > > > using > > > > > >> this > > > > > >> > > > > > expression. > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
