commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claudio Squarcella <squar...@dia.uniroma3.it>
Subject Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Date Thu, 26 Jan 2012 17:13:51 GMT


On 26/01/2012 18:05, Matt Benson wrote:
> On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi
> <simonetripodi@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

same here. Maybe with another bit of tweaking like that (although that 
sounds a bit non-deterministic...)
Claudio

>
> 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
>> <simonetripodi@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<gudnabrsam@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
>>>> <simonetripodi@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
>>>>> <squarcel@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: squarcel@dia.uniroma3.it
>>>>>> Phone: +39-06-57333215
>>>>>> Fax: +39-06-57333612
>>>>>> http://www.dia.uniroma3.it/~squarcel
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

-- 
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message