I think we probably have to. It's an integration point that we haven't
really seen a lot of call for in the past but with @CompileStatic becoming
more popular, I can see more use of this style of integration.
Keen to hear if anyone can see an ongoing problem if we remove it. Do we
know of any othe
agreed
Am 12.03.2018 um 13:07 schrieb Paul King:
I think we probably have to. It's an integration point that we haven't
really seen a lot of call for in the past but with @CompileStatic
becoming more popular, I can see more use of this style of integration.
Keen to hear if anyone can see an o
On Mon, 2018-03-12 at 12:23 +1000, Paul King wrote:
> 2.6 is just 3.0 backported to JDK7 (minus those features which don't
> backport easily without a JVM8).
> Most users should be skipping 2.6 and going straight to 3.0 which is
> where
> our focus should be ... soon.
> 2.6 is meant to help people
Calling it 3.0.0-jdk7 would reduce confusion and increase 3.0 adaption
On Mon, Mar 12, 2018 at 12:04 PM Russel Winder wrote:
> On Mon, 2018-03-12 at 12:23 +1000, Paul King wrote:
> > 2.6 is just 3.0 backported to JDK7 (minus those features which don't
> > backport easily without a JVM8).
> > Mos
I don't think calling it 3.0-jdk7 is a good thing to do: the runtime would
be different, with different bugs. Plus, it would add confusion on some
build tools, with random dependencies on jdk7, or indy, or ...
I think we should focus on getting 2.5 out, and then go with 3.0 asap.
2018-03-12 17:58
On Mon, 2018-03-12 at 18:02 +0100, Cédric Champeau wrote:
> I don't think calling it 3.0-jdk7 is a good thing to do: the runtime
> would
> be different, with different bugs. Plus, it would add confusion on
> some
> build tools, with random dependencies on jdk7, or indy, or ...
>
> I think we shoul
I just gave the Parrot Parser a quick try out for Groovy 2.6 / Eclipse 4.8.
One thing I'm noticing right away is that the parser sets the line and column
information of AST nodes, but leaves position properties start, end, nameStart
and nameEnd unset. Is there a way to request these properties
Hi Jochen,
there are definitely cases, which would suffice for my application and
where the return type could be deduced also in the dynamic case -
especially if you use final vars and parameters like I do ;-)
IntelliJ's Intellisense is proof of that - just press Ctrl+B at the
method call site
PS: Just wanted to ask what you think about the idea of making var a
compile time error in dynamic Groovy, with an error message (see
previous posting) that points the developer to @CompileStatic ?
My line of thinking is, that
# var makes no sense in dynamic Groovy in the case of var === def (in
Hi Eric,
Parrot will set node position of `ASTNode`, i.e. `lineNumber`,
`columnNumber`, `lastLineNumber`, `lastColumnNumber`. As for `start`, `end`,
`nameStart` and `nameEnd`, I can not find them in the Apache Groovy
project. Can you tell me which class contains them?
Cheers,
Daniel.Sun
-
Done:
https://github.com/apache/groovy/commit/7afe48587e9c7919b0de021c7dd84a7b54f0fe6c
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reverted:
https://github.com/apache/groovy/commit/8754145385577dff72db48a78c7de2eb027232a1
Many errors occurred after commit 7afe485:
https://travis-ci.org/apache/groovy/jobs/352622463
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
12 matches
Mail list logo
