I use ENSIME to deal with Scala code, and ENSIME uses official Presentation Compiler. For all Binding.scala examples I looked at #dom functions result in "all is red" decoration (that is false positive error detection) for DOM fragments. Say this one example https://github.com/Atry/Binding.scala-sample results in "all is red" starting from the first div of the table definition.
I guess Eclipse users are also affected by the issue as far as Eclipse uses PC also.
How to resolve the issue?
use addEnsimeCompilerPlugin in addition to addCompilerPlugin. This will be addressed by https://github.com/ensime/ensime-server/issues/1152
Related
If I type Car.Mile and press ctrl-spacebar to autocomplete the member name, it does not bring up matches that don't begin with Mile at all. This is pretty annoying because so many methods are prefixed with get/set/is like getMileage() and setMileage().
My code completion options look like this currently. Not seeing this as a choice. This is JMonkeyEngine's version of Netbeans, if that matters.
Anyway to get this behavior?
Don't use the settings for "All Languages" use the Java settings:
I'm experiencing some rather annoying problems with scala. The problem is, that I can compile small scala project perfectly, but when the projects are bigger, the compiler crashes with an StackOverflowException.
Clearly, I have to increase the stack size for the compiler, however, that's probably my main problem here, I don't know how.
I'm starting netbeans with these parameters:
netbeans_default_options="-J-client -J-Xmx512m -J-Xss8m -J-Xms512m -J-XX:PermSize=128m -J-XX:MaxPermSize=512m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true"
So, as far as I'm aware, -J-Xss8m should increase the thread stack size to 8 mb. However, that doesn't seem to affect the compiler. So I tried to pass the same parameter to the compiler directly, using the compiler flags, which I can set in netbeans, resulting in this:
-deprecation -J-Xss8m
But again, that doesn't help, I'm still getting the exception. I searched through the netbeans documentation, but all I found was the netbeans startup parameters, which I had already set. I hope somebody here can give me further information on how to handle this problem.
Further information:
So, after a day I finally had the chance to try everything out on a different machine. I used the same settings and same compiler, but to my surprise, I didn't get the same result. Meaning, on his machine the compiler compiles the whole code without any exception.
The only difference between mine computer and his is, that his has more RAM and CPU power, but that shouldn't make the deal since we both use netbeans with the same startup options.
By now, I even tried out the RC of the 2.9 scala compiler, it didn't help much. Also, I checked if I have the correct scala plugin installed, since there might be problems when using the 2.8 plugin with the 2.9 compiler and vice versa. However, I'm using the 2.9 plugin and 2.9 compiler, so that's fine.
The problem of giving the Scala compiler more stack space is similar to specifying more heap space. Both of these options must be specified as custom JVM arguments when running the Scala compiler. However Netbeans lacks any sort of documentation on how to do it, so here it is.
The way to specify custom JVM arguments for the Scala compiler with Netbeans is by customizing build.xml for each project.
Open nbproject/build-impl.xml in the project's folder.
Search for "scalac" and you will find the following target: -init-macrodef-scalac.
Copy the whole target definition, paste it into your build.xml, and save it.
Close nbproject/build-impl.xml, from now on you will work with build.xml.
In the target you just copied, locate the <scalac> tag, the nesting will be as follows: target.macrodef.sequential.scalac
Add a custom "jvmargs" attribute to the scalac tag, it will look as follows: <scalac jvmargs="-Xss2048k -Xmx2000m" ... >
Save the build.xml. Now whenever you compile your project with netbeans, the compiler will be run with the custom jvm arguments.
i have this Problem with my test ..the
driver.findElement(By.xpath("//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span")).click();
don't find the element.
the eclipse show this message of error
Cannot locate a node using
//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span
EDIT : Post edited to reflect answer to actual problem. Original answer follows.
Long XPath expressions are fragile, and tests are prone to fail when relying on them : a completely unrelated change somewhere else in the document can mess everything up, and even if you're aware of the problem, the tests' code is just harder to maintain.
In this particular case, since the site is generated by GWT, it's even worse - there is little control over the actual HTML changes. A good solution when using GWT is to use the ensureDebugId method (see link in comments).
Are you sure that this XPath expression is correct ? Does other tests work with this driver ?
I'd recommend avoiding the use of long XPath expressions like that - wouldn't it be safer in the long term to start the expression at an id-specified div somewhere in the page rather than at the root of the DOM ?
Eclipse JDT has a 'call hierarchy' feature -- start from a field/method and it recursively finds all references.
IntelliJ also implements this, but it only works from methods. For fields, you can only 'Find Usages', so if you want to dig deeper you have to do additional searches.
Tried 'Dataflow to here', but it's not what I'm looking for.
Am I missing something? Is there a better way to explore field usage in IntelliJ?
Select the method you're interested in and then use from the top menu "Navigate > Call Hierarchy" or simply Ctrl+Alt+H.
AFAIK this doesn't work for fields, because when I select a field, the "Navigate > Call Hierarchy" option becomes grayed-out. The only similar featutes I'm aware of for fields are "Edit > Find > Find Usages" (Alt+F7) and "Edit > Find > Show Usages" (Ctrl+Alt+F7).
EDIT
The issue below has been resolved and IntelliJ IDEA 2019.3 will have this feature.
EDIT 2
I downloaded:
IntelliJ IDEA 2019.3 EAP (Community Edition)
Build #IC-193.3793.14, built on September 25, 2019
But it seems this issue was not fixed correctly, the call hierarchy for fields does not take you to the actual usage of the field in the method rather to the line of the method definition.
See: https://youtrack.jetbrains.net/issue/IDEA-160274#focus=streamItem-27-3721096.0-0
Original answer
IntelliJ doesn't have this feature, however there is a feature request here:
https://youtrack.jetbrains.com/issue/IDEA-160274
If you would like the feature implemented, you can vote there.
"Dataflow to here" and "Dataflow from here" give you a recursive view of data flowing in to, and out of, fields (or local variables).
I think that these two features, in fact, are what you're after.
If not, can you rephrase the question in less IDE-specific terms? In other words: what information do you want to extract from your codebase?
Use "Find Usages" feature (Alt+F7)
I'm not much of an Eclipse guru, so please forgive my clumsiness.
In Eclipse, when I call Assert.assertEquals(obj1,obj2) and that fails, how do I get the IDE to show me obj1 and obj2?
I'm using JExample, but I guess that shouldn't make a difference.
Edit: Here's what I see:
(source: yfrog.com)
.
Comparison with failure trace is not a easy task when your object is a little bit complex.
Comparison with debugger is useful if you have not redefined toString(). It remains still very tedious as solution because you should inspect with your eyes each objects from both sides.
Junit Eclipse plugin offers a option when there is a failure : "Compare actual With Expected TestResult". The view is close enough to classic content comparison tools :
Problem is that it is avaiable only when you writeassertEquals() with String objects (in the screenshot, we can see that the option in the corner is not proposed with no String class) :
You may use toString() on your object in assertion but it's not a good solution :
firstly, you correlate toString() with equals(Object)... modification of one must entail modification of the other.
secondly, the semantic is not any longer respected. toString() should return a useful method to debug the state of one object, not to identify an object in the Java semantic (equals(Object)).
According to me, I think that the JUnit Eclipse plugin misses a feature.
When comparison fails, even when we compare not String objects, it should offer a comparison of the two objects which rely on their toString() method.
It could offer a minimal visual way of comparing two unequals objects.
Of course, as equals(Object) is not necessarily correlated to toString(), highlighted differences should be studied with our eyes but it would be already a very good basis and anyway, it is much better than no comparison tool.
If the information in the JUnit view is not enough for you, you can always set a exception breakpoint on, for example, java.lang.AssertionError. When running the test, the debugger will stop immediately before the exception is actually being thrown.
Assert.assertEquals() will put the toString() representation of the expected and actual object in the message of the AssertionFailedError it throws, and eclipse will display that in the "failure trace" part of the JUnit view:
(source: ibm.com)
If you have complex objects you want to inspect, you'll have to use the debugger and put a breakpoint inside Assert.assertEquals()
What are you seeing?
When you do assertTrue() and it fails, you see a null.
But when you do assertEquals, it is supposed to show you what it expected and what it actually got.
If you are using JUnit, mke sure you are looking at the JUnit view and moving the mouse to the failed test.
FEST Assert will display comparison dialog in case of assertion failure even when objects you compare are not strings. I explained it in more detail on my blog.
If what you are comparing is a String then you can double click stack element and it will popup a dialog showing the diff in eclipse.
This only works with Strings though. For the general case the only way to see the real reason is to install a breakpoint and step into it.