On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi <simonetrip...@apache.org> wrote: > FIXED!!!! > > Emanuele Lombardi, a former colleague of mine, simply did > > - public static <V extends Vertex, W, WE extends WeightedEdge<W>, G > extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G> > minimumSpanningTree( G graph ) > + public static <V extends Vertex, WE extends WeightedEdge<W>, W, G > extends Graph<V, WE>> SpanningTreeSourceSelector<V, W, WE, G> > minimumSpanningTree( G graph ) > > and it makes it working!!!! > Isn't that cool?
Hmm... doesn't seem to be working here on: Eclipse Platform Version: 3.7.1 Build id: M20110909-1335 Matt :| > All the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi > <simonetrip...@apache.org> wrote: >> Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! >> We do - at least, I - love you! :D >> >>> on. I can only surmise that the Oracle (?) compiler may take the >>> subsequent method calls into account when trying to infer type >>> parameters from arguments, perhaps. >> >> I am using the Apple's JDK: >> >> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) >> Maven home: /Applications/apache-maven-3.0.4 >> Java version: 1.6.0_29, vendor: Apple Inc. >> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home >> Default locale: en_US, platform encoding: MacRoman >> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >> >>> however one thing that springs to mind is to take the >>> CommonsGraph fluent APIs and move them to some typed interface, then >>> have each level of the interface hierarchy define a public static >>> final instance of this fluent interface that knows how to behave >>> appropriately for that type...? Not sure if this would work properly >>> in practice, but the best idea I'm likely to come up with. >> >> this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an >> interface where generic types are inferred depending on the graph >> input. >> >> Thanks *a lot* for your kind help, always much more than appreciated!!! >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> Whew... I hope you guys love me. :P I decided to take a look just >>> because I've had to play with Eclipse before on issues like this. >>> What I typically find is that Eclipse has a sane reason for >>> complaining where it does. This time I *really* thought Eclipse was >>> wrong... but check this out: >>> >>> In the FordFulkersonTestCase, if you break this down statement by >>> statement, what Eclipse is complaining about is "findMaxFlow(graph);". >>> Now, if you use Eclipse's 'Assign to local variable' quick assist, >>> you find that it creates a variable of type: >>> >>> FromHeadBuilder<BaseLabeledVertex, Object, >>> BaseLabeledWeightedEdge<Integer>, >>> DirectedMutableWeightedGraph<BaseLabeledVertex, >>> BaseLabeledWeightedEdge<Integer>, Integer>> >>> >>> Note that it has calculated the W type parameter to be Object. >>> >>> I am reasonably sure that the reason for this is that >>> CommonsGraph.findMaxFlow's <G> type parameter is declared as "G >>> extends DirectedGraph<V, WE>". Thus the fact that our >>> DirectedMutableWeightedGraph 'graph' has its W type parameter assigned >>> as Integer is completely irrelevant as far as #findMaxFlow() is >>> concerned. There is no way for the compiler to infer that >>> #findMaxFlow<W> should be Integer in the context of the fully chained >>> call. By contrast, simply changing Object to Integer in the signature >>> of Eclipse's generated local variable gives the compiler enough to go >>> on. I can only surmise that the Oracle (?) compiler may take the >>> subsequent method calls into account when trying to infer type >>> parameters from arguments, perhaps. >>> >>> So that's my diagnosis. How to cope with it while retaining fluency >>> is another story. I'm not familiar enough with the domain or the API >>> to be able to make any recommendation that would probably be terribly >>> useful; however one thing that springs to mind is to take the >>> CommonsGraph fluent APIs and move them to some typed interface, then >>> have each level of the interface hierarchy define a public static >>> final instance of this fluent interface that knows how to behave >>> appropriately for that type...? Not sure if this would work properly >>> in practice, but the best idea I'm likely to come up with. >>> >>> HTH, >>> Matt >>> >>> On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi >>> <simonetrip...@apache.org> wrote: >>>> Hi Claudio!!! >>>> >>>> thanks for reporting, I have indeed the same issue - even if I thought >>>> was just an Eclipse bug! >>>> I honestly don't know how to fix the problem, I hope someone in the ML >>>> can provide a solution as well - same behavior met in IntelliJ!!! >>>> >>>> All the best, >>>> -Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella >>>> <squar...@dia.uniroma3.it> wrote: >>>>> P.S. for completeness: >>>>> >>>>> Eclipse version: Indigo Service Release 1 >>>>> Build id: 20110916-0149 >>>>> OS: Mac OS X Lion >>>>> >>>>> Cheers, >>>>> Claudio >>>>> >>>>> >>>>> On 26/01/2012 15:30, Claudio Squarcella wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I am experiencing a rather annoying issue with the latest version of >>>>>> commons-graph on Eclipse. Compiling with javac (maven, command line) it >>>>>> works fine, but the editor still complains: e.g. line 72 of the new >>>>>> FordFulkersonTestCase[1] gives a list of errors[2]. >>>>>> >>>>>> Now, I know from googling that Eclipse is not new to strange behavior, >>>>>> but >>>>>> I wanted to know if anyone on the ML has a nice answer, solution or >>>>>> workaround (other than standard answers like "use another IDE"), or at >>>>>> least >>>>>> experiences the same issue with the code. >>>>>> >>>>>> Thank you, >>>>>> Claudio >>>>>> >>>>>> --- >>>>>> >>>>>> [1] >>>>>> https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827&view=markup >>>>>> [2] Multiple markers at this line >>>>>> - Bound mismatch: The generic method applyingFordFulkerson(OM) of type >>>>>> MaxFlowAlgorithmSelector<V,W,WE,G> is not applicable for the arguments >>>>>> (IntegerWeight). The >>>>>> inferred type IntegerWeight is not a valid substitute for the bounded >>>>>> parameter <OM extends OrderedMonoid<Object>> >>>>>> - Type mismatch: cannot convert from Object to Integer >>>>>> - Bound mismatch: The generic method findMaxFlow(G) of type >>>>>> CommonsGraph<V,E,G> is not applicable for the arguments >>>>>> >>>>>> (DirectedMutableWeightedGraph<BaseLabeledVertex,BaseLabeledWeightedEdge<Integer>,Integer>). >>>>>> The inferred type BaseLabeledWeightedEdge<Integer> is not a valid >>>>>> substitute >>>>>> for the bounded parameter <WE extends WeightedEdge<W>> >>>>>> >>>>> >>>>> -- >>>>> Claudio Squarcella >>>>> PhD student at Roma Tre University >>>>> E-mail address: squar...@dia.uniroma3.it >>>>> Phone: +39-06-57333215 >>>>> Fax: +39-06-57333612 >>>>> http://www.dia.uniroma3.it/~squarcel >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
