date:20160923

Re: Lazy evaluation of properties in a closure?

2016-09-23 Thread Andrew Bayer

So of course, right after sending this, I found a workaround for my
particular use case - switching from DELEGATE_ONLY to DELEGATE_FIRST got my
tests passing. But I'm still curious to know if there's a way to do this in
general. =)

A.

On Fri, Sep 23, 2016 at 9:28 AM, Andrew Bayer 
wrote:

> So I've got a DSL that has a section that looks like
> https://gist.github.com/abayer/a0bfbb531457e79aabc8d6c25d992e62, which
> ends up translating (via https://github.com/jenkinsci/pipeline-model-
> definition-plugin/blob/master/src/main/resources/org/
> jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
> and then https://github.com/jenkinsci/pipeline-model-
> definition-plugin/blob/master/src/main/resources/org/
> jenkinsci/plugins/pipeline/modeldefinition/PropertiesToMapTranslator.
> groovy) into a Map, and later on I actually do things with the contents
> of that Map in a different context entirely. Fun, right?
>
> So the literal syntax works fine, but non-literals get evaluated when I
> call the closure to translate it into a Map. I don't want that - it causes
> problems due to not being called in the context that actually has the
> "getFruit()" and "getCandy()" methods (and due to the Jenkins Pipeline
> Groovy CPS magic for continuation passing style and script security that
> make things even weirder). I'd really, really love to be able to lazily
> evaluate the property values here while still having dynamic properties,
> since I don't know what the names of all the environment variables people
> may need will be.
>
> Anyone have any suggestions or ideas? I've looked at the @Lazy field
> annotation, which would be perfect if I could use it with dynamic
> properties, but I can't see a way to actually do that...
>
> Thanks!
>
> A.
>

Lazy evaluation of properties in a closure?

2016-09-23 Thread Andrew Bayer

So I've got a DSL that has a section that looks like
https://gist.github.com/abayer/a0bfbb531457e79aabc8d6c25d992e62, which ends
up translating (via
https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
and then
https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/PropertiesToMapTranslator.groovy)
into a Map, and later on I actually do things with the contents of that Map
in a different context entirely. Fun, right?

So the literal syntax works fine, but non-literals get evaluated when I
call the closure to translate it into a Map. I don't want that - it causes
problems due to not being called in the context that actually has the
"getFruit()" and "getCandy()" methods (and due to the Jenkins Pipeline
Groovy CPS magic for continuation passing style and script security that
make things even weirder). I'd really, really love to be able to lazily
evaluate the property values here while still having dynamic properties,
since I don't know what the names of all the environment variables people
may need will be.

Anyone have any suggestions or ideas? I've looked at the @Lazy field
annotation, which would be perfect if I could use it with dynamic
properties, but I can't see a way to actually do that...

Thanks!

A.

RE: Macro methods proposal

2016-09-23 Thread Winnebeck, Jason

Assuming the AST can’t already form the right signature in the JAR for IDE to 
see, I can think of one solution:

public class MacroMethods {
  @Macro public static  T safe(T param) {
def ctx = Macros.macroContext
def exp = Macros.getExpression(param)
//original code from example…
  }
}

In this case, the IDE sees a method with an appropriate signature, and knows 
the method returns the same type as the argument, but you still have access to 
the macro context via static methods which could be implemented using thread 
locals or similar. The signature could also be used to restrict the type of the 
expression allowed, although in most cases I’d expect Object or a “T” to be 
used.

Jason

From: Sergei Egorov [mailto:bsid...@gmail.com]
Sent: Friday, September 23, 2016 9:27 AM
To: users@groovy.apache.org; d...@groovy.apache.org
Subject: Re: Macro methods proposal

Hey Jason,

Left a comment on #3.

Yes, the method signature of Macro methods is not the same as the call site. 
But, for the given call site, IDE can easily determine the signature, and I'm 
pretty sure it has all the information already. Plus, this is a new language 
feature anyway, so IDE will have to support it, at least I see no other options 
for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about the 
syntax as well

