Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Lightweight standalone AST parser
Lightweight standalone AST parser [message #1018400] Wed, 13 March 2013 19:17 Go to next message
David Apltauer is currently offline David ApltauerFriend
Messages: 10
Registered: January 2013
Junior Member
Hello, is there a nice way of exporting Xtext project as a java archive with a standalone parser? When I export the initial Hello name! project as a runnable JAR with packed references I get a 40MB archive. That is really unusable.

David Apltauer
Re: Lightweight standalone AST parser [message #1018409 is a reply to message #1018400] Wed, 13 March 2013 19:45 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
Hi,

depending on what you actually use you may strip out

- Xbase and co
-The Xtext Generator
-The Mwe stuff



Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Lightweight standalone AST parser [message #1018421 is a reply to message #1018409] Wed, 13 March 2013 20:28 Go to previous messageGo to next message
David Apltauer is currently offline David ApltauerFriend
Messages: 10
Registered: January 2013
Junior Member
Thanks for reply. I managed to boil it down to

org.eclipse.xtext;visibility:=reexport,
org.eclipse.xtext.generator;resolution:=optional,
org.eclipse.xtext.common.types

in the manifest file without Eclipse complaining, but it does not seem to affect the generated jar size. Is there another place that dependencies need to be set? There is still a lot of "plug-in dependencies" but I'm not sure how to get rid of some of them.

[Updated on: Wed, 13 March 2013 20:29]

Report message to a moderator

Re: Lightweight standalone AST parser [message #1018424 is a reply to message #1018421] Wed, 13 March 2013 20:31 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
Hi you have clean the jars yourself. The export wizard uses all dep
wheather they are used to the workflow or are optional

--
Need training, onsite consulting or any other kind of help for Xtext?
Go visit http://xtext.itemis.com or send a mail to xtext at itemis dot de


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Lightweight standalone AST parser [message #1018429 is a reply to message #1018424] Wed, 13 March 2013 20:42 Go to previous messageGo to next message
David Apltauer is currently offline David ApltauerFriend
Messages: 10
Registered: January 2013
Junior Member
You mean I have to modify the jar internals manually after its creation? I would like to get rid of those dependencies so that they would not be even optional. In which file are the dependencies now when they are not int the manifest file? (sorry for my noobiness)
Re: Lightweight standalone AST parser [message #1018437 is a reply to message #1018429] Wed, 13 March 2013 20:51 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
hey are in the manifest. but as the things are transitive you might get them anyway.
so i think you either have to clear the jar or collect all required deps as separate jar


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Lightweight standalone AST parser [message #1018439 is a reply to message #1018437] Wed, 13 March 2013 20:54 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
p.s: cant you choose not to create a single jar in the wizard?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Lightweight standalone AST parser [message #1018442 is a reply to message #1018437] Wed, 13 March 2013 20:58 Go to previous messageGo to next message
David Apltauer is currently offline David ApltauerFriend
Messages: 10
Registered: January 2013
Junior Member
Ah, okay. Thanks you very much. I hope I'll find some tool for the dependency analysis.
Re: Lightweight standalone AST parser [message #1018443 is a reply to message #1018442] Wed, 13 March 2013 20:59 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
as said before: start with xbase, the xtext.generator and the mwe stuff

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Lightweight standalone AST parser [message #1018445 is a reply to message #1018439] Wed, 13 March 2013 21:00 Go to previous messageGo to next message
David Apltauer is currently offline David ApltauerFriend
Messages: 10
Registered: January 2013
Junior Member
Well there is some "package/extract required libraries into generated JAR" and "copy them into subfolder" options. That seems not to be what you meant. Of course I can export without the dependecies but then I would have to track them manually. Still it seems better to delete the unused ones.

[Updated on: Wed, 13 March 2013 21:02]

Report message to a moderator

Re: Lightweight standalone AST parser [message #1020174 is a reply to message #1018445] Sun, 17 March 2013 12:52 Go to previous messageGo to next message
Steve Kallestad is currently offline Steve KallestadFriend
Messages: 62
Registered: March 2013
Member
Funny enough, I went through this a week or so ago. I haven't gotten to the point where I know exactly what is required, but I did manage to get it down to ~8MB and ~3K files. I'm sure there is a lot more to whittle down.

Stripping down the jar is not an easy task. It's best to start with a very simple project.

ProGuard (free/open source) is designed for this purpose, but it requires a lot of information to do the job AND you have to do a great deal of testing to make sure that something you stripped out isn't required at all.

The path I'm going down is this:

1) leverage big jar with obvious file stripping for standalone parsing

2) In a future release, create an external parser that's more lightweight.

At this time, I don't want to have to deal with language changes in two different areas and testing/syncing semantics between them. When I've gotten enough feedback for the next revision it will be time to optimize.

I have a long-standing optimize-everything mentality, but the level of effort for coming up with an optimized solution here isn't worth the effort (at least for me). Regardless of how much you can pull out, the overhead of EMF is going to be significantly higher than a targeted solution.

I have seen at least one open source standalone xtext app (the puppet one) that looks very mature. I'm sure there are plenty more. There may be an example or two out there to work from.
Re: Lightweight standalone AST parser [message #1020178 is a reply to message #1020174] Sun, 17 March 2013 13:04 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

If you're really after optimising speed and size, have time to spare and
are only interested in parsing, you could could pursue another approach.

Use an Xtext grammar for all its good development/editor properties but
then do a grammarModel-to-grammarText transformation so that you produce
a much smaller (perhaps 10-fold) and somewhat faster (perhaps two-fold)
LPG grammar. I started work on this in
org.eclipse.ocl.examples.xtext2lpg but haven't had time to progress it
recently.

Just an idea.

Regards

Ed Willink


On 17/03/2013 12:52, Steve Kallestad wrote:
> Funny enough, I went through this a week or so ago. I haven't gotten
> to the point where I know exactly what is required, but I did manage
> to get it down to ~8MB and ~3K files. I'm sure there is a lot more to
> whittle down.
>
> Stripping down the jar is not an easy task. It's best to start with a
> very simple project.
>
> ProGuard (free/open source) is designed for this purpose, but it
> requires a lot of information to do the job AND you have to do a great
> deal of testing to make sure that something you stripped out isn't
> required at all.
>
> The path I'm going down is this:
>
> 1) leverage big jar with obvious file stripping for standalone parsing
>
> 2) In a future release, create an external parser that's more
> lightweight.
>
> At this time, I don't want to have to deal with language changes in
> two different areas and testing/syncing semantics between them. When
> I've gotten enough feedback for the next revision it will be time to
> optimize.
>
> I have a long-standing optimize-everything mentality, but the level of
> effort for coming up with an optimized solution here isn't worth the
> effort (at least for me). Regardless of how much you can pull out,
> the overhead of EMF is going to be significantly higher than a
> targeted solution.
> I have seen at least one open source standalone xtext app (the puppet
> one) that looks very mature. I'm sure there are plenty more. There
> may be an example or two out there to work from.
Previous Topic:using the index to check for duplicates
Next Topic:Parameterised Terminals?
Goto Forum:
  


Current Time: Thu Mar 28 13:32:28 GMT 2024

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

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

Back to the top