http://permalink.gmane.org/gmane.comp.lang.groovy.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19879 Luke Daley schrieb: that would be ~/[A-Z].*/ if I remember correctly we would like to have that, but the people that specified annotations did a good job in only really allowing what they wanted to be allowed. Allowed are all that you can see as constants. That means Strings, classes, numbers, other annotations and enums. You can use constants, but their values are inlined.... null is a constant too, but not allowed! Now there are also arrays which are allowed, but are no constants, but still the base type has to be a number, enum, annotation, String or Class. With this set it should be impossible to provide a Patternobject. Of course a enum, that is returning the pattern would be possible.. We had a bit discussion about how to support the usage of Closures in annotations already, but I think the discussion is not really done yet. Clearly the usage of a pattern through an enum is not really what the annotation creators had in mind. It would work in Groovy well, because of duck typing, but th Jochen Theodorou 2008-12-04T01:54:36 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19878 On 04/12/2008, at 11:02 AM, Jochen Theodorou wrote: That indeed does work, I thought /[A-Z].*/ would actually be a pattern object though. So I guess my real question is, will I ever be able to do this (obviously only if my annotation is defined in Groovy)… < at >interface Matches { Pattern value() } In light of this already kinda working if you are happy with just getting the pattern as a string, this particular case is not as important. What about ranges though? < at >interface InRange { Range value() } < at >InRange(1..5) def number ? Luke Daley 2008-12-04T01:16:58 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19877 Luke Daley schrieb: since /[A-Z].*/ is only a string in the end this should work, so please fill an JIRA entry for this with a working example so we can fix it. bye blackdrag Jochen Theodorou 2008-12-04T01:02:50 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19876 Hi, You can't currently do this… < at >Matches(/[A-Z].*/) def name Is this a fundamental limitation of the annotation mechanism? Or is it something that one day might be possible in Groovy? What about ranges? Luke Daley 2008-12-04T00:30:08 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19875 Jim White schrieb: [...] yes, but since there was the overall request that calling a static method on an instance is something groovy should support it is still a valid method call... and naturally the fact that the swing2 instance does not matter is exactly why I ask. I am still not satisfied with the static and instance solution of all this. That case #1, #2 and #3 are the same in 1.5 is unfortunate, but a fact. If calling static methods on instances were invalid, then only case #2would be valid and that is at last partially the use case I had in mind for this method... well actually without the frame call surrounding it. And of course build(Class) and build(Script) behave different, because they don't have the closure connected with the surrounding closure. If we would no go and leave the SwingBuilder as it was, but change the name resolving strategy of the closures to "delegate first", then none of these cases would embed the panel in the frame, because then really the new builder would Jochen Theodorou 2008-12-03T22:05:39 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19874 I will try that such proofs of my work don't come out spilling like this on CI and are well hidden in tests. On Thu, Dec 4, 2008 at 3:30 AM, Jochen Theodorou <blackdrag-BA+cFGlbTmA< at >public.gmane.org> wrote: Roshan Dawrani 2008-12-03T22:02:37 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19873 Guillaume Laforge schrieb: at last we know that the test is actually testing for an error ;) bye blackdrag Jochen Theodorou 2008-12-03T22:00:13 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19872 Yup, it's better to do atomic commits, even just if because of the CI server building on commit. And it's easier to follow what's happening in the repository with atomic commits. On Wed, Dec 3, 2008 at 10:24 PM, Roshan Dawrani <roshandawrani-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote: Guillaume Laforge 2008-12-03T21:34:49 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19871 Sorry, broke the first build itself :-( ( http://bamboo.ci.codehaus.org/browse/GROOVY-CORE15-3803) I checked in my changes file by file under the impression that CI waits for 2 minutes for check-ins to complete before triggering the build. 3803 did not pick up all the changes. 3804 went through seeing rest of the changes. Will do the check-in in one bunch now. Sorry. Roshan Roshan Dawrani 2008-12-03T21:24:39 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19870 There is no member function build(Closure) so naturally the instances don't matter. Case #3: swing.frame{ swing2.build { panel{} } } is the same as: Case #2: swing.frame { SwingBuilder.build { panel() } } and: Case #1 (the one that motivated this thread): swing.frame { build { panel() } } That certainly is not what I expected was going on when I changed a build(Class) call to build(Closure), but the result in 1.5 for case #1 is correct. If you want to change the behavior in 1.6 of the other two, I would agree. I've tried registerExplicitMethod('build', ...) and FBS.build(Closure) but they both get hidden by the static build method (I'm not surprised by the latter but I am somewhat by the former). Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-12-03T20:13:39 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19869 Hi all, I finally found some time to work on this; here's the diff. If it looks ok, I'll create some tests & commit. Best, Martin --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Martin C. Martin 2008-12-03T19:15:01 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19868 Jim White schrieb: [...] and if it where: swing.frame{ swing2.edt { panel{} } } and if swing!=swing2 and if the swing2 panel is added to the swing1 frame, then you would also say, that this is correct? Or swing.frame{ swing2.build { panel{} } } if the panel inside the build comes from neither swing, nor swing2, but is added to the swing1 frame, meaning swing2 is totally ignored.. bye blackdrag Jochen Theodorou 2008-12-03T19:12:50 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19867 D'oh. Sorry. ~~ Robert. Guillaume Laforge wrote: Robert Fischer 2008-12-03T19:00:47 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19866 Grails question on Grails lists? On Wed, Dec 3, 2008 at 7:30 PM, Robert Fischer < robert.fischer-PhQ5OvVyDpbEbydl4kn8rAC/G2K4zDHf< at >public.gmane.org> wrote: Guillaume Laforge 2008-12-03T18:57:54 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19865 Welcome indeed Roshan! It is excellent to have fresh blood digging into those nasty bugs in the innards. I do hope you'll tackle GROOVY-3173 first! ;-) Jim Roshan Dawrani wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-12-03T18:30:27 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19864 I just did a 0.6 release of Autobase from my GitHub directory using the updated ReleasePlugins script. It seemed to work just fine, until I went to check SVN. Looks like it's still copying from trunk to do the release, which means that my updated code isn't making it in. The 0.6 release of Autobase uses Commons-IO, which isn't in the lib dir for the RELEASE_0_6 tag. And the AutobaseGrailsPlugin.groovy has its version set to 0.6, which I double-checked, yet the RELEASE_0_6 tagged file still says 0.4. https://svn.codehaus.org/grails-plugins/grails-autobase/tags/RELEASE_0_6/AutobaseGrailsPlugin.groovy https://svn.codehaus.org/grails-plugins/grails-autobase/tags/RELEASE_0_6/lib/ ~~ Robert Fischer. Grails Trainining http://www.smokejumperit.com/grails_training.html Smokejumper Consulting http://smokejumperit.com Enfranchised Mind Blog http://enfranchisedmind.com/blog --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircl Robert Fischer 2008-12-03T18:30:12 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19863 Us non-dev lurkers on the list will learn a lot from your "newbie" questions. So thanks in advance! Dave On Wed, Dec 3, 2008 at 11:58 AM, Roshan Dawrani <roshandawrani-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote: Dave Klein 2008-12-03T18:23:07 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19862 I say "yes" because adding the panel to the frame is the expected behavior of the build(Closure) and that is consistent with build(Script) and build(Class). I see no bug here. To make one of those three forms be different from the other two would be to create a bug. Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-12-03T18:21:40 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19861 Jim White schrieb: frankly I would say that is wrong. So I am quite surprised about your "yes". Or does your "yes" solely come from a "it is right, because that is how it was"? I mean with that we shouldn't fix any bugs anymore ;) bye blackdrag Jochen Theodorou 2008-12-03T18:06:26 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19860 Thanks everyone, for your warm welcome mails :-) Everyone 2 minutes a different newbie question is coming to mind - how will I do this, how will I do that! I hope you will put up with my newbie questions for some time :-) rgds, Roshan On Wed, Dec 3, 2008 at 11:22 PM, Andres Almiray <aalmiray-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> wrote: Roshan Dawrani 2008-12-03T17:58:21 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19859 Welcome aboard Roshan! Roshan Dawrani wrote: Andres Almiray 2008-12-03T17:52:18 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.groovy.devel