[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [incquery-dev] PSystem/Builder refactor - part 2
|
Thanks for the testing!
About the exceptions: I cannot really do much about it, as this would need to support the now inconsistent old versions as well. After fixing the other issues I did not experience this, but this is no guarantee. But these should go away after the project is updated.
XExpression removal: its implementation was missing.
Build issue: I forgot some required initialization during cleanup. Works now as expected.
I have updated the review in Gerrit with the fixes.
Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
On 2014.01.30., at 14:01, Istvan Rath <rath@xxxxxxxxxx> wrote:
> I have run some initial quick tests with the school example. Here are the results:
>
> - prior to running the project upgrade, I got exceptions as follows:
>
> !STACK 0
> java.lang.NullPointerException
> at org.eclipse.xtext.xbase.compiler.output.SharedAppendableState.appendType(SharedAppendableState.java:84)
> at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.append(TreeAppendable.java:310)
> at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.append(TreeAppendable.java:1)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$23.apply(JvmModelGenerator.java:1008)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$23.apply(JvmModelGenerator.java:1)
> at org.eclipse.xtext.xbase.compiler.ErrorSafeExtensions.forEachSafely(ErrorSafeExtensions.java:127)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateThrowsClause(JvmModelGenerator.java:1011)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateMember(JvmModelGenerator.java:859)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateMember(JvmModelGenerator.java:1897)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$2.apply(JvmModelGenerator.java:288)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$2.apply(JvmModelGenerator.java:1)
> at org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_doubleArrow(ObjectExtensions.java:139)
> at org.eclipse.xtext.xbase.compiler.LoopExtensions.forEach(LoopExtensions.java:34)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateBody(JvmModelGenerator.java:292)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateBody(JvmModelGenerator.java:1869)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateType(JvmModelGenerator.java:211)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._internalDoGenerate(JvmModelGenerator.java:202)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.internalDoGenerate(JvmModelGenerator.java:1852)
> at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.doGenerate(JvmModelGenerator.java:183)
> at org.eclipse.incquery.patternlanguage.emf.ui.builder.EMFPatternLanguageBuilderParticipant.handleChangedContents(EMFPatternLanguageBuilderParticipant.java:142)
> at org.eclipse.xtext.builder.BuilderParticipant.build(BuilderParticipant.java:229)
> at org.eclipse.incquery.patternlanguage.emf.ui.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:127)
>
>
> - I had to manually remove xexpression extensions from plugin.xml
>
> - the school.incquery project does not build cleanly, I get compile errors from patterns which check expressions, e.g.:
>
> private CourseWithNameLongerThanWeightIntQuerySpecification() throws IncQueryException {
> super();
> Inconsistent pattern definition
> }
>
>
> cheers
> Istvan
>
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
> On Monday 27 January 2014 at 11:07, Ujhelyi Zoltán wrote:
>
>> Hi,
>>
>> thanks again for the detailed review. I tried to address all your issues in Gerrit (the Hudson error were caused by an unintended change and plain stupidity on my behalf - sorry for spamming).
>>
>> About Eclipse/UI independency: the patternlanguage.emf project should be independent of the Eclipse runtime and of course the Eclipse UI - it can be used in eclipse-less environments, and this is true for all their dependencies (if not, it is a bug). In other words, I don't think a separate project for this logic is necessary, but correct me if this is not true.
>>
>> Cheers,
>> Zoli
>> -- Zoltán Ujhelyi
>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>>
>> On 2014.01.26., at 20:02, Istvan Rath <rath@xxxxxxxxxx> wrote:
>>
>>> Zoli,
>>>
>>> thanks for the great work. I think I will wait with the detailed tests until you get the cleaner up to speed.
>>>
>>> I have added some comments to the code in Gerrit. Some of the comments need further attention, so please take a look.
>>>
>>> A final question:
>>>
>>> On Saturday 25 January 2014 at 13:43, Ujhelyi Zoltán wrote:
>>>
>>>> * All PSystem building code is moved into patternlanguage.emf project (they should still be eclipse and UI independent)
>>>
>>>
>>> If something is Eclipse and UI independent, isn’t it better moved to a separate project which is declared to be independent of Eclipse and the UI?
>>>
>>> cheers
>>> Istvan
>>>
>>>
>>> --
>>> Istvan RATH, PhD
>>> Research fellow
>>> Budapest University of Technology and Economics
>>>
>>> Fault Tolerant Systems Research Group
>>>
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev
