Feature - use groovyserv cleint.

[MortalCatalyst]

Is there a way to use groovyserv with this LT plugin to give quicker response?

http://kobo.github.io/groovyserv/

Its easily installed via GVM.

[jimwhite]

LT already has a Groovy server that does evaluations just like groovyserv (which is to say that LT's architecture is client/server). So I don't see how unless you mean for the scenario that LT is being repeatedly launched, exited, and relaunched and you want to shorten the startup time.

[MortalCatalyst]

Everytime I pressed CTRL+ENTER a gradle build started but I recieved no
output.

Was just using a basic hello world test.

Sayth
On 18/06/2014 11:36 am, "Jim White" notifications@github.com wrote:

LT already has a Groovy server that does evaluations just like groovyserv
(which is to say that LT's architecture is client/server). So I don't see
how unless you mean for the scenario that LT is being repeatedly launched,
exited, and relaunched and you want to shorten the startup time.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[jimwhite]

Ah, I see. Haven't tried out the new Gradle stuff myself. Gradle has a --daemon switch which is probably the thing that needs setting if it isn't already.

[rundis]

A couple of things:

1. Unless you explicitly connect to a gradle project, no gradle stuff should be invoked when you evaluate groovy code
2. If you are connected to a gradle project and evaluate code it will invoke gradle (through the tooling api) to retrieve the classpath
3. The gradle tooling api is using the gradle daemon by default, so getting the classpath should be quite fast

Couple of questions:

1. Have you connected to a gradle project explicitly (doesn't sound like it from your description) ? If yes can you try evaluating some groovy code without connecting to a gradle project first and see if that works.
2. Could you check the lt_server.log (resides in the plugin directory, on my mac that something like : /Users/mrundberget/Library/Application Support/LightTable/plugins/Groovy )

To me it sounds that performance might not be the issue, but rather the fact that you are getting no results. Typically if the groovy server keeps dying each time you evaluate some code, it would incur the startup cost of firing up a new jvm, but you wouldn't get any results back.

[MortalCatalyst]

1. No I haven't connected to a gradle process explicitly.

groovy evaluation
sayth:/Scripts$ groovy hello.groovy
Hello, World!
sayth:/Scripts$ groovyclient hello.groovy
Invoking server: '/home/sayth/.gvm/groovyserv/current/bin/groovyserver' -p
1961
Groovy home directory: /home/sayth/.gvm/groovy/current
Groovy command path: /home/sayth/.gvm/groovy/current/bin/groovy (found at
GROOVY_HOME)
GroovyServ home directory: /home/sayth/.gvm/groovyserv/current
GroovyServ work directory: /home/sayth/.groovy/groovyserv
Original classpath: (none)
GroovyServ default classpath: /home/sayth/.gvm/groovyserv/current/lib/*
Starting...
groovyserver 4854(1961) is successfully started
Hello, World!

2. from the lt_server.log this is where the error starts. Because it such a
   long error I created the pastebin.

http://pastebin.com/DBgzNK5w

16:45:07.536 INFO lt.groovy.LTConnection - Before json: [null, gradle.err,
[message:Error getting generic model for project:
/home/sayth/Scripts/test.groovy, ex:java.lang.RuntimeException: Error
getting generic model for project: /home/sayth/Scripts/test.groovy]]

On Wed, Jun 18, 2014 at 2:49 PM, Magnus Rundberget <notifications@github.com

wrote:

A couple of things:

1. Unless you explicitly connect to a gradle project, no gradle stuff
   should be invoked when you evaluate groovy code
2. If you are connected to a gradle project and evaluate code it will
   invoke gradle (through the tooling api) to retrieve the classpath
3. The gradle tooling api is using the gradle daemon by default, so
   getting the classpath should be quite fast

Couple of questions:

1. Have you connected to a gradle project explicitly (doesn't sound like
   it from your description) ? If yes can you try evaluating some groovy code
   without connecting to a gradle project first and see if that works.
2. Could you check the lt_server.log (resides in the plugin directory, on
   my mac that something like : /Users/mrundberget/Library/Application
   Support/LightTable/plugins/Groovy )

To me it sounds that performance might not be the issue, but rather the
fact that you are getting no results. Typically if the groovy server keeps
dying each time you evaluate some code, it would incur the startup cost of
firing up a new jvm, but you wouldn't get any results back.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[rundis]

Ah. Got it.

And its bad, cause this should have been tested; What's happening is that when you have a .groovy file and try to evaluate it (without a previous connection) it will create a new connection. The logic for checking whether you try to connect to a gradle project or not, checks for the presence of a path argument. When you evaluate a saved .groovy file it sends the path of the file as an argument. So in your case it believes /home/sayth/Scripts/test.groovy is a gradle project. It tries to connect to that through the gradle tooling api and that fails (obviously). It fails spectacularly bad

So I will need to create a fix. My bad. Sorry.

There are two possible workarounds for now:

1. • In Light Table open a new blank editor, from the command menu select "Set current editor syntax" and select groovy. Enter some groovy code and evaluate. This works because the editor is transient (ie not saved so no filename and no path is sent when connecting)
2. • In Light Table connect to a gradle project (any gradle project). You can do that form the command menu "Add connection" then select groovy from the menu, in the file/dir popup select the directory of a gradle project (where build.gradle resides).
     Now it also should work to evaluate any .groovy file because it has got a connection to a valid gradle project already

[rundis]

I have created a separate issue: #19

I'm closing this, cause Its highly unlikely that I will ever support groovyserv because It's already a server and pretty fast as well (once you actually manage to connect that is).