who uses groovysh?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|

who uses groovysh?

Thibault Kruse
Hi,

I am very new to Groovy, I have some experience with Java and Python. I thought to give groovy a go, and unfortunately started by trying to use groovysh with a few java classes. i noticed groovysh looks to be in a terrible state. Does anyone use it like that?

In particular the completion and the error behavior seems quite annoying or broken.
I created several patches on github:
https://github.com/groovy/groovy-core/pull/150
https://github.com/groovy/groovy-core/pull/152
https://github.com/groovy/groovy-core/pull/153
and there is more to come.

If a more experienced Groovy programmer would like to review, I'd be happy to get some comments.

But really, does this mean nobody really uses groovysh? Because it seems that there have not been regular commits to groovysh on master for a year or so, and the bugs I found seem rather basic. So is everybody using some other secret hip groovy REPL? Or is the groovy community mostly coding in files, without any REPL?

cheers
Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

paulk_asert

Looks like you have some great additions! I mostly use GroovyConsole or an IDE
but think a better REPL is important for Groovy and you are right, it could do
with some more TLC. I'm super busy at the moment but will look at your suggested
patches when time permits if someone else doesn't beat me to it.

Cheers, Paul.

On 31/03/2013 10:57 AM, Thibault Kruse wrote:

> Hi,
>
> I am very new to Groovy, I have some experience with Java and Python. I thought to give groovy a go, and unfortunately started by trying to use groovysh with a few java classes. i noticed groovysh looks to be in a terrible state. Does anyone use it like that?
>
> In particular the completion and the error behavior seems quite annoying or broken.
> I created several patches on github:
> https://github.com/groovy/groovy-core/pull/150
> https://github.com/groovy/groovy-core/pull/152
> https://github.com/groovy/groovy-core/pull/153
> and there is more to come.
>
> If a more experienced Groovy programmer would like to review, I'd be happy to get some comments.
>
> But really, does this mean nobody really uses groovysh? Because it seems that there have not been regular commits to groovysh on master for a year or so, and the bugs I found seem rather basic. So is everybody using some other secret hip groovy REPL? Or is the groovy community mostly coding in files, without any REPL?
>
> cheers


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Andrew Taylor
In reply to this post by Thibault Kruse
On 3/30/2013 6:57 PM, Thibault Kruse wrote:

> But really, does this mean nobody really uses groovysh? Because it seems
> that there have not been regular commits to groovysh on master for a
> year or so, and the bugs I found seem rather basic. So is everybody
> using some other secret hip groovy REPL? Or is the groovy community
> mostly coding in files, without any REPL?

I use groovysh extensively as my REPL.  I generally feed it input
directly from an editor, so I haven't stumbled on those indentation and
line editing issues.  But thanks for showing groovysh some love and rest
assured it does get used!

--
Andrew Taylor


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Thibault Kruse
Hi Paul,

so I got some feedback on github regarding the import classloading code, which I took into account. Also I created a lot of unit tests for groovysh for all things I fixed/added.
The total result is here: https://github.com/tkruse/groovy-core/tree/fix_and_imports

This fixes numerous small and huge issues of groovysh:

- no more Exception traces on tab completion
- nice display of arrays
- Less annoyingly repetitive Exception lines
- completion now working in some more cases (some cases stopped working as they were not safe)
- Auto-indentation (2 spaces) for open curly braces, if enabled in Preferences. I chose 2 because for the REPL it's better if they can quickly be removed. Maybe should be a preference...
- tab completion does not evaluate expressions that may have side effects (which is sooo evil). Based on Lexed input rather than character iteration.
- import completion uses all jars in classpath, unless disabled in Preferences. Caches in memory only all packagenames and classnames used by import statements

I guess it would be enough for a 30 JIRA issues when creating one for each details. Or maybe a dozen JIRA issues if summarizing several issues. I tried to give examples in the commit messages.

Some things I would have liked to add but could not, given my limited time:

- coloured / bold / italic output of completion candidates showing modifiers. Would require JLine extention
- displaying return type / param types for methods while typing. Would require JLine Extention
- safe completion of statements with Casts and methods. Would require much Parsing Logic to be safe, though simple cases could be dealt with
- import completion for classes in classpath, but not in jars. Should be simple, jline has code, but was too tough for me to unit-test, so I left that out.
- Completion of filenames inside (incomplete) Strings. Would be great for file operations, but requires much more GroovyLexer trickery
- Display of Strings in hyphens in result output. No idea even where to start for a clean solution.

