Jump to content

Support for Groovy


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...