Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » [Xtext 2.3] Using the new debugging features
[Xtext 2.3] Using the new debugging features [message #870258] Mon, 07 May 2012 13:29 Go to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Hi

I wanted to try the new debugging features you get with Xtext 2.3 and
Xbase, thus I wrote the JvmModelInferrence for my test DSL with some
Operation which should correspond to Java methods. However, the
correspondence between an Operation and the Java method is not direct
(e.g., like in the Domainmodel example); for instance I do (I'll try to
simplify)

@Inject extension JvmTypesBuilder

@Inject extension IQualifiedNameProvider

@Inject extension TypeReferences

@Inject extension TypeReferenceSerializer

@Inject XbaseCompiler xbaseCompiler

def dispatch void infer(Greeting element, IJvmDeclaredTypeAcceptor
acceptor, boolean isPreIndexingPhase) {
acceptor.accept(
element.toClass( element.fullyQualifiedName )
).initializeLater [
documentation = element.documentation
for (o : element.operations) {
members += o.toMethod(o.name,
o.output.returnType
) [
documentation = o.documentation
for (p : o.params) {
parameters += p.toParameter(p.name, p.parameterType)
}
body = [
val outputVarName = it.declareVariable(o, o.simpleName)
o.parameterType.serialize(o, it)
it.append(" " + outputVarName + " = null; // output parameter")

xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)

it.generateFinalReturnStatement(o.output)
]
]
}
]
}

So you see, before doing the actual xbase compilation (with an injected
XbaseCompiler) I declare into the generated code an additional variable.
Here are again the relevant lines

body = [
val outputVarName = it.declareVariable(o, o.simpleName)
o.parameterType.serialize(o, it)
it.append(" " + outputVarName + " = null; // output parameter")

xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
]

Everything works fine (of course, I customized some scoping and
validation so that the generated code is consistent and checks work
correctly), but the debugger does not really work as expected: if I
enter, from Java code, into one of the generated Java methods the
debugger skips the first line of the original Operation (and it is kind
of messed up then)... I guess that's because the ITreeAppendable I use
for generating code should be somehow configured to skip the generated
Java line for the additional variable, shouldn't it? It is not clear,
however, how to use the ITreeAppendable API to achieve this (I guess the
same should be done for the additional final generated return statement).

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