The last one also annoys me in unit tests:
Expected :[]
Actual   :[groovy., java.]

There is no telling of the type(s) of the result, it actually is Strings, and if Groovy could display those as
Actual   :['groovy.', 'java.']
Then It would be much faster seeing what's what and copying that result into my unit test.

The commits all make sense individually, so you can cherry pick a sublist of them, and comment on the rest. I tried to move more daring changes towards the end of the branch.

Other than that, i wrote my unit tests using MockFor, and notice that if I add @CompileStatic annotations (I did not push such changes to github), those stop working. I guess that's just a limitation of MockFor, so I don't know whether by now mockFor is discouraged.

My groovy code is probably not too idiomatic for Groovy, I often use Java-style constructs and declared types, not sure whether that's against Groovy conventions.

While I wrote a lot of unit tests, I'd be surprised if I did not introduce bugs, so some user testing would be preferrable, by users who actually use tab completion a lot in groovysh.


cheers,
  Thibault




On Mon, Apr 1, 2013 at 6:44 PM, Andrew Taylor <[hidden email]> wrote:
On 3/30/2013 6:57 PM, Thibault Kruse wrote:

But really, does this mean nobody really uses groovysh? Because it seems
that there have not been regular commits to groovysh on master for a
year or so, and the bugs I found seem rather basic. So is everybody
using some other secret hip groovy REPL? Or is the groovy community
mostly coding in files, without any REPL?

I use groovysh extensively as my REPL.  I generally feed it input directly from an editor, so I haven't stumbled on those indentation and line editing issues.  But thanks for showing groovysh some love and rest assured it does get used!

--
Andrew Taylor



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Guillaume Laforge-4
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume



On Fri, Apr 12, 2013 at 12:44 AM, Thibault Kruse <[hidden email]> wrote:
Hi Paul,

so I got some feedback on github regarding the import classloading code, which I took into account. Also I created a lot of unit tests for groovysh for all things I fixed/added.
The total result is here: https://github.com/tkruse/groovy-core/tree/fix_and_imports

This fixes numerous small and huge issues of groovysh:

- no more Exception traces on tab completion
- nice display of arrays
- Less annoyingly repetitive Exception lines
- completion now working in some more cases (some cases stopped working as they were not safe)
- Auto-indentation (2 spaces) for open curly braces, if enabled in Preferences. I chose 2 because for the REPL it's better if they can quickly be removed. Maybe should be a preference...
- tab completion does not evaluate expressions that may have side effects (which is sooo evil). Based on Lexed input rather than character iteration.
- import completion uses all jars in classpath, unless disabled in Preferences. Caches in memory only all packagenames and classnames used by import statements

I guess it would be enough for a 30 JIRA issues when creating one for each details. Or maybe a dozen JIRA issues if summarizing several issues. I tried to give examples in the commit messages.

Some things I would have liked to add but could not, given my limited time:

- coloured / bold / italic output of completion candidates showing modifiers. Would require JLine extention
- displaying return type / param types for methods while typing. Would require JLine Extention
- safe completion of statements with Casts and methods. Would require much Parsing Logic to be safe, though simple cases could be dealt with
- import completion for classes in classpath, but not in jars. Should be simple, jline has code, but was too tough for me to unit-test, so I left that out.
- Completion of filenames inside (incomplete) Strings. Would be great for file operations, but requires much more GroovyLexer trickery
- Display of Strings in hyphens in result output. No idea even where to start for a clean solution.

The last one also annoys me in unit tests:
Expected :[]
Actual   :[groovy., java.]

There is no telling of the type(s) of the result, it actually is Strings, and if Groovy could display those as
Actual   :['groovy.', 'java.']
Then It would be much faster seeing what's what and copying that result into my unit test.

The commits all make sense individually, so you can cherry pick a sublist of them, and comment on the rest. I tried to move more daring changes towards the end of the branch.

Other than that, i wrote my unit tests using MockFor, and notice that if I add @CompileStatic annotations (I did not push such changes to github), those stop working. I guess that's just a limitation of MockFor, so I don't know whether by now mockFor is discouraged.

My groovy code is probably not too idiomatic for Groovy, I often use Java-style constructs and declared types, not sure whether that's against Groovy conventions.

While I wrote a lot of unit tests, I'd be surprised if I did not introduce bugs, so some user testing would be preferrable, by users who actually use tab completion a lot in groovysh.


cheers,
  Thibault




