Home » Modeling » TMF (Xtext) » Issue with scope provider in Xtext 2.4
| Issue with scope provider in Xtext 2.4 [message #1021270] |
Tue, 19 March 2013 19:17  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I've just started migrating to Xtext/Xbase 2.4 and suddenly scoping
doesn't seem to work. Consider the DSL fragment below:
model test1
actor a1
String in ==> String out
actor a2
String in ==> String out
relation a1.out -> a2.in
The relation should be from actor a1's out port to actor a2's in port.
Suggestions and completion lets me select a1.out and a2.in, but
nevertheless these two qualified names won't link/resolve. Note that the
suggested names are test1.a1.out and test1.a2.in, but they are shortened
to a1.out and a2.in since my grammar only allows two segments.
A can see that the scope provided includes all the ports test.a1.in,
test.a1.out, test.a2.in and test.a2.out, but when searching for the
element named a1.out (or a2.in) it doesn't find them. In fact, when
stepping through the search, it seems that an anonymous subclass of
ImportScope in XbaseImportedNamespaceScopeProvider only considers names
with only 1 segment.
This worked nicely in Xtext 2.3, so what has happened?
Hallvard
|
|
|
| Re: Issue with scope provider in Xtext 2.4 [message #1021297 is a reply to message #1021270] |
Tue, 19 March 2013 20:42  |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
2.4 has changes in the provisional APIs around Xbase.
We've moved up the import section from Xtend to be easily included in
Xbase languages and had to change the contracts a bit.
We'll release a migration guide for xbase users in the coming days.
Sorry for the inconveniences,
Sven
Am 3/19/13 8:17 PM, schrieb Hallvard Trætteberg:
> Hi,
>
> I've just started migrating to Xtext/Xbase 2.4 and suddenly scoping
> doesn't seem to work. Consider the DSL fragment below:
>
> model test1
>
> actor a1
> String in ==> String out
>
> actor a2
> String in ==> String out
>
> relation a1.out -> a2.in
>
> The relation should be from actor a1's out port to actor a2's in port.
> Suggestions and completion lets me select a1.out and a2.in, but
> nevertheless these two qualified names won't link/resolve. Note that the
> suggested names are test1.a1.out and test1.a2.in, but they are shortened
> to a1.out and a2.in since my grammar only allows two segments.
>
> A can see that the scope provided includes all the ports test.a1.in,
> test.a1.out, test.a2.in and test.a2.out, but when searching for the
> element named a1.out (or a2.in) it doesn't find them. In fact, when
> stepping through the search, it seems that an anonymous subclass of
> ImportScope in XbaseImportedNamespaceScopeProvider only considers names
> with only 1 segment.
>
> This worked nicely in Xtext 2.3, so what has happened?
>
> Hallvard
--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de
|
|
|
| Re: Issue with scope provider in Xtext 2.4 [message #1021348 is a reply to message #1021297] |
Tue, 19 March 2013 22:49 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 19.03.13 13.42, Sven Efftinge wrote:
> 2.4 has changes in the provisional APIs around Xbase.
> We've moved up the import section from Xtend to be easily included in
> Xbase languages and had to change the contracts a bit.
I guessed that much.
> We'll release a migration guide for xbase users in the coming days.
Great! You don't have a beta of the guide, for those of us in need? In
general, when deprecating API, it would be great to have hint for where
to look for alternatives, if only a class name or two.
I also noticed that I cannot anymore use null as the return type for
toMethod to indicate void, since some mechanism seems to set the type to
a computed one, which in my case ends up being Object, though the method
body ends with a void method call.
Hallvard
> Sven
>
> Am 3/19/13 8:17 PM, schrieb Hallvard Trætteberg:
>> Hi,
>>
>> I've just started migrating to Xtext/Xbase 2.4 and suddenly scoping
>> doesn't seem to work. Consider the DSL fragment below:
>>
>> model test1
>>
>> actor a1
>> String in ==> String out
>>
>> actor a2
>> String in ==> String out
>>
>> relation a1.out -> a2.in
>>
>> The relation should be from actor a1's out port to actor a2's in port.
>> Suggestions and completion lets me select a1.out and a2.in, but
>> nevertheless these two qualified names won't link/resolve. Note that the
>> suggested names are test1.a1.out and test1.a2.in, but they are shortened
>> to a1.out and a2.in since my grammar only allows two segments.
>>
>> A can see that the scope provided includes all the ports test.a1.in,
>> test.a1.out, test.a2.in and test.a2.out, but when searching for the
>> element named a1.out (or a2.in) it doesn't find them. In fact, when
>> stepping through the search, it seems that an anonymous subclass of
>> ImportScope in XbaseImportedNamespaceScopeProvider only considers names
>> with only 1 segment.
>>
>> This worked nicely in Xtext 2.3, so what has happened?
>>
>> Hallvard
>
>
|
|
|
| Re: Issue with scope provider in Xtext 2.4 [message #1021543 is a reply to message #1021348] |
Wed, 20 March 2013 09:48 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Hallvard,
if you need to infer the type of a method from the expression in it's
body (assigned as the logically contained expression), use
JvmTypeBuilder.inferredType, or you could explicitly set Void.TYPE as
the return type. The former behavior was inconsistent and error prone.
Withouth a reproducable example it's hard to tell what's going on in
your scope provider. Please note that the 2.4 is first and foremost an
Xtend release - many newly introduced, provisional APIs are not yet
polished or documented and probably not even general purpose at the
moment. The underlying Xbase implementation will be improved,
streamlined and documented together with Kepler. Meanwhile you may want
to explore the XbaseBatchSCopeProvider. It is not a declarative scope
provider. Customizing is done like in
XbaseWithAnnotationsBatchScopeProvider.
Sorry for any inconvenience caused.
Regards,
Sebastian
Am 19.03.13 23:49, schrieb Hallvard Trætteberg:
> On 19.03.13 13.42, Sven Efftinge wrote:
>> 2.4 has changes in the provisional APIs around Xbase.
>> We've moved up the import section from Xtend to be easily included in
>> Xbase languages and had to change the contracts a bit.
>
> I guessed that much.
>
>> We'll release a migration guide for xbase users in the coming days.
>
> Great! You don't have a beta of the guide, for those of us in need? In
> general, when deprecating API, it would be great to have hint for where
> to look for alternatives, if only a class name or two.
>
> I also noticed that I cannot anymore use null as the return type for
> toMethod to indicate void, since some mechanism seems to set the type to
> a computed one, which in my case ends up being Object, though the method
> body ends with a void method call.
>
> Hallvard
>
>> Sven
>>
>> Am 3/19/13 8:17 PM, schrieb Hallvard Trætteberg:
>>> Hi,
>>>
>>> I've just started migrating to Xtext/Xbase 2.4 and suddenly scoping
>>> doesn't seem to work. Consider the DSL fragment below:
>>>
>>> model test1
>>>
>>> actor a1
>>> String in ==> String out
>>>
>>> actor a2
>>> String in ==> String out
>>>
>>> relation a1.out -> a2.in
>>>
>>> The relation should be from actor a1's out port to actor a2's in port.
>>> Suggestions and completion lets me select a1.out and a2.in, but
>>> nevertheless these two qualified names won't link/resolve. Note that the
>>> suggested names are test1.a1.out and test1.a2.in, but they are shortened
>>> to a1.out and a2.in since my grammar only allows two segments.
>>>
>>> A can see that the scope provided includes all the ports test.a1.in,
>>> test.a1.out, test.a2.in and test.a2.out, but when searching for the
>>> element named a1.out (or a2.in) it doesn't find them. In fact, when
>>> stepping through the search, it seems that an anonymous subclass of
>>> ImportScope in XbaseImportedNamespaceScopeProvider only considers names
>>> with only 1 segment.
>>>
>>> This worked nicely in Xtext 2.3, so what has happened?
>>>
>>> Hallvard
>>
>>
>
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Issue with scope provider in Xtext 2.4 [message #1021810 is a reply to message #1021543] |
Wed, 20 March 2013 18:05 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 20.03.13 02.48, Sebastian Zarnekow wrote:
>
> if you need to infer the type of a method from the expression in it's
> body (assigned as the logically contained expression), use
> JvmTypeBuilder.inferredType, or you could explicitly set Void.TYPE as
> the return type. The former behavior was inconsistent and error prone.
OK, so the use of null as the return type actually means "infer it".
I'll set it explicitly to void instead.
> Without a reproducable example it's hard to tell what's going on in
> your scope provider.
I can understand that, but the problem isn't my scope provider, it's how
new registrations and injections for xbase in the abstract runtime
module prevents my scope provider from being used at all! In my newly
regenerated abstract runtime module, I find registrations for various
batch scope providers, so it seems I need to subclass a different one,
to insert my own logic.
> The underlying Xbase implementation will be improved,
> streamlined and documented together with Kepler. Meanwhile you may want
> to explore the XbaseBatchSCopeProvider. It is not a declarative scope
> provider. Customizing is done like in XbaseWithAnnotationsBatchScopeProvider.
Yes, I found out now that it's XbaseWithAnnotationsBatchScopeProvider
that is used with the new registrations and injections.
> Sorry for any inconvenience caused.
I understand that it's difficult to maintain and evolve such a complex
framework without causing incompatibilities, particularly when people
like me hook into parts like Xbase that are semi-official. That's why
it's called bleeding edge, isn't it :-)
In any case, I'm very grateful for your work!
Hallvard
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 05:15:42 GMT 2024
Powered by FUDForum. Page generated in 0.02138 seconds |
] 
Search
Help
Register
Login
Home
