cps-groovy => translate.txt

[medianopepeter]

Hi all,

I am learning more about Jenkins and I ended up in the cps-groovy project (and groovy-cps-dgm-builder) and when checking how this last library translates groovy into CPS syntax, I am not fully understanding how the resource translate.txt actually works, I see it is a list of methods from groovy to translate but seems that they are not all the methods listed in the DefaultGroovyMethods, DefaultGroovyStaticMethods and StringGroovyMethods.

I still don’t get the discrimination pattern, or how methods are chosen, what to translate and what no.

Please can someone explain me how this library interact with translate.txt file?

Regards,
Juanma.

[Jesse Glick]

On Tue, Nov 19, 2019 at 10:27 AM medianopepeter
<jm.rodulf...@gmail.com> wrote:
> I am not fully understanding how the resource translate.txt actually works

I suppose you are referring to translatable.txt and
https://github.com/cloudbees/groovy-cps/blob/4916a1f80c5c8b1a1a23c2bf366d98be7e87ab56/dgm-builder/src/main/java/com/cloudbees/groovy/cps/tool/Translator.java#L189

> I see it is a list of methods from groovy to translate but seems that they are not all the methods listed in the DefaultGroovyMethods, DefaultGroovyStaticMethods and StringGroovyMethods.

Correct, it is a subset.

> how methods are chosen, what to translate and what no.

GDK methods can be added to it when `Translator` bugs are fixed so
that the translation actually works, as verified mostly by
`CpsDefaultGroovyMethodsTest`.

While curiosity is great, please be aware that no one is expecting to
make changes here other than for security vulnerabilities or critical
regressions: the code is so hard to follow (I am speaking as a
coauthor!) that we are reluctant to spend the time even reviewing
proposed support for the remaining methods. Few people will ever
notice that, say, `Set.takeWhile(Closure)` is not supported (as of
recent changes, this is called out with a runtime warning in the build
log), and these gaps are not so hard to work around with either
`@NonCPS` or just using more common idioms. In the longer term, we
would rather find ways to run scripts out of process so this library
(and `groovy-sandbox`) can be retired.

[medianopepeter]

I really appreciate your answer Jesse,

I am not planning on touching anything but I discovered this.. CPS stuff and is quite interesting, never heard of it and it is fascinating the applications it may have, that is the main reason I am deeply trying to understand the library.

Also, may I ask you as co-author what drove you to choose this style of programming? It is really amazing.

Thank you in advance,

Juanma.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3-_YHq02eF5d2%2Bqz7EuWC1y7KaAk2OSVAAwMJ408c7eA%40mail.gmail.com.

[Jesse Glick]

On Wed, Nov 20, 2019 at 10:03 PM medianopepeter
<jm.rodulf...@gmail.com> wrote:
> may I ask you as co-author

Kohsuke is the main author of `groovy-cps` library and its usage in
Pipeline, and also wrote an initial draft of the DGM translator;
Andrew Bayer & I got the translator working well enough to include in
the product.

> what drove you to choose this style of programming?

The CPS transformation is what allows a Pipeline script to run across
a (master) JVM restart, with all context like local variables, loops,
and closures intact, unlike its conceptual predecessor the Build Flow
plugin. Few programming languages support serializable continuations,
and Groovy (the traditional scripting language for Jenkins) certainly
did not, so `groovy-cps` effectively implements a custom interpreter
for the language with serializable state (via a compiler extension).
Some reading:

https://github.com/jenkinsci/workflow-cps-plugin/#technical-design
https://github.com/cloudbees/groovy-cps/blob/master/doc/cps-basics.md#basics-of-continuation-passing-style

[medianopepeter]

 In the longer term, we
would rather find ways to run scripts out of process so this library
(and `groovy-sandbox`) can be retired.

Can you spoil me/us about how should this functionality evolve (or be replaced with)? Really keen to know.

Regards,

Juanma.

On Nov 20, 2019, 8:52 PM +0700, Jesse Glick <jgl...@cloudbees.com>, wrote: