Re: [groovy-dev] new AST Transforms in groovy.lang + auto import

This one seems consistent with Java:

groovy.lang.annotation

Paul.

On 1/06/2010 7:41 AM, Peter Niederwieser wrote:
>
> Jochen,
>
> the whole point of my previous posts was that "groovy.transform" reveals an
> implementation detail of these annotations which is irrelevant to their
> usage. In other words, from a user's perspective the name "groovy.transform"
> doesn't make a lot of sense. (S)he couldn't care less if something like
>  <at> InheritConstructors was implemented as a transform or not. What's important
> is that it's a language feature, hence why I proposed "groovy.lang.ext" or
> "groovy.lang.annotation".
>
> Cheers,
> Peter
>
>
> Jochen Theodorou wrote:
>>
>> groovy.transform does not serve this purpose?
>>
>

---------------------------------------------------------------------

Re: [groovy-dev] new AST Transforms in groovy.lang + auto import

While we are at it: " <at> InheritConstructors" without the 's' in between sounds
better to me (but maybe just me; I understand it sounds less declarative).

Cheers,
Peter

Paul King wrote:
> 
> 
> This one seems consistent with Java:
> 
> groovy.lang.annotation
> 
> Paul.
> 
> On 1/06/2010 7:41 AM, Peter Niederwieser wrote:
>>
>> Jochen,
>>
>> the whole point of my previous posts was that "groovy.transform" reveals
>> an
>> implementation detail of these annotations which is irrelevant to their
>> usage. In other words, from a user's perspective the name
>> "groovy.transform"
>> doesn't make a lot of sense. (S)he couldn't care less if something like
>>  <at> InheritConstructors was implemented as a transform or not. What's
>> important
>> is that it's a language feature, hence why I proposed "groovy.lang.ext"
>> or

Re: [groovy-dev] new AST Transforms in groovy.lang + auto import

It is without the 's' already - just a cut and paste glitch earlier
in the thread. Just as further thinking on the package I would add
that while on the one hand the fact that 'Synchronized' or whatever
is implemented using AST transforms is largely irrelevant, it isn't
totally irrelevant. If I am trying to work out whether I can combine
 <at> Category with  <at> Immutable or  <at> Delegate with  <at> Lazy (or whatever) then
at the moment, knowing about how transforms work is the best bet.
It is giving a clue to the programmer that their code is changing
so perhaps there are some subtle issues to know about. Having said
that, if the package name is the only thing providing such guidance
then  we haven't done the best possible job in our doco.

Cheers, Paul.

On 1/06/2010 11:05 AM, Peter Niederwieser wrote:
>
> While we are at it: " <at> InheritConstructors" without the 's' in between sounds
> better to me (but maybe just me; I understand it sounds less declarative).
>
> Cheers,
> Peter
>
>
> Paul King wrote:
>>
>>
>> This one seems consistent with Java:
>>
>> groovy.lang.annotation

Re: [groovy-dev] [groovy-user] [BETA TEST] Big Decimal changes

On 31 May 2010, at 23:32, Peter Niederwieser wrote:

> 
> Just to be clear, the change could be called a bug fix. BigDecimal division
> now always returns the same result as BigDecimal.divide() if there is an
> exact result (previously it didn't). If there is no exact result, it may
> return a slightly differently rounded result than before. As a side effect,
> the new implementation is faster. That said, I wouldn't mind if the fix only
> went into 1.8.

I agree entirely with Graeme, but seeing as this seems to be a bug fix, surely the defining factor in this
issue should be:

'What would the people using this to manage millions of pounds want?'

To them the fix may be desperately urgent and about to save them millions of pounds. Conversely it may cost
them more to re-test and analyse the affects of changing it in a 1.7 point release. Do they need a fix right
now, or can they wait for 0.8

Can anybody from a major financial institution please step forward?

$0.02

Marc

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] [groovy-user] [BETA TEST] Big Decimal changes

