On 11 Jul 2011, at 18:27, Henry Story wrote:
>
> On 11 Jul 2011, at 18:06, Reto Bachmann-Gmür (JIRA) wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/CLEREZZA-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063414#comment-13063414
>> ]
>>
>> Reto Bachmann-Gmür commented on CLEREZZA-603:
>> ---------------------------------------------
>>
>> Your code is calling b_ on an explicitely specified EzMGraph, All the
>> examples should shows usage that either subclass EzMGraph to create an
>> instance or set the context to specific graph by importing the methods of an
>> EzMGraph instance, but I see the method coud be improved not to require
>> implict conversions thus allowing usage as you describe (have b_ return a
>> (Rich)GraphNode rather than a bnode.
>>
>> put the patched version in the svn folder issues/CLEREZZA-603?
>
> for me working on git, it's easier if I put the patch on github. The
> CLEREZZA-xxx folder structure is not very standards based, and is not
> visibile from github.
Sorry: I mean it's not visible from the git clone, even from the one you get
from the clerezza repository at
http://git.apache.org
>
> Furthermore in general it also has a problem in that sometimes changes in one
> module require some changes across different modules, one would have to copy
> a number of directories out into it.
So in this case my fix to the issue 603 then also required a fix to WebID
tester.
> You can easily pull down all from git.apache.org and then pull down from my
> github, work on it and put that up somewhere on your github. Then it is easy
> to work in a distributed manner, and it is very fast.
In fact that is the workflow that one can deduce from this git model which I
mentioned earlier today
http://nvie.com/posts/a-successful-git-branching-model/
> It also helps keep track of changes much better.
>
> Henry
>
>>
>> Cheers,
>> Reto
>>
>>> EzMGraph fails when working with more than one instance
>>> -------------------------------------------------------
>>>
>>> Key: CLEREZZA-603
>>> URL: https://issues.apache.org/jira/browse/CLEREZZA-603
>>> Project: Clerezza
>>> Issue Type: Bug
>>> Reporter: Henry Story
>>> Priority: Critical
>>> Original Estimate: 1h
>>> Remaining Estimate: 1h
>>>
>>> All the EzMGraph test cases currently assume that there is only one ez
>>> graph available per method.
>>> When one adds two EzMGraphs together in some code one gets a failure as the
>>> following test case shows when run in EzMGraphTest class:
>>> @Test
>>> def twographs {
>>> val ez1 = new EzMGraph() {(
>>> b_("reto") -- FOAF.name --> "Reto
>>> Bachman-Gmür".lang("rm")
>>> )}
>>> Assert.assertEquals("the two graphs should be equal",1,ez1.size)
>>> import ez1._
>>> ez1.b_("reto") -- FOAF.homepage --> "http://bblfish.net/".uri
>>> Assert.assertEquals("ez1 has grown by one",2,ez1.size)
>>> //now a second graph
>>> val ez2 = new EzMGraph() {(
>>> b_("hjs") -- FOAF.name --> "Henry Story"
>>> )}
>>> ez2.b_("hjs") -- FOAF.homepage --> "http://bblfish.net/".uri
>>> //both of these tests fail
>>> Assert.assertEquals("ez1 is the same size as it used to
>>> be",2,ez1.size)
>>> Assert.assertEquals("ez2 has grown by one",2,ez2.size)
>>> }
>>> This is caused by a bit too much implicit magic. EzMGraph extends
>>> TcDependentConversions which is defined as
>>> protected trait TcDependentConversions {
>>>
>>> def baseTc: TripleCollection
>>>
>>> implicit def toRichGraphNode(resource: Resource) = {
>>> new RichGraphNode(new GraphNode(resource, baseTc))
>>> }
>>> }
>>> So when developing this one has to import the toRichGraphNode method for
>>> the TripleCollection one is using.
>>> Hence you will see the first
>>> import ez1._
>>> above. The errors can be avoided if one enters a new import for ez2._ just
>>> before code using ez2 . The problem is that this will never be picked up by
>>> the compiler and the error will only be found at runtime. But then code
>>> would look like this
>>> import ez1._
>>> ez1.b_("reto") -- FOAF.homepage --> "http://bblfish.net/".uri
>>> import ez2._
>>> ez2.b_("hjs") -- FOAF.homepage --> "http://bblfish.net/".uri
>>> import ez1._
>>> ez1.b_("reto") -- FOAF.currentProject -->
>>> "http://clerezza.org/".uri
>>> The answer to this problem is simply to have the ez1.b_ method return a
>>> RichGraphNode directly containing the EzGraphNode from which it was called.
>>> It makes more sense anyway to have a Graph return a GraphNode when one asks
>>> for a node from it. Certainly a BNode outside of the context of a graph
>>> makes very little sense.
>>>
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
Social Web Architect
http://bblfish.net/