Re: [Xtext 2.3] Using the new debugging features [message #873040 is a reply to message #870258] Thu, 17 May 2012 11:31 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
any help please?

thanks in advance
Lorenzo

On 05/07/2012 03:29 PM, Lorenzo Bettini wrote:
> Hi
>
> I wanted to try the new debugging features you get with Xtext 2.3 and
> Xbase, thus I wrote the JvmModelInferrence for my test DSL with some
> Operation which should correspond to Java methods. However, the
> correspondence between an Operation and the Java method is not direct
> (e.g., like in the Domainmodel example); for instance I do (I'll try to
> simplify)
>
> @Inject extension JvmTypesBuilder
>
> @Inject extension IQualifiedNameProvider
>
> @Inject extension TypeReferences
>
> @Inject extension TypeReferenceSerializer
>
> @Inject XbaseCompiler xbaseCompiler
>
> def dispatch void infer(Greeting element, IJvmDeclaredTypeAcceptor
> acceptor, boolean isPreIndexingPhase) {
> acceptor.accept(
> element.toClass( element.fullyQualifiedName )
> ).initializeLater [
> documentation = element.documentation
> for (o : element.operations) {
> members += o.toMethod(o.name,
> o.output.returnType
> ) [
> documentation = o.documentation
> for (p : o.params) {
> parameters += p.toParameter(p.name, p.parameterType)
> }
> body = [
> val outputVarName = it.declareVariable(o, o.simpleName)
> o.parameterType.serialize(o, it)
> it.append(" " + outputVarName + " = null; // output parameter")
>
> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
>
> it.generateFinalReturnStatement(o.output)
> ]
> ]
> }
> ]
> }
>
> So you see, before doing the actual xbase compilation (with an injected
> XbaseCompiler) I declare into the generated code an additional variable.
> Here are again the relevant lines
>
> body = [
> val outputVarName = it.declareVariable(o, o.simpleName)
> o.parameterType.serialize(o, it)
> it.append(" " + outputVarName + " = null; // output parameter")
>
> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
> ]
>
> Everything works fine (of course, I customized some scoping and
> validation so that the generated code is consistent and checks work
> correctly), but the debugger does not really work as expected: if I
> enter, from Java code, into one of the generated Java methods the
> debugger skips the first line of the original Operation (and it is kind
> of messed up then)... I guess that's because the ITreeAppendable I use
> for generating code should be somehow configured to skip the generated
> Java line for the additional variable, shouldn't it? It is not clear,
> however, how to use the ITreeAppendable API to achieve this (I guess the
> same should be done for the additional final generated return statement).
>
> thanks in advance
> Lorenzo
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


Re: [Xtext 2.3] Using the new debugging features [message #873077 is a reply to message #873040] Thu, 17 May 2012 13:14 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
probably I figured this out myself... as soon as I'm sure about that
I'll post the solution :)

On 05/17/2012 01:31 PM, Lorenzo Bettini wrote:
> any help please?
>
> thanks in advance
> Lorenzo
>
> On 05/07/2012 03:29 PM, Lorenzo Bettini wrote:
>> Hi
>>
>> I wanted to try the new debugging features you get with Xtext 2.3 and
>> Xbase, thus I wrote the JvmModelInferrence for my test DSL with some
>> Operation which should correspond to Java methods. However, the
>> correspondence between an Operation and the Java method is not direct
>> (e.g., like in the Domainmodel example); for instance I do (I'll try to
>> simplify)
>>
>> @Inject extension JvmTypesBuilder
>>
>> @Inject extension IQualifiedNameProvider
>>
>> @Inject extension TypeReferences
>>
>> @Inject extension TypeReferenceSerializer
>>
>> @Inject XbaseCompiler xbaseCompiler
>>
>> def dispatch void infer(Greeting element, IJvmDeclaredTypeAcceptor
>> acceptor, boolean isPreIndexingPhase) {
>> acceptor.accept(
>> element.toClass( element.fullyQualifiedName )
>> ).initializeLater [
>> documentation = element.documentation
>> for (o : element.operations) {
>> members += o.toMethod(o.name,
>> o.output.returnType
>> ) [
>> documentation = o.documentation
>> for (p : o.params) {
>> parameters += p.toParameter(p.name, p.parameterType)
>> }
>> body = [
>> val outputVarName = it.declareVariable(o, o.simpleName)
>> o.parameterType.serialize(o, it)
>> it.append(" " + outputVarName + " = null; // output parameter")
>>
>> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
>>
>> it.generateFinalReturnStatement(o.output)
>> ]
>> ]
>> }
>> ]
>> }
>>
>> So you see, before doing the actual xbase compilation (with an injected
>> XbaseCompiler) I declare into the generated code an additional variable.
>> Here are again the relevant lines
>>
>> body = [
>> val outputVarName = it.declareVariable(o, o.simpleName)
>> o.parameterType.serialize(o, it)
>> it.append(" " + outputVarName + " = null; // output parameter")
>>
>> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
>> ]
>>
>> Everything works fine (of course, I customized some scoping and
>> validation so that the generated code is consistent and checks work
>> correctly), but the debugger does not really work as expected: if I
>> enter, from Java code, into one of the generated Java methods the
>> debugger skips the first line of the original Operation (and it is kind
>> of messed up then)... I guess that's because the ITreeAppendable I use
>> for generating code should be somehow configured to skip the generated
>> Java line for the additional variable, shouldn't it? It is not clear,
>> however, how to use the ITreeAppendable API to achieve this (I guess the
>> same should be done for the additional final generated return statement).
>>
>> thanks in advance
>> Lorenzo
>>
>
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


Re: [Xtext 2.3] Using the new debugging features [message #875431 is a reply to message #873077] Tue, 22 May 2012 18:36 Go to previous message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
here's the article I wrote about this example

http://www.rcp-vision.com/?p=4089&lang=en

any comment is more than welcome :)

Lorenzo

On 05/17/2012 03:14 PM, Lorenzo Bettini wrote:
> probably I figured this out myself... as soon as I'm sure about that
> I'll post the solution :)
>
> On 05/17/2012 01:31 PM, Lorenzo Bettini wrote:
>> any help please?
>>
>> thanks in advance
>> Lorenzo
>>
>> On 05/07/2012 03:29 PM, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> I wanted to try the new debugging features you get with Xtext 2.3 and
>>> Xbase, thus I wrote the JvmModelInferrence for my test DSL with some
>>> Operation which should correspond to Java methods. However, the
>>> correspondence between an Operation and the Java method is not direct
>>> (e.g., like in the Domainmodel example); for instance I do (I'll try to
>>> simplify)
>>>
>>> @Inject extension JvmTypesBuilder
>>>
>>> @Inject extension IQualifiedNameProvider
>>>
>>> @Inject extension TypeReferences
>>>
>>> @Inject extension TypeReferenceSerializer
>>>
>>> @Inject XbaseCompiler xbaseCompiler
>>>
>>> def dispatch void infer(Greeting element, IJvmDeclaredTypeAcceptor
>>> acceptor, boolean isPreIndexingPhase) {
>>> acceptor.accept(
>>> element.toClass( element.fullyQualifiedName )
>>> ).initializeLater [
>>> documentation = element.documentation
>>> for (o : element.operations) {
>>> members += o.toMethod(o.name,
>>> o.output.returnType
>>> ) [
>>> documentation = o.documentation
>>> for (p : o.params) {
>>> parameters += p.toParameter(p.name, p.parameterType)
>>> }
>>> body = [
>>> val outputVarName = it.declareVariable(o, o.simpleName)
>>> o.parameterType.serialize(o, it)
>>> it.append(" " + outputVarName + " = null; // output parameter")
>>>
>>> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
>>>
>>> it.generateFinalReturnStatement(o.output)
>>> ]
>>> ]
>>> }
>>> ]
>>> }
>>>
>>> So you see, before doing the actual xbase compilation (with an injected
>>> XbaseCompiler) I declare into the generated code an additional variable.
>>> Here are again the relevant lines
>>>
>>> body = [
>>> val outputVarName = it.declareVariable(o, o.simpleName)
>>> o.parameterType.serialize(o, it)
>>> it.append(" " + outputVarName + " = null; // output parameter")
>>>
>>> xbaseCompiler.compile(o.body, it, "void".getTypeForName(o), null)
>>> ]
>>>
>>> Everything works fine (of course, I customized some scoping and
>>> validation so that the generated code is consistent and checks work
>>> correctly), but the debugger does not really work as expected: if I
>>> enter, from Java code, into one of the generated Java methods the
>>> debugger skips the first line of the original Operation (and it is kind
>>> of messed up then)... I guess that's because the ITreeAppendable I use
>>> for generating code should be somehow configured to skip the generated
>>> Java line for the additional variable, shouldn't it? It is not clear,
>>> however, how to use the ITreeAppendable API to achieve this (I guess the
>>> same should be done for the additional final generated return
>>> statement).
>>>
>>> thanks in advance
>>> Lorenzo
>>>
>>
>>
>
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


Previous Topic:whitespaces not allowed in grammar
Next Topic:Templates for Xtext
Goto Forum:
  


Current Time: Thu Apr 25 00:07:46 GMT 2024

Powered by FUDForum. Page generated in 0.03002 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top