Macro methods inherit all the rules of Groovy AST transformations - they work 
only for Groovy code.

BR,
Sergei


On Fri, Sep 23, 2016 at 4:02 PM Winnebeck, Jason 
> wrote:
This is a really cool idea, especially I like the idea of the compile-time 
checked ORM example. I wonder whether or not the use in simple cases is 
productive given JIT inlining and branch prediction when branching on a 
constant, and decided to phrase that question in an issue 
https://github.com/bsideup/groovy-macro-methods-proposal/issues/3.

I noticed that the method signature for the macro method does not match the 
signature used at the call site – does this confuse IDEs like IntelliJ, or does 
this actually work properly because ASTs must be in a separate JAR, so the 
@Macro AST has already run to generate a stub with the proper call signature 
that the IDE sees?

Last question, is there any interaction with Java? That is, is it possible for 
an implementation to provide a “normal” version of the method like in your 
“warn” example so that Java can call it as a normal method while in Groovy the 
transform would be applied? In that way you could make a logging library that 
would work like a normal logging library in Java but in Groovy would apply the 
macro transformations.

Jason

From: Sergei Egorov [mailto:bsid...@gmail.com]
Sent: Friday, September 23, 2016 5:58 AM
To: d...@groovy.apache.org; 
users@groovy.apache.org
Subject: Macro methods proposal

Hey, everyone.

It's been awhile since last time I participated in Groovy.
I was mostly in read-only mode for the last two years.

With this move, I hope to change it.

I created a proposal for macro methods (no ETA, initially aimed to 3.0) because 
I think they are great for the future of Groovy and compile time 
metaprogramming.

You can find the proposal here:
https://github.com/bsideup/groovy-macro-methods-proposal

Not sure how Apache people will react on it since it's on GitHub, but it was 
the simplest way for me to share and discuss it.

Please note that macro methods are not the same as MacroGroovy - another thing 
from me already merged to groovy-core. But, MacroGroovy can and should be 
implemented with macro methods.


Grammar and clearness are not my strong points, but we can improve the proposal 
altogether.


For the few years Guillaume, Baruch, Cedric and others were trying to spread 
the word  about macro methods, but the problem here that they are something 
really new and I didn't succeed explained them back in the days.


So, I'm inviting everyone to discuss them, by raising GitHub issues, or here, 
in mail list, to make them more clear for everyone, including end users.


Cheers,
Sergei
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Macro methods proposal

2016-09-23 Thread Sergei Egorov

Hey Jason,

Left a comment on #3.

Yes, the method signature of Macro methods is not the same as the call
site. But, for the given call site, IDE can easily determine the signature,
and I'm pretty sure it has all the information already. Plus, this is a new
language feature anyway, so IDE will have to support it, at least I see no
other options for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about
the syntax as well

Macro methods inherit all the rules of Groovy AST transformations - they
work only for Groovy code.

BR,
Sergei