On Tue, Jun 1, 2010 at 13:48, Marc Palmer <marc@...> wrote:
>
> On 31 May 2010, at 23:32, Peter Niederwieser wrote:
>
>>
>> Just to be clear, the change could be called a bug fix. BigDecimal division
>> now always returns the same result as BigDecimal.divide() if there is an
>> exact result (previously it didn't). If there is no exact result, it may
>> return a slightly differently rounded result than before. As a side effect,
>> the new implementation is faster. That said, I wouldn't mind if the fix only
>> went into 1.8.
>
> I agree entirely with Graeme, but seeing as this seems to be a bug fix, surely the defining factor in this
issue should be:

This is indeed more a bug fix than a breaking change.
It corrects certain edge cases our current implementation was suffering from.
So usually we do backport bug fixes in 1.7, but this one is a bit
special, hence why we're requesting feedback and greater attention
than most bug fixes.

> 'What would the people using this to manage millions of pounds want?'

They usually want more pounds 

> To them the fix may be desperately urgent and about to save them millions of pounds. Conversely it may cost
them more to re-test and analyse the affects of changing it in a 1.7 point release. Do they need a fix right
now, or can they wait for 0.8
>
> Can anybody from a major financial institution please step forward?

Re: [groovy-dev] [groovy-user] [BETA TEST] Big Decimal changes

Perhaps a reasonable solution is to provide a compatibility flag here
as a system property (at least in the 1.7 stream), which can control
what behavior BigDecimals will have.

Eg- specify on the command line to use the new bigdecimal support:
-Dgroovy.bigdecimal.normalization=true
(Someone can choose a better name for the property.)

The next question is whether the new behavior should default to being
on or off.  I am biased to seeing this flag default to being turned
off so that existing users are not surprised by new behavior, but if
this behavior is truly a bug, then an argument can be made to make the
flag default to being on.

--a

On Tue, Jun 1, 2010 at 4:51 AM, Guillaume Laforge <glaforge@...> wrote:
> On Tue, Jun 1, 2010 at 13:48, Marc Palmer <marc@...> wrote:
>>
>> On 31 May 2010, at 23:32, Peter Niederwieser wrote:
>>
>>>
>>> Just to be clear, the change could be called a bug fix. BigDecimal division
>>> now always returns the same result as BigDecimal.divide() if there is an
>>> exact result (previously it didn't). If there is no exact result, it may
>>> return a slightly differently rounded result than before. As a side effect,
>>> the new implementation is faster. That said, I wouldn't mind if the fix only
>>> went into 1.8.
>>
>> I agree entirely with Graeme, but seeing as this seems to be a bug fix, surely the defining factor in this

[groovy-dev] Re: [groovy-user] Groovy 1.7 and 1.8 snapshots are available

Re: [groovy-dev] Re: [groovy-user] Groovy 1.7 and 1.8 snapshots are available

They have been playing with server (rebooting it and such)
so I suspect deployment never got a run. Perhaps explanation
below will be useful.

Deploy of snapshot artifacts is done as part of "Release"
build which kicks off ~20mins after "Quality" build which
kicks off ~20mins after normal trunk build. Probably should
give the normal build a more meaningful name but anyway.
I did this to try to not hog the Bamboo server but it is
all configurable. At the moment, the Release build won't
run if Quality fails or doesn't run, Quality won't run if
normal build fails. All this changeable too. Now that they
have more build servers, might change 20 min interval down
a bit - it basically waits for a quiet period - if we make
a mistake and fix it quickly then it won't waste time doing
long builds for no benefit.

Cheers, Paul.

On 3/06/2010 1:27 PM, Roshan Dawrani wrote:
> Hi Guillaume / Paul,
>
> Is the deployment of snapshots dependent only on the Bamboo builds or
> other CI servers as well?
>
> I was waiting for one and for it all Bamboo builds are done, but the
> snapshots have not been updated yet.
>
> Do I need to wait for builds to finish on other CI servers as well?
>
> rgds,
> Roshan
>
> On Mon, May 31, 2010 at 7:25 PM, Guillaume Laforge <glaforge@...
> <mailto:glaforge@...>> wrote:
>
>     Hi all,
>
>     I just wanted to bring that to the attention of the user list as
>     well, as it was mentioned on a thread on the dev list only so far:
>     Our continuous integration builds now generate *snapshot artifacts
>     for the Groovy 1.7 and 1.8 branch*.
>
>     So if you want to easily / regularly check that your projects and
>     applications are running fine with newer or upcoming versions of
>     Groovy, you can try using our snapshots:
>     http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/
>
>     I've also added a mention about those snapshots on the Groovy
>     download page:
>     http://groovy.codehaus.org/Download
>
>     Good idea of the day:
>     If you run a continuous integration server for your project, you
>     could add a new build plan that uses the latest Groovy version, to
>     check everything's going to run fine with newer versions and that
>     you don't see any regression or anything.
>
>     Thanks a lot for your attention.
>
>     --
>     Guillaume Laforge
>     Groovy Project Manager
>     Head of Groovy Development at SpringSource
>     http://www.springsource.com/g2one
>
>

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Re: [groovy-user] Groovy 1.7 and 1.8 snapshots are available

Re: [groovy-dev] Re: [groovy-user] Groovy 1.7 and 1.8 snapshots are available

I split it into two - again to avoid hogging Bamboo. Now that it  has
more build agents, perhaps those two could be kicked off in parallel.

Cheers, Paul.

On 3/06/2010 2:30 PM, Roshan Dawrani wrote:
> Thanks, Paul. Didn't know about "Release" build plan. I thought the
> "Quality" build's successful completion will immediately trigger the
> snapshot deployment.
>
>
> On Thu, Jun 3, 2010 at 9:53 AM, Paul King <paulk@...
> <mailto:paulk@...>> wrote:
>
>
>     They have been playing with server (rebooting it and such)
>     so I suspect deployment never got a run. Perhaps explanation
>     below will be useful.
>
>     Deploy of snapshot artifacts is done as part of "Release"
>     build which kicks off ~20mins after "Quality" build which
>     kicks off ~20mins after normal trunk build. Probably should
>     give the normal build a more meaningful name but anyway.
>     I did this to try to not hog the Bamboo server but it is
>     all configurable. At the moment, the Release build won't
>     run if Quality fails or doesn't run, Quality won't run if
>     normal build fails. All this changeable too. Now that they
>     have more build servers, might change 20 min interval down
>     a bit - it basically waits for a quiet period - if we make
>     a mistake and fix it quickly then it won't waste time doing
>     long builds for no benefit.
>
>     Cheers, Paul.
>
>
>     On 3/06/2010 1:27 PM, Roshan Dawrani wrote:
>
>         Hi Guillaume / Paul,
>
>         Is the deployment of snapshots dependent only on the Bamboo
>         builds or
>         other CI servers as well?
>
>         I was waiting for one and for it all Bamboo builds are done, but the
>         snapshots have not been updated yet.
>
>         Do I need to wait for builds to finish on other CI servers as well?
>
>         rgds,
>         Roshan
>
>         On Mon, May 31, 2010 at 7:25 PM, Guillaume Laforge
>         <glaforge@... <mailto:glaforge@...>
>         <mailto:glaforge@...
<mailto:glaforge@...>>> wrote:
>
>             Hi all,
>
>             I just wanted to bring that to the attention of the user list as
>             well, as it was mentioned on a thread on the dev list only
>         so far:
>             Our continuous integration builds now generate *snapshot
>         artifacts
>             for the Groovy 1.7 and 1.8 branch*.
>
>             So if you want to easily / regularly check that your
>         projects and
>             applications are running fine with newer or upcoming versions of
>             Groovy, you can try using our snapshots:
>         http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy-all/
>
>             I've also added a mention about those snapshots on the Groovy
>             download page:
>         http://groovy.codehaus.org/Download
>
>             Good idea of the day:
>             If you run a continuous integration server for your project, you
>             could add a new build plan that uses the latest Groovy
>         version, to
>             check everything's going to run fine with newer versions and
>         that
>             you don't see any regression or anything.
>
>             Thanks a lot for your attention.
>
>             --
>             Guillaume Laforge
>             Groovy Project Manager
>             Head of Groovy Development at SpringSource
>         http://www.springsource.com/g2one
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email