Re: Catch clause difference

2018-01-09 Thread Dinko Srkoč
Is your `NoSuchElementException` in the catch clause by any chance `java.util.NoSuchElementException`? cheers, Dinko On 8 January 2018 at 16:18, Mohan Radhakrishnan wrote: > In the second case it is this. > > org.openqa.selenium.NoSuchElementException > > In the

Re: Java 8 Date/Time API Extension Methods

2017-06-08 Thread Dinko Srkoč
On 8 June 2017 at 13:34, Russel Winder <rus...@winder.org.uk> wrote: > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: >> On 8 June 2017 at 13:09, Russel Winder <rus...@winder.org.uk> wrote: >> > On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: &

Re: Java 8 Date/Time API Extension Methods

2017-06-08 Thread Dinko Srkoč
On 8 June 2017 at 13:09, Russel Winder wrote: > On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: >> I think it makes perfect sense that you can do the same calculations >> with >> java.time.* as you can with java.util.Date >> > > Shouldn't it be fair to assume

Re: Syntax question using (identifier 1, identifier 2) on LHS of =

2017-01-27 Thread Dinko Srkoč
On 27 January 2017 at 19:15, Les Hartzman wrote: > Hi, > > I just saw a reference to using the above syntax, specifically as follows: > >def (string1, string2) = "part1-part2".tokenize("-") > > This assigns string1 "part1" and string2 "part2". > > So my main question is

Re: @Delegate and Date

2016-10-25 Thread Dinko Srkoč
On 25 October 2016 at 16:02, VG wrote: > Hi there, > > why this does not work? > > class Example { > @Delegate Date when > } > > def x = new Example(when: new Date()) > x.next() // fails > > I checked > http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Date.html

Re: Weird behavior with .with

2016-04-19 Thread Dinko Srkoč
mail with { // 4. service = 'postfix' delivery = 'courier' } is actually resolved as this.mail(this.with({ service = 'postfix' delivery = 'courier' })) where `this` is the instance of `Profile`. BTW, the same happens with `hostname with {}`, but,

Re: Check if List is of specific size and elements of specific type

2016-03-29 Thread Dinko Srkoč
On 29 March 2016 at 12:29, Marcos Carceles wrote: > Would this work? > > listVariable*.class == [Integer, Integer] It would in this particular example, but this may be dangerous for some other cases. Try e.g. this: [1, [:], [class: 1]]*.class Cheers, Dinko > > On

Re: search for particular text in a multi-line string

2016-03-16 Thread Dinko Srkoč
It seems to me that `contains()` works as expected. def str = '''foo bar baz quux''' assert str.contains('bar') assert str.contains('baz') assert str.contains('r\nb') assert str.contains('xxx') == false Cheers, Dinko On 16 March 2016 at 08:55, Paul King wrote: > Can you

Re: Failing to change the value of a Java variable from wihtin a Groovy script (potential issue?)

2016-03-09 Thread Dinko Srkoč
actually invoke the setter. > > This is disturbing and concerning as it leads to unpredictable behaviour. > > Thierry > > > -Original Message- > From: Dinko Srkoč [mailto:dinko.sr...@gmail.com] > Sent: 08 March 2016 18:20 > To: users@groovy.apache.org > Subjec

Re: Failing to change the value of a Java variable from wihtin a Groovy script (potential issue?)

2016-03-08 Thread Dinko Srkoč
On 8 March 2016 at 18:11, Thierry Hanser wrote: > > Thank you Jason, you were indeed right, without CompileStatic or using > TypeChecked works. Well, it works, but probably not the way you think it works. Here's what you can do to get more insight into what's

Re: Implicit type conversion

2016-01-26 Thread Dinko Srkoč
On 24 January 2016 at 17:29, Mike M mike...@outlook.com wrote: A question about implicit type conversion. See code sample below. On line 3, an implicit conversion takes place by invoking the toString method of the object. On line 6, a similar construct, but

Re: Super Confused About Java vs Groovy Date() and deprecation

2016-01-10 Thread Dinko Srkoč
On 10 January 2016 at 05:41, Gerald Wiltse wrote: > I'm sure this is old topic, but I can't find clear answer. IT's about > Date(), but i suppose it's true for anything "Java" which Groovy has > decorated. Actually, it's mostly about Java, not much Groovy here. > >