[furcas-discussion] Where are things?

[Stephan Erb]

That would be great. Thanks!

On Thu, 2011-07-14 at 10:42 +0200, Thomas Goldschmidt wrote:
> 
> Hi Stephan, 
> 
> The fix does not break anything. It is just that the tests I intended
> to fix with my modifications are still not green due to additional
> problems in reference resolving. I can push the changes tomorrow
> morning if you like. 
> 
> 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> 
> 
> 14.07.2011 10:37 
> 
> 
>                To
> Thomas
> Goldschmidt/DEABB/ABB at ABB 
>                cc
> 
>           Subject
> Re:
> [furcas-discussion] Where are things?
> 
> 
> 
> 
> 
> 
> 
> 
> 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
> > 
> 
> 
>