Mijathi Posted April 5, 2013 Share Posted April 5, 2013 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 More sharing options...
jdfwarrior Posted April 5, 2013 Share Posted April 5, 2013 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 More sharing options...
Mijathi Posted April 5, 2013 Author Share Posted April 5, 2013 Too bad because it would be very useful for a wide community. Back to the terminal . Link to comment Share on other sites More sharing options...
ctwise Posted April 5, 2013 Share Posted April 5, 2013 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 More sharing options...
Mijathi Posted April 5, 2013 Author Share Posted April 5, 2013 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 More sharing options...
ctwise Posted April 5, 2013 Share Posted April 5, 2013 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 More sharing options...
mklement0 Posted May 11, 2013 Share Posted May 11, 2013 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now