Support for Groovy

[Mijathi]

Would it be possible to add support for groovy based scripts.

 

#!/usr/bin/env groovy

 

Example:

 

#!/usr/bin/env groovy
println("Hello world")
for (a in this.args) {
    println("Argument: " + a)
}

 

For this of course a groovy environment is needed on the machine.

[jdfwarrior]

Would it be possible to add support for groovy based scripts.

 

#!/usr/bin/env groovy

 

Example:

 

#!/usr/bin/env groovy
println("Hello world")
for (a in this.args) {
    println("Argument: " + a)
}

 

For this of course a groovy environment is needed on the machine.

 

So far we've only been adding support for env/interpreters that installed by default on any Mac OS X installation. The reason for doing that is so that people don't start getting workflows that don't work because the script is using an interpreter that doesn't exist on their machine.

[Mijathi]

Too bad because it would be very useful for a wide community. Back to the terminal .

[ctwise]

Would it be possible to add support for groovy based scripts.

 

Groovy start-up is too slow for fast-firing scripts. Groovy's fine for web applications (I develop mainly in Grails myself), but PHP, Python and Ruby are much better choices for small, short-execution scripts.

[Mijathi]

Groovy start-up is too slow for fast-firing scripts. Groovy's fine for web applications (I develop mainly in Grails myself), but PHP, Python and Ruby are much better choices for small, short-execution scripts.

 

 

It has a negligible extra, but not in those figures I could not sleep overnight . 

http://keyzero.wordpress.com/2010/05/26/groovy-vs-ruby-vs-python-performance/

 

Just that support would be nice as there is a large groovy community. I understand the issues mentioned by David, but still I think this could be solved for example by not allowing to import workflows for which a environment is not present on the system. I' m not the alfred guru, so just asking. 

[ctwise]

It has a negligible extra, but not in those figures I could not sleep overnight . 

http://keyzero.wordpress.com/2010/05/26/groovy-vs-ruby-vs-python-performance/

 

Just that support would be nice as there is a large groovy community. I understand the issues mentioned by David, but still I think this could be solved for example by not allowing to import workflows for which a environment is not present on the system. I' m not the alfred guru, so just asking. 

 

It's not the speed of the language that's the problem. It's the speed of loading. I just did a quick test on my system for programs that do nothing else but print "hello":

 

ruby - 0.01s

python - 0.01s

php - 0.03s

groovy - 0.81s

 

Those times are consistent. A Groovy script takes almost a whole second _just to start_. Once it's running? Yes, it's as fast or faster then the others. But most of the scripts fired off by Alfred are short and run for far, far less then one second. You want a server that runs for a while? Groovy's a good choice. You want a command-line processing script that should finish in under a second - not so much.

[mklement0]

The issues is not performance, but, as David said, consciously restricting the choices to those interpreters that come preinstalled on OS X.

 

Of course, you can always

• Place the script in the language of your choice in your workflow's folder.
• Use an auxiliary bash script action or filter to invoke it.

 

Bash script actions execute with the workflow's folder as the working folder, so any (executable) file placed there can simply be invoked by prefixing the filename with './'

 

Many existing workflows already use this technique.