[jira] [Commented] (GROOVY-8543) Support setting compileStatic by default via system properties
[ https://issues.apache.org/jira/browse/GROOVY-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438689#comment-16438689 ] Jochen Theodorou commented on GROOVY-8543: -- [~daniel_sun] what you need for your phoenix plan is not the groovy static compiler, so "groovy.compile.static.by.default" is the wrong property for this. What you need is a java compilation mode. It will differ in method selection and flow typing, and maybe a few other small things. They can share a lot of the code, especially for generics, but it is a second static compiler. > Support setting compileStatic by default via system properties > -- > > Key: GROOVY-8543 > URL: https://issues.apache.org/jira/browse/GROOVY-8543 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-2, 2.6.0-alpha-4 > > > Enable compile static by default via `-Dgroovy.compile.static=true` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8543) Support setting compileStatic by default via system properties
[ https://issues.apache.org/jira/browse/GROOVY-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438775#comment-16438775 ] Daniel Sun commented on GROOVY-8543: We can refine the current static compiler to make it compatible with Java compilation mode ;-) P.S. I wonder why does the current static compiler not use Java compilation(method selection, type flowing, etc.) at the beginning? > Support setting compileStatic by default via system properties > -- > > Key: GROOVY-8543 > URL: https://issues.apache.org/jira/browse/GROOVY-8543 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-2, 2.6.0-alpha-4 > > > Enable compile static by default via `-Dgroovy.compile.static=true` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8543) Support setting compileStatic by default via system properties
[ https://issues.apache.org/jira/browse/GROOVY-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438802#comment-16438802 ] Jochen Theodorou commented on GROOVY-8543: -- why does the current static compiler not use Java compilation(method selection, type flowing, etc.) at the beginning? The generics problem surely was underestimated, but if you think about it... the static compiler started by compiling more and more Groovy constructs static, with the goal to have the semantics as near to the dynamic mode as it makes sense and if technically feasible. Why should you then first let it compile to semantics that are neither the targeted static compilation mode, nor the original dynamic mode and not declare it as a bug on top of it? > Support setting compileStatic by default via system properties > -- > > Key: GROOVY-8543 > URL: https://issues.apache.org/jira/browse/GROOVY-8543 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-2, 2.6.0-alpha-4 > > > Enable compile static by default via `-Dgroovy.compile.static=true` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8545) DGM#intersect(Iterable) throws ClassCastException if Iterable larger than Set
Paul King created GROOVY-8545: - Summary: DGM#intersect(Iterable) throws ClassCastException if Iterable larger than Set Key: GROOVY-8545 URL: https://issues.apache.org/jira/browse/GROOVY-8545 Project: Groovy Issue Type: Bug Reporter: Paul King -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8545) DGM#intersect(Iterable) throws ClassCastException if Iterable larger than Set
[ https://issues.apache.org/jira/browse/GROOVY-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8545: -- Description: see https://github.com/apache/groovy/pull/645 > DGM#intersect(Iterable) throws ClassCastException if Iterable larger than Set > - > > Key: GROOVY-8545 > URL: https://issues.apache.org/jira/browse/GROOVY-8545 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Priority: Major > > see https://github.com/apache/groovy/pull/645 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
Eric Milles created GROOVY-8546:
---
Summary: Parrot Parser: multiple Reader instances opened from
SourceUnit; many left open
Key: GROOVY-8546
URL: https://issues.apache.org/jira/browse/GROOVY-8546
Project: Groovy
Issue Type: Improvement
Components: parser
Reporter: Eric Milles
{{Antlr4ParserPlugin}} makes very inefficient use of
{{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with the
idea that it is the source of source character data and is closed from outside.
It ignores this and mines the passed {{SourceUnit}}, which seems unnecessary
since the same reference is passed again in {{buildAST}}. Both {{parseCST}}
and {{buildAST}} call {{getReader}}, which opens a buffered reader on the
source unit file and never closes them. Lastly, {{AstBuilder}} calls
{{getReader}} as well to create a {{CharStream}} and never closes this reader.
Doing this in a long-running process (like an IDE) is causing numerous problems
due to open file handles.
{code:java}
public class Antlr4ParserPlugin implements ParserPlugin {
private ReaderSource readerSource;
@Override
public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
throws CompilationFailedException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null != readerSource && null != readerSource.getReader()) {
this.readerSource = readerSource;
} else {
this.readerSource = new
StringReaderSource(IOGroovyMethods.getText(reader),
sourceUnit.getConfiguration());
}
} catch (IOException e) {
throw new GroovyBugError("Failed to create StringReaderSource
instance", e);
}
return null;
}
@Override
public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader classLoader,
Reduction cst) throws ParserException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null == readerSource || null == readerSource.getReader()) {
sourceUnit.setSource(this.readerSource);
}
} catch (IOException e) {
sourceUnit.setSource(this.readerSource);
}
AstBuilder builder = new AstBuilder(sourceUnit);
return builder.buildAST();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8546:
Issue Type: Bug (was: Improvement)
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines the passed {{SourceUnit}}, which
> seems unnecessary since the same reference is passed again in {{buildAST}}.
> Both {{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered
> reader on the source unit file and never closes them. Lastly, {{AstBuilder}}
> calls {{getReader}} as well to create a {{CharStream}} and never closes this
> reader.
> Doing this in a long-running process (like an IDE) is causing numerous
> problems due to open file handles.
> {code:java}
> public class Antlr4ParserPlugin implements ParserPlugin {
> private ReaderSource readerSource;
> @Override
> public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
> throws CompilationFailedException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null != readerSource && null != readerSource.getReader()) {
> this.readerSource = readerSource;
> } else {
> this.readerSource = new
> StringReaderSource(IOGroovyMethods.getText(reader),
> sourceUnit.getConfiguration());
> }
> } catch (IOException e) {
> throw new GroovyBugError("Failed to create StringReaderSource
> instance", e);
> }
> return null;
> }
> @Override
> public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader
> classLoader, Reduction cst) throws ParserException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null == readerSource || null == readerSource.getReader()) {
> sourceUnit.setSource(this.readerSource);
> }
> } catch (IOException e) {
> sourceUnit.setSource(this.readerSource);
> }
> AstBuilder builder = new AstBuilder(sourceUnit);
> return builder.buildAST();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8546:
Affects Version/s: 2.6.0-alpha-3
3.0.0-alpha-2
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Improvement
> Components: parser
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines the passed {{SourceUnit}}, which
> seems unnecessary since the same reference is passed again in {{buildAST}}.
> Both {{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered
> reader on the source unit file and never closes them. Lastly, {{AstBuilder}}
> calls {{getReader}} as well to create a {{CharStream}} and never closes this
> reader.
> Doing this in a long-running process (like an IDE) is causing numerous
> problems due to open file handles.
> {code:java}
> public class Antlr4ParserPlugin implements ParserPlugin {
> private ReaderSource readerSource;
> @Override
> public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
> throws CompilationFailedException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null != readerSource && null != readerSource.getReader()) {
> this.readerSource = readerSource;
> } else {
> this.readerSource = new
> StringReaderSource(IOGroovyMethods.getText(reader),
> sourceUnit.getConfiguration());
> }
> } catch (IOException e) {
> throw new GroovyBugError("Failed to create StringReaderSource
> instance", e);
> }
> return null;
> }
> @Override
> public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader
> classLoader, Reduction cst) throws ParserException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null == readerSource || null == readerSource.getReader()) {
> sourceUnit.setSource(this.readerSource);
> }
> } catch (IOException e) {
> sourceUnit.setSource(this.readerSource);
> }
> AstBuilder builder = new AstBuilder(sourceUnit);
> return builder.buildAST();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438915#comment-16438915
]
Daniel Sun commented on GROOVY-8546:
{{CharStream}} of antlr4 is not a IO stream, so we need not close it.
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines the passed {{SourceUnit}}, which
> seems unnecessary since the same reference is passed again in {{buildAST}}.
> Both {{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered
> reader on the source unit file and never closes them. Lastly, {{AstBuilder}}
> calls {{getReader}} as well to create a {{CharStream}} and never closes this
> reader.
> Doing this in a long-running process (like an IDE) is causing numerous
> problems due to open file handles.
> {code:java}
> public class Antlr4ParserPlugin implements ParserPlugin {
> private ReaderSource readerSource;
> @Override
> public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
> throws CompilationFailedException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null != readerSource && null != readerSource.getReader()) {
> this.readerSource = readerSource;
> } else {
> this.readerSource = new
> StringReaderSource(IOGroovyMethods.getText(reader),
> sourceUnit.getConfiguration());
> }
> } catch (IOException e) {
> throw new GroovyBugError("Failed to create StringReaderSource
> instance", e);
> }
> return null;
> }
> @Override
> public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader
> classLoader, Reduction cst) throws ParserException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null == readerSource || null == readerSource.getReader()) {
> sourceUnit.setSource(this.readerSource);
> }
> } catch (IOException e) {
> sourceUnit.setSource(this.readerSource);
> }
> AstBuilder builder = new AstBuilder(sourceUnit);
> return builder.buildAST();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438916#comment-16438916
]
Daniel Sun commented on GROOVY-8546:
{{CharStreams.fromReader}} in the {{AstBuilder.createCharStream}} method will
close the reader held by {{sourceUnit, please see the source code of antlr4}}
{code:java}
private CharStream createCharStream(SourceUnit sourceUnit) {
CharStream charStream;
try {
charStream = CharStreams.fromReader(
new BufferedReader(sourceUnit.getSource().getReader()),
sourceUnit.getName());
} catch (IOException e) {
throw new RuntimeException("Error occurred when reading source
code.", e);
}
return charStream;
}
{code}
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines the passed {{SourceUnit}}, which
> seems unnecessary since the same reference is passed again in {{buildAST}}.
> Both {{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered
> reader on the source unit file and never closes them. Lastly, {{AstBuilder}}
> calls {{getReader}} as well to create a {{CharStream}} and never closes this
> reader.
> Doing this in a long-running process (like an IDE) is causing numerous
> problems due to open file handles.
> {code:java}
> public class Antlr4ParserPlugin implements ParserPlugin {
> private ReaderSource readerSource;
> @Override
> public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
> throws CompilationFailedException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null != readerSource && null != readerSource.getReader()) {
> this.readerSource = readerSource;
> } else {
> this.readerSource = new
> StringReaderSource(IOGroovyMethods.getText(reader),
> sourceUnit.getConfiguration());
> }
> } catch (IOException e) {
> throw new GroovyBugError("Failed to create StringReaderSource
> instance", e);
> }
> return null;
> }
> @Override
> public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader
> classLoader, Reduction cst) throws ParserException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null == readerSource || null == readerSource.getReader()) {
> sourceUnit.setSource(this.readerSource);
> }
> } catch (IOException e) {
> sourceUnit.setSource(this.readerSource);
> }
> AstBuilder builder = new AstBuilder(sourceUnit);
> return builder.buildAST();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8545) DGM#intersect(Set, Iterable) throws ClassCastException if Iterable larger than Set
[ https://issues.apache.org/jira/browse/GROOVY-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8545: -- Summary: DGM#intersect(Set, Iterable) throws ClassCastException if Iterable larger than Set (was: DGM#intersect(Iterable) throws ClassCastException if Iterable larger than Set) > DGM#intersect(Set, Iterable) throws ClassCastException if Iterable larger > than Set > -- > > Key: GROOVY-8545 > URL: https://issues.apache.org/jira/browse/GROOVY-8545 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Priority: Major > > see https://github.com/apache/groovy/pull/645 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8546:
Description:
{{Antlr4ParserPlugin}} makes very inefficient use of
{{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with the
idea that it is the source of character data -- and this reader is closed from
outside. It ignores this and mines the passed {{SourceUnit}}, which seems
unnecessary since the same reference is passed again in {{buildAST}}. Both
{{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered reader
on the source unit file and never closes them. Lastly, {{AstBuilder}} calls
{{getReader}} as well to create a {{CharStream}} and never closes this reader.
Doing this in a long-running process (like an IDE) is causing numerous problems
due to open file handles.
{code:java}
public class Antlr4ParserPlugin implements ParserPlugin {
private ReaderSource readerSource;
@Override
public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
throws CompilationFailedException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null != readerSource && null != readerSource.getReader()) {
this.readerSource = readerSource;
} else {
this.readerSource = new
StringReaderSource(IOGroovyMethods.getText(reader),
sourceUnit.getConfiguration());
}
} catch (IOException e) {
throw new GroovyBugError("Failed to create StringReaderSource
instance", e);
}
return null;
}
@Override
public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader classLoader,
Reduction cst) throws ParserException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null == readerSource || null == readerSource.getReader()) {
sourceUnit.setSource(this.readerSource);
}
} catch (IOException e) {
sourceUnit.setSource(this.readerSource);
}
AstBuilder builder = new AstBuilder(sourceUnit);
return builder.buildAST();
}
}
{code}
was:
{{Antlr4ParserPlugin}} makes very inefficient use of
{{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with the
idea that it is the source of source character data and is closed from outside.
It ignores this and mines the passed {{SourceUnit}}, which seems unnecessary
since the same reference is passed again in {{buildAST}}. Both {{parseCST}}
and {{buildAST}} call {{getReader}}, which opens a buffered reader on the
source unit file and never closes them. Lastly, {{AstBuilder}} calls
{{getReader}} as well to create a {{CharStream}} and never closes this reader.
Doing this in a long-running process (like an IDE) is causing numerous problems
due to open file handles.
{code:java}
public class Antlr4ParserPlugin implements ParserPlugin {
private ReaderSource readerSource;
@Override
public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
throws CompilationFailedException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null != readerSource && null != readerSource.getReader()) {
this.readerSource = readerSource;
} else {
this.readerSource = new
StringReaderSource(IOGroovyMethods.getText(reader),
sourceUnit.getConfiguration());
}
} catch (IOException e) {
throw new GroovyBugError("Failed to create StringReaderSource
instance", e);
}
return null;
}
@Override
public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader classLoader,
Reduction cst) throws ParserException {
try {
ReaderSource readerSource = sourceUnit.getSource();
if (null == readerSource || null == readerSource.getReader()) {
sourceUnit.setSource(this.readerSource);
}
} catch (IOException e) {
sourceUnit.setSource(this.readerSource);
}
AstBuilder builder = new AstBuilder(sourceUnit);
return builder.buildAST();
}
}
{code}
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Improvement
> Components: parser
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines
[jira] [Created] (GROOVY-8547) Factory pattern side-stepped by CompilerConfiguration/ParserVersion
Eric Milles created GROOVY-8547:
---
Summary: Factory pattern side-stepped by
CompilerConfiguration/ParserVersion
Key: GROOVY-8547
URL: https://issues.apache.org/jira/browse/GROOVY-8547
Project: Groovy
Issue Type: Improvement
Reporter: Eric Milles
It seems to me the selection of the Antlr2 or Antlr4 parser could be
implemented within a default implementation of {{ParserPluginFactory}} instead
of introducing {{ParserVersion}} with separate get/set on
{{CompilerConfiguration}}. I don't see the need for static factory methods
{{antlr2()}} and {{antlr4()}} on {{ParserPluginFactory}}, their use from
{{CompilerConfiguration}} and the strange class loading in
{{ParserPluginFactory}}.
The factory pattern appears to me to be side-stepped in favor of a version
constant. Is there still meaning is offering a config option of setting a
{{ParserPluginFactory}}? Has this been used ever in the past?
Couldn't this suffice for a default in {{CompilerConfiguration}}? Then
{{ParserVersion}} could be dropped.
{code:java}
public ParserPluginFactory getPluginFactory() {
if (pluginFactory == null) {
pluginFactory = new ParserPluginFactory() {
@Override
public ParserPlugin createParserPlugin() {
return Boolean.getBoolean(GROOVY_ANTLR4_OPT) ? new
Antlr4PluginFactory() : new AntlrParserPluginFactory();
}
}
}
return pluginFactory;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8543) Support setting compileStatic by default via system properties
[ https://issues.apache.org/jira/browse/GROOVY-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438993#comment-16438993 ] Paul King commented on GROOVY-8543: --- Yes, I think a "compile static by default" switch is a useful feature if we implement correctly but it isn't the same as a Java mode switch. Mind you, there will be large slabs of Java code that might behave exactly the same - just not all code and that is intentional. > Support setting compileStatic by default via system properties > -- > > Key: GROOVY-8543 > URL: https://issues.apache.org/jira/browse/GROOVY-8543 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-2, 2.6.0-alpha-4 > > > Enable compile static by default via `-Dgroovy.compile.static=true` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8548) DGM#intersect should provide a variant with a comparator
[ https://issues.apache.org/jira/browse/GROOVY-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8548. --- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.5.0-rc-2 DGM methods added. > DGM#intersect should provide a variant with a comparator > > > Key: GROOVY-8548 > URL: https://issues.apache.org/jira/browse/GROOVY-8548 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.5.0-rc-2 > > > There is a performance penalty using NumberAwareComparator when that feature > is not required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8545) DGM#intersect(Set, Iterable) throws ClassCastException if Iterable larger than Set
[ https://issues.apache.org/jira/browse/GROOVY-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8545. --- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.5.0-rc-2 Proposed fix merged - thanks! > DGM#intersect(Set, Iterable) throws ClassCastException if Iterable larger > than Set > -- > > Key: GROOVY-8545 > URL: https://issues.apache.org/jira/browse/GROOVY-8545 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.5.0-rc-2 > > > see https://github.com/apache/groovy/pull/645 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-7464) Iterable.intersect() is not commutative (and allows duplicates)
[
https://issues.apache.org/jira/browse/GROOVY-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7464.
-
> Iterable.intersect() is not commutative (and allows duplicates)
> ---
>
> Key: GROOVY-7464
> URL: https://issues.apache.org/jira/browse/GROOVY-7464
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.3
>Reporter: Peter Ledbrook
>Assignee: Paul King
>Priority: Major
>
> The {{intersect()}} method on {{Iterable}} has different results depending on
> the order of the receiver object and the argument. For example,
> {code}
> def a = [1, 1, 2, 4]
> def b = [1, 2, 2, 3]
> println a.intersect(b)
> println b.intersect(a)
> {code}
> prints out two different results ({{[1, 1, 2]}} and {{[1, 2, 2]}}).
> Assuming that the operation should be commutative, i.e. the results should be
> the same for both, the question then becomes whether duplicates should even
> be returned at all.
> I think the method should always return a set as intersection is a set
> operation. In other words, {{Iterable.intersect()}} becomes a convenience
> wrapper that converts the receiver object and the argument to sets.
> This issue started as a discussion on the [dev mailing
> list|http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/browser].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-7464) Iterable.intersect() is not commutative (and allows duplicates)
[
https://issues.apache.org/jira/browse/GROOVY-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7464.
---
Resolution: Won't Fix
Assignee: Paul King
I am going to close this. There is now a Set-based version of intersect and the
argument-flipping "optimisation" has been removed which makes the operation
much more understandable.
> Iterable.intersect() is not commutative (and allows duplicates)
> ---
>
> Key: GROOVY-7464
> URL: https://issues.apache.org/jira/browse/GROOVY-7464
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.3
>Reporter: Peter Ledbrook
>Assignee: Paul King
>Priority: Major
>
> The {{intersect()}} method on {{Iterable}} has different results depending on
> the order of the receiver object and the argument. For example,
> {code}
> def a = [1, 1, 2, 4]
> def b = [1, 2, 2, 3]
> println a.intersect(b)
> println b.intersect(a)
> {code}
> prints out two different results ({{[1, 1, 2]}} and {{[1, 2, 2]}}).
> Assuming that the operation should be commutative, i.e. the results should be
> the same for both, the question then becomes whether duplicates should even
> be returned at all.
> I think the method should always return a set as intersection is a set
> operation. In other words, {{Iterable.intersect()}} becomes a convenience
> wrapper that converts the receiver object and the argument to sets.
> This issue started as a discussion on the [dev mailing
> list|http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/browser].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-6523) Improve Documentation for in DefaultGroovyMethods.intersect(..)
[ https://issues.apache.org/jira/browse/GROOVY-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-6523. --- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.5.0-rc-2 This has been improved somewhat with GROOVY-8548. Please open a new issue or PR if you think further improvements are required. > Improve Documentation for in DefaultGroovyMethods.intersect(..) > > > Key: GROOVY-6523 > URL: https://issues.apache.org/jira/browse/GROOVY-6523 > Project: Groovy > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.0 >Reporter: Alex Beardsley >Assignee: Paul King >Priority: Minor > Fix For: 2.5.0-rc-2 > > > As noted in GROOVY-1986, the current version of this method is slow compared > to Java's existing retainAll method for Sets, on the order of 4000% in test > cases with a significant amount of data and intersections. The performance > can't be improved due to limitations in the Java API. > This should be documented, as we would have never chosen intersect(..) if we > were aware of the performance implications vs. convenience it provides. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GROOVY-8544) The new parser Parrot does not support enum constants end with semicolon
[
https://issues.apache.org/jira/browse/GROOVY-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reopened GROOVY-8544:
> The new parser Parrot does not support enum constants end with semicolon
>
>
> Key: GROOVY-8544
> URL: https://issues.apache.org/jira/browse/GROOVY-8544
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3
>
>
> Currently Parrot supports the following code:
> {code:java}
> enum {
> A, B
> }
> {code}
> but does not support:
> {code:java}
> enum {
> A, B;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8548) DGM#intersect should provide a variant with a comparator
Paul King created GROOVY-8548: - Summary: DGM#intersect should provide a variant with a comparator Key: GROOVY-8548 URL: https://issues.apache.org/jira/browse/GROOVY-8548 Project: Groovy Issue Type: Improvement Reporter: Paul King There is a performance penalty using NumberAwareComparator when that feature is not required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8546) Parrot Parser: multiple Reader instances opened from SourceUnit; many left open
[
https://issues.apache.org/jira/browse/GROOVY-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-8546.
Resolution: Not A Problem
> Parrot Parser: multiple Reader instances opened from SourceUnit; many left
> open
> ---
>
> Key: GROOVY-8546
> URL: https://issues.apache.org/jira/browse/GROOVY-8546
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> {{Antlr4ParserPlugin}} makes very inefficient use of
> {{ReaderSource}}/{{SourceUnit}}. {{parseCST}} is passed a {{Reader}} with
> the idea that it is the source of character data -- and this reader is closed
> from outside. It ignores this and mines the passed {{SourceUnit}}, which
> seems unnecessary since the same reference is passed again in {{buildAST}}.
> Both {{parseCST}} and {{buildAST}} call {{getReader}}, which opens a buffered
> reader on the source unit file and never closes them. Lastly, {{AstBuilder}}
> calls {{getReader}} as well to create a {{CharStream}} and never closes this
> reader.
> Doing this in a long-running process (like an IDE) is causing numerous
> problems due to open file handles.
> {code:java}
> public class Antlr4ParserPlugin implements ParserPlugin {
> private ReaderSource readerSource;
> @Override
> public Reduction parseCST(SourceUnit sourceUnit, java.io.Reader reader)
> throws CompilationFailedException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null != readerSource && null != readerSource.getReader()) {
> this.readerSource = readerSource;
> } else {
> this.readerSource = new
> StringReaderSource(IOGroovyMethods.getText(reader),
> sourceUnit.getConfiguration());
> }
> } catch (IOException e) {
> throw new GroovyBugError("Failed to create StringReaderSource
> instance", e);
> }
> return null;
> }
> @Override
> public ModuleNode buildAST(SourceUnit sourceUnit, ClassLoader
> classLoader, Reduction cst) throws ParserException {
> try {
> ReaderSource readerSource = sourceUnit.getSource();
> if (null == readerSource || null == readerSource.getReader()) {
> sourceUnit.setSource(this.readerSource);
> }
> } catch (IOException e) {
> sourceUnit.setSource(this.readerSource);
> }
> AstBuilder builder = new AstBuilder(sourceUnit);
> return builder.buildAST();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8544) The new parser Parrot does not support enum constants end with semicolon
[
https://issues.apache.org/jira/browse/GROOVY-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun closed GROOVY-8544.
--
Resolution: Not A Problem
Fix Version/s: (was: 3.0.0-alpha-3)
(was: 2.6.0-alpha-4)
The issue does not exist, but the current implementation is a bit tricky. I've
refined it.
> The new parser Parrot does not support enum constants end with semicolon
>
>
> Key: GROOVY-8544
> URL: https://issues.apache.org/jira/browse/GROOVY-8544
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Minor
>
> Currently Parrot supports the following code:
> {code:java}
> enum {
> A, B
> }
> {code}
> but does not support:
> {code:java}
> enum {
> A, B;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8544) The new parser Parrot does not support enum constants end with semicolon
[
https://issues.apache.org/jira/browse/GROOVY-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-8544:
---
Affects Version/s: (was: 3.0.0-alpha-2)
(was: 2.6.0-alpha-3)
> The new parser Parrot does not support enum constants end with semicolon
>
>
> Key: GROOVY-8544
> URL: https://issues.apache.org/jira/browse/GROOVY-8544
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3
>
>
> Currently Parrot supports the following code:
> {code:java}
> enum {
> A, B
> }
> {code}
> but does not support:
> {code:java}
> enum {
> A, B;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #645: DefaultGroovyMethods bug fix: Set.intersect(Iterab...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/645 ---
