My sketch needs to read in database keys that are "long" ints (64-bits).

Processing can convert "String" to "int", but seems to have a problem converting "String" to "long". I am hoping this is a small oversight that can be fixed in the next update to Processing.

Here is some code that illustrates the problem:
Code:

void setup() {
  int x = int("17");
  long y = long("27");  // this causes the error message
// workaround
  long z = java.lang.Long.parseLong("27");  // this looks so ugly!
}
 

The compile-time error message is:
Code:

Semantic Error: No accessible method with signature "parseLong(java.lang.String)" was found in type "processing.core.PApplet".
 

The JAVA documentation tells me there is a "parseLong" method available in java.lang.Long, but Processing doesn't seem to know about it, since the error message is referring to java.lang.String.  There isn't a "parseInt" in java.lang.String either, but Processing knows how to handle that conversion, ...

It would be great if Processing could be "educated" about "long" for the next update, since many large databases (which we might like to visualize using Processing) have keys that are larger than 32-bit "int"s.

thanks,
 djones

put another way, the confusion is that the syntax:

int("1234");

is converted to

parseInt("1234");

and "parseInt()" is a function in PApplet. it's a shortcut for typing "Integer.parseInt()", which is the way you'd do it in java. so these all do (basically) the same thing:

int("1234");
parseInt("1234");
Integer.parseInt("1234");

when you're trying to do the same thing with long, your code that says

long("1234");

is getting converted to:

parseLong("1234");

which is not a built-in function the way parseInt() is. so instead you have to use the java-style method, Long.parseLong() to do what you want.