Re: Groovy 2.5.4 planning

[Daniel Sun]

Hi Andres, 

  > if GProperties is added to core I’d suggest to set that flag to
false as default. 
  Agreed :)

  > Additionally, couldn’t this behavior be added to ConfigSlurper? 
  As you can see, `GProperties` is a subclass of `Properties`, I
recommend groovy users to use the enhanced `Properties` by
default(`GProperties` to `Properties` is similar with `GString` to
`String`), which can handle properties smartly and handle input
stream/reader properly

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

About the enhanced version of `Properties`, i.e. `GProperties`

[Daniel Sun]

Hi all,

   I propose to implement an enhanced version of `Properties`, i.e.
`GProperties`, which can interpolate values of properties and import other
properties in classpath. 

   Here is the PR:   https://github.com/apache/groovy/pull/818

   Any thoughts?
   ( Andres's opinion on `GProperties` can be found at here[1]  )

Cheers,
Daniel.Sun

[1]
http://groovy.329449.n5.nabble.com/Groovy-2-5-4-planning-tp5754788p5754790.html




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Groovy 2.5.4 planning

[Andres Almiray]

Hi Daniel,

Then so, if GProperties is added to core I’d suggest to set that flag to false 
as default. 

Additionally, couldn’t this behavior be added to ConfigSlurper?

Cheers
Andres

Sent from my primitive tricorder

> On Nov 1, 2018, at 10:49 PM, Daniel Sun  wrote:
> 
> Hi Andres,
> 
>  We can disable running code feature by default(enabled by a switch,
> e.g. -Dgroovy.properties.evaluate.code=true).
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Groovy 2.5.4 planning

[Daniel Sun]

Hi Andres,

  We can disable running code feature by default(enabled by a switch,
e.g. -Dgroovy.properties.evaluate.code=true).

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Groovy 2.5.4 planning

[Andres Almiray]

FWIW enabling arbitrary code on a properties file sounds like a risk to me. 

What if this be released as a standalone library for people to try it out 
first? Remember once added to Groovy core it’ll be hard to remove later. 

Best
Andres

Sent from my primitive tricorder

> On Nov 1, 2018, at 7:46 PM, Daniel.Sun  wrote:
> 
> Hi Paul,
> 
>  I wish GProperties could be included in 2.5.4. Here is the relevant
> PR:  https://github.com/apache/groovy/pull/818
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> -
> Daniel Sun 
> Apache Groovy committer 
> Blog: http://blog.sunlan.me 
> Twitter: @daniel_sun 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Groovy 2.5.4 planning

[Daniel.Sun]

Hi Paul,

  I wish GProperties could be included in 2.5.4. Here is the relevant
PR:  https://github.com/apache/groovy/pull/818

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Groovy 2.5.4 planning

[Paul King]

Just a little bit of advance warning. I'm still working on a few bug fixes
but I'll aim to prepare a new release next week. If you have any pending
changes, please get them in and/or let me know your plans. The release date
isn't super urgent if there are other fixes we should be waiting for but
I'd like to get the non-beta version of ASM 7 incorporated and a few other
important fixes.

Cheers, Paul.

Re: Remembering imports between script invocations

[Keith Suderman]

Hi David,

I am not a Groovy committer and I am not that familiar with the Groovy code 
base so _I_ can't revise the JSR-223 implementation.  I did take a quick look 
at the code, and other than having "GroovyScriptEngine" in their names the two 
classes (GroovyScriptEngine and GroovyScriptEngineImpl) have nothing in common 
and parse/load Groovy code in completely different ways.  I suspect adding a 
feature like you want would be a non-trivial undertaking.  Maybe one of the 
active committers (Paul, Daniel, et al)  can comment.

However, I suspect that the GroovyScriptEngineImpl class is "crippled" by 
JSR-223 itself as it caters to the lowest common denominator

- Keith

> On Oct 31, 2018, at 12:12 PM, David Ekholm  wrote:
> 
> Hi Keith,
> 
> I'm "resurrecting" this old thread in an attept to see if we can use Groovy 
> as the next scritpting language in jAlbum. What I'd really want to achive is 
> to supply a number of default star imports. This is expecially important as 
> Groovy sadly doesn't remember imports between script invocations.
> 
> I looked at your code suggetion below and tried to fit it to JSR-223 
> (javax.script API) but it fails as the GroovyScriptEngineImpl class I get 
> from that API doesn't extend the GroovyScriptEngine class. It's only the 
> GroovyScriptEngine class that supplies the important setConfig method.
> 
> Could you revise the JSR-223 implementation so it isn't unnecessary crippled 
> compared to the GroovyShell API, at very least add the setConfig method to 
> the GroovyScriptEngineImpl class? If we're to use the GroovyShell API, then 
> we need to introduce our own abstraction layer in order to continue 
> supporting multiple scripting languages in jAlbum.
> 
> Regards
> /David, jAlbum founder
> 
>> On 10 Feb 2018, at 21:25, Keith Suderman > > wrote:
>> 
>> Import statements are really just shortcuts to tell the compiler how to 
>> resolve class names so there is nothing to "remember" between invocations, 
>> that is, nothing gets added to the Binding.
>> 
>> I am not familiar with the javax.script API, but I suspect that you will 
>> have to provide your own ScriptEngine implementation as you will need to 
>> modify the CompilerConfiguration object the GroovyShell is using to compile 
>> the Groovy code.  For example:
>> 
>> CompilerConfiguration configuration = new CompilerConfiguration()
>> GroovyShell compiler = new GroovyShell(configuration)
>> println compiler.evaluate('json=\'{"foo":"bar"}\'')
>> println compiler.evaluate("groovy.json.JsonOutput.prettyPrint(json)")
>> 
>> /* Fails: MissingPropertyException */
>> /* println compiler.evaluate("JsonOutput.prettyPrint(json)") */
>> 
>> ImportCustomizer imports = new ImportCustomizer()
>> imports.addStarImports("groovy.json")
>> configuration.addCompilationCustomizers(imports)
>>  // Works, the compiler can now resolve groovy.json.JsonOutput
>> println compiler.evaluate("JsonOutput.prettyPrint(json)")
>> 
>> The difficult part will be "hooking" into the compiler to know when an 
>> import statement is used so you can update your CompilerConfiguration 
>> object.  I am sure the really clever programmers here could come up with 
>> some sort of AST transform that would do this.  However, depending on what 
>> you are allowed to do one option would be to tell your users that you have a 
>> "Groovy DSL" and then implement an "include" method that users would use to 
>> "import" Java packages.
>> 
>> println eval('json=\'{"foo":"bar"}\'')
>> println eval('include "groovy.json"')
>> println eval('JsonOutput.prettyPrint(json)')
>>  
>> Object eval(String code) {
>> Script script = compiler.parse(code)
>> ExpandoMetaClass metaClass = new ExpandoMetaClass(script.class, 
>> false)
>> metaClass.include = { String name ->
>> ImportCustomizer includes = new ImportCustomizer()
>> includes.addStarImports(name)
>> configuration.addCompilationCustomizers(includes)
>> "Imported $name"
>> }
>> metaClass.initialize()
>> script.metaClass = metaClass
>> script.run()
>> }
>> 
>> Hopefully that gives you some ideas.
>> 
>> Cheers,
>> Keith
>> 
>>> On Feb 8, 2018, at 3:47 PM, David Ekholm >> > wrote:
>>> 
>>> How do I do that via the javax.script API?
>>> 
>>> Even if this is possible via the javax.script API, chances are that a user 
>>> wishes to ad-hoc add another import, but as they are forgotten between 
>>> script invocations, it makes it hard to use Groovy to interactively create, 
>>> say a Swing or JavaFX UI one line at a time. With BeanShell, the user can 
>>> add the needed imports, execute that "script" and then continue to refer to 
>>> the imported classes in the following script invocations. Making Groovy 
>>> remember imports would make it behave in as 

help

[David R. Fischer]