On Mon, Apr 1, 2013 at 6:44 PM, Andrew Taylor <[hidden email]> wrote:
On 3/30/2013 6:57 PM, Thibault Kruse wrote:

But really, does this mean nobody really uses groovysh? Because it seems
that there have not been regular commits to groovysh on master for a
year or so, and the bugs I found seem rather basic. So is everybody
using some other secret hip groovy REPL? Or is the groovy community
mostly coding in files, without any REPL?

I use groovysh extensively as my REPL.  I generally feed it input directly from an editor, so I haven't stumbled on those indentation and line editing issues.  But thanks for showing groovysh some love and rest assured it does get used!

--
Andrew Taylor



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Guillaume Laforge-4
I think we need a little guidance on how to apply all this :-)

Not sure it'll make this release though, as the improvements, in particular, would rather go in the master branch for now (new stuff in master, only fixes in 2.0.x / 2.1.x)

Guillaume


On Fri, Apr 12, 2013 at 8:59 AM, Guillaume Laforge <[hidden email]> wrote:
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume



On Fri, Apr 12, 2013 at 12:44 AM, Thibault Kruse <[hidden email]> wrote:
Hi Paul,

so I got some feedback on github regarding the import classloading code, which I took into account. Also I created a lot of unit tests for groovysh for all things I fixed/added.
The total result is here: https://github.com/tkruse/groovy-core/tree/fix_and_imports

This fixes numerous small and huge issues of groovysh:

- no more Exception traces on tab completion
- nice display of arrays
- Less annoyingly repetitive Exception lines
- completion now working in some more cases (some cases stopped working as they were not safe)
- Auto-indentation (2 spaces) for open curly braces, if enabled in Preferences. I chose 2 because for the REPL it's better if they can quickly be removed. Maybe should be a preference...
- tab completion does not evaluate expressions that may have side effects (which is sooo evil). Based on Lexed input rather than character iteration.
- import completion uses all jars in classpath, unless disabled in Preferences. Caches in memory only all packagenames and classnames used by import statements

I guess it would be enough for a 30 JIRA issues when creating one for each details. Or maybe a dozen JIRA issues if summarizing several issues. I tried to give examples in the commit messages.

Some things I would have liked to add but could not, given my limited time:

- coloured / bold / italic output of completion candidates showing modifiers. Would require JLine extention
- displaying return type / param types for methods while typing. Would require JLine Extention
- safe completion of statements with Casts and methods. Would require much Parsing Logic to be safe, though simple cases could be dealt with
- import completion for classes in classpath, but not in jars. Should be simple, jline has code, but was too tough for me to unit-test, so I left that out.
- Completion of filenames inside (incomplete) Strings. Would be great for file operations, but requires much more GroovyLexer trickery
- Display of Strings in hyphens in result output. No idea even where to start for a clean solution.

The last one also annoys me in unit tests:
Expected :[]
Actual   :[groovy., java.]

There is no telling of the type(s) of the result, it actually is Strings, and if Groovy could display those as
Actual   :['groovy.', 'java.']
Then It would be much faster seeing what's what and copying that result into my unit test.

The commits all make sense individually, so you can cherry pick a sublist of them, and comment on the rest. I tried to move more daring changes towards the end of the branch.

Other than that, i wrote my unit tests using MockFor, and notice that if I add @CompileStatic annotations (I did not push such changes to github), those stop working. I guess that's just a limitation of MockFor, so I don't know whether by now mockFor is discouraged.

My groovy code is probably not too idiomatic for Groovy, I often use Java-style constructs and declared types, not sure whether that's against Groovy conventions.

While I wrote a lot of unit tests, I'd be surprised if I did not introduce bugs, so some user testing would be preferrable, by users who actually use tab completion a lot in groovysh.


cheers,
  Thibault




On Mon, Apr 1, 2013 at 6:44 PM, Andrew Taylor <[hidden email]> wrote:
On 3/30/2013 6:57 PM, Thibault Kruse wrote:

But really, does this mean nobody really uses groovysh? Because it seems
that there have not been regular commits to groovysh on master for a
year or so, and the bugs I found seem rather basic. So is everybody
using some other secret hip groovy REPL? Or is the groovy community
mostly coding in files, without any REPL?

I use groovysh extensively as my REPL.  I generally feed it input directly from an editor, so I haven't stumbled on those indentation and line editing issues.  But thanks for showing groovysh some love and rest assured it does get used!

--
Andrew Taylor



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Thibault Kruse
In reply to this post by Guillaume Laforge-4
Hi Guillaume,

