[jira] [Commented] (GROOVY-7661) Option to consume BOM if present
[ https://issues.apache.org/jira/browse/GROOVY-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880171#comment-16880171 ] Paul King commented on GROOVY-7661: --- To clarify, we already automatically consume the BOM if present for source files read by the compiler and in some DGM methods but this request is to allow full control, e..g perhaps you want to read in the BOM bytes? And if inconsistencies are found to make things consistent? One difference I see is that consuming the bytes only succeeds if the correct BOM is found, so having auto-consumption turned on by default seems less concerning. > 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 >Priority: Major > > 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 (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880229#comment-16880229
]
Remko Popma edited comment on GROOVY-9165 at 7/8/19 11:29 AM:
--
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an creating a new internal
CliBuilder. Some of the tools have been localized but picocli can do
internationalization. I can help with the changes but I want to work on
releasing picocli 4.0 first. After that I'd be happy to help migrate the 6
classes that currently use the new internal CliBuilder to plain picocli on both
master and the 2.5 branch.
was (Author: rem...@yahoo.com):
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an internal CliBuilder.
Some of the tools have been localized but picocli can do internationalization.
I can help with the changes but I want to work on releasing picocli 4.0 first.
After that I'd be happy to help migrate the 6 classes that currently use the
new internal CliBuilder to plain picocli on both master and the 2.5 branch.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9165) Grape cannot pull in picocli
[
https://issues.apache.org/jira/browse/GROOVY-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880229#comment-16880229
]
Remko Popma commented on GROOVY-9165:
-
I've had a chance to take a look at the changes.
I think we should just use plain picocli instead of an internal CliBuilder.
Some of the tools have been localized but picocli can do internationalization.
I can help with the changes but I want to work on releasing picocli 4.0 first.
After that I'd be happy to help migrate the 6 classes that currently use the
new internal CliBuilder to plain picocli on both master and the 2.5 branch.
> Grape cannot pull in picocli
>
>
> Key: GROOVY-9165
> URL: https://issues.apache.org/jira/browse/GROOVY-9165
> Project: Groovy
> Issue Type: Improvement
> Components: Grape, groovy-runtime
>Affects Versions: 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-beta-2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I try to run a Groovy script I am unable to pull in a newer version of
> picocli via {{@Grab}}:
> {code:groovy}
> @Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')
> @GrabExclude('org.codehaus.groovy:groovy-all')
> @picocli.groovy.PicocliScript
> @picocli.CommandLine.Command
> import picocli.CommandLine
> println "Groovy version ${GroovySystem.version}"
> println "Picocli version $CommandLine.VERSION"
> {code}
> Depending on the Groovy version, this prints
> {code}
> Groovy version 2.5.0
> Picocli version 3.0.2
> {code}
> or
> {code}
> Groovy version 2.5.7
> Picocli version 3.9.5
> {code}
> So the {{@Grab('info.picocli:picocli-groovy:4.0.0-beta-1b')}} is not honoured.
> This is because the {{groovy.ui.GroovyMain}} class, which executes Groovy
> scripts, itself uses picocli to parse the command line parameters.
> Unfortunately, this means that Groovy script authors cannot control the
> picocli version used by their scripts.
> Is there anything we can do to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [groovy] eric-milles commented on issue #963: GROOVY-9168: emit more specific error for use of uninitialized this
eric-milles commented on issue #963: GROOVY-9168: emit more specific error for
use of uninitialized this
URL: https://github.com/apache/groovy/pull/963#issuecomment-509392526
There is a redundant check in `Verifier.visitConstructor` (included below).
Is this the better place to do checking for uninitiualized this/super
references -- instead of in `StaticVerifier`? I think `Verifier` runs later
and could catch references added by the compiler.
```java
@Override
public void visitConstructor(ConstructorNode node) {
GroovyCodeVisitor checkSuper = new CodeVisitorSupport() {
boolean firstMethodCall = true;
String type = null;
@Override
public void visitMethodCallExpression(MethodCallExpression call)
{
if (!firstMethodCall) return;
firstMethodCall = false;
String name = call.getMethodAsString();
// the name might be null if the method name is a GString
for example
if (name == null) return;
if (!name.equals("super") && !name.equals("this")) return;
type = name;
call.getArguments().visit(this);
type = null;
}
@Override
public void
visitConstructorCallExpression(ConstructorCallExpression call) {
if (!call.isSpecialCall()) return;
type = call.getText();
call.getArguments().visit(this);
type = null;
}
@Override
public void visitVariableExpression(VariableExpression
expression) {
if (type == null) return;
String name = expression.getName();
if (!name.equals("this") && !name.equals("super")) return;
throw new RuntimeParserException("cannot reference " + name
+ " inside of " + type + "() before supertype constructor has been called",
expression);
}
};
Statement s = node.getCode();
if (s == null) {
return;
} else {
s.visit(new VerifierCodeVisitor(this));
}
s.visit(checkSuper);
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (GROOVY-9159) [GEP] Support LINQ, aka GINQ
[
https://issues.apache.org/jira/browse/GROOVY-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9159:
---
Description:
h2. *Ⅰ. Background*
In order to make querying different types of data sources convenient, we need a
unified querying interface, i.e. GINQ
h2. *Ⅱ. Solution*
The basic rationale can be shown as follows:
*Groovy User* ==_writes GINQ code_==> *Parrot Parser* ==generates AST==> *GINQ
Engine* ==_translates AST to Stream-Like method invocations_==> *Bytecode
Writer*
h3. {{translates AST to Stream-Like method invocations}} will be designed for
different cases:
h4. 1) target objects are all collections
translates AST to Java 8+ stream method invocations
h4. 2) target objects are all DB related objects
translates AST to *JOOQ* method invocations( [https://github.com/jOOQ/jOOQ] ),
which would be implemented as a {{GINQ provider}} in a seperate
sub-project(e.g. {{groovy-linq-jooq}}). _Note: *JOOQ* is licensed under *APL2*
too_( [https://github.com/jOOQ/jOOQ/blob/master/LICENSE] )
h4. 3) target objects are XML, CSV, etc. related objects, or even mixed types
of objects
We can treate the case as a special sub-case of case 1
h3. *Note:*
{color:#d04437}1. The exact syntax might be altered before introduction,
currently working on the general principle.{color}
2.GINQ will reuse most of standard SQL syntax, which can make the learning
curve smooth and avoid infringing the patent of Microsoft.
3. All GINQ related keywords are uppercase to avoid breaking existing source
code as possible as we can, e.g. {{FROM}}, {{WHERE}}, {{SELECT}}, etc.
4. In order to support type inference better, {{SELECT}} clause is placed at
the end of GINQ expression.
5. {{alias.VALUE}} is a virtual property and is used to reference the whole
record as value. It can be simplified as {{alias}}.
6. {{SELECT P1, P2 ... Pn}} is a simplifed syntax of {{SELECT Tuple.tuple(P1,
P2 ... Pn)}} and will create a {{List}} of {{Tuple}} sub-class instances when
and only when {{n >= 2}}
h2. *Ⅲ. EBNF*
h3. TBD
h2. *Ⅳ. Examples*
h3. 1. Filtering
{code:java}
@groovy.transform.EqualsAndHashCode
class Person {
String name
int age
}
def persons = [new Person(name: 'Daniel', age: 35), new Person(name: 'Peter',
age: 10), new Person(name: 'Alice', age: 22)]
def result =
FROM persons p
WHERE p.age > 15 && p.age <= 35
SELECT p.name
assert ['Daniel', 'Alice'] == result
result =
FROM persons p
WHERE p.age > 15 && p.age <= 35
SELECT p
assert [new Person(name: 'Daniel', age: 35), new Person(name: 'Alice', age:
22)] == result
{code}
{code:java}
def numbers = [1, 2, 3]
def result =
FROM numbers t
WHERE t <= 2
SELECT t
assert [1, 2] == result
{code}
h3. 2. Joining
{code:java}
import static groovy.lang.Tuple.*
@groovy.transform.EqualsAndHashCode
class Person {
String name
int age
City city
}
@groovy.transform.EqualsAndHashCode
class City {
String name
}
def persons = [new Person(name: 'Daniel', age: 35, city: new City('Shanghai')),
new Person(name: 'Peter', age: 10, city: new City('Beijing')), new Person(name:
'Alice', age: 22, city: new City('Hangzhou'))]
def cities = [new City('Shanghai'), new City('Beijing'), new City('Guangzhou')]
// inner join
def result =
FROM persons p INNER JOIN cities c
ON p.city.name == c.name
SELECT p.name
assert ['Daniel', 'Peter'] == result
result =
FROM persons p, cities c
WHERE p.city.name == c.name
SELECT p.name
assert ['Daniel', 'Peter'] == result
result =
FROM persons p, cities c
WHERE p.city == c
SELECT p.name
assert ['Daniel', 'Peter'] == result
// left outer join
result =
FROM persons p LEFT JOIN cities c // same to LEFT OUTER JOIN
ON p.city.name == c.name
SELECT p.name, c.name
assert [tuple('Daniel', 'Shanghai'), tuple('Peter', 'Beijing'), tuple('Alice',
null)] == result
// right outer join
result =
FROM persons p RIGHT JOIN cities c // same to RIGHT OUTER JOIN
ON p.city.name == c.name
SELECT p.name, c.name
assert [tuple('Daniel', 'Shanghai'), tuple('Peter', 'Beijing'), tuple(null,
'Guangzhou')] == result
{code}
h3. 3. Projection
{code:java}
import static groovy.lang.Tuple.*
@groovy.transform.EqualsAndHashCode
class Person {
String name
int age
}
def persons = [new Person(name: 'Daniel', age: 35), new Person(name: 'Peter',
age: 10), new Person(name: 'Alice', age: 22)]
def result =
FROM persons p
SELECT p.name
assert ['Daniel', 'Peter', 'Alice'] == result
result =
FROM persons p
SELECT p.name, p.age
assert [tuple('Daniel', 35), tuple('Peter', 10), tuple('Alice', 22)] == result
result =
FROM persons p
SELECT [name: p.name, age: p.age]
assert [ [name: 'Daniel', age: 35], [name:
