incubator-clerezza-dev mailing list archives

Re: [jira] [Commented] (CLEREZZA-603) EzMGraph fails when working with more than one instance

Date

Tue, 12 Jul 2011 06:07:16 GMT

On 12 Jul 2011, at 01:43, Reto Bachmann-Gmür wrote:
> Hi Henry
>
> I wouldn't mind changing the structure we use in svn branches if that
> helps we can put the issue branches into branches rather than into
> issues.
>
> How exactly should we look at the patch you propose for CLEREZZA-603?
the easiest is to
$ git clone git@github.com:bblfish/clerezza.git
$ git checkout zz_issues
$ git diff HEAD^
or
$ git diff trunk
That is it.
If you want you can also checkout the apache git first. So starting from scratch
$ git clone git://git.apache.org/clerezza.git
Then you can fetch (don't pull - as that merges) my github version.
It is easy then to tie that git repository in to svn so that you
can commit into the trunk by following the "Git for Apache committers"
on the Apache wiki
http://wiki.apache.org/general/GitAtApache
Just remember that our project is incubator/clerezza not clerezza.
You can then commit with
$ git svn dcommit
$ git svn rebase
I can also send you a patch old style, though I have never tried that yet.
We could also create a branch per issue. But in svn that may just be a bit excessive. Not
sure.
It's the merging that is made a lot easier I am told in git. (some say it is close to impossible
in svn).
Henry
>
> Reto
>
>
> On Mon, Jul 11, 2011 at 7:21 PM, Henry Story <henry.story@bblfish.net> wrote:
>>
>> 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/
>>
>>
Social Web Architect
http://bblfish.net/