gmane.comp.lang.groovy.devel

Re: [groovy-dev] should we use bazaar?

Russel Winder — 2008-07-05T05:53:04

|> port list active | grep apr apr < at >1.3.2 devel/apr apr-util < at >1.3.2 devel/apr-util |> Everytime I have had problems with MacPorts compilations, the advice has been "Make sure you have an up to date XCode." and generally this has been the problem, i.e. upgrade XCode and things start compiling as they should.

Re: [groovy-dev] should we use bazaar?

Jason Dillon — 2008-07-05T03:41:07

Did you get it to compile okay? I can't get apr to compile... gonna try a fresh install. --jason On Jul 4, 2008, at 12:23 PM, Russel Winder wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

RE: [groovy-dev] ant.inport from groovy?

Russel Winder — 2008-07-04T18:21:59

Chris, On Fri, 2008-07-04 at 14:48 +0100, Chris Miles wrote: Indeed. (And here was me hoping no-one would spot that :-) This is caused by the lack of integration between Ant projects and Gant scripts, the AntFile mechanism just gives access to the targets not to the processing of the targets. Getting this right deserves proper thought and not a quick hack, hence my proposal for it being a Gant 1.5.0 thing. I agree, but for now a necessity I'm afraid. If you fancy putting up a JIRA for this, then there is no chance the problem will get forgotten.

RE: [groovy-dev] ant.inport from groovy?

Chris Miles — 2008-07-04T13:48:21

Thanks Russel, That seems pretty good - however it seems that the dependencies of target init were not automatically processed. In the file brought in init depends on -macrodef. If I specify depends ( ['init'] ) I get Could not create task or type of type: read.build.properties. 'read.build.properties' is a macrodef defined in target '-macrodef'. If I specify depends ( ['-macrodef', 'init'] ) my job processes as required. This seems a bit of a drawback. Chris -----Original Message----- From: Russel Winder [mailto:russel.winder-DsImGR7CbQu8rjiVs5Nzzw< at >public.gmane.org] Sent: 04 July 2008 12:48 To: dev-i9PBDF1N6cxnkHa44VUL00B+6BGkLq7r< at >public.gmane.org Subject: Re: [groovy-dev] ant.inport from groovy? On Fri, 2008-07-04 at 12:35 +0100, Chris Miles wrote: ant.'import' currently loads the XML file into the Ant project but this does not make the target names available to the Gant framework -- it should perhaps but currently it does not. An a

[groovy-dev] OT: font readability (was: Fonts determine everything)

Martin C. Martin — 2008-07-04T12:43:50

Interesting, I wasn't aware of that research. Do you have any references I could read? I'd love to learn more. Best, Martin Russel Winder wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Fonts determine everything

Russel Winder — 2008-07-04T12:15:52

Actually it depends which research you look at regarding reading and readability. Of course facts often get hidden by opinion -- witness all the issues surrounding the fonts that got labelled "grotesque". Certainly it is the dogma that serif fonts be used for body text of documents with sans serif only used for headings or display text because serif fonts are easier to read. However this dogma is founded very much a print media and anyway has been subject to doubt with the arrival of the humanist fonts. The issue here is that screen rendering is very different to print rendering, not to mention that displays are light generative and not light reflective as paper is, and this makes some difference. For screen usage sans serif has come much more into its own for text since the fiddly little serifs don't generally render well at 92dpi or whatever the dot pitch of your screen is equivalent to. Of course this is where the humanist fonts come in, they are in the grey area between serif and sans serif.

Re: [groovy-dev] Fonts determine everything

Martin C. Martin — 2008-07-04T11:56:24

Russel Winder wrote: Serif fonts are generally considered a little easier to read, the serifs help distinguish the letters visually, freeing up more of your brain for coding. :) I'm not sure how big of a difference it is, but I don't know of any compelling argument against serif fonts. Best, Martin --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Fonts determine everything

Martin C. Martin — 2008-07-04T11:54:31

I've used a slightly modified version of Georgia for a long time. Georgia is pretty dense, i.e. you get more characters in a given number of pixels than most other fonts. All I had to do was add a slash through the zero, and modify the lower case "l" to look less like the number 1. I just downloaded some freeware/shareware font editor; the changes were trivial. Mark Derricutt wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Meta Object Protocol woes

