<br><font size=2 face="sans-serif">Hi Stephan,</font>
<br>
<br><font size=2 face="sans-serif">I worked on some of the problems this
week. One thing I fixed was the - too early - consistency checking
of TBs in the merging process. This fixed some of the errors in the OperatorTestCases.
However, due to a problem in reference resolving the tests are not green
yet. I can anyway push these fixes, perhaps they may also help you.</font>
<br>
<br><font size=2 face="sans-serif">BR.</font>
<br><font size=2 face="sans-serif">Thomas<br>
</font>
<table>
<tr>
<td valign=top><img src=cid:_1_0EB776D01449B6780027C493C12578CD>
<td><font size=3> </font>
<td><font size=1 face="Verdana"><b>Thomas Goldschmidt </b><br>
Dr.-Ing.<br>
Associate Scientist<br>
Industrial Software Technologies<br>
DECRC/I1<br>
<br>
ABB AG<br>
Forschungszentrum Deutschland<br>
Wallstadter Straße 59<br>
68526 Ladenburg<br>
Office Phone: +49 6203 716134<br>
Office Fax: +49 6203 716253<br>
e-mail:</font><font size=1 color=blue face="Verdana"> thomas.goldschmidt@de.abb.com<br>
</font></table>
<br>
<br><font size=1 color=#808080 face="Verdana">ABB AG<br>
Sitz/Head Office: Mannheim <br>
Registergericht/Registry Court: Mannheim<br>
Handelsregisternummer/Commercial Register No.: HRB 4664<br>
Vorstand/Managing Board: Dr. Peter Terwiesch (Vorsitzender/Chairman), Hans-Georg
Krabbe, Dr. Martin Schumacher, Markus Ochsner<br>
Vorsitzender des Aufsichtsrats/Chairman of Supervisory Board: Bernhard
Jucker<br>
<br>
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
erhalten haben, informieren Sie bitte sofort den Absender und vernichten
Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
dieser Mail ist nicht gestattet. <br>
<br>
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stephan Erb <stephan@dev.static-void.de></b>
</font>
<br><font size=1 face="sans-serif">Sent by: furcas-discussion-bounces@lists.furcas.org</font>
<p><font size=1 face="sans-serif">14.07.2011 02:52</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">furcas-discussion@lists.furcas.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [furcas-discussion] Where are things?</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hey,<br>
<br>
On Sun, 2011-07-10 at 11:36 +0200, Stephan Erb wrote:<br>
> No problem for the tests :-). Actually, these are not just some random<br>
> tests, but my materialized hope to present a working FURCAS/PCM Editor<br>
> during the upcoming final semester presentation (taking place in 2<br>
> weeks, but I have to create the screencasts a few days earlier).<br>
> <br>
> Given our progress during the last weeks, it does not seem likely
that<br>
> we can finish the bugs on time.<br>
<br>
<br>
I am running out of time, so here is a patch with some workarounds that<br>
'fix' 5 testcases. The patch is only fixing symptoms, because some of<br>
these TB merging, grammar generation concepts and invariants seem to be<br>
over my head.<br>
<br>
A short explanation of the changes:<br>
* Property inits (silently?) fail in OperatorTemplates
with<br>
right-associative (unary) operators . SetOCLRef
uses<br>
input.LT(-1) in order to find the token belonging
to the current<br>
template. The way right-associative operator
templates are<br>
mapped to ANTLR grammars, SetOCLRef ends up
being called before<br>
the operator is consumed and will therefore
retrieve the wrong<br>
token. Thus, any code relying on DelayedReference.token
might do<br>
something random.<br>
* I don't trust that EcoreHelper.isAlive is doing
the right thing<br>
in all cases. We cannot differentiate between
newly created<br>
TBs / model elements that have not yet been
assigned to a<br>
resource and the ones we have deleted explicitly.
I commented<br>
most isAlive calls because those seem to be
more or less<br>
optional and were only required to prevent
crashes in MOIN. <br>
* The TextBlocks merging in reuseTextBlockInternal
is sometimes<br>
working on invalid data: It performs a recursive
descend and<br>
folds empty TextBlocks at the end of each recursion
level.<br>
However, within sub-Blocks it sometimes needs
to traverse the<br>
current TB hierarchy up again and then fails
because it hits the<br>
empty but not-yet-deleted TextBlocks that are
subject to<br>
modification on a higher recursion level. I've
implemented a<br>
crude hack in getOriginalVersion to prevent
some obvious<br>
crashes.<br>
<br>
<br>
I will report back from the FZI if these workarounds are of any value<br>
for the real-world usecase.<br>
<br>
Best,<br>
Stephan<br>
<br>
<br>
<br>
[attachment "workarounds.patch" deleted by Thomas Goldschmidt/DEABB/ABB]
_______________________________________________<br>
Furcas-discussion mailing list<br>
Furcas-discussion@lists.furcas.org<br>
</font></tt><a href="http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion"><tt><font size=2>http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion<br>
</font></tt></a>
<br>