Home » Modeling » TMF (Xtext) » Using Xbase in own grammar
| Using Xbase in own grammar [message #691468] |
Fri, 01 July 2011 13:26  |
Eclipse User |
|
|
|
Originally posted by:
Hi,
I'm still struggling with Xbase, but at least my setup seems to be
correct now. Now I consistently get out of heap error:
at
org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
... 16 more
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2786)
at sun.misc.Resource.getBytes(Resource.java:101)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
I suppose this is because the grammar becomes too large, although my
grammar does only contain 10 or so rules, with only two references to
XExpression.
I can set the heap size with the mx option to 1536 mb, but if I try
2048, the MacOSX (Snow Leopard) Java VM will not start.
Now I wonder what strategies I can use to make the grammar "smaller" in
a way that will make the generator survive.
One option is to remove features of the language, e.g. by redefining the
rule for XPrimaryExpression or XLiteral. E.g. if I include the following
rule I don't run out of memory:
XPrimaryExpression returns xbase::XExpression:
XConstructorCall |
XBlockExpression |
// XSwitchExpression |
XFeatureCall |
XLiteral |
XIfExpression |
// XForLoopExpression |
// XWhileExpression |
// XDoWhileExpression |
// XThrowExpression |
// XReturnExpression |
// XTryCatchFinallyExpression |
XParenthesizedExpression;
However, this will reduce the whole Xbase language, not specific usages
in some (problematic) contexts.
Another option is to make my own rules refer to special subclasses of
XExpression, to limit the legal constructs on that context. E.g. if I
only want simple expressions, I could refer to XOrExpression, which
disallows assignments. But this will still allow blocks etc.
Of course a combination of these two strategies are possible, but it's
difficult to find a balance between crippling the whole language (which
is nice, BTW) and limiting the options in contexts where grammar
ambiguities occur. In the extreme you could define several sub-languages
with different power that can be used on parallel, but this will of
course make the grammar large (text-wise) and difficult to maintain.
Comments, advice or interesting discussions are welcome!
Hallvard
|
|
|
| Re: Using Xbase in own grammar [message #692066 is a reply to message #691468] |
Sun, 03 July 2011 11:20  |
 Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Documentation about Xbase and how to integarte it into your langauge
will be made available within the next couple of days.
Could you please open a bug and add a reproducable example for the
memory issue?
Sven
Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
> Hi,
>
> I'm still struggling with Xbase, but at least my setup seems to be
> correct now. Now I consistently get out of heap error:
>
> at
> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>
> ... 16 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at sun.misc.Resource.getBytes(Resource.java:101)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>
> I suppose this is because the grammar becomes too large, although my
> grammar does only contain 10 or so rules, with only two references to
> XExpression.
>
> I can set the heap size with the mx option to 1536 mb, but if I try
> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>
> Now I wonder what strategies I can use to make the grammar "smaller" in
> a way that will make the generator survive.
>
> One option is to remove features of the language, e.g. by redefining the
> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
> rule I don't run out of memory:
>
> XPrimaryExpression returns xbase::XExpression:
> XConstructorCall |
> XBlockExpression |
> // XSwitchExpression |
> XFeatureCall |
> XLiteral |
> XIfExpression |
> // XForLoopExpression |
> // XWhileExpression |
> // XDoWhileExpression |
> // XThrowExpression |
> // XReturnExpression |
> // XTryCatchFinallyExpression |
> XParenthesizedExpression;
>
> However, this will reduce the whole Xbase language, not specific usages
> in some (problematic) contexts.
>
> Another option is to make my own rules refer to special subclasses of
> XExpression, to limit the legal constructs on that context. E.g. if I
> only want simple expressions, I could refer to XOrExpression, which
> disallows assignments. But this will still allow blocks etc.
>
> Of course a combination of these two strategies are possible, but it's
> difficult to find a balance between crippling the whole language (which
> is nice, BTW) and limiting the options in contexts where grammar
> ambiguities occur. In the extreme you could define several sub-languages
> with different power that can be used on parallel, but this will of
> course make the grammar large (text-wise) and difficult to maintain.
>
> Comments, advice or interesting discussions are welcome!
>
> 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: Using Xbase in own grammar [message #692411 is a reply to message #692066] |
Mon, 04 July 2011 11:34 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
I've just updated the online docs and added a chapter on Xbase and Java
integration. You might find this helpful:
http://www.eclipse.org/Xtext/documentation/2_0_0/199-xtext-and-java.php
Am 03.07.11 13:20, schrieb Sven Efftinge:
> Documentation about Xbase and how to integarte it into your langauge
> will be made available within the next couple of days.
> Could you please open a bug and add a reproducable example for the
> memory issue?
>
> Sven
>
> Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
>> Hi,
>>
>> I'm still struggling with Xbase, but at least my setup seems to be
>> correct now. Now I consistently get out of heap error:
>>
>> at
>> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>>
>> ... 16 more
>> Caused by: java.lang.OutOfMemoryError: Java heap space
>> at java.util.Arrays.copyOf(Arrays.java:2786)
>> at sun.misc.Resource.getBytes(Resource.java:101)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>>
>> I suppose this is because the grammar becomes too large, although my
>> grammar does only contain 10 or so rules, with only two references to
>> XExpression.
>>
>> I can set the heap size with the mx option to 1536 mb, but if I try
>> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>>
>> Now I wonder what strategies I can use to make the grammar "smaller" in
>> a way that will make the generator survive.
>>
>> One option is to remove features of the language, e.g. by redefining the
>> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
>> rule I don't run out of memory:
>>
>> XPrimaryExpression returns xbase::XExpression:
>> XConstructorCall |
>> XBlockExpression |
>> // XSwitchExpression |
>> XFeatureCall |
>> XLiteral |
>> XIfExpression |
>> // XForLoopExpression |
>> // XWhileExpression |
>> // XDoWhileExpression |
>> // XThrowExpression |
>> // XReturnExpression |
>> // XTryCatchFinallyExpression |
>> XParenthesizedExpression;
>>
>> However, this will reduce the whole Xbase language, not specific usages
>> in some (problematic) contexts.
>>
>> Another option is to make my own rules refer to special subclasses of
>> XExpression, to limit the legal constructs on that context. E.g. if I
>> only want simple expressions, I could refer to XOrExpression, which
>> disallows assignments. But this will still allow blocks etc.
>>
>> Of course a combination of these two strategies are possible, but it's
>> difficult to find a balance between crippling the whole language (which
>> is nice, BTW) and limiting the options in contexts where grammar
>> ambiguities occur. In the extreme you could define several sub-languages
>> with different power that can be used on parallel, but this will of
>> course make the grammar large (text-wise) and difficult to maintain.
>>
>> Comments, advice or interesting discussions are welcome!
>>
>> Hallvard
>
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Using Xbase in own grammar [message #692413 is a reply to message #692411] |
Mon, 04 July 2011 11:44 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 13.34, Jan Koehnlein wrote:
> I've just updated the online docs and added a chapter on Xbase and Java
> integration. You might find this helpful:
>
> http://www.eclipse.org/Xtext/documentation/2_0_0/199-xtext-and-java.php
Great! I'll most likely create an example project, where I experiment
with various constructs that utilize and extend Xbase in various ways.
So far, I've defined two new operators and mapped them to XXXExtensions
class methods. The next steps are inferring Jvm elements from constructs
that first map to Ecore and then to Jvm elements (as if generated by a
genmodel).
Pity I'm off for summer vacation, now :-)
Hallvard
>
>
> Am 03.07.11 13:20, schrieb Sven Efftinge:
>> Documentation about Xbase and how to integarte it into your langauge
>> will be made available within the next couple of days.
>> Could you please open a bug and add a reproducable example for the
>> memory issue?
>>
>> Sven
>>
>> Am 7/1/11 3:26 PM, schrieb Hallvard Trætteberg:
>>> Hi,
>>>
>>> I'm still struggling with Xbase, but at least my setup seems to be
>>> correct now. Now I consistently get out of heap error:
>>>
>>> at
>>> org.eclipse.xtext.generator.parser.antlr.AntlrToolFacade.runWithParams(AntlrToolFacade.java:132)
>>>
>>>
>>> ... 16 more
>>> Caused by: java.lang.OutOfMemoryError: Java heap space
>>> at java.util.Arrays.copyOf(Arrays.java:2786)
>>> at sun.misc.Resource.getBytes(Resource.java:101)
>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:257)
>>>
>>> I suppose this is because the grammar becomes too large, although my
>>> grammar does only contain 10 or so rules, with only two references to
>>> XExpression.
>>>
>>> I can set the heap size with the mx option to 1536 mb, but if I try
>>> 2048, the MacOSX (Snow Leopard) Java VM will not start.
>>>
>>> Now I wonder what strategies I can use to make the grammar "smaller" in
>>> a way that will make the generator survive.
>>>
>>> One option is to remove features of the language, e.g. by redefining the
>>> rule for XPrimaryExpression or XLiteral. E.g. if I include the following
>>> rule I don't run out of memory:
>>>
>>> XPrimaryExpression returns xbase::XExpression:
>>> XConstructorCall |
>>> XBlockExpression |
>>> // XSwitchExpression |
>>> XFeatureCall |
>>> XLiteral |
>>> XIfExpression |
>>> // XForLoopExpression |
>>> // XWhileExpression |
>>> // XDoWhileExpression |
>>> // XThrowExpression |
>>> // XReturnExpression |
>>> // XTryCatchFinallyExpression |
>>> XParenthesizedExpression;
>>>
>>> However, this will reduce the whole Xbase language, not specific usages
>>> in some (problematic) contexts.
>>>
>>> Another option is to make my own rules refer to special subclasses of
>>> XExpression, to limit the legal constructs on that context. E.g. if I
>>> only want simple expressions, I could refer to XOrExpression, which
>>> disallows assignments. But this will still allow blocks etc.
>>>
>>> Of course a combination of these two strategies are possible, but it's
>>> difficult to find a balance between crippling the whole language (which
>>> is nice, BTW) and limiting the options in contexts where grammar
>>> ambiguities occur. In the extreme you could define several sub-languages
>>> with different power that can be used on parallel, but this will of
>>> course make the grammar large (text-wise) and difficult to maintain.
>>>
>>> Comments, advice or interesting discussions are welcome!
>>>
>>> Hallvard
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:05:16 GMT 2024
Powered by FUDForum. Page generated in 0.03374 seconds |
] 
Search
Help
Register
Login
Home
