> So I guess that means that if someone created a pure EMF/Java based > implementation (without thinking about pattern matching and search > strategies too much) the performance should be roughly the same as > FunnyQT? Yes, I think so.

Hi all, yesterday, I found out that the validator asserts wrong numbers of AND/OR elements for the performance test cases. The reason was that I didn't understand from the case description that in the or-rule, the places q and r may be identical. This case only occurs with the performance test cases, and then the action of the rule is simply to delete the transition t without doing anything else. I've grasped that by checking the EOL solution, since it's really not discussed in the case description. I've fixed the numbers in the validator right now. Sorry for the inconvenience. I've also added two LOCs to the FunnyQT solution to handle that case. Of course, that's only in the github repository but not in the image on SHARE.

No problem. The largest model (sp200000-pvg.petrinet) is also converted now, and available in the Github repo.

Great, thanks Pieter.

Seems I was slightly wrong. A HyperEdge e should be contained in the nearest compound state that contains all of its "next" and "rnext" states.

Ok. I've read "the output model should contain a single instance of Statechart..." as "it should already exist up to this point.

Hi Tassilo, >> Wrt. the "there's exactly one correct final model": >>Too bad, then I have a bug somewhere. ;-) Note that this is only for testcase 1 and 2. For testcase 3, this is not the case (as discussed in the case description and also clarified on http://planet-sl.org/community/index.php?option=com_community&view=groups&task=viewdiscussion&groupid=26&topicid=100&Itemid=387&lang=en). Best, P