Alex Tkachman — 2008-07-04T11:50:18

And it is what I recommend to everybody - don't use custom meta classes On Fri, Jul 4, 2008 at 2:36 PM, Graeme Rocher public.gmane.org> wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] ant.inport from groovy?

Russel Winder — 2008-07-04T11:48:25

ant.'import' currently loads the XML file into the Ant project but this does not make the target names available to the Gant framework -- it should perhaps but currently it does not. An as yet unpublished piece of work I had in mind for Gant 1.5.0 was to much better integrate the namespaces of the Ant project and the Gant framework. Currently (Gant 1.2.0 and later if I remember correctly) there is a tool AntFile which can be used to include an Ant XML file and which bridges things so that the targets from the Ant file are Gant targets: includeTool << gant.tools.AntFile antFile.includeTargets ( 'ant/xml/file/path/as/string' ) You can use a list of strings as well to include multiple files. Of course using File objects should be allowed as well but I don't think they are. Seems like a good thing for a JIRA issue!

Re: [groovy-dev] Meta Object Protocol woes

Russel Winder — 2008-07-04T11:37:02

Peter, As per Graeme's message, I am going to try using an ExpandoMetaClass as a base for GantMetaClass instead of the current implementation, but I think these issues we are looking at will still arise. On Fri, 2008-07-04 at 04:07 -0700, Peter Ledbrook wrote: Side issue: There is actually an question of whether the inner closure needs to have a special metaclass or whether it is sufficient for only the outer closure to have the specialist metaclass. Experimentally (assuming I did the experiment right) it makes no difference whatsoever whether the inner closure has GantMetaClass as its metaclass or its original one. I guess one solution is to transform the exception from GantBuilder back into a MissingMethodException, but that seems like a dreadful hack. The question is I guess how does this happen? What role does bb have with respect to the inner closure. This is definitely nail on head isn't it, it is down to making the attempted dispatch via the GantBuilder the last thing in the chain. That w

[groovy-dev] ant.inport from groovy?

Chris Miles — 2008-07-04T11:35:02

Hi - I want to invoke a couple of Ant targets before running my gant stuff. I can include my common ant stuff with ant.'import' ( file : 'buildSWFcommon.xml' ) but when I try target ('try13' : '' ) { depends ( 'init' ) // stuff using pre-defined properties and targets ... } (init is defined in buildSWFcommon.xml) I get Target `init' does not exist in this project. Using -d to gant I find that gant is looking for init in build.xml - which is strange. Can I invoke the buildSWFcommon.xml target 'init' ? Chris

Re: [groovy-dev] Meta Object Protocol woes

Russel Winder — 2008-07-04T11:34:11

Graeme, On Fri, 2008-07-04 at 12:18 +0100, Graeme Rocher wrote: Is that a lemma, theorem or axiom ;-) It is all water under the bridge now so no real point in worrying. The publishers have failed to deliver my copy of the book so I'll have to go back to the proofs I had -- unless I already threw them on the expectation of getting a copy of the final tome. I guess my main worry is that the problem is not just a metaclass technology one, it is actually a metaclass search algorithm implementation one, i.e. that the particular technology in use is a red herring, albeit an important issue.

Re: [groovy-dev] Meta Object Protocol woes

Graeme Rocher — 2008-07-04T11:18:27

On Fri, Jul 4, 2008 at 12:13 PM, Russel Winder public.gmane.org> wrote: The API that doesn't change == ExpandoMetaClass :-) I'm not sure where John was going with this, but I can't say I agree. All DMC does is delegate to another meta class, of course a side effect of this is that it always implements all interface provided/abstract methods which may have persuaded John to believe this, but certainly that is not the only thing that can cause breakage. There is also the semantics of the code and remove of methods all together. That is my view yes. Also refer to Venkat's book (http://www.pragprog.com/titles/vslg/programming-groovy) he has lots of great examples of this. Cheers

Re: [groovy-dev] Meta Object Protocol woes

Russel Winder — 2008-07-04T11:13:40

Graeme, On Fri, 2008-07-04 at 12:01 +0100, Graeme Rocher wrote: I agree with the sentiment regarding not working at the internals level. On the other hand a MOP is supposed to be there to be used, it just needs an API that is not subject to change -- at least not during 1.x since 2.x si when the new MOP happens. John answered this question originally by saying DelegatingMetaClass is the superclass to use as it is a guaranteed API that will never change. Then the API changed. Also it is malleable and I think it best to avoid that. If the best advice is now use ExpandoMetaClass and it can be used as an intercepting metaclass then it is certainly worth a try. Fortunately I think GantMetaClass can be changed without changing anything else in the Gant code. Definitely worth the experiment, and definitely worth tryin prior to releasing 1.4.0. I shall give up on trying to get Eclipse and IntelliJ IDEA to tell me stuff and just get on with writing new code :-)

