Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] PSystem/Builder refactor - part 2 
Hi,

I have merged the code to master. I have added check for the missing eiq files from bin: in case it is not found, a full clean is triggered that does not look for any of these files. This is slower than optimal, but automatically goes to a consistent phase.

Additionally, I updated Zest in the target platform to the newest version, and added Zest to the extra update site as an additional download. Without updating Zest compile errors will appear.

For everybody: after downloading the new version, you have to do two things:
 1. Regenerate the Xtext editor
 2. Update existing eiq project
   a. There is an update item in the Configure submenu of the project.
   b. If the project was using both runtime and Patterns, the patternlanguage project(s) need to be added as additional dependency.

Of course, extensive testing needed, but it should work.

Cheeers,
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.02.04., at 16:17, Istvan Rath <rath@xxxxxxxxxx> wrote:

> OK, I have played around with it a bit. It seems to work quite well, so it’s a green from me to merge it ASAP into master.
> 
> Nice job!
> 
> A final remark: the only issue that will need some further care is to eliminate the “exception-in-the-background” behavior when the EIQ files cannot be located under /bin, due to some previous builder error.
> 
> cheers
> Istvan
> 
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
> On Friday 31 January 2014 at 12:05, Ujhelyi Zoltán wrote:
> 
>> 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
>> 
>> _______________________________________________
>> 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

Back to the top