[groovy-dev] ant.inport from groovy?

[groovy-dev] Fonts determine everything

Has anyone discovered a way of getting anything other than monospace
fonts for the code editor in IntelliJ IDEA?  Eclipse and NetBeans allow
access to all the fonts you have available, but IntelliJ IDEA appears to
fascistically dictate that you will use a monospace font, even though
the concept is complete anathema to any right thinking person.

I guess I need to write a bug report to JetBrains to add to all the
others I have regarding errors in their adherence to the Gnome theme.
Is there a special Groovy place for sending stuff so that they will
actually listen?

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

[groovy-dev] Meta Object Protocol woes

Clearly I really don't understand the Meta Object Protocol.  However,
before launching into the deep and detailed, let me ask an easy
question.

MetaObjectProtocol requires there to be:

	invokeMethod ( Object , String , Object[] )
	invokeMethod ( Object , String , Object )

is there any obvious reason why?  Are they supposed to have different
purposes, and different implementations?  OK, that was three qeustions.

If I can get a definitive answer to these, then I may be able to save
boring the list with the real problems which involve Gant, Grails, and
why the GantMetaClass implementated one way causes incomprehensible
errors and implemented a different way works fine except for GANT-49.  I
mention this to give people motivation to avoid the detail 

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

[groovy-dev] Gant runs from Maven!

Ok, I was stuck on stoopid the other day! Trying to throw together a GAnt
plugin using GMaven which should have been sooo simple if I had studied my
art! My problem was a dependency conflict! Not thinking to actually look at
the Gant pom I declared as a dependency I naively included Maven-ant-tasks
as well as Ivy. After taking some time to pay attention I sidestepped my
conflicts by removing the redundant dependencies and using the Exclusions
tag in the Gant dependency to filter the maven-ant-tasks dependency.
(Apparently I believe the GMaven mojo support or something else in the mix
already brings in Maven-ant-tasks.) The net result, a lot less garbage in my
pom and a simple one line integration of Gant. We're talking straight
delegation here. I have it working as of five minutes ago. Now I'm looking
for a place to put it. Should it be a Groovy module? A subproject of GMaven?
Does it go in the Maven project? Mojo incubator? What's the next steps?
--

-- 
View this message in context: http://www.nabble.com/Gant-runs-from-Maven%21-tp18162030p18162030.html
Sent from the groovy - dev mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] Floating point literals

Hi,

Why do we require a digit before the decimal point in floating point 
literals?

foo.groovy: 1: expecting EOF, found '+' @ line 1, column 11.
   println 5 + .3
             ^

1 error

Best,
Martin

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] optional returns

Martin C. Martin schrieb:
> In Ruby, there's not distinction between statements and expressions. 
> There's a convention that sometimes if, for, etc. are called statements, 
> but the compiler/interpreter make no such distinction.
> 
> So looping constructs are expressions, but they always return nil, since 
> there's really no good return value for them.  It's the same reason that 
> Groovy's "each" doesn't return anything.

I think we changed each to return the object we iterate on, so in 
list.each{println it} we will return the list...

> switch statements (which Ruby calls "case" statements) return a value. 
> Here's the first example of their use in Matz's book on Ruby:
> 
> # Determine US generation name based on birth year
> # Case expression tests ranges with ===
> generation = case birthyear
>              when 1946..1963: "Baby Boomer"
>              when 1964..1976: "Generation X"
>              when 1978..2000: "Generation Y"
>              else nil
>              end

yes, I think we really should keep in mind, that Groovy has statements 
and expressions, while others have probably only expressions. That is a 
huge difference. And starting to let statements return something, means 
in the end to let all statements become expressions.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] should we use bazaar?

Hi all,

since I still have internet connection problems I constantly am aware of 
the fact, that I can not commit my code, I can not even really work on 
other bugs, because I can not do a checkout... and doing a commit? 
Forget it. This sucks big times.

I noticed, that with bazaar and other distributed revision tools I won't 
have this problem at all. Because even if I would not be able to do the 
commit I would still be able to work on a different branch for each bug 
I fix and then merge them all together as soon as the internet works again.

So I searched a bit in the net (using public internet) and I found that 
there exists bazaar-gtk 
(http://linux.softpedia.com/get/Programming/Version-Control/Bazaar-GTK-20586.shtml) 
and tortoise-bzr (http://bazaar-vcs.org/TortoiseBzr), two tools with UIs 
  that can be used on windows or linux to handle updates, commits and 
whatever, both contain bindings with the file manager (nautilus for 
bazaar-gtk, windows explorer for tortoise-bzr). Also bazaar is available 
on every platform and it seems as it can use subversion as backend too.

We should really target to migrate to bazaar I think. I looked at git as 
well, but it seems the tool-support isn't as nice as for bazaar. Those 
UIs have the advantage, that you don't need to use the IDE internals for 
this. I always worked like that when I was still on windows and still do 
so most of the time, but now without UI.

So my question is more or less, if someone has
(1) a good reason to not to switch
(2) tested the tools
(3) can explain why another tool is better

Russel? You like bazaar most too, yes? What do others think?

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] sun.reflect.Reflection usage

I noticed that we now use sun.reflect.Reflection.
Did I missed discussion how we will workaround on non-Sun platforms?

Alex

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] defining a field and a property of the same name

http://jira.codehaus.org/browse/GROOVY-2864

Is it really a bug or reasonable behavior? I was going to fix it but
realized that it might be logical because if we allow such things then
there is no clear strategy what to do if field and property defined
with different types.

BTW, it has nothing to do with
http://jira.codehaus.org/browse/GROOVY-2917 - which is bug in Verifier
to be fixed.

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] proposed minor breaking change: isCase for Gstring

At the moment if we run this script:

def one = 'one'
def two = 'two'

switch('onetwo') {
  case 'onetwo': println true
  default: println false
}

switch("$one$two") {
  case 'onetwo': println true
  default: println false
}

switch('onetwo') {
  case "$one$two": println true
  default: println false
}

switch("one${two}") {
  case "${one}two": println true
  default: println false
}

it prints:

true
true
false
true

I propose that we add an isCase method for GString which just
calls toString() on the GString and then calls isCase on that.

The above script will then print true in all cases.

This is a breaking change for anyone relying on the 'broken'
behavior. Anyone wanting the most natural behavior for this
scenario would probably be calling toString() on the GString
anyway which will still work but no longer be required.

Can anyone see any gotchas with this proposal?

Thanks,

Paul.

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

    http://xircles.codehaus.org/manage_email

[groovy-dev] interesting bug

1st of all I am sorry for my last commit, which broke trunk. I don't
know why I thought that I've run full test suite before commit.

Now about nature of the problem.

Groovy-2138 asks for DGM method Object#plus(String) is needed, which
seems to be very natural. So I implemented Object#plus(CharSecuence)
and wrote simple test

      def x = new Object()
      assertEquals ("${x}239".toString(),  x + "239")
      assertEquals ("239${x}777".toString(), "239" + x + 777)
      assertEquals ("${x}Builder${x}".toString(), x + new
StringBuilder("Builder") + x)

But they life is not so simple.

We have GString GString#plus(String) which clashes because interfaces
has preferences to inheritance in Groovy.

We also have List#plus(Object) which also clashes when called with
String parameter.

So far I reverted my fix and reopen the issue but here are 2 questions:

1) Specific one: what is right way to implement this particular
functionality. Or is it any cheap way to implement it.

2) General one: how to approach such situations in general? I can
imagine checking meta class and doing default operation only if
nothing better was found but I don't like that a lot.

Alex

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

    http://xircles.codehaus.org/manage_email