Re: [groovy-dev] Meta Object Protocol woes

Peter Ledbrook — 2008-07-04T11:07:30

Russel Winder-4 wrote: Just to add fuel, here's my take on the problem. Let's imagine we have a Gant target like this: target(tgt : "Some description") { def bb = new BeanBuilder() bb.beans { i18nService(I18nService) } } The outer {}'s demarcate a closure (not a method body). All invocations inside that closure, including "i18nService(...)", go through GantMetaClass.invokeMethod(...). All well and good. The problem appears with that "i18nService(...)" method call. The method doesn't exist, so when GantMetaClass tries to invoke that method on the meta class that it's proxying, a big, fat MissingMethodException is thrown. Since the method doesn't appear to exist, GantMetaClass catches that exception and tries to call the method on its AntBuilder instead. Boom! That throws an InvokerSomethingException and the build breaks. Now, if GantMetaClass actually lets that MissingMethodException propagate out of invokeMethod(...), "i18nService(...)" ends up being called on the BeanB

Re: [groovy-dev] Meta Object Protocol woes

Graeme Rocher — 2008-07-04T11:01:23

On Fri, Jul 4, 2008 at 11:50 AM, Russel Winder concertant.com> wrote: My view on this is you should not be working at this level of the MOP as its subject to constant change, you should always work with a higher level abstraction that isn't going to change (like EMC). By implementing your own meta class you are working directly with the internals of Groovy can its really easy to make a hash of the dispatch logic even without realising it (introducing subtle bugs) Looking at GantMetaClass this is nothing you cannot do with EMC by overriding invokeMethod: http://groovy.codehaus.org/ExpandoMetaClass+-+GroovyObject+Methods Cheers

Re: [groovy-dev] Meta Object Protocol woes

Russel Winder — 2008-07-04T10:50:56

Graeme, On Fri, 2008-07-04 at 11:36 +0100, Graeme Rocher wrote: I am not sure the problem can be laid at the door of the custom metaclass (vs. ExpandoMetaClass). I need an intercepting metaclass. Initially I used DelegatingMetaClass as a superclass but now I have switched to a more minimal specialist class that has no superclass and implements all the requirements of MetaClass, MetaObjectProtocol and GroovyObject directly to try and avoid any areas of doubt and uncertainty. OK so it is a custom class but it is just a minimal intercepting metaclass. The problem here is the metaclass system itself

Re: [groovy-dev] Meta Object Protocol woes

Graeme Rocher — 2008-07-04T10:36:39

On Fri, Jul 4, 2008 at 11:16 AM, Russel Winder public.gmane.org> wrote: It is due to pain like this that we don't use any custom meta classes in Grails. Only ExpandoMetaClass Cheers

Re: [groovy-dev] Meta Object Protocol woes

Russel Winder — 2008-07-04T10:16:23

Alex, On Fri, 2008-07-04 at 12:29 +0400, Alex Tkachman wrote: That is exactly the code I found (and copied :-) for Gant and that is what is causing a) the errors that Gant had to go away; and b) introduce new errors into Gant. I was happy with a then Peter noted b cf. GANT-49 :-( Peter and I had a private email exchange which has shed some light on the problem, which really comes down to the interaction between overloading and method lookup search order. I am not sure of the exact problem nor the solution just now. Hopefully over the next few days, the light will dawn.

Re: [groovy-dev] Gant runs from Maven!

Peter Ledbrook — 2008-07-04T09:41:11

Russel Winder-4 wrote: This gets my vote. I would even be tempted to make it part of GMaven itself, rather than a sub-project but that's really up to others. Cheers, Peter