[furcas-discussion] Where are things?

[Stephan Erb]

Hi Thomas,

does your fix break reference resolving in general, or is it just that
our reference resolving tests fail? Most of the latter tend to use
ForEach which is not relevant for me at the moment...

Thanks!,
Stephan

On Thu, 2011-07-14 at 09:14 +0200, Thomas Goldschmidt wrote:
> 
> Hi Stephan, 
> 
> 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. 
> 
> BR. 
> Thomas
> 
>   
> Thomas Goldschmidt 
> Dr.-Ing.
> Associate Scientist
> Industrial Software
> Technologies
> DECRC/I1
> 
> ABB AG
> Forschungszentrum
> Deutschland
> Wallstadter Straße 59
> 68526 Ladenburg
> Office Phone: +49 6203
> 716134
> Office Fax: +49 6203
> 716253
> e-mail:
> thomas.goldschmidt at de.abb.com
> 
> 
> 
> ABB AG
> Sitz/Head Office: Mannheim 
> Registergericht/Registry Court: Mannheim
> Handelsregisternummer/Commercial Register No.: HRB 4664
> Vorstand/Managing Board: Dr. Peter Terwiesch (Vorsitzender/Chairman),
> Hans-Georg Krabbe, Dr. Martin Schumacher, Markus Ochsner
> Vorsitzender des Aufsichtsrats/Chairman of Supervisory Board: Bernhard
> Jucker
> 
> 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. 
> 
> 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. 
> 
> 
> Stephan Erb
> <stephan at dev.static-void.de> 
> Sent by:
> furcas-discussion-bounces at lists.furcas.org 
> 
> 14.07.2011 02:52 
> 
> 
>                To
> furcas-discussion at lists.furcas.org 
>                cc
> 
>           Subject
> Re:
> [furcas-discussion] Where are things?
> 
> 
> 
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> [attachment "workarounds.patch" deleted by Thomas
> Goldschmidt/DEABB/ABB] _______________________________________________
> Furcas-discussion mailing list
> Furcas-discussion at lists.furcas.org
> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion
>