On Fri, Sep 23, 2016 at 4:02 PM Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> This is a really cool idea, especially I like the idea of the compile-time
> checked ORM example. I wonder whether or not the use in simple cases is
> productive given JIT inlining and branch prediction when branching on a
> constant, and decided to phrase that question in an issue
> https://github.com/bsideup/groovy-macro-methods-proposal/issues/3.
>
>
>
> I noticed that the method signature for the macro method does not match
> the signature used at the call site – does this confuse IDEs like IntelliJ,
> or does this actually work properly because ASTs must be in a separate JAR,
> so the @Macro AST has already run to generate a stub with the proper call
> signature that the IDE sees?
>
>
>
> Last question, is there any interaction with Java? That is, is it possible
> for an implementation to provide a “normal” version of the method like in
> your “warn” example so that Java can call it as a normal method while in
> Groovy the transform would be applied? In that way you could make a logging
> library that would work like a normal logging library in Java but in Groovy
> would apply the macro transformations.
>
>
>
> Jason
>
>
>
> *From:* Sergei Egorov [mailto:bsid...@gmail.com]
> *Sent:* Friday, September 23, 2016 5:58 AM
> *To:* d...@groovy.apache.org; users@groovy.apache.org
> *Subject:* Macro methods proposal
>
>
>
> Hey, everyone.
>
>
>
> It's been awhile since last time I participated in Groovy.
>
> I was mostly in read-only mode for the last two years.
>
>
>
> With this move, I hope to change it.
>
>
>
> I created a proposal for macro methods (no ETA, initially aimed to 3.0)
> because I think they are great for the future of Groovy and compile time
> metaprogramming.
>
>
>
> You can find the proposal here:
>
> https://github.com/bsideup/groovy-macro-methods-proposal
>
>
>
> Not sure how Apache people will react on it since it's on GitHub, but it
> was the simplest way for me to share and discuss it.
>
>
>
> Please note that macro methods are not the same as MacroGroovy - another
> thing from me already merged to groovy-core. But, MacroGroovy *can* and
> *should* be implemented with macro methods.
>
>
>
>
>
> Grammar and clearness are not my strong points, but we can improve the
> proposal altogether.
>
>
>
>
>
> For the few years Guillaume, Baruch, Cedric and others were trying to
> spread the word  about macro methods, but the problem here that they are
> something really new and I didn't succeed explained them back in the days.
>
>
>
>
>
> So, I'm inviting everyone to discuss them, by raising GitHub issues, or
> here, in mail list, to make them more clear for everyone, including end
> users.
>
>
>
>
>
> Cheers,
>
> Sergei
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Macro methods proposal

2016-09-23 Thread Sergei Egorov

Hey, everyone.

It's been awhile since last time I participated in Groovy.
I was mostly in read-only mode for the last two years.

With this move, I hope to change it.

I created a proposal for macro methods (no ETA, initially aimed to 3.0)
because I think they are great for the future of Groovy and compile time
metaprogramming.

You can find the proposal here:
https://github.com/bsideup/groovy-macro-methods-proposal

Not sure how Apache people will react on it since it's on GitHub, but it
was the simplest way for me to share and discuss it.

Please note that macro methods are not the same as MacroGroovy - another
thing from me already merged to groovy-core. But, MacroGroovy *can* and
*should* be implemented with macro methods.


Grammar and clearness are not my strong points, but we can improve the
proposal altogether.


For the few years Guillaume, Baruch, Cedric and others were trying to
spread the word  about macro methods, but the problem here that they are
something really new and I didn't succeed explained them back in the days.


So, I'm inviting everyone to discuss them, by raising GitHub issues, or
here, in mail list, to make them more clear for everyone, including end
users.


Cheers,
Sergei

Re: JsonOutput serialization options feature

2016-09-23 Thread Graeme Rocher

Great, yeah that would be a big help, since efficiency over the wire
for JSON services is a big deal and the unicode escaping doesn't help
there.

Also, can we consider https://github.com/apache/groovy/pull/429 as an
improvement? Again it makes using StreamingJsonBuilder more efficient
and maintainable.

Thanks

On Fri, Sep 23, 2016 at 1:11 AM, John Wagenleitner
 wrote:
> On Wed, Sep 21, 2016 at 3:22 AM, Graeme Rocher 
> wrote:
>>
>> Hi John,
>>
>> Looks very useful, so +1
>>
>> One thing that would also be useful is to be able to configure the
>> ability to disable unicode encoding. It doesn't seem to be recommended
>> for all circumstances. See:
>>
>>
>> http://stackoverflow.com/questions/12271547/shouldnt-json-stringify-escape-unicode-characters?noredirect=1=1
>>
>> And it is blocking resolution of this issue:
>>
>> https://github.com/grails/grails-views/issues/71
>>
>> Thoughts?
>
>
>
> Hi Graeme,
>
> Good suggestion, and also seems to be a requested feature in GROOVY-6975
> [1].  So seems worthwhile to add a disableUnicodeEscaping or
> disableNonAsciiEscaping option.  I'll see if I can add that to the PR soon.
>
>
> [1] https://issues.apache.org/jira/browse/GROOVY-6975
>
>
>
>
>>
>>
>> On Mon, Sep 12, 2016 at 12:02 AM, John Wagenleitner
>>  wrote:
>> > On Sun, Sep 11, 2016 at 11:51 AM, Kostas Saidis 
>> > wrote:
>> >>
>> >> +1, definitely!
>> >>
>> >> If it is possible, the dateFormat method should also accept an optional
>> >> Locale parameter (as mentioned in TODO comment in the source), with a
>> >> default value of Locale.US.
>> >>
>> >> Cheers,
>> >> Kostas
>> >>
>> >
>> >
>> > Thanks for pointing that out, I had forgot about that.  I added a new
>> > method
>> > that accepts both a date format string and Locale.
>> >
>> >
>> >>
>> >>
>> >> On 11/9/2016 6:59 πμ, John Wagenleitner wrote:
>> >>
>> >> Groovy Json users,
>> >>
>> >> I recently worked on a project where it would have been helpful if
>> >> JsonOutput/JsonBuilder/StreamingJsonBuilder had options for controlling
>> >> the
>> >> output.  I noticed there were some open tickets [1] for feature
>> >> requests
>> >> around this so decided to try to add some options to control the
>> >> serialization and have proposed a pull request
>> >> (https://github.com/apache/groovy/pull/371).
>> >>
>> >> Just wanted to poll those that use the Json generating features in
>> >> Groovy
>> >> to see if you think these options would be useful and would welcome any
>> >> code
>> >> review for those that would be interested in reviewing the PR.  For a
>> >> quick
>> >> overview I've included a sample below [2].
>> >>
>> >> [1]
>> >> GROOVY-6699: JSON slurper ability to ignore propertie/field names (at
>> >> least the serializing part)
>> >> GROOVY-6854: JsonOutput should be configurable with ISO 8601 UTC time
>> >> zone
>> >> instead of GMT
>> >> GROOVY-7682: JsonBuilder or JsonOutput incompatible with JodaTime (for
>> >> now
>> >> via a closure converter)
>> >> GROOVY-7780: JSONBuilder/JSONSlurper: Option to Only Include NonNull
>> >> values
>> >> GROOVY-7858: Make JsonBuilder configurable to not write entries with
>> >> null
>> >> values
>> >>
>> >> [2]
>> >>
>> >> import groovy.json.*
>> >>
>> >> def options = JsonOutput.options()
>> >> .excludeNulls()
>> >> .excludeFieldsByName('make', 'country', 'record')
>> >> .excludeFieldsByType(Number)
>> >> .addConverter(URL) { url -> '"http://groovy-lang.org;' }
>> >>
>> >> StringWriter writer = new StringWriter()
>> >> StreamingJsonBuilder builder = new StreamingJsonBuilder(writer,
>> >> options)
>> >>
>> >> builder.records {
>> >> car {
>> >> name 'HSV Maloo'
>> >> make 'Holden'
>> >> year 2006
>> >> country 'Australia'
>> >> homepage new URL('http://example.org')
>> >> record {
>> >> type 'speed'
>> >> description 'production pickup truck with speed of 271kph'
>> >> }
>> >> }
>> >> }
>> >>
>> >> assert writer.toString() == '{"records":{"car":{"name":"HSV
>> >> Maloo","homepage":"http://groovy-lang.org"}}}'
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Graeme Rocher
>
>



-- 
Graeme Rocher

Re: Lazy evaluation of properties in a closure?

Lazy evaluation of properties in a closure?

RE: Macro methods proposal

Re: Macro methods proposal

Macro methods proposal

Re: JsonOutput serialization options feature

6 matches

Site Navigation

Mail list logo

Footer information