GWT Super Dev Mode variable referenceError: variable is not defined - gwt

I'm using GWT Super Dev Mode and the Chrome debugger. Some (not all) variables won't let me examine their values, either by hovering or by right-click -> Evaluate in Console. The latter gives "ReferenceError: is not defined. It reminds me of an earlier environment where the compiler optimizer simply removed variables of short duration. Does anyone know why this happens or how to stop it? Here is a code example:
public AbstractModal( final String title, final String width )
{
this( title, width, ( int )( Window.getClientHeight( ) * AbstractModal.MaxHeightPercentage ) + "px" );
}

Related

MQL4 - How to set a "today"-datetime to an extern variable in MQL4 script?

I have an MQL4 script ( a script that runs on MetaTrader4 Terminal platform ) and I need to define an extern variable, named extractionDate of type datetime, so that the user can change its input value before the script starts.
I tried the conventional way to define the variable before the standard script's function start(), but it doesn't work. When I compile I, get the error message
['TimeLocal' - constant expected]
that means MQL4 wants a constant value for the variable. But this isn't my goal. I would like to show as default value the "Today" date, when the script starts and not a fixed predefined date value.
Is it possible to do this or not?
extern datetime extractionDate = TimeLocal();
int start()
{
......
return(0);
}
No, compiler does not allow this directly
Compiler does not allow a way to assign a default value, that is not constant.
It has to know the value, so an attempt to setup / assign an unknown / variable-value as a default one, will yield compilation error.
Yet, how to solve this?
My approach would be to give user instructions and a choice to setup any datetime, or setup a value of -1, which would be translated inside the OnInit() event handler code-block:
void OnInit(){
...
if ( extractionData == -1 ) extractionDate = TimeLocal();
...
}

Run processing PApplet in Scala

Here is the code:
import processing.core._
import PConstants._
import PApplet._
class PApp extends PApplet{
args = Array("PApp")
var x: Float = 0.0f
var y: Float = 0.0f
var z: Float = 0.0f
override def setup(): Unit = {
size(200, 200, "P3D")
x = width/2
y = height/2
z = 0
}
override def draw(): Unit = {
translate(x, y, z)
rectMode(CENTER)
rect(0, 0, 10, 10)
z += 1
}
}
If I try to run this (ctrl-shift-R in intellij), I get this message:
Usage: PApplet [options] <class name> [sketch args]
See the Javadoc for PApplet for an explanation.
And no graphics appear. How can I solve this?
You should fill up the "Program arguments:" option inside the Run Configuration.
This is like this option is set up in my case:
As stated in the error message:
Usage: PApplet [options] <class name> [sketch args]
This means that when PApplet runs, it needs at least one argument - <class name> - the full class-path of your sketch. The options and Sketch Args are optional, as indicated by the square braces.
So, if you have a sketch like this:
package com.something.nice;
public class MySketch extends PApplet
{
...
}
Then, you'll need to pass com.something.nice.MySketch as an argument to your application.
In IntelliJ IDEA, you do this in your build configuration (via the menu: Run -> Edit Configurations...), in the "Program arguments" field.
This requirement was a result of the changes from Processing v2 to v3.
Applet is gone — Java's java.awt.Applet is no longer the base class
used by PApplet, so any sketches that make use of Applet-specific
methods (or assume that a PApplet is a Java AWT Component object) will
need to be rewritten.
You may also want to take note of this (same doc):
A new settings() method that is called behind the scenes. Most users
will never notice this, but if you're using Processing without its
preprocessor (i.e. from Eclipse or a similar development environment),
then put any calls to size(), fullScreen(), smooth(), noSmooth(), and
pixelDensity() into that method. More information can be found in the
reference. Only users who are in other development environments should
use settings(). It shouldn't be used for any other purpose.

Java 8 Optional.ifPresent is my code wrong or is it eclipse?