Pull request #150 is up-to-date, but the branch https://github.com/tkruse/groovy-core/tree/fix_and_imports has additional commmits which make more drastic changes. I can can include those in the pull request if that helps, or turn the brnch into a pull request. It really depends on how the merger wants to handle this.

I closed #152 early moving the commits onto #150, and closed #153 (which was outdated) just now, as the commits depend on the changes in #150, mostly on the unit tests.


On Fri, Apr 12, 2013 at 8:59 AM, Guillaume Laforge <[hidden email]> wrote:
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume


Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Cédric Champeau
Hi Thibault,

For reference, as Guillaume said, we have several branches:
    * master, corresponding to the future 2.2 release
    * GROOVY_2_1_X: maintenance branch for Groovy 2.1.x, all bug fixes should go there
    * GROOVY_2_0_X: maintenance branch for Groovy 2.0.x, all critical bug fixes should go there
    * GROOVY_1_8_X: maintenance branch for Groovy 1.8.x, all critical bug fixes should go there

When you make a PR, we merge on master, then we cherry-pick commits to backport them to maintenance branches. So basically, it's easier for us to have separate PRs for bugfixes and new features. Also it's better if you can link bugfixes to JIRA issues so that we can track them.

We're doing a release today, and as you have a lot of commits, we won't be able to integrate it into 2.1.x right now, but we're planning to do it in the next bugfix release.

Le 12/04/2013 09:36, Thibault Kruse a écrit :
Hi Guillaume,

Pull request #150 is up-to-date, but the branch https://github.com/tkruse/groovy-core/tree/fix_and_imports has additional commmits which make more drastic changes. I can can include those in the pull request if that helps, or turn the brnch into a pull request. It really depends on how the merger wants to handle this.

I closed #152 early moving the commits onto #150, and closed #153 (which was outdated) just now, as the commits depend on the changes in #150, mostly on the unit tests.


On Fri, Apr 12, 2013 at 8:59 AM, Guillaume Laforge <[hidden email]> wrote:
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume




-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau
Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Thibault Kruse
Hi,

@Guillaume:
I did not want the PR to become so big (or to spendsomuch time on it), but the deeper I looked, the more issues I found. The commits in PR #150 are very small in terms of groovysh code changed, mostly they change 5 lines or less (plus adding 50 lines of unit test). So they can be understood individually fairly easily, i believe . Still, if you calculate 10 minutes per commit, then you'll spend 5 hours for 30 commits, I understand that.

Maybe this process can work for you:

Cherry-pick the next single commit.
Read the commit message. Test the issue locally to confirm the issue if it is an issue (rather than rather than refactoring)
Create a JIRA issue with the commit test. Confirm the fix and unit test.
Change the commit message to include JIRA issue.
merge to master.
Repeat.

As I said, the commits make sense individually, so you can digest the PR150 slowly that way.

Also use github to comment on commits and code, I will respond to questions, if that helps. I only have so much time, but I'll help where I can.


@Cedric:
I know it would have been nicer to create several issues on JIRA, and make a PR for each, but I did not have the time. Also I have no JIRA account yet, and it says "please contact your JIRA administrators. ", so I am already discouraged from using JIRA. But the commit messages should for all issue fixes work nicely as JIRA issues, and anyone can change the commit messages to point include a suitable JIRA ticket.

I understand you want to take your time looking through the commits, and I am in no rush for this to be released. I did this for fun, I am not actually using Groovy for anything yet. If you merge the changes sometime in the next few months, that's fine with me.

Obviously separate PRs are nicer, but because of the unit tests, my commits are very often based on one another, so the pull requests would overlap a lot, making it harder for you, I believe, to see what's what.

But thanks for telling me anyway.


On Fri, Apr 12, 2013 at 10:02 AM, Cédric Champeau <[hidden email]> wrote:
Hi Thibault,

For reference, as Guillaume said, we have several branches:
    * master, corresponding to the future 2.2 release
    * GROOVY_2_1_X: maintenance branch for Groovy 2.1.x, all bug fixes should go there
    * GROOVY_2_0_X: maintenance branch for Groovy 2.0.x, all critical bug fixes should go there
    * GROOVY_1_8_X: maintenance branch for Groovy 1.8.x, all critical bug fixes should go there

When you make a PR, we merge on master, then we cherry-pick commits to backport them to maintenance branches. So basically, it's easier for us to have separate PRs for bugfixes and new features. Also it's better if you can link bugfixes to JIRA issues so that we can track them.

