Hi,
I debugged the example.
The error occurs when trying to match a "ver" edge. Based on the
fact that the target domain slot is not initialized I guess that it
is the edge from the top right node to the bottom right forbidden
node (in the diagram file).
The reason that the NAC does not match is because the domain of the
forbidden node is empty. I don't know yet why but I will see if I
can find out.
Cheers,
Enrico
On 08.06.2012 14:21, Christian Krause wrote:
I created a minimal example of the error. Copy the two files into
the 'combpattern' package and run it. It should not find a match.
The graph has this structure:
o---o
| |
o---o
| |
o---o
On 06/08/2012 02:05 PM, Christian Krause wrote:
Hi Enrico,
I still don't know where the problem is. I know exactly when and
where it happens (step #7) but I don't know why. No match for
the NAC is found. The graph is correct at this point and the
rule is also fine as far as I can tell. The debugging is really
difficult. I did not really understand what you meant by making
a rule for each constraint type. Can you maybe give me some more
hints how to debug this?
Cheers,
Christian
On 06/03/2012 11:06 AM, Enrico Biermann wrote:
Hi,
true, the optimization is not the problem, however it probably
uncovered a bug in the constraints. you could make a rule for
each constraint type present in the application condition of
addNewColumn and then switching the order of variables (a nice
side benefit is that these rules would also make great unit
tests).
At least one variable order of one rule should fail to match.
Regards,
Enrico
On 03.06.2012 10:53, Christian Krause wrote:
Hi,
I couldn't find a bug in the example. The optimization is
not the problem. I changed the order of the nodes in the NAC
and now I get the error with and without the optimization.
From the log I can see that the NAC was not correctly
checked. There does exist an object and two edge, so the
rule should not be applicable to this match. The interpreter
prints waring now that edges are deleted due to a side
effect. I still don't know why the match finder has a
problem.
Cheers
Christian
On 06/03/2012 10:38 AM, Enrico Biermann wrote:
Hi,
The order of variables should be irrelevant (for correct
results).
If it is not, then it points to either a missing
constraint or an incorrect handling of either initialized
or uninitialized domain slots for an existing constraint.
The order of nodes for the application condition of
addNewColumn was changed from 1, 2, 3, 4, 5 (order of
creation) to 3, 1, 4, 5, 2. So a constraint of 3, 4 or 5
should be responsible, but someone with knowledge of the
example should continue with the analysis.
Regards,
Enrico
On 02.06.2012 18:07, Christian Krause wrote:
Hi,
if you want to see why the optimization is important:
check out the latest version of the examples and run the
STSBenchmark with and without the optimization (order of
magnitude faster with optimization).
Enrico: does the MatchFinder assume any particular order
of the variables in the value lists returned by
ruleInfo.getVariableInfo().getGraph2variables() ? All I
was doing is to sort the lists.
Cheers,
Christian
On 06/02/2012 11:06 AM, Christian Krause wrote:
Hi,
I added the examples to the SVN. My last optimization
causes the comp-example to fail. I commented out the
optimization in line 342 of EngineImpl therefore. So
for now it works, but we should try to fix it so that
the optimization can be used. It seems like the NAC of
addNewColumn is not properly checked when the
optimization is used (nodes are added in every rule
application for the same match).
I turned on the logging. So if you want to try it out,
do this:
1) run CombBenchmarkManyMatches (works)
2) comment line 343 and uncomment 344-350 in
EngineImpl and execute it again (will not stop).
Cheers,
Christian
On 06/02/2012 10:06 AM, Dmitry Zakharov wrote:
Hi Christian,
I am giving you the short summery of all test cases.
With red I highlight those where hanshin is slower.
1) STS: Henshin is faster
2) LTS:
Henshin
StoryDiagram
N=20 R=10000 50541 ms 76562
ms
N=500 R=1 120765 ms 21505
ms
3) ALAP:
Henshin and SD have time same time
Nodes HENSHIN StoryDiagram
1000 468 ms 571 ms
5000 6973 ms 6751 ms
10000 29319 ms 30936 ms
4) Program Understanding : Henshin is
faster
5) Comb Many-Matches
Henshin Story
Diagram
Grid 50, pattern size 10 (2009
matches) 48725
1098 ms
Grid 50, pattern size 50 (49
matches) 46747
748 ms
6) Comb No-Match
Henshin
Story Diagram
Grid 200, pattern 10 38551 ms
1478 ms
Grid 200, pattern 50 54934 ms 3109
ms
regards, dmitry
on 02.06.2012 9:19, Christian Krause wrote:
Hi Dmitry,
I have one more request: could you briefly summarize where Henshin was
slower than SD and also give us a hint how much slower it was? This
would be very helpful for the profiling and optimization.
Cheers,
Christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|