http://permalink.gmane.org/gmane.comp.lang.groovy.user 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.user/58360 <pre> It's been a long time since I've seen any discussions around this. From (somewhat vague) recollections it was to allow implementation details to change under the covers without affecting user code and to encourage user code that would be easier to switch back and forth between MarkupBuilder and StreamingMarkupBuilder. I guess perhaps time has moved on and the earlier assumptions might be less relevant now - the underlying implementation leaks through the abstraction anyway and SMB could be revamped to share a common api I guess. My feeling though is one of reluctance to change it in a piecemeal fashion before 2.0 is out - but if someone looks further into it and comes up with a nice proposal I would be delighted to alter my current leanings. Cheers, Paul. On 18/05/2012 9:18 PM, Evgeny Goldin wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Paul King 2012-05-18T11:35:21 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58359 <pre>Hi, I was wondering why MarkupBuilder.getMkp() return type is Object rather than MarkupBuilderHelper? Thanks! Warm regards, Evgeny </pre> Evgeny Goldin 2012-05-18T11:18:33 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58358 <pre>Hi Peter, Starting from today, snapshots should be available like they were, but *without* invokedynamic support. Cédric Le 12/05/2012 12:10, Peter Niederwieser a écrit : </pre> Cédric Champeau 2012-05-18T08:22:32 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58357 <pre>My guess is that the trouble is in PlayCommand at line 478 where there is a ClassLoader that is locking a scala.Some inside its implementation of the synchronized loadClass method. There have been some changes in the vicinity of that code recently, are you using the latest and greatest version of that? When I look at the source here: https://github.com/playframework/Play20/blob/master/framework/src/sbt-plugin/src/main/scala/PlayCommands.scala I don't see where the lock on that scala.Some is occurs and line 478 is just a closing brace. Jim On Thu, May 17, 2012 at 3:45 PM, Manuel Bernhardt &lt; bernhardt.manuel-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Jim White 2012-05-18T06:44:53 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58356 <pre>Am 17.05.2012 21:51, schrieb Jamie Echlin: did you try super(*args), where args is a list or array? btw, caling the super class constructor by reflection is not possible. I mean you can call it, but only as normal constructor. bye blackdrag </pre> Jochen Theodorou 2012-05-18T06:06:04 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58355 <pre>Hi, I'm trying to track down the root cause of a deadlock that happens when using Play 2, Akka, and Groovy. We have a component that makes use of Groovy for data transformation and that I try to call inside of Akka actors in Play 2, so as to run the computations concurrently. One example of a recent stacktrace: https://gist.github.com/2722048 The discussion about this on the Play 2 issue tracker: https://play.lighthouseapp.com/projects/82401-play-20/tickets/470-deadlock-in-dev-mode#ticket-470-19 I'm not entirely sure that this is a Groovy issue, however I'm starting to feel somewhat desperate and hope someone here would be able to shed some light on what is going on. Thanks! Manuel --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Manuel Bernhardt 2012-05-17T22:45:29 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58354 <pre>Hi - Is it possible using some groovy-magic to *not* call super in the first line of an overloaded constructor? My problem is that my groovy class subclasses a class in a third-party package, and I want to support more than one version, and the base class constuctor signature has changed between versions. So I'd like to do something like create the ctor args in a static initialiser... then call the ctor with a list or something. Possible? Or maybe I can .invoke the constructor from the super class... I guess that would have the same effect as super()? (Except I got compilation errors). Anyway, falling at the first hurdle, I thought I would create a map as interface based on enumerating the methods of the interface, and delegate all to what would be the base class except one method. But some of the methods are overloaded, and of course the method names are the map keys, which are then duplicated. So I don't understand how this can work with overloads. Any ideas on this? cheers, jamie </pre> Jamie Echlin 2012-05-17T19:51:41 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58353 <pre>Hi all, I updated Glab (or jlabgroovy), http://code.google.com/p/jlabgroovy/, to use native BLAS through the JBLAS library. Speedups are 3-5 times faster tha Java. However, for Win64 the JBLAS shipped native BLAS .dll seems not to work (for Win32 is OK). Does anyone knows why? Regards Sterg --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> sterg 2012-05-17T12:22:07 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58352 <pre>Great, thanks for fixing this! Regards Peter On 16/05/12 14:41, Cédric Champeau wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Peter 2012-05-17T08:20:45 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58351 <pre>Hi, Shouldn't the compiler be able to recognize the property and method from Closure instead of failing? &lt; at &gt;TypeChecked class StaticGroovy { def test() { def cls = { [ this, delegate, getOwner() ] } } -- View this message in context: http://groovy.329449.n5.nabble.com/TypeChecked-closure-definition-does-not-recognize-Closure-methods-properties-inside-a-closure-definin-tp5709826.html Sent from the groovy - user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> rgarcia 2012-05-17T01:52:13 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58350 <pre>You can certainly modify your ~/.groovy/grapeConfig.xml file as you see fit, e.g. comment out the "localm2" resolver entry or uncomment the "cachedGrapes" one (this will actually be enabled again in the next release if nothing changes between now and then). Or alternatively reorder them. But from what you have said the proper "fix" would be to delete the incomplete artifact from your local m2 repo and then just re-run your script. Cheers, Paul. -- View this message in context: http://groovy.329449.n5.nabble.com/Problem-resolving-artifacts-using-Grab-tp5709803p5709825.html Sent from the groovy - user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> paulk_asert 2012-05-17T00:37:23 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58349 <pre>Well, actually for the problem to surface a series of circumstances must be present: 1. It must be Groovy 1.8+ 2. In the local maven repository (~/.m2/repository) an incomplete artifact must be present 3. The &lt; at &gt;Grab annotation must be present in the script like in the example I showed before. I've examined defaultGrabConfig.xml baked into groovy jar and it contains a definition of the local maven repository as the first one on the list. This is quite OK for most circumstances but caused issues in the case I described. Does anybody knows how to disable that resolver in the script? Best regards, Matthias. 2012/5/16 Alexander Kleymenov &lt;kleymenov-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; </pre> Matthias Hryniszak 2012-05-16T19:49:18 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58348 <pre>Hi, I've tried your script by Easy Starter: https://github.com/sankl/groovy Worked fine on both 1.8.6 and 2.0.0-beta-3 . Regards, Alexander On Wed, May 16, 2012 at 2:34 PM, Matthias Hryniszak &lt;padcom-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Alexander Kleymenov 2012-05-16T19:43:50 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58347 <pre> Every Groovy script is, at the same time, a class. You should consider your scripts collection as a Java or Groovy project with the directory structure being your source dir tree/package tree. That means every script, apart from the top level scripts, should have a `package` declaration. Running the scripts should then include a classpath pointing to the source dir. Is it unintuitive? No, it's a Java/Groovy/Scala/other JVM language way. Is it ugly? Well, that's in the eye of the beholder. Cheers, Dinko --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Dinko Srkoc 2012-05-16T15:47:44 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58346 <pre> $ cd foo $ groovy -cp .. Run.groovy foo.One.testMe ;-) Dinko --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Dinko Srkoc 2012-05-16T15:33:21 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58345 <pre> Yes, you got me ... I see that this works... but this is a workaround and would you agree it is a bit ugly ( and not intuitive ) to be forced to stand one directory back in order for it to work ? $groovy *foo/*Run.groovy try running that script from the directory where the script is located or from ANY other location on the disk, like two directories back but you did manage to get it working, congrats! :) // Moe </pre> Mohamed Seifeddine 2012-05-16T15:07:54 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58344 <pre>$ cat foo/One.groovy package foo def testMe() { println "foo.One.testMe" } $cat foo/Run.groovy package foo new foo.One().testMe() $groovy -cp . foo/Run.groovy foo.One.testMe Cheers, Dinko On 16 May 2012 16:48, Levi Hoogenberg &lt;levihoogenberg-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Dinko Srkoc 2012-05-16T14:56:01 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58343 <pre>Maybe this will help? http://padcom13.blogspot.com/2012/05/making-groovy-scripts-maintainable.html Best regards, Maciej 2012/5/16 Mohamed Seifeddine &lt;mseifeddo-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; </pre> Matthias Hryniszak 2012-05-16T14:48:39 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58342 <pre>And you run your script from the top-level directory, right? Op 16 mei 2012 16:45 schreef "Mohamed Seifeddine" &lt;mseifeddo-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; het volgende: </pre> Levi Hoogenberg 2012-05-16T14:48:32 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58341 <pre>Was sent to early... but the last thing above won't work... *Caught: groovy.lang.MissingPropertyException: No such property: abc for class: One* *groovy.lang.MissingPropertyException: No such property: abc for class: One* * at One.printSomething(One.groovy:4)* * at Two.run(Two.groovy:13)* * * Altgouhg, it will work if your method prints the string itself ... ie println "aaaaaaaaaaaa"... // Moe On Wed, May 16, 2012 at 4:45 PM, Mohamed Seifeddine &lt;mseifeddo-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Mohamed Seifeddine 2012-05-16T14:47:14 http://permalink.gmane.org/gmane.comp.lang.groovy.user/58340 <pre>&lt; at &gt;Levi That doesn't help. Create two Groovy files in the same directory, where One is: One.groovy package myDir class One { static def printSomething () { println "something" } } Two.groovy package myDir One.printSomething() ; // Doesn't work myDir.One.printSomething() // Doesn't work, with or without the package declaration in the two &lt; at &gt;Tim Yes, that will work. I also demonstrated that. However, try moving your Run.groovy into the *pkg* directory and call the method in *Test2* *pkg/Run.groovy* new pkg.Test2().testFunction() There is no easy way I see on how you can call the method in test2 ( I haven't evaluated Cedrics suggestion yet ). Run.groovy cannot find the class pkg.Test2.groovy Now, some of you might suggest that I need to remove the package declaration in *Test2.groovy* for this to work ... but then *Test.groovy*with new pkg.Test2().testFunction() in the top directory will no longer work! I should be able to have libraries built on libraries in my library directory, ( in this c</pre> Mohamed Seifeddine 2012-05-16T14:45:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.groovy.user