[furcas-discussion] Reference Re-Evaluation Algorithm

[Stephan Erb]

Thursday and/or Friday are fine for Sebastian and me.

Best,
Stephan

On Mon, 2011-02-14 at 10:24 +0100, Thomas Goldschmidt wrote:
> 
> Except for the 28th itself that's fine with me. Maybe, as last time,
> starting 15:30 or 16:00?


> 
> Makes sense for me. The week starting Feb28 would be good. If that
> works for everyone else, I can organize a room. I'm flexible that
> week. Let me know which days work for you. 
>   
> Best, 
> -- Axel 
>   
> From: furcas-discussion-bounces at lists.furcas.org
> [mailto:furcas-discussion-bounces at lists.furcas.org] On Behalf Of
> Thomas Goldschmidt
> Sent: Monday, February 14, 2011 8:36 AM
> To: furcas-discussion
> Subject: Re: [furcas-discussion] Reference Re-Evaluation Algorithm 
>   
> 
> Sounds like a plan, should we schedule an on-site meeting for that?
> What do you think? 
> 
> 
>   
> Thomas Goldschmidt 
> 
> ABB AG
> Forschungszentrum
> 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
> Geschäftsführung/Managing Board: Peter Smits (Vorsitzender), Joachim
> Schneider, Markus Ochsner, Hans-Georg Krabbe
> 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. 
> 
> 
> Axel Uhl <axel.uhl at gmx.de> 
> Sent by:
> furcas-discussion-bounces at lists.furcas.org 
> 
> 11.02.2011 20:57 
> 
> 
> 
>                To
> Stephan Erb
> <stephan at dev.static-void.de> 
>                cc
> furcas-discussion
> <furcas-discussion at lists.furcas.org> 
>           Subject
> Re:
> [furcas-discussion] Reference Re-Evaluation Algorithm
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> +1
> 
> On 02/11/2011 08:35 PM, Stephan Erb wrote:
> > Hey Axel,
> >
> > I have no clue. Your proposal sounds reasonable to me but I wouldn't
> bet
> > on it, given the fact that sometimes TextBlocks are merged if they
> don't
> > contribute to the concrete syntax.
> >
> > This discussion somewhat implies to me that we are wasting our
> energy:
> > Our second-most important data structure, the TextBlocks model, is
> so
> > complex and underspecified that we constantly struggle with it.
> >
> > I would suggest that we try to redesign the TextBlocks model so that
> it
> > is easier to handle. For example, each TextBlock could have exactly
> one
> > corresponding ModelElement. If TextBlocks contain no concrete
> syntax,
> > then they would simply have no subnodes.  I guess we can think of
> even
> > more simplifications.
> >
> > This is additional short term effort, but I am very sure it is a
> > worthwhile investment.
> >
> >
> > Best Regards,
> > Stephan
> >
> >
> > On Fri, 2011-02-11 at 17:19 +0100, Uhl, Axel wrote:
> >> Stephan,
> >>
> >> thinking about this again suggest something else. I don't think we
> want to rely on the token's referencedElements to be set in order to
> determine whether the token is the one that belongs to the update
> notification received. The token may be stale anyway because it was in
> some remote resource that didn't get updated upon an earlier change.
> >>
> >> Instead, we should be looking for the token's parent text blocks.
> They should lead to a text block, ultimately, whose corresponding
> model element is the one to be updated with the resolution of the
> token, shoulnd't it?
> >>
> >> I'm just uncertain again how the LexedToken may be nested inside
> TextBlocks. Can I assume that the LexedToken's getParent() is the
> template that has in its correspondingModelElements the element to be
> updated with the property?
> >>
> >> -- Axel
> >>
> >>> -----Original Message-----
> >>> From: furcas-discussion-bounces at lists.furcas.org [mailto:furcas-
> >>> discussion-bounces at lists.furcas.org] On Behalf Of Stephan Erb
> >>> Sent: Friday, February 11, 2011 3:12 PM
> >>> To: furcas-discussion
> >>> Subject: Re: [furcas-discussion] Reference Re-Evaluation Algorithm
> >>>
> >>>>> PS: Thomas, we might need your help with all this textblocks
> magic
> >>>>> (e.g.
> >>>>> find out if a reference is still bound). Expect some questions
> on
> >>> the
> >>>>> mailing list rather soon :-)
> >>>>
> >>>> I found that out myself. In this case it was an easy reverse
> lookup
> >>> on DocumentNode_SequenceElement using the OppositeEndFinder API.
> >>>
> >>> Hi Axel,
> >>>
> >>> I just had a (very) short look at the OCLQueryPropertyUpdate. Is
> there
> >>> a
> >>> reason why the 'referencedElements' aren't checked anywhere? I
> always
> >>> thought that those entail the crucial information whether a token
> is
> >>> bound to something or not.
> >>>
> >>> Example from the MOIN code base where used them:
> >>>
> >>>      private Collection<?>
>  findCurrentlySetElements(DelayedReference
> >>> unresolvedRef, ModelInjector modelInjector,
> >>>                      LexedToken tokenInCurrentConnection) throws
> >>> ModelAdapterException {
> >>>
> >>>                  Collection<?>  valueCollection =
> >>>
> modelInjector.getModelAdapter().get(unresolvedRef.getModelElement(),
> >>> unresolvedRef.getPropertyName());
> >>>                  if (tokenInCurrentConnection != null) {
> >>>
> >>>
> valueCollection.retainAll(tokenInCurrentConnection.getReferencedElement
> >>> s());
> >>>                  }
> >>>                  return valueCollection;
> >>>      }
> >>>
> >>> Best,
> >>> Stephan
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Furcas-discussion mailing list
> >>> Furcas-discussion at lists.furcas.org
> >>> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion
> >
> >
> 
> -- 
> Find Security Certificate at http://www.axel-uhl.de/cgi-bin/cacert.cgi
> 
> [attachment "smime.p7s" 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 
> 
> 
> _______________________________________________
> Furcas-discussion mailing list
> Furcas-discussion at lists.furcas.org
> http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion