Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF-IncQuery » Compare values
Compare values [message #1385082] Wed, 04 June 2014 09:04 Go to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi,

in a Java-Source, I want to find all occurances of a for-loop which iterates over all elements of an iterable member. Therefore I use a java metamodel ("http:\\www.emftext.org\java\" <- had to change slashes, because I'm not allowed to post links outside of eclipse.org) and load the java file as a model.

To find out, if every element of the iterable-type is used in the for-loop, I have to determine that the index variable is initialized with zero. In order to do so, I have to find an integer-litaral "0". So I tried the naive way:

	DecimalIntegerLiteral.decimalValue(c,0);


which fails because of a type conflict ("The type infered from the path expression (java.math.BigInteger) is different from the input literal/computational value (int)."). So my next idea was to use the check-statement:

	DecimalIntegerLiteral.decimalValue(c,r);
	check(r.equals(0));


which also does not work. I get the message "Check expressions must return boolean instead of void". So I thought ok, let's try stupid things and I did this:

	DecimalIntegerLiteral.decimalValue(c,r);
	check({if (r.toString().equals("0")) true else false});


which didn't show any failure message but also didn't work.

Help -> About Eclipse -> Installation Details -> Plugins tells me, that I'm using version 0.7.2.201403071538.

I'd appreciate any suggestions how to solve my problem. Are there any issues known in that version concerning the check-statement?

regards,

Ronny
Re: Compare values [message #1385119 is a reply to message #1385082] Wed, 04 June 2014 12:52 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi Ronny,

sadly, you have hit a known issue with the pattern language of EMF-IncQuery, as its pattern language only support a limited number of Java types outside check and eval (only available in the upcoming 0.8 version) expressions, and the referenced BigInteger type is not between them. We already have bug 398769 opened for similar reasons (https://bugs.eclipse.org/bugs/show_bug.cgi?id=398769), but as of now, we did not had the time to fix the issue.

Your second example with the check expression is close to what should be working. In that case, I guess the error message "Check expressions must return boolean instead of void" is only one of multiple error messages added to that line, as it usually relates to some internal type inference issues. Additionally, I would look at the manifest.mf of your project and see whether the org.eclipse.xtext.xbase.lib plug-in is added, as if it is missing, we have experimented very strange issues with regards to check expressions.

I hope this helps, otherwise feel free to ask for clarification.

Cheers,
Zoltán
Re: Compare values [message #1385126 is a reply to message #1385119] Wed, 04 June 2014 13:25 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi Zoltán,

thank you for your quick reply. I'm sorry to tell you, that your suggestion to add "org.eclipse.xtext.xbase.lib" didn't work. Also I don't get other error messages for that line. I only get some "Error executing EValidator" messages even though it is a plugin-project and I triggered "Config->Update EMFIncQuery Nature".

Do you have any other ideas?

Cheers,

Ronny
Re: Compare values [message #1385130 is a reply to message #1385126] Wed, 04 June 2014 13:50 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi,

if you got an "Error executing EValidator" message, then some exception was thrown during analyis. In this case there should be a corresponding entry with an exception trace in the Eclipse Error log. Can you please check it as well (e.g. using the Error log view of Eclipse).

Cheers,
Zoltán
Re: Compare values [message #1385170 is a reply to message #1385130] Wed, 04 June 2014 18:00 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hello Zoltán,

the log say this:

java.lang.ClassCastException: org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider cannot be cast to org.eclipse.xtext.common.types.access.impl.ClasspathTypeProvider
	at org.eclipse.xtext.common.types.access.ClasspathTypeProviderFactory.findTypeProvider(ClasspathTypeProviderFactory.java:63)
	at org.eclipse.xtext.common.types.access.ClasspathTypeProviderFactory.findTypeProvider(ClasspathTypeProviderFactory.java:1)
	at org.eclipse.xtext.common.types.access.AbstractTypeProviderFactory.findOrCreateTypeProvider(AbstractTypeProviderFactory.java:38)
	at org.eclipse.xtext.common.types.util.TypeReferences.findDeclaredType(TypeReferences.java:240)
	at org.eclipse.xtext.common.types.util.TypeReferences.findDeclaredType(TypeReferences.java:219)
	at org.eclipse.xtext.common.types.util.TypeReferences.getTypeForName(TypeReferences.java:179)
	at org.eclipse.incquery.patternlanguage.emf.types.EMFPatternTypeProvider.getTypeReferenceForVariableWithEClassifier(EMFPatternTypeProvider.java:107)
	at org.eclipse.incquery.patternlanguage.emf.types.EMFPatternTypeProvider.getVariableType(EMFPatternTypeProvider.java:90)
	at org.eclipse.incquery.patternlanguage.emf.types.EMFPatternTypeProvider.typeForIdentifiable(EMFPatternTypeProvider.java:80)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$4.doComputation(AbstractTypeProvider.java:454)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$4.doComputation(AbstractTypeProvider.java:1)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$CyclicHandlingSupport$3.get(AbstractTypeProvider.java:658)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$CyclicHandlingSupport$3.get(AbstractTypeProvider.java:1)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$1.get(AbstractTypeProvider.java:159)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider$CyclicHandlingSupport.getType(AbstractTypeProvider.java:655)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider.doGetType(AbstractTypeProvider.java:348)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider.getTypeForIdentifiable(AbstractTypeProvider.java:477)
	at org.eclipse.xtext.xbase.typing.AbstractTypeProvider.getTypeForIdentifiable(AbstractTypeProvider.java:473)
	at org.eclipse.incquery.patternlanguage.validation.PatternLanguageJavaValidator.checkApplicabilityOfTransitiveClosureInPatternCall(PatternLanguageJavaValidator.java:164)
	at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.xtext.validation.AbstractDeclarativeValidator$MethodWrapper.invoke(AbstractDeclarativeValidator.java:115)
	at org.eclipse.xtext.validation.AbstractDeclarativeValidator.internalValidate(AbstractDeclarativeValidator.java:292)
	at org.eclipse.xtext.validation.AbstractInjectableValidator.validate(AbstractInjectableValidator.java:66)
	at org.eclipse.xtext.validation.CompositeEValidator.validate(CompositeEValidator.java:127)
	at org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:171)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:158)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
	at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:181)
	at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
	at org.eclipse.xtext.xbase.validation.XbaseDiagnostician.doValidateContents(XbaseDiagnostician.java:46)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
	at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:185)
	at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
	at org.eclipse.xtext.xbase.validation.XbaseDiagnostician.doValidateContents(XbaseDiagnostician.java:46)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
	at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:185)
	at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
	at org.eclipse.xtext.xbase.validation.XbaseDiagnostician.doValidateContents(XbaseDiagnostician.java:46)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:132)
	at org.eclipse.incquery.patternlanguage.emf.validation.PatternSetValidator.validate(PatternSetValidator.java:114)
	at org.eclipse.incquery.patternlanguage.emf.validation.PatternSetValidator.validateTransitively(PatternSetValidator.java:81)
	at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelBuilder.build(XmiModelBuilder.java:161)
	at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.internalBuild(XmiModelSupport.java:103)
	at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.build(XmiModelSupport.java:76)
	at org.eclipse.incquery.tooling.core.generator.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:143)
	at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:186)
	at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:210)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:89)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)



