[jira] [Commented] (GROOVY-7768) groovy.sql.Sql callWithAllRows returns blank result when passing params

2016-03-08 Thread Ryan Mills (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186530#comment-15186530
 ] 

Ryan Mills commented on GROOVY-7768:



public class SqlCall {

public DataSource dataSource;
public Sql sql;


public void setDataSource(DataSource dataSource){
this.dataSource = dataSource
this.sql = new Sql(this.dataSource)
}

public List call(sqlString){

List rows = sql.rows(sqlString);
return rows;

}

public List call(sqlString, args){
List argsList = orderedParams(sqlString, args)
String cleanSql = stripSqlString(sqlString)
List rows = sql.rows(cleanSql, argsList);
return rows;

}

/**
 * Standard callWithAll rows. Does not work with sprocs with params
 * @param sqlString
 * @param args
 * @return
 */
public List multipleCall(sqlString, args){
List argsList = orderedParams(sqlString, args)
String cleanSql = stripSqlString(sqlString)
//println("sql:" + cleanSql);
//println("args:" + argsList);
List rows = sql.callWithAllRows(cleanSql, argsList, {})
//println("rows:" + rows);
return rows;

}

public List orderedParams(sqlString, args){
if (args instanceof List){
return args
}
List returnList = new ArrayList();
List valueList = new ArrayList();
def m = namedParamMatches(sqlString)
while (m.find()) {
valueList.add(m.group().replace(" ", "").replace(":", ""))
}
for(String s: valueList ){
returnList.add(args.get(s))
}
// using the sqlString :params, order the args to match, turn into ?
return returnList
}

public String stripSqlString(inString){
def m = namedParamMatches(inString)
while (m.find()) {
inString = inString.replace(m.group(), "?")
}
return inString
}

def static Matcher namedParamMatches(inString) {
Pattern p = Pattern.compile("(:[a-zA-Z]\\w+)"); //\w mean [a-zA-Z_0-9]
Matcher m = p.matcher(inString);
return m; //while m.find() {m.group()}

}

/**
 * Returns multiple result sets, supports params, sprocs
 * @param query
 * @param args
 * @return
 */
public List rows(String query, args){
List argsList = orderedParams(query, args)
String cleanSql = stripSqlString(query)

List rows = new ArrayList();

int rowCounter = -1;
List rowList = new ArrayList();
eachSprocRow(cleanSql, argsList) {rsCount, row ->
//println "rsCount:" + rsCount
//println "row:" + row

if(rowCounter != rsCount ){
if(rowCounter > -1) {
rows.add(rowList); // new result set now
rowList = new ArrayList();
}
rowCounter = rsCount
}

rowList.add(row); // add this row to the current list
}

rows.add(rowList); // catch the first
return rows;

}

/**
 * Call with all rows does not work on compiled sprocs with params
 *
 * @param query
 * @param parameters
 * @param closure
 */
public void eachSprocRow(String query, List parameters, Closure closure) {
sql.cacheConnection { Connection con ->
CallableStatement proc = con.prepareCall(query)
try {
parameters.eachWithIndex { param, i ->
proc.setObject(i+1, param)
}

//System.err.println "executing..."
try{
//display = "executing..."
boolean result = proc.execute()
//display = ""
}catch (Exception e){
System.err.println e
//display = e.toString()
return
}

//boolean moreResults = true
boolean found = false
int rsCount = 0;
while (true) {
//println result
ResultSet rs = proc.getResultSet()
if (rs != null) {
//ResultSet rs = proc.getResultSet()
ResultSetMetaData md = rs.getMetaData()
int columnCount = md.getColumnCount()
while (rs.next()) {
Map row = new LinkedHashMap()
for (int i = 0; i < columnCount; ++ i) {
row[md.getColumnName(i+1)] = rs.getObject(i+1)
}
closure.call(rsCount, row)
}
  

[jira] [Comment Edited] (GROOVY-7768) groovy.sql.Sql callWithAllRows returns blank result when passing params

2016-03-08 Thread Ryan Mills (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186529#comment-15186529
 ] 

Ryan Mills edited comment on GROOVY-7768 at 3/9/16 5:22 AM:


JDBC Driver was com.sybase.jdbc3.jdbc.SybDriver

Functionally, I have code that does the same thing as a work around, so at some 
level the base Sql handles this. One other thing, it should ideally support a 
map as a param, not list. 

Given below, without the imports.



was (Author: oniseijin):
JDBC Driver was com.sybase.jdbc3.jdbc.SybDriver

Functionally, I have code that does the same thing as a work around, so at some 
level the base Sql handles this. One other thing, it should ideally support a 
map as a param, not list. 


> groovy.sql.Sql callWithAllRows returns blank result when passing params
> ---
>
> Key: GROOVY-7768
> URL: https://issues.apache.org/jira/browse/GROOVY-7768
> Project: Groovy
>  Issue Type: Bug
>  Components: SQL processing
>Affects Versions: 2.4.0
>Reporter: Ryan Mills
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> callWithAllRows works with regular sql, and an empty list.
> call works with a map or list
> Howver, callWithAllRows returns an empty list when using with params eg.)
> List list = new ArrayList();
> l.add("myid");
> sql.callWithAllRows("sp_who ?", list, {}); 
> result is []



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-7768) groovy.sql.Sql callWithAllRows returns blank result when passing params

2016-03-08 Thread Ryan Mills (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186530#comment-15186530
 ] 

Ryan Mills edited comment on GROOVY-7768 at 3/9/16 5:22 AM:



public class SqlCall {

public DataSource dataSource;
public Sql sql;


public void setDataSource(DataSource dataSource){
this.dataSource = dataSource
this.sql = new Sql(this.dataSource)
}

public List call(sqlString){

List rows = sql.rows(sqlString);
return rows;

}

public List call(sqlString, args){
List argsList = orderedParams(sqlString, args)
String cleanSql = stripSqlString(sqlString)
List rows = sql.rows(cleanSql, argsList);
return rows;

}

/**
 * Standard callWithAll rows. Does not work with sprocs with params
 * @param sqlString
 * @param args
 * @return
 */
public List multipleCall(sqlString, args){
List argsList = orderedParams(sqlString, args)
String cleanSql = stripSqlString(sqlString)
//println("sql:" + cleanSql);
//println("args:" + argsList);
List rows = sql.callWithAllRows(cleanSql, argsList, {})
//println("rows:" + rows);
return rows;

}

public List orderedParams(sqlString, args){
if (args instanceof List){
return args
}
List returnList = new ArrayList();
List valueList = new ArrayList();
def m = namedParamMatches(sqlString)
while (m.find()) {
valueList.add(m.group().replace(" ", "").replace(":", ""))
}
for(String s: valueList ){
returnList.add(args.get(s))
}
// using the sqlString :params, order the args to match, turn into ?
return returnList
}

public String stripSqlString(inString){
def m = namedParamMatches(inString)
while (m.find()) {
inString = inString.replace(m.group(), "?")
}
return inString
}

def static Matcher namedParamMatches(inString) {
Pattern p = Pattern.compile("(:[a-zA-Z]\\w+)"); //\w mean [a-zA-Z_0-9]
Matcher m = p.matcher(inString);
return m; //while m.find() {m.group()}

}

/**
 * Returns multiple result sets, supports params, sprocs
 * @param query
 * @param args
 * @return
 */
public List rows(String query, args){
List argsList = orderedParams(query, args)
String cleanSql = stripSqlString(query)

List rows = new ArrayList();

int rowCounter = -1;
List rowList = new ArrayList();
eachSprocRow(cleanSql, argsList) {rsCount, row ->
//println "rsCount:" + rsCount
//println "row:" + row

if(rowCounter != rsCount ){
if(rowCounter > -1) {
rows.add(rowList); // new result set now
rowList = new ArrayList();
}
rowCounter = rsCount
}

rowList.add(row); // add this row to the current list
}

rows.add(rowList); // catch the first
return rows;

}

/**
 * Call with all rows does not work on compiled sprocs with params
 *
 * @param query
 * @param parameters
 * @param closure
 */
public void eachSprocRow(String query, List parameters, Closure closure) {
sql.cacheConnection { Connection con ->
CallableStatement proc = con.prepareCall(query)
try {
parameters.eachWithIndex { param, i ->
proc.setObject(i+1, param)
}

//System.err.println "executing..."
try{
//display = "executing..."
boolean result = proc.execute()
//display = ""
}catch (Exception e){
System.err.println e
//display = e.toString()
return
}

//boolean moreResults = true
boolean found = false
int rsCount = 0;
while (true) {
//println result
ResultSet rs = proc.getResultSet()
if (rs != null) {
//ResultSet rs = proc.getResultSet()
ResultSetMetaData md = rs.getMetaData()
int columnCount = md.getColumnCount()
while (rs.next()) {
Map row = new LinkedHashMap()
for (int i = 0; i < columnCount; ++ i) {
row[md.getColumnName(i+1)] = rs.getObject(i+1)
}
closure.call(rsCount, row)
 

[jira] [Commented] (GROOVY-7768) groovy.sql.Sql callWithAllRows returns blank result when passing params

2016-03-08 Thread Ryan Mills (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186529#comment-15186529
 ] 

Ryan Mills commented on GROOVY-7768:


JDBC Driver was com.sybase.jdbc3.jdbc.SybDriver

Functionally, I have code that does the same thing as a work around, so at some 
level the base Sql handles this. One other thing, it should ideally support a 
map as a param, not list. 


> groovy.sql.Sql callWithAllRows returns blank result when passing params
> ---
>
> Key: GROOVY-7768
> URL: https://issues.apache.org/jira/browse/GROOVY-7768
> Project: Groovy
>  Issue Type: Bug
>  Components: SQL processing
>Affects Versions: 2.4.0
>Reporter: Ryan Mills
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> callWithAllRows works with regular sql, and an empty list.
> call works with a map or list
> Howver, callWithAllRows returns an empty list when using with params eg.)
> List list = new ArrayList();
> l.add("myid");
> sql.callWithAllRows("sp_who ?", list, {}); 
> result is []



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-6880) Please add Inline AST Transform

2016-03-08 Thread Paul King (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15186381#comment-15186381
 ] 

Paul King commented on GROOVY-6880:
---

But should anyone wish to play with building such a transform, don't let us 
stop you. Please feel free to create a PR.

> Please add Inline AST Transform
> ---
>
> Key: GROOVY-6880
> URL: https://issues.apache.org/jira/browse/GROOVY-6880
> Project: Groovy
>  Issue Type: Improvement
>  Components: xforms
>Reporter: Suminda Dharmasena
>Priority: Minor
>
> Kotlin has also added inline support. This would be a very useful feature for 
> performance sensitive code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8

2016-03-08 Thread Jochen Theodorou (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185972#comment-15185972
 ] 

Jochen Theodorou commented on GROOVY-7772:
--

I think there is one more point to clear:
{code:Java}
class X {
  def m() {1}
  def m(int i) {i+1}
}

def ref = new X().
assert ref() == 1
assert ref(1) == 2
assert ref.parameterTypes == [int]{code}
As you can imagine code like this would not be possible in Java. It also means. 
The implementation guarantees, that the prameterTypes will be corresponding to 
the longest signature. If multiple signatures of the same length exists, then a 
random one might be taken. In similar fashion this imposes a problem for 
determining if we do dispatch on a static method or not in your code.  Imagine 
for example m() being static and m(int) not, and the reference X. The code 
will make a setup for isStaticMethod=false and owner being a Class, 
prameterTypes will become [X,int], a call X.(1) will incorrectly not work 
according to the logic in doCall.
Actually the class has another big problem not caused by this change. If we do 
a call to the MethodClosure from Groovy, the meta class logic will be used. But 
if we do the call from Java, the logic in doCall will be used. They have to 
stay in sync, to show the same effect, which is bad. Good would be one version 
using the other. Now for efficiency reasons we have sometimes direct calls from 
call to doCall. So at this point I would normally suggest making the class 
final and remove the doCall method. call, goes to doCall dynamically, so the 
logic in the meta class would still work out... but this would be a breaking 
change.. So instead I would let doCall throw an Exception. 
Then of course call should not be specified by MethodClosure at all. And of 
course the decision if we do a dispatch based on the static method or not, with 
an instance or a Class, must be completely in the MetaClassImpl part, you 
already touched. But instead of blindly invoking, you will need to get the 
MetaMethod and check. for the special case, to blindly invoke otherwise. This 
of course also means MethodClosure would not have a isStaticMethod property as 
well

> Class. had better to have same meaning of 
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
>  Issue Type: Improvement
>  Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method 
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's :: 
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same 
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error 
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method 
> instance method of Class which is declared as ```RetType 
> instanceMethod(Args..) {...}```. In other words it is interpreted as a 
> function which takes LHS Class as the first parameter which additionally 
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy  
> same as Java 8 's. Because:
>  * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and 
> needed for Java programmers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] groovy pull request: Javalike method pointer groovy 7772

2016-03-08 Thread blackdrag
Github user blackdrag commented on a diff in the pull request:

https://github.com/apache/groovy/pull/287#discussion_r55440244
  
--- Diff: src/main/org/codehaus/groovy/runtime/MethodClosure.java ---
@@ -62,9 +74,34 @@ public String getMethod() {
 }
 
 protected Object doCall(Object arguments) {
+if (getOwner() instanceof Class && !isStaticMethod) {
+if (arguments instanceof Object[]) {
+Object[] args = (Object[])arguments;
+if (args.length <= 0) {
+throw new MissingMethodException(method, 
(Class)getOwner(), args);
+}
+Object insertedReceiver = args[0];
+Object[] newArgs = Arrays.copyOfRange(args, 1, 
args.length);
+return InvokerHelper.invokeMethod(insertedReceiver, 
method, newArgs);
+}
+return InvokerHelper.invokeMethod(arguments, method, new 
Object[]{});
+}
 return InvokerHelper.invokeMethod(getOwner(), method, arguments);
 }
 
+@SuppressWarnings("unchecked")
+public Object call(Object... args) {
+try {
--- End diff --

why do we need this method?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] groovy pull request: Javalike method pointer groovy 7772

2016-03-08 Thread blackdrag
Github user blackdrag commented on a diff in the pull request:

https://github.com/apache/groovy/pull/287#discussion_r55433138
  
--- Diff: src/spec/test/CoercionTest.groovy ---
@@ -214,7 +214,7 @@ boolean doFilter(String s) { s.contains('G') }
 Predicate filter = this.
 assert filter.accept('Groovy') == true
 
-Greeter greeter = GroovySystem.
+Greeter greeter = new GroovySystem().
--- End diff --

this change does not make sense to me. getVersion is a static method, so 
GroovySystem. must be fine


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8

2016-03-08 Thread UEHARA Junji (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185817#comment-15185817
 ] 

UEHARA Junji commented on GROOVY-7772:
--

I made PR for this change as a reference. Would you review it?

> Class. had better to have same meaning of 
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
>  Issue Type: Improvement
>  Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method 
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's :: 
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same 
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error 
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method 
> instance method of Class which is declared as ```RetType 
> instanceMethod(Args..) {...}```. In other words it is interpreted as a 
> function which takes LHS Class as the first parameter which additionally 
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy  
> same as Java 8 's. Because:
>  * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and 
> needed for Java programmers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8

2016-03-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185802#comment-15185802
 ] 

ASF GitHub Bot commented on GROOVY-7772:


GitHub user uehaj opened a pull request:

https://github.com/apache/groovy/pull/287

Javalike method pointer groovy 7772

This is a change for method pointer semantics in groovy discussed in 
following issue.
https://issues.apache.org/jira/browse/GROOVY-7772

ref.

http://docs.groovy-lang.org/latest/html/documentation/index.html#method-pointer-operator

https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html#type


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/uehaj/groovy 
javalike-method-pointer-GROOVY-7772

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/287.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #287


commit 0308f6fe44ba354ba3eaf61d45f924895d09483d
Author: UEHARA Junji 
Date:   2016-03-07T21:18:54Z

GROOVY-7772: Change method pointer like Java 8

commit f2ab90ea1ee0960d2a87b0feb536c4134841eb82
Author: UEHARA Junji 
Date:   2016-03-08T20:00:44Z

GROOVY-7772: Add test cases.

commit 280a27b6b4715d153e01258670dda5131ebed187
Author: UEHARA Junji 
Date:   2016-03-08T20:28:32Z

GROOVY-7772: Handle too few arguments as missing method exception.




> Class. had better to have same meaning of 
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
>  Issue Type: Improvement
>  Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method 
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's :: 
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same 
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error 
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method 
> instance method of Class which is declared as ```RetType 
> instanceMethod(Args..) {...}```. In other words it is interpreted as a 
> function which takes LHS Class as the first parameter which additionally 
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy  
> same as Java 8 's. Because:
>  * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and 
> needed for Java programmers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] groovy pull request: Javalike method pointer groovy 7772

2016-03-08 Thread uehaj
GitHub user uehaj opened a pull request:

https://github.com/apache/groovy/pull/287

Javalike method pointer groovy 7772

This is a change for method pointer semantics in groovy discussed in 
following issue.
https://issues.apache.org/jira/browse/GROOVY-7772

ref.

http://docs.groovy-lang.org/latest/html/documentation/index.html#method-pointer-operator

https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html#type


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/uehaj/groovy 
javalike-method-pointer-GROOVY-7772

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/287.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #287


commit 0308f6fe44ba354ba3eaf61d45f924895d09483d
Author: UEHARA Junji 
Date:   2016-03-07T21:18:54Z

GROOVY-7772: Change method pointer like Java 8

commit f2ab90ea1ee0960d2a87b0feb536c4134841eb82
Author: UEHARA Junji 
Date:   2016-03-08T20:00:44Z

GROOVY-7772: Add test cases.

commit 280a27b6b4715d153e01258670dda5131ebed187
Author: UEHARA Junji 
Date:   2016-03-08T20:28:32Z

GROOVY-7772: Handle too few arguments as missing method exception.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Updated] (GROOVY-4659) GroovyDoc omits closure parameters

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated GROOVY-4659:
--
Summary:  GroovyDoc omits closure parameters  (was: javadoc omits closure 
parameters)

>  GroovyDoc omits closure parameters
> ---
>
> Key: GROOVY-4659
> URL: https://issues.apache.org/jira/browse/GROOVY-4659
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyDoc
>Affects Versions: 1.7.6
> Environment: groovy 1.7.6 (grails 1.3.6)
>Reporter: Patrick Huber
>
> running grails doc does generate the doc but in most closures i actually use 
> typed arguments as in "def closure = { MyOwnClass arg -> ... }" and I'd like 
> groovydoc to automatically link to "MyOwnClass", same as it happens with a 
> plain java method...
> So my current workaround to get a reasonable javadoc out of my code goes like 
> this:
> {code}
> /**
>  * my documentation
>  */
> public void myMethod(SomeClass arg) {}
> def myMethod = { SomeClass arg ->
>   // actual code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (GROOVY-6880) Please add Inline AST Transform

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed GROOVY-6880.
-
Resolution: Won't Fix

Closing this after reading CĂ©drics comment.

> Please add Inline AST Transform
> ---
>
> Key: GROOVY-6880
> URL: https://issues.apache.org/jira/browse/GROOVY-6880
> Project: Groovy
>  Issue Type: Improvement
>  Components: xforms
>Reporter: Suminda Dharmasena
>Priority: Minor
>
> Kotlin has also added inline support. This would be a very useful feature for 
> performance sensitive code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (GROOVY-6136) Possibly memory leak in Eval with PathExpression

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed GROOVY-6136.
-
Resolution: Duplicate

> Possibly memory leak in Eval with PathExpression
> 
>
> Key: GROOVY-6136
> URL: https://issues.apache.org/jira/browse/GROOVY-6136
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-jdk
>Affects Versions: 2.0.7, 2.1.3
> Environment: JDK 1.6, JDK 1.7 with JVM Option: 
> -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled  
> -XX:+TraceClassUnloading  -XX:+TraceClassLoading
>Reporter: Donghun Lee
> Attachments: EvalTest.zip
>
>
> Possibly PermGen memory leak in eval.
> It loads Script class every execution of eval but never unloads and triggers 
> "java.lang.OutOfMemoryError: PermGen space" error.
> I performed GC manually by JVisualVM among the time but no effect on PermGen 
> space (works well on Heap).
> Here are the ClassLoading/Unloading trace log:
> ...
> [Loaded sun.reflect.GeneratedMethodAccessor24 from __JVM_DefineClass__]
> [Loaded sun.reflect.GeneratedMethodAccessor25 from __JVM_DefineClass__]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded sun.reflect.GeneratedMethodAccessor26 from __JVM_DefineClass__]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]
> [Loaded Script1 from file:/groovy/shell]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7768) groovy.sql.Sql callWithAllRows returns blank result when passing params

2016-03-08 Thread John Wagenleitner (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185643#comment-15185643
 ] 

John Wagenleitner commented on GROOVY-7768:
---

I tested with Groovy 2.4.0 and 2.4.6 with the jtds-1.3.1 driver and it worked.  
The user I passed to {{sp_who}} was defined under both Logins for SQLServer and 
Users for the database I connected to.  If you execute the procedure in a SQL 
Query sheet does it return rows?  Can you provide more details on which db and 
driver you're using?

> groovy.sql.Sql callWithAllRows returns blank result when passing params
> ---
>
> Key: GROOVY-7768
> URL: https://issues.apache.org/jira/browse/GROOVY-7768
> Project: Groovy
>  Issue Type: Bug
>  Components: SQL processing
>Affects Versions: 2.4.0
>Reporter: Ryan Mills
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> callWithAllRows works with regular sql, and an empty list.
> call works with a map or list
> Howver, callWithAllRows returns an empty list when using with params eg.)
> List list = new ArrayList();
> l.add("myid");
> sql.callWithAllRows("sp_who ?", list, {}); 
> result is []



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (GROOVY-2330) GString vs String equality in collections

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed GROOVY-2330.
-
Resolution: Fixed

Close after reading Jochens comments.

> GString vs String equality in collections
> -
>
> Key: GROOVY-2330
> URL: https://issues.apache.org/jira/browse/GROOVY-2330
> Project: Groovy
>  Issue Type: Sub-task
>  Components: groovy-runtime
>Affects Versions: 1.1-rc-3
>Reporter: Hans Dockter
>
> GStrings are one of the big groovy features. But there current equals 
> behavior in collections makes them useless for many use cases. Very confusing 
> is also the behavioral difference between lists and other collections.
> All tests fail except the first one. (Tests run against rev 9408)
> {code}
> class StringVersusGStringEqualsInCollections extends GroovyTestCase {
> String string
> GString gString
> void setUp() {
> def g = 'g'
> string = 'groovy'
> gString = "${g}roovy"
> }
> void testEqualsInList() {
> assertEquals([string], [gString])
> }
> void testEqualsInSet() {
> assertEquals([string] as Set, [gString] as Set)
> }
> void testKeyEqualsInMap() {
> String someValue = 'somevalue'
> Map stringMap = [(string): someValue]
> Map gStringMap = [(gString): someValue]
> assertEquals(stringMap, gStringMap)
> }
> void testValueEqualsInMap() {
> String someKey = 'somekey'
> Map stringMap = [(someKey): string]
> Map gStringMap = [(someKey): gString]
> assertEquals(stringMap, gStringMap)
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7469) ClassCastException in groovy 2.3.10. See description section for more information

2016-03-08 Thread Pascal Schumacher (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185597#comment-15185597
 ] 

Pascal Schumacher commented on GROOVY-7469:
---

Sorry for the late reply, but without a self-contained script this is 
impossible to replicate. 

> ClassCastException in groovy 2.3.10. See description section for more 
> information
> -
>
> Key: GROOVY-7469
> URL: https://issues.apache.org/jira/browse/GROOVY-7469
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: Vijaykumar
>  Labels: usertask
>
> Hi Team,
> I'm facing an issue with groovy version 2.3.10. I'm doing the version upgrade 
> from 2.2.2 to 2.3.10.
> The existing code is working in groovy 2.2.2 and the same code throws an 
> exception (ClassCastException) in groovy 2.3.10.
> //FoodItem Class -- start
> Class FoodItem extends Item 
> {
> static Construct builder() {
> new Construct() 
> }
>   static class Construct
>   {
>   Item.Construct build
>   Construct() {
> build = new   Item.Construct() { }
>}
>FoodItem build() {
> new FoodItem (build.map)  // This line throws the classcastexception
> }
> }
> //FoodItem Class -- End
> // Item class -- start
> abstract class Item 
> {
>  protected TreeMap map
> protected Item() {
> this.map = [:]
> }
> protected Item(TreeMap map) {
> this.map = [:]
> if (map != null) {
> this.map = map
> }
> }
> protected Item(Map map) {
> this.map = [:]
> if (map != null) {
> this.map = new TreeMap(map)
> }
> }
> TreeMap getMap() { this.map }
> abstract protected static class Construct {
>  protected TreeMap map
> protected Construct() {
> this.map = [:]
> }
> protected Construct(Item item) {
> this.map = item.map as TreeMap
> }
> }
> // Item class -- End



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GROOVY-7469) ClassCastException in groovy 2.3.10. See description section for more information

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated GROOVY-7469:
--
Labels: usertask  (was: )

> ClassCastException in groovy 2.3.10. See description section for more 
> information
> -
>
> Key: GROOVY-7469
> URL: https://issues.apache.org/jira/browse/GROOVY-7469
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: Vijaykumar
>  Labels: usertask
>
> Hi Team,
> I'm facing an issue with groovy version 2.3.10. I'm doing the version upgrade 
> from 2.2.2 to 2.3.10.
> The existing code is working in groovy 2.2.2 and the same code throws an 
> exception (ClassCastException) in groovy 2.3.10.
> //FoodItem Class -- start
> Class FoodItem extends Item 
> {
> static Construct builder() {
> new Construct() 
> }
>   static class Construct
>   {
>   Item.Construct build
>   Construct() {
> build = new   Item.Construct() { }
>}
>FoodItem build() {
> new FoodItem (build.map)  // This line throws the classcastexception
> }
> }
> //FoodItem Class -- End
> // Item class -- start
> abstract class Item 
> {
>  protected TreeMap map
> protected Item() {
> this.map = [:]
> }
> protected Item(TreeMap map) {
> this.map = [:]
> if (map != null) {
> this.map = map
> }
> }
> protected Item(Map map) {
> this.map = [:]
> if (map != null) {
> this.map = new TreeMap(map)
> }
> }
> TreeMap getMap() { this.map }
> abstract protected static class Construct {
>  protected TreeMap map
> protected Construct() {
> this.map = [:]
> }
> protected Construct(Item item) {
> this.map = item.map as TreeMap
> }
> }
> // Item class -- End



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (GROOVY-7481) Update to Groovy 2.4.3 breaks existing code

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed GROOVY-7481.
-
Resolution: Not A Bug

I'm closing this after reading Pauls comment.

> Update to Groovy 2.4.3 breaks existing code
> ---
>
> Key: GROOVY-7481
> URL: https://issues.apache.org/jira/browse/GROOVY-7481
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.3
>Reporter: Alexander Veit
>
> After update to Groovy 2.4.3 coll.addAll() fails for null values.
> groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> our.package.OurCollection#addAll.
> Cannot resolve which method to invoke for [null] due to overlapping 
> prototypes between:
>   [interface java.util.Collection]
>   [interface java.lang.Iterable]
>   [interface java.util.Iterator]
>   at 
> groovy.lang.MetaClassImpl.chooseMostSpecificParams(MetaClassImpl.java:3238)
>   at 
> groovy.lang.MetaClassImpl.chooseMethodInternal(MetaClassImpl.java:3191)
>   at groovy.lang.MetaClassImpl.chooseMethod(MetaClassImpl.java:3134)
>   at 
> groovy.lang.MetaClassImpl.getMethodWithCachingInternal(MetaClassImpl.java:1325)
>   at groovy.lang.MetaClassImpl.createPojoCallSite(MetaClassImpl.java:3367)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite(CallSiteArray.java:129)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:163)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:122)
>   at test.run(test.groovy:62)
>   at groovy.lang.GroovyShell.evaluate(GroovyShell.java:589)
>   at groovy.lang.GroovyShell.evaluate(GroovyShell.java:636)
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GROOVY-7661) Option to consume BOM if present

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated GROOVY-7661:
--
Assignee: (was: Keegan Witt)

> Option to consume BOM if present
> 
>
> Key: GROOVY-7661
> URL: https://issues.apache.org/jira/browse/GROOVY-7661
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Keegan Witt
>
> Add an argument to IOGroovyMethods and NIOGroovyMethods to consume the BOM if 
> present, similar to Common IO's  
> [BOMInputStream|https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/input/BOMInputStream.html].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (GROOVY-7725) compatibility issue of class groovy.lang.IntRange

2016-03-08 Thread Pascal Schumacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed GROOVY-7725.
-
Resolution: Not A Bug

I'm closing this after reading [~paulk]s comment.

> compatibility issue of class groovy.lang.IntRange
> -
>
> Key: GROOVY-7725
> URL: https://issues.apache.org/jira/browse/GROOVY-7725
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime, GroovyScriptEngine
>Affects Versions: 2.4.5
>Reporter: ZENG Jipeng
>
> Hi,
> We are using the class groovy.lang.IntRange in our code to get the sub 
> string, everything is working fine. Recently, we upgrade the groovy version 
> from 1.7.8 to 2.4.5, but the the code is no more working with an error 
> message "java.lang.IllegalStateException: Should not call subListBorders on a 
> non-inclusive aware IntRange". Here are the sample codes,
> {quote}
> def name = "this is a test";
> IntRange range = new IntRange(5,6);
> return name.getAt(range);
> {quote}
> In the version 1.7.8, it can successfully return "is".
> I read the groovy api document and found the constructor of IntRange seems 
> have some changes, so I change the code,
> {quote}
> def name = "this is a test";
> IntRange range = new IntRange(*true*,5,6);
> return name.getAt(range);
> {quote}
> And it can work well again in the version 2.4.5.
> So, this looks like a compatibility issue to me, is this a known issue? Is 
> there anyway to solve this without modify the source code? Thanks.
> BR,
> Jipeng



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] groovy pull request:

2016-03-08 Thread blackdrag
Github user blackdrag commented on the pull request:


https://github.com/apache/groovy/commit/a0aed6c6e523d176ebd480075d54aa9a3e19b472#commitcomment-16558458
  
In src/main/org/codehaus/groovy/ast/PropertyNode.java:
In src/main/org/codehaus/groovy/ast/PropertyNode.java on line 125:
FieldNode implements Variable, which defines
boolean isClosureSharedVariable();
void setClosureSharedVariable(boolean inClosure);
So... yes... it is unused.. Not sure Depretaed makes sense for a method 
from an interface, without making that interface method deprecated... only that 
the interface method is used


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---