We're doing a release today, and as you have a lot of commits, we won't be able to integrate it into 2.1.x right now, but we're planning to do it in the next bugfix release.

Le 12/04/2013 09:36, Thibault Kruse a écrit :
Hi Guillaume,

Pull request #150 is up-to-date, but the branch https://github.com/tkruse/groovy-core/tree/fix_and_imports has additional commmits which make more drastic changes. I can can include those in the pull request if that helps, or turn the brnch into a pull request. It really depends on how the merger wants to handle this.

I closed #152 early moving the commits onto #150, and closed #153 (which was outdated) just now, as the commits depend on the changes in #150, mostly on the unit tests.


On Fri, Apr 12, 2013 at 8:59 AM, Guillaume Laforge <[hidden email]> wrote:
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume




-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

Reply | Threaded
Open this post in threaded view
|

Re: who uses groovysh?

Cédric Champeau
No worries, I just wanted to let you know your work is appreciated even if we can't merge it right now. As for JIRA, yeah, this is not explicit at all, you need to create an account through Xircles...

Le 12/04/2013 10:46, Thibault Kruse a écrit :
Hi,

@Guillaume:
I did not want the PR to become so big (or to spendsomuch time on it), but the deeper I looked, the more issues I found. The commits in PR #150 are very small in terms of groovysh code changed, mostly they change 5 lines or less (plus adding 50 lines of unit test). So they can be understood individually fairly easily, i believe . Still, if you calculate 10 minutes per commit, then you'll spend 5 hours for 30 commits, I understand that.

Maybe this process can work for you:

Cherry-pick the next single commit.
Read the commit message. Test the issue locally to confirm the issue if it is an issue (rather than rather than refactoring)
Create a JIRA issue with the commit test. Confirm the fix and unit test.
Change the commit message to include JIRA issue.
merge to master.
Repeat.

As I said, the commits make sense individually, so you can digest the PR150 slowly that way.

Also use github to comment on commits and code, I will respond to questions, if that helps. I only have so much time, but I'll help where I can.


@Cedric:
I know it would have been nicer to create several issues on JIRA, and make a PR for each, but I did not have the time. Also I have no JIRA account yet, and it says "please contact your JIRA administrators. ", so I am already discouraged from using JIRA. But the commit messages should for all issue fixes work nicely as JIRA issues, and anyone can change the commit messages to point include a suitable JIRA ticket.

I understand you want to take your time looking through the commits, and I am in no rush for this to be released. I did this for fun, I am not actually using Groovy for anything yet. If you merge the changes sometime in the next few months, that's fine with me.

Obviously separate PRs are nicer, but because of the unit tests, my commits are very often based on one another, so the pull requests would overlap a lot, making it harder for you, I believe, to see what's what.

But thanks for telling me anyway.


On Fri, Apr 12, 2013 at 10:02 AM, Cédric Champeau <[hidden email]> wrote:
Hi Thibault,

For reference, as Guillaume said, we have several branches:
    * master, corresponding to the future 2.2 release
    * GROOVY_2_1_X: maintenance branch for Groovy 2.1.x, all bug fixes should go there
    * GROOVY_2_0_X: maintenance branch for Groovy 2.0.x, all critical bug fixes should go there
    * GROOVY_1_8_X: maintenance branch for Groovy 1.8.x, all critical bug fixes should go there

When you make a PR, we merge on master, then we cherry-pick commits to backport them to maintenance branches. So basically, it's easier for us to have separate PRs for bugfixes and new features. Also it's better if you can link bugfixes to JIRA issues so that we can track them.

We're doing a release today, and as you have a lot of commits, we won't be able to integrate it into 2.1.x right now, but we're planning to do it in the next bugfix release.

Le 12/04/2013 09:36, Thibault Kruse a écrit :
Hi Guillaume,

Pull request #150 is up-to-date, but the branch https://github.com/tkruse/groovy-core/tree/fix_and_imports has additional commmits which make more drastic changes. I can can include those in the pull request if that helps, or turn the brnch into a pull request. It really depends on how the merger wants to handle this.

I closed #152 early moving the commits onto #150, and closed #153 (which was outdated) just now, as the commits depend on the changes in #150, mostly on the unit tests.


On Fri, Apr 12, 2013 at 8:59 AM, Guillaume Laforge <[hidden email]> wrote:
Looks like great job on those groovysh contributions!

Are all those changes solely on your branch, or you've updated the associated pull request?

Guillaume




-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau



-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau
12