[furcas-discussion] Where are things?

[Stephan Erb]

Hey,

On Sun, 2011-07-10 at 11:36 +0200, Stephan Erb wrote:
> No problem for the tests :-). Actually, these are not just some random
> tests, but my materialized hope to present a working FURCAS/PCM Editor
> during the upcoming final semester presentation (taking place in 2
> weeks, but I have to create the screencasts a few days earlier).
> 
> Given our progress during the last weeks, it does not seem likely that
> we can finish the bugs on time.


I am running out of time, so here is a patch with some workarounds that
'fix' 5 testcases. The patch is only fixing symptoms, because some of
these TB merging, grammar generation concepts and invariants seem to be
over my head.

A short explanation of the changes:
      * Property inits (silently?) fail in OperatorTemplates with
        right-associative (unary) operators . SetOCLRef uses
        input.LT(-1) in order to find the token belonging to the current
        template. The way right-associative operator templates are
        mapped to ANTLR grammars, SetOCLRef ends up being called before
        the operator is consumed and will therefore retrieve the wrong
        token. Thus, any code relying on DelayedReference.token might do
        something random.
      * I don't trust that EcoreHelper.isAlive is doing the right thing
        in all cases. We cannot differentiate between newly created
        TBs / model elements that have not yet been assigned to a
        resource and the ones we have deleted explicitly. I commented
        most isAlive calls because those seem to be more or less
        optional and were only required to prevent crashes in MOIN. 
      * The TextBlocks merging in reuseTextBlockInternal is sometimes
        working on invalid data: It performs a recursive descend and
        folds empty TextBlocks at the end of each recursion level.
        However, within sub-Blocks it sometimes needs to traverse the
        current TB hierarchy up again and then fails because it hits the
        empty but not-yet-deleted TextBlocks that are subject to
        modification on a higher recursion level. I've implemented a
        crude hack in getOriginalVersion to prevent some obvious
        crashes.


I will report back from the FZI if these workarounds are of any value
for the real-world usecase.

Best,
Stephan



-------------- next part --------------
A non-text attachment was scrubbed...
Name: workarounds.patch
Type: text/x-patch
Size: 18253 bytes
Desc: not available
URL: <http://lists.furcas.org/pipermail/furcas-discussion/attachments/20110714/e2459708/attachment.bin>