| semantic change to resource with unresolved references [message #858821] |
Fri, 27 April 2012 06:01  |
Eclipse User |
|
|
|
Hi,
I have a question regarding semantic modifications to resources containing
unresolved lazy linking references.
When applying a semantic modification to a resource (e.g. using a semantic
quick fix) it is possible that the resource contains some unresolved lazy
linking references (i.e. "xtextLink_" proxies). The problem with these is that
the modification may invalidate the proxy URIs as they contain a path to the
object owning the reference, which may have changed as a result of the
modification.
The problem typically manifests itself as errors logged by LazyLinkingResource
("resolution of uriFragment 'xtextLink_::...' failed.") when serializing the
resource after the modification. But it could of course be worse: The URIs
could actually point to some other object in the AST and the serializer could
serialize the wrong thing.
I am looking into approaches to deal with this problem. Basically the
following come to mind:
1. Don't allow semantic modifications when the resource contains unresolved
lazy linking references. This of course works but is quite limiting. The JDT
doesn't have any problems with this nor would Xtext if the unresolved
references had a "normal" URI.
2. Fixup all unresolved lazy linking references after (or as part of) the
semantic change. This seems like a rather nasty thing to do...
Does anyone have experience with this problem or knows of other solutions?
Thanks,
--knut
|
|
|
|
|
| Re: semantic change to resource with unresolved references [message #859068 is a reply to message #859044] |
Fri, 27 April 2012 08:43  |
| Eclipse User |
|
|
|
Hi Knut
You may find the extra map has other advantages.
For OCL where there are distinct Concrete Syntax Trees (from Xtext) and
Abstract Syntax Trees (for the specification), I maintain a CSI
(Concrete Syntax Identifier) to AST element map, so that after an Xtext
edit the often substantially changed CST can be correlated against its
predecessor to drive a refresh of the AST. This avoids violating the
Xtext prohibition on maintaining references to the CST. The algorithm
for computing the CSI (rather than the URI) is a free choice so long as
each CST node acquires a unique and desirably stable refactorable identity.
Regards
Ed Willink
On 27/04/2012 13:30, Knut Wannheden wrote:
> Hi Sebastian,
>
> Performing a #resolveAll() prior to the modification is certainly a
> good idea. What I forgot to mention in the original post is that it's
> *unresolvable* lazy linking references causing the headache. These
> would of course remain unresolved after a #resolveAll().
>
> So it's down to either some kind of stabler ID mapping like you
> propose or a fixup of the lazy linking URIs. Neither seems very
> appealing... Your approach has the advantage that it would be
> transparent to the client. But it would require another map,
> preferably with weak references to the EObjects.
>
> Regards,
>
> --knut
>
> On 4/27/12 2:09 PM, Sebastian Zarnekow wrote:
>> Hi Knut,
>>
>> a #resolveAll prior to the semantic modification seems the way to go.
>> Another possibility is to adapt the lazy linking uris, e.g by
>> introducing some
>> sort of object to id map where the linking uri just holds the id of
>> an object
>> which was previously put into that map. Those should be pretty stable.
>> Other options don't come to my mind.
>>
>> Regards,
>> Sebastian
>
|
|
|
|
| Re: semantic change to resource with unresolved references [message #859470 is a reply to message #859158] |
Fri, 27 April 2012 12:54 |
| Eclipse User |
|
|
|
Hi Knut,
I like that approach. Do you have some numbers on the small performance
boost of #resolveLazyCrossReferences? I'd expect a small percentage
around 2 or 3? More importantly it seems to reduce the complexity of the
uri encoding / decoding algorithm.
Actually I find the shorter version of the lazy linking uri more
readable than the actual notation.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 27.04.12 15:37, schrieb Knut Wannheden:
> Hi Ed
>
> Thanks for the input.
>
> I've now implemented a custom LazyURIEncoder returning fragments like
> "xtextLink_::42" where 42 is the index in a List<Triple<EObject,
> EReference, INode>> which is a field declared by the LazyLinkingResource
> object.
>
> This makes both URI encoding and decoding very fast. Also all lazy
> linking proxies of a resource can be resolved very easily in
> #resolveLazyCrossReferences() by simply iterating over this list.
>
> Of course the URIs are very cryptic and not serializable, but that may
> not be a requirement. On the positive side this results in a small
> performance boost.
>
> Regards,
>
> --knut
>
> On 4/27/12 2:43 PM, Ed Willink wrote:
>> Hi Knut
>>
>> You may find the extra map has other advantages.
>>
>> For OCL where there are distinct Concrete Syntax Trees (from Xtext) and
>> Abstract Syntax Trees (for the specification), I maintain a CSI (Concrete
>> Syntax Identifier) to AST element map, so that after an Xtext edit the
>> often
>> substantially changed CST can be correlated against its predecessor to
>> drive a
>> refresh of the AST. This avoids violating the Xtext prohibition on
>> maintaining
>> references to the CST. The algorithm for computing the CSI (rather
>> than the
>> URI) is a free choice so long as each CST node acquires a unique and
>> desirably
>> stable refactorable identity.
>>
>> Regards
>>
>> Ed Willink
>>
>
>
|
|
|
| Re: semantic change to resource with unresolved references [message #865707 is a reply to message #859470] |
Mon, 30 April 2012 10:25 |
| Eclipse User |
|
|
|
Hi Sebastian,
On 4/27/12 6:54 PM, Sebastian Zarnekow wrote:
>
> I like that approach. Do you have some numbers on the small performance boost
> of #resolveLazyCrossReferences? I'd expect a small percentage around 2 or 3?
Right on the spot :-) 2 to 3 percent is what I measured. The linking phase of
the resource loading probably benefits the most from this change, as the lazy
linking URIs are faster to compute.
> More importantly it seems to reduce the complexity of the uri encoding /
> decoding algorithm.
> Actually I find the shorter version of the lazy linking uri more readable than
> the actual notation.
>
I quite like this as well. It probably comes at the price of a small memory
increase (the additional Triple objects and the List or Map object in the
resource) but I think the benefits (i.e. safe semantic modifications in
resources with unresolvable references) outweigh this.
I will file an enhancement request.
Regards,
--knut
|
|
|
Powered by
FUDForum. Page generated in 0.04025 seconds
Home