eclipse-ocl-bot
commented
1 month ago By Adolfo Sanchez-Barbudo Herrera on Sep 03, 2009 06:55
(In reply to comment #50)
Preliminary comments:
Change the {lpg.exe} in the launches to {lpg2.exe} so that the old LPG cannot be used accidentally.
Ok.\
The test_hebrew_singleQuote_135321 fails in both Ecore and UML bindings.
That test has been "arbitrarily" failing to me, in some occasions since years ago. I guessed that comes from any character encoding reason which I don't know. I think that it's time to discover the reason ;)
EssentialOcl.gi has an "Invalid" token which EssentialOcl.g does not.
Ok, I'll take a look to this. I probably skipped something while merging.
Lexer.lexer() replaces lexToTokens(). lexToToken was not a verty good name, but lexer is differently bad; not a verb, and now requires caller to getIPrsStream. Suggest chanke to lex(AbstractParser) using a verb and hiding the indirection.
Similarly change parseTokensToCST to parse() rather than parser().
Well, that names comes from the original template. It can obviously be changed ;)
AbstractOCLParser has a @SuppressWarnings("nls"). I think this should only be used in auto-generated or test modules. Real code should have per-string NLS apologies, since at one point OCL was internationalised and might well be again.
Ok, that should be there since time ago. If it's not solved when this is applied, I'll silently add the change.
The revised architecture seems to solve a lot of the uncomfortable compatibilities I had to struggle with originally, but I think it deserves more careful thought to get it right in one go.
There really are two changes here. I do not like reviewing them together. The LPG change involves numerous trivial changes that are tedious and not that necessary to review. The architecture change involves just a few changes that are masked by the volume of trivial changes. Please prepare a first set of patches that is a no-functionality change migration to LPG2. We can commit these (perhaps to a branch to assist creation of a two stage patch) and then review the architecture revision patch.
Although I dislike the idea, I have no option since this is matter of two. I only hope that the patch doesn't die in the branch.
About including LPG into Orbit:
IMP's newsgroup message about including LPG v2.0.17 has not been replied. Collaboration with IMP's team is not being as I have liked. I'll try a final private email to Robert
I have discovered that an IPZilla CQ about LPG v2.0.16 has been approved, the bundle is not in Orbit though. Since LPG v2.0.16 is properly tagged in sourceforge version, I could try the patch on this lpg runtime to see if it properly works. However I would prefer including the last version.
I'll ask robert if he has any intention of including the last LPG version in Eclipse. If don't receive any response we could:
- Go straightforward on including LPG v2.0.16 bundle in Orbit.
- Including LPG v2.0.17, which would previously involve solving legal IP revision on LPG v2.0.17.
Suggestions are welcomed. Meanwhile I'll prepare the one step patch and try to see if it also works on LPG v2.0.16.
Cheers,\ Adolfo.
| --- | --- | | Bugzilla Link | 242153 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Jul 26, 2008 14:31 EDT | | Modified | May 27, 2011 02:55 EDT | | Version | 1.2.0 | | Depends on | 288666, 298542, 298562 | | Blocks | 297966, 298634 | | Reporter | Ed Willink |
Description
The Eclipse IMP project provides useful automation for editors,\ especially those using LPG. This could be very useful for OCL-based\ languiages such as QVT.
I therefore started modifying org.eclipse.ocl to use LPG 2.x rather\ than LPG 1.x so that IMP could be more naturally exploited.
Eventually I backed out nearly all my changes since they are not\ necessary and create more problems than they solve. A summary of\ these activities is provided below\ -----------------------------------------------------------------\ IMP provides a builder so *.g files are automatically built.\ Seems like a good idea, but only when there are no errors. If\ there are problems, the OCLParsersym.java is set to bad content\ and it's difficult to know which grammar is bad. I disabled the\ builder quite rapidly.
IMP provides an LPG editor, which works well for syntax colouring\ and outlines but has some strange ideas about where the errors are.
IMP (the Ganymede synchronised release) has a bad bug whereby any\ edit of a file with an error hogs CPU. A bit tedious when LPG\ files have spurious errors.
LPG 2 uses lpg.runtime rather than lpg.lpgjavaruntime so any\ change introduces a binary incompatibility. lpg.runtime is not\ in Orbit.
IMP exploits LPG 2 parsers and lexers through very small ILexer\ and IParser interfaces. It would be good for these to be directly\ supported by OCLParser and OCLLexer, however IMP is an incubation\ project, so introducing an MDT-OCL dependency on IMP is undesirable.
LPG 2 deprecates $ so e.g. $empty needs changing to %Empty.\ Unfortunately preventing '$' being converted to '' defeated\ me in the KWLexerMap, so I had to change the escape to # rather\ than $. This mostly worked, but for unexplained reasons the NewCase\ macro for EssentialOCL.gi got a BeginJava/EndJava wrtapped around it.\ Changing all BeginJava/EndJava to BeginCode/EndCode cured the problem.\ Similar macros not in an include did not have this problem.
LPG 2 seems to have an ordering problem with include paths. I had to change\ the %Import section to provide an explicit path. This may be because\ LPG 2 has the IMP paths built-in.
LPG2 appears to introduce bison-style production type suffixes\ such as unary$$OCLExpressionCS ::= ...\ This didn't work for me with either $$ or ##.\ ------------------------------------------------------------------\ IMP also supports non-LPG grammars, so I investigated use of the\ existing LPG 1 grammars as non-LPG IMP grammars. Very little problem,\ just need to clone IMP's SimpleLPGParseController.
Consequently, I recommend that MDT OCL delay migrating to LPG 2\ until LPG 2 and IMP are more mature.
The only significant changes I found worth making to OCL were:\ -------------\ Change CSTNode.startOffset:EInt to CSTNode.startToken:IToken\ Change CSTNode.endOffset:EInt to CSTNode.endToken:IToken\ Add CSTNode.getStartOffset() for compatibility\ Add CSTNode.getEndOffset() for compatibility
Modify all setOffsets() to use setXxxToken rather than setXxxOffset.
Only the dotArrowExpCS ::= NUMERIC_OPERATION '(' argumentsCSopt ')'\ causes trouble through use of setXxxOffset in a non-IToken fashion.\ Perhaps this partitioned IToken usage deserves revisiting anyway.\ -------------\ Add to AbstractLexer \ public abstract int [] getKeywordKinds();
so that IMP can access the list of tokens for colouring.