Community
Participate
Working Groups
Make LPGv2 take part in Orbit so that new OCL grammars, parsing infrastructure and textual editor based on this LPG runtime may be integrated in MDT-OCL project. In principle, LPG 2.0.18 will be our target.
Since LPG 2.0.18 release has been delayed, our target will be 2.0.17.
*** Bug 297659 has been marked as a duplicate of this bug. ***
CQ approved: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=3653 Next step: Check in the new LPG Runtime into Orbit's repository As agreed with Robert's Fuhrer, the bundle's name will be: lpg.runtime.java
Created attachment 154938 [details] LPG Runtime inclusion patch The attached patch should be applied against dev.eclipse.org/tools/org.eclipse.orbit/lpg.runtime.java project BRANCH v2_0_17 The bundle has been created in a similar way the previous net.sourceforge.lpg.lpgjavaruntime bundle was created. The following guidelines have also been taken: http://wiki.eclipse.org/Adding_Bundles_to_Orbit
Adding David... David, since it's my first contribution to Orbit I would be pleased if you are able to do a quick review of the contribution. I think that I'll need tag once this is committed to properly update the bundles.map A patch with iplog, bundles.map, orbit.psf and set1/features.xml will be provided when this one is committed.
Also adding Robert since he must be interested in this.
Looks close enough to try. I didn't see any obvious errors or common mistakes (with a 4 minute review). Don't forget, you'll also have to add it to the feature.xml file and map file too. I'll be "around" most the time, so I think its fine if you just give it a try, and if there's a few build failures, this is a good time to have them (not a critical time of milestone) and I'm sure you'll straighten it out ... I mean, I'll be here and happy to help if you need it. :) Thanks.
David, Thank you very much !! I think I'm done. How could I check that all has gone fine ?. I remember reading that I have to wait 1 hour so that Orbit's realizes that it has a new bundle to build. Am I wrong ? Cheers, Adolfo.
Adolfo, For my own edification, would you be able to outline the chief benefits in moving to LPG2? Regards, Mat
(In reply to comment #8) > ... I remember > reading that I have to wait 1 hour so that Orbit's realizes that it has a new > bundle to build. Am I wrong ? > Yes, up to one hour. But if you are impatient, you can "force a build" by clicking on the refreshing-looking button at http://build.eclipse.org:9777/dashboard/tab/builds But, one has started, and will be done in hour or two.
Oh, and if the build works at all, you can see/get the results from http://download.eclipse.org/tools/orbit/committers/
You'll want to be sure this runs as expected. When I pulled in the code from cvs, I later noticed a bunch of messages in my log file. All of this form: !ENTRY org.eclipse.jdt.core 2 0 2009-12-22 13:08:25.556 !MESSAGE The Java indexing could not index /lpg.runtime.java/lpg/runtime/Recover yParser.class. This .class file doesn't follow the class file format specificati on. Please report this issue against the .class file vendor So ... think these are really odd .class files? Could you have accidental added end-of-lines in them somehow?
(In reply to comment #12) > You'll want to be sure this runs as expected. When I pulled in the code from > cvs, I later noticed a bunch of messages in my log file. All of this form: > > !ENTRY org.eclipse.jdt.core 2 0 2009-12-22 13:08:25.556 > !MESSAGE The Java indexing could not index > /lpg.runtime.java/lpg/runtime/Recover > yParser.class. This .class file doesn't follow the class file format > specificati > on. Please report this issue against the .class file vendor > > So ... think these are really odd .class files? Could you have accidental added > end-of-lines in them somehow? I think I have simply added the classes (and the .java files in the source-bundle), from the lpg.runtime.jar downloaded from sourceforge.net... I'll check it again to ensure they are same...
> > I think I have simply added the classes (and the .java files in the > source-bundle), from the lpg.runtime.jar downloaded from sourceforge.net... > I'll check it again to ensure they are same... I'll try to recompile the .java file with my Java 5 compiler, and check if they are the same. Cheers, Adolfo.
> > I'll try to recompile the .java file with my Java 5 compiler, and check if they > are the same. > > Cheers, > Adolfo. After: 1. recompiling the source-bundle .java files in a temporal bin folder. 2. replacing the original root-project .class files by the new .class files. 3. Comparing the project the Orbit's cvs. Only a non-perceptible-by-the-compare-editor change is detected for the messages.properties file. Do you think this could be error's source ?
(In reply to comment #15) > ... Do you think this could be error's source ? No, I wouldn't think so. I'm using eclipse SDK M4 as my development environment. I wonder if this is some new JDT check? Maybe their bug? Maybe would happen to lots of .class files? (not compiled by JDT :) If you haven't done something funny (like use FTP to get the .class files, or change your .class cvs filetype setting to ascii (both, highly unlikely ... that's all I can think of of how you'd cause this) then it may not be a real problem. If someone else sees (after using eclipse-sdk M4) perhaps we could ask someone on JDT team "what it means" and if we should be concerned. As far as I know, it could just be my setup, somehow.
(In reply to comment #16) > (In reply to comment #15) > > > > ... Do you think this could be error's source ? > > ... it could just be my setup, somehow. > Oh wait, I think I know what caused this. I initially didn't check out from cvs, but just applied your patch. And "binary" files don't actually patch correctly, or at least not easily ... so probably did have some extra EOLs in there, or something. I imagine you actually "imported" these into your workspace and then committed, so should be fine. I do not see this message now that I've checked out your version directly from cvs. Sorry for the false alarm.
> For my own edification, would you be able to outline the chief benefits in > moving to LPG2? a) responding from a plea from the LPG developers to stop using LPG 1 b) using the active development stream c) using the same stream as used by IMP Of the technical changes, the only one that I know of that seems useful for MDT/OCL's mundane purposes is: d) the possibility to use type-safe grammar rule returns
> > Oh wait, I think I know what caused this. I initially didn't check out from cvs, > but just applied your patch. And "binary" files don't actually patch correctly, > or at least not easily ... so probably did have some extra EOLs in there, or > something. I imagine you actually "imported" these into your workspace and then > committed, so should be fine. > > I do not see this message now that I've checked out your version directly from > cvs. > > Sorry for the false alarm. It doesn't matter. It seems that all has gone fine. I have checked that the binary and source bundles have been sucessfully built. Thank you very much for the help and congratulations for the helpful documentation, it has been essential to make this work in my first try. N.B: I'll wait until LPGv2.0.17 reuse approval for MDT-OCL, to resolve the bug.
(In reply to comment #18) > > For my own edification, would you be able to outline the chief benefits in > > moving to LPG2? > > a) responding from a plea from the LPG developers to stop using LPG 1 > b) using the active development stream > c) using the same stream as used by IMP > > Of the technical changes, the only one that I know of that seems useful for > MDT/OCL's mundane purposes is: > > d) the possibility to use type-safe grammar rule returns There is a long thread in which you may find more reasons. If you are bored you could try to follow Bug 242153. Apart from all that Ed has pointed out, I could add some notes: - We tend to ship an OCLEditor as an example which uses IMP, which uses LPGv2. So, since LPGv2 will be needed by the example it should be good that the parser uses the same runtime, and we could then forget the old runtime. - Technically, LPGv2.x runtime has been refactored improving its design, including more interfaces, etc which should also be exploited by MDT-OCL. At least, we will do the first step, changing the runtime in this major version increment (MDT-OCL 3.0.0). Let's see if we are able to do notable changes to make MDT-OCL parser take advantage from the new LPG design. - Technically, LPGv1.x runtime has some deficiences relating performance and memory usage. I detected one related to backtracking parser, which used an IntTuple action = new IntTuple(1 << 20) to stack parser actions. In Lpg v2.x an improved dinamic array is used instead, which shouldn't use so amount of memory: private IntSegmentedTuple action = new IntSegmentedTuple(10, 1024); Regards, Adolfo.
Approval granted : http://dev.eclipse.org/ipzilla/show_bug.cgi?id=3656 Fixed
Closing after over 18 months in resolved state.
