You're comparing `class java.lang.String` and `class java.lang.Class`.
Which rule in the docs leads you to expect this to be truthy?
On Sun, Jun 30, 2024, 13:17 o...@ocs.cz wrote:
> Hi there,
>
> is this the intended behaviour?
>
> ===
> groovy:000> switch (String) { case Class: println "C"; bre
4, 06:14 Jochen Theodorou wrote:
> On 28.06.24 18:35, Christopher Smith wrote:
> > Heads up that Jenkins (as of plugin parent 4.83, and at least
> > workflow-cps is still on 4.80) still uses Groovy 2.4.21. The CPS plugin
> > is a drastic ASTT, and it's core to modern Jen
Virus-free.www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
--
Christopher Smith
> On 29.06.23 19:28, Christopher Smith wrote:
> > One note I'll add is that while Lombok was presented as an example of a
> > Java annotation processor, it really isn't—it's a monkey-patch of javac
> > itself, as otherwise annotation processors can't modify cl
One note I'll add is that while Lombok was presented as an example of a
Java annotation processor, it really isn't—it's a monkey-patch of javac
itself, as otherwise annotation processors can't modify classes, just add
new ones. Regarding "regular" annotation processors, it would be possible
to impl
Apologies if I'm spamming, but I filed GROOVY-10888 against 4.0.7 a while
back. Today, I ran into the same problem again and was about to work up a
ticket when I found my old one. I used the Parrot component tag, but it
doesn't appear to have shown up on anyone's dashboard, and unfortunately
parser
a week?) to see if any other problems surface. Would that work for
> you?
>
> On Tue, Jan 3, 2023 at 8:04 AM Christopher Smith
> wrote:
>
>> GROOVY-10890 fixes a regression in 4.0.7 relating to generic inference
>> that causes compilation errors in previously-happy code
GROOVY-10890 fixes a regression in 4.0.7 relating to generic inference that
causes compilation errors in previously-happy code. Would it be feasible to
release a 4.0.8 to unblock existing code bases?
I believe the feature at play is "flow typing", and it surprises me that it
would apply to variables declared with an explicit type. What version of
Groovy are you targeting, and is this compiled statically or dynamically?
On Sat, Dec 3, 2022, 05:04 Saravanan Palanichamy wrote:
> Hello developer
where that this work is filed so that I don't clutter up trackers, and
(2) is there anything that I can do to assist extending the processing
through SEMANTIC_ANALYSIS or CANONICALIZATION?
--
Christopher Smith
The parser seems to be interpreting what you mean as a ternary as a
null-safe array index.
On Thu, Sep 8, 2022, 08:37 o...@ocs.cz wrote:
> Hi there,
>
> I've just decided it's time to upgrade from Groovy 3 to Groovy 4... and
> immediately bumped into a problem, which looks like a parser bug in a
least 3.x and
4.x.
On Fri, Jul 29, 2022 at 5:27 PM Paul King wrote:
> I was planning to perhaps do a 4.0.5 release not too far away (as in
> maybe 1-2 weeks time). Were you wanting faster than that or also a
> 3.0.13?
>
> On Sat, Jul 30, 2022 at 8:12 AM Christopher Smith
> wr
I am aware that we've just had a release batch, but I would like to request
another release to include Eric's graciously quick fix for GROOVY-10711.
This bug resulted in the static compiler's silently failing to use
`asBoolean()` methods defined directly on classes, which can result in data
corrupt
The documentation does not specify whether the Elvis operator (and its
related Elvis assignment operator) short-circuits. It does in the
implementation of Groovy 3.0.9, but this seems like it should be specified
behavior.
I will concur in part and disagree in part with Eric: I think that as a
broad rule it makes sense to baseline, but on JDK LTS releases, which it
happens 17 is.
That said, 17 seems likely to finally introduce serious breaking changes
that have been warned about for a decade, and I absolutely predic
I'm trying to import Groovy HEAD (currently 20b87e9) into Eclipse (4.20,
STS 4.11). When I do so, I'm getting a pair of class of errors:
- Circular dependencies (groovy-$module depends on -test and -xml)
I think that for the work I'm trying to do (enhancements to
DefaultGroovyMethods), this might
, 14:03 Remi Forax wrote:
>
>
> ------
>
> *De: *"Christopher Smith"
> *À: *"dev"
> *Envoyé: *Jeudi 29 Avril 2021 19:38:27
> *Objet: *Re: () call-type syntax for functional interfaces?
>
> Also an object implementing multiple
Also an object implementing multiple functional interfaces. In dynamic
mode, you wouldn't know which method to invoke.
On Thu, Apr 29, 2021, 12:34 Jochen Theodorou wrote:
> On 29.04.21 15:32, Christopher Smith wrote:
> > Sure, this is theoretically possible (though many functio
Sure, there are some glitches still, but that's why I said that even so
it's a net boost, and I have been using it exclusively since I had the
choice.
On Thu, Apr 29, 2021, 10:56 OCsite wrote:
> Christopher,
>
> On 29 Apr 2021, at 16:57, Christopher Smith wrote:
>
ew extension methods may only be available in Groovy 4. Myself, I'm still
> stuck on Groovy 2.5 and I get tickets all the time about keeping Groovy 2.4
> supported.
>
>
>
> *From:* Christopher Smith
> *Sent:* Thursday, April 29, 2021 9:37 AM
> *To:* dev@groovy.apache.o
k
> back to the ticket should suffice. The ticket prevents surprise when a
> pull request shows up. And I'd suggest starting with a small change first.
>
> -Original Message-
> From: Christopher Smith
> Sent: Wednesday, April 28, 2021 11:36 AM
> To: dev@groovy.ap
.apply(java.lang.Object)]
>
> Modify to allow any interface as long as it has only one abstract method
> by, instead of the .findFirst(), go to a list or array and only use it if
> it’s exactly one entry long.
>
> --
> Rachel Greenham
> rac...@merus.eu
>
>
>
&
> Angelo
>
> ---
> Angelo Schneider
> angelo.schnei...@oomentor.de
> +49 172 9873893
>
> > Am 29.04.2021 um 02:47 schrieb Christopher Smith <
> chrylis+gro...@gmail.com>:
> >
> > It would be convenient to be able to use the convention of "use
> > pa
It would be convenient to be able to use the convention of "use
parentheses on a function-like object" with functional interfaces; for
example, if a variable is declared as type Function, to have
`myVar(3)` run `myVar.apply(3)`. Is there any chance this would be
practical, or would its semantics be
t; I think it would probably be best to submit one JIRA ticket for each group of
> methods. That is, one for "collect", one for "findAll", etc. So we can
> break the problem down and test things a little at a time.
>
>
>
> From: Christopher Smith
> Sent:
to use Java streams if you want a
> lambda/method reference friendly API. There is an ticket in JIRA about
> making streams a bit more "groovy":
> https://issues.apache.org/jira/browse/GROOVY-10026
>
>
> -Original Message-
> From: Christopher Smith
> Se
This would be both expensive and problematic with static mode, which is
what I use almost exclusively for production code.
On Tue, Apr 27, 2021, 20:26 Remi Forax wrote:
> - Mail original -
> > De: "Christopher Smith"
> > À: "dev"
> > Envoyé:
Since Paul is now threatening us with a 4.0 beta, I wanted to float an
idea that I've been thinking over for a bit now that might be best to
add there (though maybe it would be okay in 3 still, with the Java 8
baseline).
A large number of the GDK extension methods (particularly stuff like
`with`,
e correct ones show up - hopefully
> they'll override the glitched ones.
>
> Cheers, Paul.
>
> On Tue, Apr 20, 2021 at 2:32 PM Christopher Smith
> wrote:
>>
>> See, for example, results at https://search.maven.org/search?q=groovy-all
>>
>> The 3.0.
:
>
> So seems fixed?
>
> On Tue, Apr 20, 2021 at 1:55 PM Christopher Smith wrote:
>>
>> When I updated my Groovy version to 3.0.8 (I'm using groovy-bom), I got a
>> "not found" from Central immediately before posting. I looked on the Central
>>
eeing that? There was a glitch with an earlier upload but I
> thought it was fixed now?
>
> Cheers, Paul.
>
> On Tue, Apr 20, 2021 at 11:34 AM Christopher Smith
> wrote:
>
>> It appears that the deployment to Central somehow attached the wrong
>> coordinates; I&#
ur help and feedback and in particular want
> to thank everyone who contributed to this release.
>
> For more information on how to report problems, and to get involved,
> visit the project website at https://groovy.apache.org/
>
> Best regards,
>
> The Apache Groovy team.
--
Christopher Smith
Is there a planned timeline for 3.0.8? I'm running into some shiny new
problems (including a VerifyError!), but I know there have been a lot
of updates to the areas of the compiler that I'm hammering, so if the
3.0.8 release is happening in the near future, I'll try to work around
in the meantime a
e time is something we would need to be worried
> about here... ?
>
> Cheers,
> mg
>
>
> On 20/01/2021 23:25, Christopher Smith wrote:
>
> I'm open to tinkering on it, but my understanding of the compiler
> Internals is extremely limited. If more knowledgeable people s
A longstanding shortcoming of the AST-transformation system is the
minimal guarantees provided when multiple ASTTs target the same area
of code. While comprehensive support for this seems like it would
require a redesign or at least major rework, I have a suggestion for a
small change that might ge
Currently, the method AbstractASTTransformation#getMemberClassValue
takes as a parameter a "default value" (parameter defaulted to null),
which is returned if the annotation instance does not provide a value
for that parameter. This means that if an annotation is declared with
a "default Foo.class"
This is substantially lower-level than is probably warranted, but what
you're looking for could be implemented by pushing the values onto the
stack immediately at the entry point.
On Tue, Nov 24, 2020, 15:36 Milles, Eric (TR Technology) <
eric.mil...@thomsonreuters.com> wrote:
> > since you seeme
"state" is not always convertible into a java.util.Stack. Sometimes
> this is 3rd-party code that is being extended.
>
>
>
>
>
>
>
> I was thinking of something like this so as not to overload the try keyword:
>
>
>
> class Foo {
>
> def bar() {
>
> push (field1 = value, field2) { // AST would be re-written to try/finally
> like Scenario 1/2
>
> baz()
>
> }
>
> }
>
> ...
>
> }
>
>
>
> This e-mail is for the sole use of the intended recipient and contains
> information that may be privileged and/or confidential. If you are not an
> intended recipient, please notify the sender by return e-mail and delete this
> e-mail and any attachments. Certain required legal entity disclosures can be
> accessed on our website:
> https://www.thomsonreuters.com/en/resources/disclosures.html
>
>
--
Christopher Smith
> Just to clarify, there is no issue
> when using the full getter name for property getter, correct? E.g.
> map.isEmpty()
>
That's correct; explicitly invoking the methods always works. The current
logic, though, leads to circumstances where
def v1 = value
obj.foo = v1
v1 != obj.foo
(among other
ly want to use a lookup, get and `[]` are easily available.
--
Christopher Smith
40 matches
Mail list logo