I am new to Java 8 and trying out Null type annotations and Optional.
For my example below, I have used String rather than my class and am calling toUpperCase just to call something, in my case I actually call a function passing in a parameter (so don't think I can use :: operator and/or maps).
In Eclipse I have the Java - Compiler - Errors/Warnings - Null Analysis Errors turned on.
My test code below:
public void test1(#Nullable String s) {
// the 2nd s2 has a Potential null pointer access error.
// I was hoping ifPresent would imply NonNull
Optional.ofNullable(s).ifPresent(s2 -> s2.toUpperCase());
}
#Nullable
public String getSomeString() {
return null;
}
public void test2() {
String s = getSomeString();
// This is fine, unlike the first example, I would have assumed that
// it would know s was still nullable and behave the same way.
Optional.ofNullable(s).ifPresent(s2 -> s2.toUpperCase());
}
It would seem that using Eclipse type null annotations and Optional.ifPresent doesn't go well together.
Am I wasting my time trying to get something like this to work? Should I just revert back to assigning the getter to a temp var then checking if null, and if not call my function?
JDT's null analysis cannot know about the semantics of each and every method in JRE and other libraries. Therefore, no conclusions are drawn from seeing a call to ifPresent. This can be remedied by adding external annotations to Optional so that the analysis will see method ofNullable as
<T> Optional<#NonNull T> ofNullable(#Nullable T value)
External annotations are supported starting with Eclipse Mars, released June, 24, 2015. See Help: Using external null annotations.
The difference between the two variants in the question is due to how null analysis is integrated with Java 8 type inference: In variant (1) s has type #Nullable String. When this type is used during type inference, it is concluded that the argument to ifPresent is nullable, too. In variant (2) s has type String (although flow analysis can see that is may be null after the initialization from getSomeString). The unannotated type String is not strong enough to aid type inference to the same conclusion as variant (1) (although this could possibly be improved in a future version of JDT).
First of: #Nullable seams not to be part of the public Java 8 SDK. Have a look at the package you imported: com.sun.istack.internal.Nullable.
Second: I have run both of your methods: test1(null) and test2() and nothing out of the ordinary happened. Everything was fine (as expected). So what did you observe?
run test1(null) => no execution of lambda expression.
run test2() => no execution of lambda expression.
I changed your code for testing in the following way:
public void test1(#Nullable String s) {
Optional.ofNullable(s).ifPresent(s2 -> System.out.println("executed"));
}
public void test2() {
String s = getSomeString();
Optional.ofNullable(s).ifPresent(s2 -> System.out.println("executed"));
}

Java: Using the 'this' keyword in conjunction with enum attributes produces errors and compiles fine w/o changes. Is this a bug?

I apologize in advance for not knowing how to better state this question.
In the following program, I'll get an error if I run it in NetBeans. It's using an enum and it seems to not like it when I use the 'this' keyword. Code:
enum moreEnum{
JOHN(10,"nice"),
TONY(20,"cool");
String desc;
int myNum;
moreEnum (int a, String desc){
myNum = a;
this.desc = desc;
}
public String getDesc(){
return desc;
}
public static void main (String [] args){
System.out.printf("%s \t %s \n", moreEnum.JOHN, moreEnum.JOHN.desc);
System.out.printf("getDesc() method - %s", moreEnum.JOHN.getDesc());
}
}
I'll get this error when I run it:
java.lang.VerifyError: Constructor must call super() or this() before return in method moreEnum.<init>(Ljava/lang/String;ILjava/lang/String;)V at offset 0
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getMethod0(Class.java:2685)
at java.lang.Class.getMethod(Class.java:1620)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:488)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:480)
Exception in thread "main" Java Result: 1
If I change the position of the line:
this.desc = desc;
to directly above the myNum = a; , then it will run fine. If I put the this.desc = desc; right back to where I moved it from (making the program identical to way I ran it the first time w/ the error), I will no longer have an error. If I then change the "desc" variable to anything else, I'll get the error again, and can resolve it by switching the placement of the 'this' line, running it with no error, and switching it back and then it'll run fine.
I guess my question is really, "What is going on?!" Is this an enum issue? 'this' issue? Or a NetBeans issue?
It could be a caching issue with Netbeans? I cannot reproduce this in Eclipse (JDK 1.7), unfortunately. Maybe try to clean the project before compiling/running?

How can I improve eclipse code completion?

Eclipse does not find the correct variable for code completion as shown below.
int i = 0;
f(xyz); // f takes an int but eclipse won't fill it with i.
Under "Window" > "Preferences" > "Java" > "Editor" > "Content Assist", make sure "Fill method arguments and show guess arguments" is set and "Insert best guessed arguments" is selected.
Edit:
I tried this in my Eclipse (Version: Helios Service Release 1 - Build id: 20100917-0705):
public class BestGuessedParameter {
static int xyz = 1;
static void f(final int xyz) {
}
public static void main(final String[] args) {
final int i = 0;
f/*cursor here*/
}
}
Right after I typed the f, I hit space and selected f(xyz), Eclipse did supply f(i) with i highlighted and in a pop-down menu of i (highlighted), xyz, and 0. i was the default.
I couldn't find any info on how Eclipse selects the "best guessed parameters" (I have no idea where to look in the Eclipse source). I would guess that Eclipse "guesses" based on type, name, and visibility, and that Eclipse thinks there's a better match than your local variable. Perhaps if the local variable were closer in type and name, it would be a better match?