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
|  
Report Content as Inappropriate

Re: who uses groovysh?

Thibault Kruse
Hi,

so meanwhile I have rebased my branch and pull reuqest to the latest master, will continue to do so, though no conflicts will happen as long as nobody else works on groovysh.

I also fixed minor bugs, and added one new feature, completion of filenames within Strings, such as in

groovy:000> f = new File('/us|

Also I realized in the meantime that groovy allows operator overloading. I had not known this before, so this is a bit of a problem.
Basically my changes tried to avoid that in this case:

groovy:000> launchNuclearMissile().|

pressing tab evaluates and thus executes the method. This to prevent both undesired side-effects as well as long runtime.
Now in this situation:

groovy:000> foo[a+b].|

both getAt() as well as plus() might be implemented with side-effects and/or long running operations, which still would be bad on tab completion.

It would have been nice to just reuse the code for code completion from e.g. Eclipse, but I could not do it, it seemed too heavyweight. So the question is whether completion should also avoid all operator evaluation, or whether this is an acceptable risk. I figured it would probably be an acceptable risk, given that developers should generally make operators quick and side-effect free (I already avoid ++  and --), and those few who use different operators can disable tab completion in groovysh.

cheers


On Fri, Apr 12, 2013 at 10:52 AM, Cédric Champeau <[hidden email]> wrote:
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
Loading...