Greetings,

Ronny
Re: Compare values [message #1385173 is a reply to message #1385170] Wed, 04 June 2014 18:13 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi,

this trace shows something I have long since not seen (and not missed at all Smile ). When I have seen this issue, there was always some kind of strange internal behaviour of Xtext. However, I have no idea what to suggest to you.

On one hand, the upcoming 0.8.0 version should fix this issue, as we have worked a lot to make the IncQuery tooling more Xtext-conform. However, for now I know of a few quite irritating (albeit as far as I know, manageable) issues in the tooling, so I cannot recommend an upgrade full-heartedly. Of course, we plan to fix these until the release on the 2nd of July... Smile

Cheers,
Zoltán
Re: Compare values [message #1385174 is a reply to message #1385173] Wed, 04 June 2014 18:28 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel HegedusFriend
Messages: 120
Registered: July 2009
Senior Member
Can you tell us which Xtext version do you have currently installed?
Re: Compare values [message #1385176 is a reply to message #1385174] Wed, 04 June 2014 19:00 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
I have version 2.4.3 installed.
Re: Compare values [message #1385192 is a reply to message #1385173] Wed, 04 June 2014 21:16 Go to previous messageGo to next message
Istvan Rath is currently offline Istvan RathFriend
Messages: 58
Registered: July 2009
Member
Hi,

Quote:

On one hand, the upcoming 0.8.0 version should fix this issue, as we have worked a lot to make the IncQuery tooling more Xtext-conform. However, for now I know of a few quite irritating (albeit as far as I know, manageable) issues in the tooling, so I cannot recommend an upgrade full-heartedly. Of course, we plan to fix these until the release on the 2nd of July...


I think Zoli is exaggerating here. 0.8.0 is almost ready, so I recommend you give it a try (with at least Xtext 2.5.3 installed) and if possible, provide us feedback whether the problem went away.

cheers
Istvan
Re: Compare values [message #1385267 is a reply to message #1385192] Thu, 05 June 2014 09:56 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 24
Registered: July 2009
Junior Member
Hi Ronny,

I think your equals-based approach will fail (regardless of IncQuery), as a BigInteger instance will never ever equal a Long or Integer.
Consequently, BigInteger.ZERO.equals(0) returns false by definition.
http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html
So even if you manage to compile your check(r.equals(0)) expression, it will always return false.

This is also the reason why the type inferrer indicates an error in your very first example, whereas DecimalIntegerLiteral.decimalValue(c,0); would be perfectly fine if decimalValue had type java.lang.Integer. But using a BigInteger-typed constant instead of the integer literal 0 would most likely work. Unfortunately, our query language does not have native BigInteger literals at the moment (in fact, it does not even have longs yet - see Bug 398769). So you have to use expression evaluation to work around the problem:

DecimalIntegerLiteral.decimalValue(c, eval(BigDecimal.ZERO));


Or if you use the constant multiple times:

zero == eval(BigDecimal.ZERO);
DecimalIntegerLiteral.decimalValue(c, zero);
SomethingElse.bigIntegerAttribute(foo, zero);


This eval() syntax should work as of v0.8.
Please tell us whether this solves your issue!
Re: Compare values [message #1385335 is a reply to message #1385267] Thu, 05 June 2014 17:11 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi,

I have good and bad news.
First, the good news: I got it working with version 0.8. The working piece of code is:

pattern test(a,r){
	DecimalIntegerLiteral.decimalValue(a,r);
	eval(r.intValue) == 0;
}


The bad news: some issues occured.


  1. The word "java" in the package name causes an error: "missing EOF at '.'".
  2. I can't navigate with ctrl-<arrow> through eiq-files anymore
  3. 	DecimalIntegerLiteral.decimalValue(a,r);
    	check(r.equals(BigInteger.ZERO));
    
    leads to the error: "Couldn't resolve reference to JvmIdentifiableElement 'BigInteger'."


regards,

Ronny
Re: Compare values [message #1385338 is a reply to message #1385335] Thu, 05 June 2014 17:24 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi,

thanks for the feedback.

1. Java is used as a keyword in the language in 0.8. To use it as an identifier, prefix it with ^, so write "^java". It is exactly the same as writing java as an identifier, just the parser needs some help. Smile
2. I am sorry, but I am not familiar with the Ctrl+<arrow> navigation. Can you please detail what should it do and how is now behaving instead?
3. Yes, to refer the BigInteger type, you either have to import it, or use its fully qualified name. This import works similar to java classes, so java.lang.* gets imported automatically; for other cases add import java ^java.math.BigInteger to the eiq file header.

Cheers,
Zoltán
Re: Compare values [message #1385343 is a reply to message #1385338] Thu, 05 June 2014 18:13 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi,

thank you for your support, it works fine now.

ctrl-left and ctrl-right normally jumps word-wise over the text. Just like "w" and "b" in vim. In eclipse also the "." character is a delimiter for words.

At the moment Ctrl-Left and Ctrl-Right just does nothing. Even Ctrl-Space seems to not work on every hit. I can reproduce this, when let something be autocompleted and than hit Ctrl-Space just behind the "." character.

I hope this helps to improve your fine work.

Cheers,

Ronny
Re: Compare values [message #1385348 is a reply to message #1385343] Thu, 05 June 2014 18:27 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi,

a little suggestion to think about:

If you use the java-keyword just for the import statement, what do you think about introducing the keyword "importjava" instead of "import java". In my opinion it would make it more intuitive than "escaping" java in identifiers. Isn't it possible to distinguish between java packages and metamodel imports by the use of quotation-marks?

Cheers,

Ronny
Re: Compare values [message #1385360 is a reply to message #1385348] Thu, 05 June 2014 19:47 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi,

thanks for the suggestion. Technically you are right, the syntax is enough to distinguish between java and EPackage imports, but since 0.8 we also have a third import type for importing patterns (from other packages). Basically we made two kind of imports use optional extended keywords, while in case of java imports the additional keyword is mandatory.

So, the following kind of imports can be used

//EPackage imports
import "http://www.eclipse.org/emf/2002/Ecore"
import epackage "http://www.eclipse.org/incquery/snapshot"
//Pattern imports
import hu.bme.mit.viatra2.examples.reveng.notAbstractStateClass
import pattern hu.bme.mit.viatra2.examples.reveng.notAbstractStateClass
//Java/Xbase import
import java java.math.BigInteger


We had a detailed discussion about possible syntaxes starting in https://bugs.eclipse.org/bugs/show_bug.cgi?id=418991#c5; and relied on these settings as they seemed to be the least problematic. Again, I understand that it is hard to use sometimes; for imports we are aiming at the content assist providing the imports, thus it is not problematic to write the ^java into import declarations; for other identifiers it seemed rare enough. (And yes, the content assist is sometimes problematic in the latest release; we plan to return to the issue before the final 0.8.0 release.)

Furthermore, although this is a much more subjective stance, the importjava keyword seems a bit strange to me (and maybe for consistency we would also need the importpackage and importpattern keywords)... Maybe I could get used to it, but it does not seem natural to me. It is entirely possible that I am defending my own ideas here instead of embracing new ones; but for me that option does not seem clearly better, especially considering the amount of time until the release. Maybe others have a different opinion about it, this last part was my own subjective opinion.

However, thanks for the suggestion; it is really worth having an entirely different perspective about the costs and results of changes we make to our grammar. E.g. introducing a new keyword is kind of expensive. Smile

Cheers,
Zoltán
Re: Compare values [message #1385366 is a reply to message #1385360] Thu, 05 June 2014 20:34 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Hi,

OK, that makes sense. Even though I still don't really like it Wink Only a better error message would be handy. So thanks a lot for you nice and quick help.

regards,

Ronny
Re: Compare values [message #1385415 is a reply to message #1385366] Fri, 06 June 2014 09:43 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel HegedusFriend
Messages: 120
Registered: July 2009
Senior Member
I also thought a bit about the names, and while I would strongly disagree with merging the keywords (see "importjava"), I believe that using "import class" would be better than "import java", as it is more in line with "epackage" and "pattern".
Of course, this only works if "class" is not already a keyword that we cannot (or should not) add to our language.
Re: Compare values [message #1385419 is a reply to message #1385415] Fri, 06 June 2014 10:14 Go to previous messageGo to next message
Gabor Bergmann is currently offline Gabor BergmannFriend
Messages: 24
Registered: July 2009
Junior Member
I think a slight problem with "import class" variant is that it is not immediately obvious that we are referring to a Java class as opposed to a metamodel class.
Re: Compare values [message #1385421 is a reply to message #1385419] Fri, 06 June 2014 10:31 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
So what about "import javapackage"? This way, it is kind of intuitive and it will collide in fewer cases, if you think about importing java.x.* packages...

Cheers,

Ronny
Re: Compare values [message #1385423 is a reply to message #1385421] Fri, 06 June 2014 10:54 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel HegedusFriend
Messages: 120
Registered: July 2009
Senior Member
I think the keyword has to match with its default usage:
- epackage -> Ecore EPackage
- pattern -> EMF-IncQuery Pattern
- class -> Java Class

I get that some class is overloaded, but it is actually EClass in EMF, similarly as we use epackage instead of package (and not only because we already use package elsewhere, I hope).

The .* wildcard is supported, but not the default behavior, imho. Otherwise we would have to use "import patternpackage" as well.

Completely crazy, _do not use_ idea: epackage, jpackage, ppackage Very Happy
Re: Compare values [message #1385435 is a reply to message #1385423] Fri, 06 June 2014 12:27 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi all,

sorry to be a party-killer here, but as I see it, we don't get closer to a consensus here. The import class alternative is by far the best one in my opinion, but even that has its share of opponents.

Seeing we have no clear alternative here, I don't think it is a good idea to change a keyword in the language after the feature-freeze milestone (it would break our promised compatability for the rest of 0.Cool. If we would have reached a clear winner, it might have been worth it for the future, but here it is not that clear. However, if some time later we have a better idea, I am open to changing it in future releases somehow.

Thanks again for the participation and the ideas.

Cheers,
Zoltán
Re: Compare values [message #1386892 is a reply to message #1385343] Sun, 22 June 2014 15:54 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi Ronny,

sorry for forgetting your issue with the modifier keys. Sadly, I could not reproduce your issue on my main environment (I had some differences: I use OSX where instead of Ctrl+left/Ctrl+right Alt+left/Alt+right is used).

Can you share your platform, Eclipse, Xtext and IncQuery version to be able to try it out in a different environment?

Thanks,
Zoltán
Re: Compare values [message #1394131 is a reply to message #1386892] Fri, 04 July 2014 21:08 Go to previous messageGo to next message
Ronny Marx is currently offline Ronny MarxFriend
Messages: 10
Registered: June 2014
Junior Member
Sorry for the late response. The problem doesn't seem to exist anymore since I use your CI-Build and another Version of the plugin that could also have been involved in this issue. So I think you don't have to care about this anymore.

cheers,

Ronny
Re: Compare values [message #1395033 is a reply to message #1394131] Sun, 06 July 2014 08:29 Go to previous message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 255
Registered: July 2009
Senior Member
Hi,

ok, thanks for the feedback.

Cheers,
Zoltán
Previous Topic:java.lang.Override is not on the classpath
Next Topic:Simplification of Query
Goto Forum:
  


Current Time: Tue Jun 30 08:29:01 GMT 2015

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

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