what happens, exactly? i wasn't able to reproduce the problem.

k, this is now on the todo list.

this is still a ton of code, there are dozens of things that could be
wrong. i need something more specific that would show the problem, because
this isn't something that's ever been reported. is it possible to cull this
down to 5-10 lines that show the issue?

sorry, lost track of this. is it still relevant for the current code with
the linux script, or have these issues been covered with the more recent
updates?

thanks for looking into it!

This appears to have been a Java problem that was fixed with a later Java
release. 

k, we'll leave it in the db so people can vote on it or advocate for its
inclusion.

looked into this, it's simply the correct behavior. you're just seeing the
key repeat kicking in. if you hold down any key for a certain amount of
time, you'll get multiple keyPressed() events. with alt-tab on windows,
you're holding down ALT, which kicks in the repeat.

apple has deprecated quicktime for java, so i suspect that it's starting to
break when used in browsers, and likely isn't going to come back. i'll add
it to the list.

can you post a very short example that shows the problem?

you've probably figured this out in the meantime, but you should never use
a while() loop in that fashion. unlike on microcontrollers, there are
several threads running at once in this case, so by locking one of them,
you'll have bad/inconsistent results for anything else that tries to happen
in that time. this is just bad code in this context.

Created an attachment (id=400)
example from ira

k, noted.

it's just a cross-platform thing. we just refer to preferences.txt in tons
of places in the documentation, and there are enough caveats about its
location with regards to each platform without having to change the name
for each platform as well. so we'll just keep it as preferences.txt.

verified, will look into it.

does setSize(w, h) work?

the limit should be a few megabytes. can you post it somewhere else? or
make it smaller perhaps? thanks!

k, added to the preprocessor bugs list.

thanks, now implemented for the next release.

what happens? error message? something crashes? nothing starts?

to be clear, does this work in 1.0.9 and is broken in the svn version?

have you tried this with JOGL examples? this sounds complicated enough that
it may not be specific to processing.

I am not sure if that is the intended behavior, because, at least in my
case, the ALT key event was repeatedly called even if I immediately
released the ALT key after switching windows.
And it continued calling the ALT key although I did not press any button
afterwards.

          
>       looked into this, it's simply the correct behavior. you're just
seeing the
> key repeat kicking in. if you hold down any key for a certain amount of
> time, you'll get multiple keyPressed() events. with alt-tab on windows,
> you're holding down ALT, which kicks in the repeat.		 
> 		 
>

If the code is cut down, the problem with the obstinately transparent panel will not be 
that evident, I think.

May I dare ask if you have copied and pasted the code to Processing, ran it, and 
visually verified what the problem is, please?

I am willing to explain the code in detail if you wish. Basically, the draw() routine 
consists of drawing a teapot made up four circular layers, plus a spout() and a handle
(). The panel to which the handle affixes remains transparent, whereas it should be 
coloured in line with the ring of panels of which it is part of.

The coordinates of the four layers are given at lines 41 to 45. Lines 60 to 62 are 
responsible to colour each layer. Accordingly, the transparent panel should instead 
show up in colour as per line 61. Instead, it is transparent!

I have just dowloaded Processing 1.0.9 with bundled Java onto my Compaq
6910p laptop running XP SP3, English (UK). When I try and run the program I
get 'Launch4j An error occured when starting the program'. I have no
non-standard characters in my Windows username.

Thanks
Dave

CmdLine:	C:\Program Files\processing-1.0.9\processing.exe --l4j-debug 
WOW64:		no
Working dir:	C:\Program Files\processing-1.0.9\.
Bundled JRE:	java
Check launcher:	C:\Program Files\processing-1.0.9\java\bin\javaw.exe (OK)
Add classpath:	lib\pde.jar
Add classpath:	lib\core.jar
Add classpath:	lib\jna.jar
Add classpath:	lib\ecj.jar
Add classpath:	lib\antlr.jar
Launcher:	C:\Program Files\processing-1.0.9\java\bin\javaw.exe
Launcher args:	-Xms128m -Xmx128m -classpath "lib;C:\Program
Files\processing-1.0.9\java\lib\tools.jar;lib\pde.jar;lib\core.jar;lib\jna.jar;lib\ecj.jar;lib\antlr.jar"
processing.app.Base
Args length:	170/32768 chars

Created an attachment (id=401)
img.copy() changes alpha from 255 to 254

Hello fry!

My report was a little confusing. I created a minimal sketch, its clearer now.
There is just one image that is copied over itself. Look at the console output,
press shift for a second, after the image is swapped, alpha goes from 255 to
254. filtering does not help. loadPixels neither.

PImage img; // image we want to track
PImage nimg; // next image
color c; // under mouse

void setup()
{
  frameRate(1);
  size (200, 200);
  img = loadImage("some.jpg");
  nimg = loadImage("some.jpg");
  //nimg.filter(OPAQUE);
}

void draw()
{
  image(img, 0, 0, width, height);
  if(keyPressed && keyCode == SHIFT) {
    img.copy(nimg, 0, 0, nimg.width, nimg.height, 0, 0, width, height);
    //img.loadPixels();
    println("image swapped.");
  }
  c = img.pixels[mouseY*img.width+mouseX];
  println(mouseX+", "+mouseY+", "+alpha(c));
}

are you using a 64-bit version of windows?

The bottom line is that the event is what we're getting from Java, or the
OS. If you feel it's a bug, you can file a report at http://bugs.sun.com/

It was in the SVN version. At that time the latest release was working fine.

(In reply to comment #1)
> 
> 		
>         
>           Additional Comment #1 From
>           fry
>           2010-02-17 20:54 
>           
>           [reply]
>           
>           	
>       
>         
>       
>       
>       to be clear, does this work in 1.0.9 and is broken in the svn
version?		 
> 		 
> 		

you're getting a tesselation error, usually this is because of an error in
the code where a vertex on a shape is coming back and meeting itself, or a
NaN value for one of the vertices.

but if you don't want to debug your code, you can just change it--these
shouldn't be drawn as polygons. use beginShape(QUAD) which will be more
efficient, and the problem goes away.

k, the problem is just that the image functions (like copy) aren't super
accurate. they sacrifice accuracy for speed, so there's some rounding error
as things are transferred. unfortunately that's what you're seeing here.
there's not much we can do about it short of making the image copy() method
far slower, so i think we're mostly stuck with it.

thanks for the report, i'll keep this around in case we can move to a
better solution in the future.

thanks, it's a regression from another bug that was caused by
camera/perspective being called in setSize(). will fix.

32 bit.


(In reply to comment #1)
> 
> 		
>         
>           Additional Comment #1 From
>           
>           	fry
>           2010-02-18 05:41 
>           
>           [reply]
>           
>           	
>       
>         
>       
>       
>       are you using a 64-bit version of windows?		 
> 		 
> 		

k, any other clues that might give me something to go on? 

What would you like to know?

I have J2SE Runtime Environment 5.0 Update 12 in my programs list.
The Jinitiator Control Panel About informs me 
'Java(TM) Runtime Environmnet, Standard Edition 1.3.1.23-internal
Default Virtual Mchine Version 1.3.1_16-b06
Oracle Jinitiator 1.3.1.23'

I have many other programs installed.

Processing 1.0.9
Mac OS X 10.6.2
MacBookPro5,2 (2009 17")

The following sketch does not run/export:

Class a = PApplet.class;
void draw() {}

Rather, an error "Invalid type:70" is output.

Turns out this is because the LITERAL_class token (after "PApplet.") is ignored in the 
print(AST) function of PdeEmitter.  Inserting

case LITERAL_class:

into the long list of cases around line 670 of processing/app/preproc/PdeEmitter.java solves 
the problem.  At the bottom of that file is a list of other tokens which are believed to never 
be produced by the syntax parser – maybe they should all go to the list at line 670 to get 
passed through.

hello fry,

it wont start, nothing happends.
i solved the problem, look here----

http://processing.org/discourse/yabb2/YaBB.pl?num=1262107133

regards maik

(In reply to comment #1)
> 
> 		
>         
>           Additional Comment #1 From
>           fry
>           2010-02-17 19:25 
>           
>           [reply]
>           
>           	
>       
>         
>       
>       
>       what happens, exactly? i wasn't able to reproduce the problem.		 
> 		 
> 		

The lines, instead of flowing smoothly, jitter, briefly jumping back and
forth between and old and new position. I'll post a version with more lines
 - maybe it will become more clear. And as I said, you may have to watch
for a while. My colleague has the same problem and for that reason has
stopped using OpenGL.

import processing.opengl.*;

void setup() {
size(720, 720, OPENGL);
frameRate(40);
smooth();
}

float a = random(-1, 1);
float b = random(-1, 1);
float c = random(-1, 1);
float d = random(-1, 1);
float e = random(-1, 1);
float f = random(-1, 1);
float g = random(-1, 1);
float h = random(-1, 1);

void draw() {
background(75, 60, 85);

a = a + .002;
b = b + .0025;
c = c + .001;
d = d + .0015;
e = e + .0005;
f = f + .003;
g = g + .0035;
h = h + .0015;

noStroke();
fill(20, 220);
curve(width/2+sin(b)*(width/2+100), width/2+sin(c)*(width/2+100),
width/2+sin(d)*(width/2+100), width/2+sin(e)*(width/2+100),
width/2+sin(f)*(width/2+100), width/2+sin(g)*(width/2+100),
width/2+sin(h)*(width/2+100), width/2+sin(a)*(width/2+100));
curve(width/2+sin(c)*(width/2+100), width/2+sin(d)*(width/2+100),
width/2+sin(e)*(width/2+100), width/2+sin(f)*(width/2+100),
width/2+sin(g)*(width/2+100), width/2+sin(h)*(width/2+100),
width/2+sin(a)*(width/2+100), width/2+sin(b)*(width/2+100));
curve(width/2+sin(d)*(width/2+100), width/2+sin(e)*(width/2+100),
width/2+sin(f)*(width/2+100), width/2+sin(g)*(width/2+100),
width/2+sin(h)*(width/2+100), width/2+sin(a)*(width/2+100),
width/2+sin(b)*(width/2+100), width/2+sin(c)*(width/2+100));
curve(width/2+sin(e)*(width/2+100), width/2+sin(f)*(width/2+100),
width/2+sin(g)*(width/2+100), width/2+sin(h)*(width/2+100),
width/2+sin(a)*(width/2+100), width/2+sin(b)*(width/2+100),
width/2+sin(c)*(width/2+100), width/2+sin(d)*(width/2+100));
}

Now updated for the next release. Thanks for your help!

awesome, thanks so much for the help! now fixed for the next release.

Thanks for your kind advice. An interesting suggestion!

how about making a video of it (use saveFrame() to make an image sequence,
then movie-ify them with quicktime 7) so you can point out where the
problem is?

I'm interested in this bug to get fixed, not for text but for drawing low
opacity lines in a created graphics.  Any idea where should I start looking
in the code to try to get this fixed?
thanks

It's in the rendering code for PTriangle and PLine for P2D and P3D. The
issue is how blending works on top of an alpha channel, but it affects
dozens of places in the code and has to be done consistently. Basically,
need to set some rules for how drawing happens on a transparent surface
versus an opaque surface, and have that be consistent with expectations
when people overlay that image on another drawing area. 

That would be great if you can take a look into it, and I'm happy to help
however I can. It's just that it's a piece that touches a lot of rendering
code (almost anywhere that you have a pixels[xxx] = xxx), so it has to be
done wholesale.

OK, I've done that. It should be obvious from watching these two identical
sequences, one done with OpenGL and the other with the default renderer.

http://www.mti.dmu.ac.uk/~rherrema/graphics/OpenGL.mov

http://www.mti.dmu.ac.uk/~rherrema/graphics/Default.mov

That looks like a clipping problem--that some of the triangles are actually
flying past the camera and going missing. Because of their long distances
toward you, that's why you get the flicker. In P3D, you don't see it,
because P3D doesn't do clipping properly. OpenGL does clipping, so your
geometry is getting chopped up (like it should, really).

A glance at your code looks like that's probably the case, and that you
actually need to translate backwards from z=0:
http://processing.org/reference/environment/#Coordinates

Fixed for revision 0176.

Fixed for revision 0176.

'static mode' (no setup/draw methods) sketches result in a blank screen.
Any sketch that calls noLoop() also has problems.

(In reply to comment #5)
> 
> 		
>         
>           Additional Comment #5 From
>           
>           	fry
>           2010-02-20 11:04 
>           
>           [reply]
>           
>           	
>       
>         
>       
>       
>       That looks like a clipping problem--that some of the triangles are
actually
> flying past the camera and going missing. Because of their long distances
> toward you, that's why you get the flicker. In P3D, you don't see it,
> because P3D doesn't do clipping properly. OpenGL does clipping, so your
> geometry is getting chopped up (like it should, really).
> 
> A glance at your code looks like that's probably the case, and that you
> actually need to translate backwards from z=0:
> http://processing.org/reference/environment/#Coordinates		 
> 		 
> 		

Actually, I do see the flicker when I use P3D. It's only in JAVA2D that I
don't see it.

I don't understand what you mean by clipping (in audio it means you've
exceeded the dynamic range of the system), nor what you mean when you say
'to translate backwards from z=0. Can you explain or point me in the right
direction? Of course, my primary goal is simply to produce the smoothest
graphics possible.

Thanks.

Export code has been updated for revision 0176 for better scenarios all around.

Filed to the Apple bug reporting black hole as #7671837. 

Sorry--I misspoke. You're running into something else. I'll take a look
into it.

fixed for revision 0176.

Is anyone using Processing on UNR? Please let me know your experience good
or bad and what hardware you are running on.

I am having problems running processing on my netbook, but could do with
some more info to submit a bug report to the developers.

Whenever I try and run a windowed processing application in UNR on my EeePC
1000H I lose my session and end up at the login prompt. I assume X is
crashing and being restarted. This only appears to happen on my Netbook and
only when on UNR. It also only works when it's a windowed application. If I
run the same application in fullscreen mode without the title bars etc.
then it works fine.

It's not a problem with my code as this is happening using the Examples
that are shipped with the PDE (Processing Development Environment) as well.

Processing works on

Ubuntu desktop
Ubuntu Netbook Remix (UNR) running on my laptop as a Virtualbox VM
Fedora running on the same EeePC netbook as the problem is in UNR

but not UNR on EeePC.

I am running processing 1.0.9 from the processing.org binaries.



I have searched the log files, but can't find anything meaningful.

There are no messages for processing or X.org in the syslog.

I do have X.org logs, but they appear to be just giving X.org startup
information, I can't see anything that jumps out as a problem with X.org.
Maybe I'm missing something, but there doesn't appear to be any timestamps
in the log so I'm not sure what I should be looking for.

Please let me know if anyone knows of any way of any issues or just of a
way to get debug messages from either X or from Processing so I can submit
a more meaningful bug report.

*** This bug has been marked as a duplicate of 1457 ***

*** Bug 1468 has been marked as a duplicate of this bug. ***

Looks like the initial binaries for the Linux's will be more complicated
then I initially thought.

For starters, I'll need to go over the Copyright file...

System libraries need to be ported, (perhaps I'll work with upstream to fix
the awkward bits which need adjustment.)

I'll setup ant to build all the source into a small [known] number of jars.
Then all I need to do is list those jars in the install file.

This'll take a week or two, maybe longer (as Uni begins tomorrow).

I'll keep you updated.

Alec Taylor

On Mac OS X, there's a problem with picking up the ANDROID_SDK environment
variable. Try setting it in your .profile or .bashrc file, then use
Terminal to launch via: 

open /Applications/Processing-0177.app

Theoretically you can set ANDROID_SDK in ~/.MacOSX/environment.plist, but I
wouldn't recommend it, because it can break launching all
applications on your machine.

This will be fixed for revision 0178.

The tools.jar included with Processing should be enough, unless people are
using their own JDK (which also needs to be handled more gracefully anyway). 

Also need to remove the requirement that the PATH must include
JAVA_HOME/bin. Instead use the local JRE+tools for Processing (or keep the
requirement for advanced users).

It's no fun, and not necessary. Just need to sort out env mess.

compiling a sketch that includes a '.java' file may result in complaints
about duplicate class definitions.

could be just a config issue, but with a naive installation of 0177 (download, place in Application folder) 
sketches that:

import processing.pdf.*;

result in 

The package processing.pdf does not exist

2/21/10 6:19:03 PM	[0x0-0x3a83a8].org.processing.app[29109]	Note that release 1.0, libraries must 
be installed in a folder named 'libraries' inside the 'sketchbook' folder.

Invalid link to http://processing.org/reference/environment/platforms.html
on http://processing.org/faq.html

Gives me a blank page (with the header & footer of the other Processing pages)

Please fix.

Thank you

Alec Taylor

bummer, looks like something didn't work with the itext downgrade. in the
meantime, you can probably use the pdf library (or even just its itext.jar
file) from 1.0.9 and you should be fine.

Created an attachment (id=402)
Modified PApplet.java

The processing command line tool does not initialize the libraries and
therefore is unable to export applets and applications for sketches that
use external libraries.  Another reason for this not working is that the
app.Commander tool does not use the preferences file parameter and
therefore cannot find the sketchbook folder.

Created an attachment (id=403)
Fixes both issues

*** This bug has been marked as a duplicate of 1298 ***

*** Bug 1476 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 1048 ***

*** Bug 1476 has been marked as a duplicate of this bug. ***

As of 1.0.9.

This is a trivial, low-visibility/low-significance bug, but...

Within PImage.java dilate(boolean) there two occurences of code to clamp the l/r/t/b 
kernel coords at image edges.  The clamp for the top coordinate incorrectly assigns 
pixel[0] for all columns, currently reads:

if (idxUp<0)
  idxUp=0;

should be changed to read:

if (idxUp<0)
  idxUp=currIdx;

as do the similar tests for l/r/b edges.

It's very subtle, but can be seen as a 5 pixel tall "gray band" across the top of this 
example:

size(200,200);
background(loadImage("milan_rubbish.jpg"));
for (int i=0; i<5; i++)
  filter(DILATE);

thanks! just made the change in the two places in PImage, i'll assume we're
all set but let me know if there's a problem.

need a method to bring up the virtual keyboard, especially for devices that
don't have one.

Good Evening,

Whilst writing some rudimentary code, I came across a bug.

When inputting a negative number in the int field of an object (eg;
ellipse), the output shows everything but the object, until code is saved.

Here's my code (from my very basic class assignment);
ellipse(-50,50,50,50);
line(25,25,75,75);
line(75,25,25,75);

Please fix this bug ASAP.

Thank you

Alec Taylor

BTW: I'm aware integers should be positive, however this is still an issue
with the IDE

PS: I'm using Windows XP (32-bit) with latest JRE & included JDK

Correction;

Signed integers can show negative numbers, whilst unsigned integers can't.

That's not a bug, you've simply drawn the shape where you can't see it. 

I perfectly understand that, however why would pressing Ctrl+S, then Ctrl+R
again make the object reappear?

this probably means that some memory isn't being freed that should be, as
it re-allocates the PGraphics drawing surface repeatedly.

fixed for 0178.

now behaving better for 0178.

new window and surfaceview objects are being created in onCreate, so they
should probably be taken down in onDestroy, since they aren't automatically
garbage collected.

if building and running a sketch on a device across multiple machines, the
debug.keystore will be different. when trying to install, you'll get an
error saying that the application must be manually removed. 

options for this: 1) copy the keystore between machines that do development
(yech) 2) automatically remove the code the first time it's compiled and
installed from p5 within a session.

#2 is better, but requires a check to see if the application is already
installed. the remove operation seems fairly quick.

on the other hand, the actual 'release' keystore will have to be synched
between machines, so maybe we just need to make it easier to set up a
processing-specific keystore to be used for debug and release.

Processing 1.0.9

I believe the following code demonstrates a bug with respects to the copy and blend functions. 
Given an image (in this case 32x32), if we use the image(PImage img, int dx, int dy) to copy an 
image to a location the image is drawn accurately pixel for pixel without scaling. However if you use 
one of the following calls:

copy(src, sx, sy, 32, 32, dx, dy, 32, 32)
-or-
blend(src, sx, sy, 32, 32, dx, dy, 32, 32, REPLACE)

the resulting image is bilaterally filtered an the results from the copy() and blend() don't look the 
same as when the image() method is used. I've attached sample code below. Assume that 
example.png is a 32x32 icon.

Thanks

[code]
PImage myImage;

void setup()
{
  myImage = loadImage("example.png");
  
  size(300, 300);
}

void draw()
{
  background(0);
  image(myImage, 32, 32);
  copy(myImage, 0, 0, 32, 32, 0, 32, 32, 32);
  blend(myImage, 0, 0, 32, 32, 64, 32, 32, 32, REPLACE);
}
[/code]

Created an attachment (id=404)
Example sketch with image.

Running a simple app, and switching from portrait to landscape orientation, causes an 
application crash.

Environment is a Motorola Droid, running DroidMod 1.0 (kernel 2.6.29-omap1), 
Processing 0177 and the latest full SDK install.

fixed it yesterday. the change will be in release 0178.

...with no updates happening on the screen, though the application appears
to still be running and responding to at least some events. this can be
seen with the Basics > Web > EmbeddedLinks example. after hitting the
'back' button from the browser, the application no longer draws, though it
responds to touch events.

for computationally intensive applications in particular, often getting the
error when quitting out of the app (e.g. with ESC in the emulator), even
though the app was closing.

Examples > Topics > Drawing > Continuous Lines shows gaps

right now it's using the expensive copy() operation inside PImage. no need
to do that, and it's probably lower quality.

fixed, was just that the BACK key was mapped to exiting the application.
now changed to proper exit(), just like ESC with the desktop version.

currently locked to the Eclair AVD, but need a way to run multiple
configurations for testing. general idea would be something like AVDs for
1) Nexus One 2) Droid 3) myTouch 3G. 

since it's not exact (we don't have the actual classes or skins for these),
this mostly just means memory, screen size, resolution, latest public os
version on that device, and maybe even default sd card (though that could
be 2GB or 4GB, so prolly not).

if possible, we'd like to have createGraphics() also work for OpenGL rendering.

createGraphics() for A2D (P2D/JAVA2D) working for 0178. A3D/P3D/OPENGL
coming in the future, see bug #1488.

like the desktop version, it'd be nice to allow others to write alternative
rendering engines that can be plugged in. however, it's a lower priority
since it's far less useful on the mobile platform.

fonts use PConstants.ALPHA for images, which are just converting to ARGB on
first draw. the ALPHA config from the Android SDK might be more efficient
(and even higher quality).

fixed for 0178.

probably not possible, or necessarily a good idea.

this may have been fixed for 0178, but need more info to find the bug.

just as the man said. for the moment, will probably encourage use of other
libraries, since the multi-touch APIs are settling.

not sure if this is necessary, but might be a useful speedup or
housekeeping endeavor.

thanks, will look into it. should be a simple fix. 

though for the copy() and blend(... REPLACE) case, you can just use get()
or set(), which will be faster in the meantime.

After a fresh checkout of revision 6305 I cd to the build directory and successfully compile with 
ant. Running the app causes "Uncaught exception in main method: 
java.lang.NullPointerException" Feel free to delete the bug if you already know about it, I just 
wanted to have it documented somewhere. Here's the error log dump:

3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]	
java.lang.ClassNotFoundException: processing.app.tools.android.AndroidTool
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.net.URLClassLoader$1.run(URLClassLoader.java:200)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.security.AccessController.doPrivileged(Native Method)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.ClassLoader.loadClass(ClassLoader.java:315)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.ClassLoader.loadClass(ClassLoader.java:250)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.Class.forName0(Native Method)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.Class.forName(Class.java:169)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.createToolMenuItem(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.addInternalTools(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.buildToolsMenu(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.buildMenuBar(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleOpen(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleOpen(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleNew(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.main(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.reflect.Method.invoke(Method.java:597)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.LaunchRunner.run(LaunchRunner.java:115)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]	[LaunchRunner Error] 
processing.app.Base.main(String[]) threw an exception:
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]	
java.lang.NullPointerException
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.addInternalTools(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.buildToolsMenu(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.buildMenuBar(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Editor.(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleOpen(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleOpen(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.handleNew(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
processing.app.Base.main(Unknown Source)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
java.lang.reflect.Method.invoke(Method.java:597)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.LaunchRunner.run(LaunchRunner.java:115)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
3/2/10 8:23:37 AM	[0x0-0x32032].org.processing.app[444]		at 
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

Finally took a minute to sort this out.

When noLoop() is on and you quit, exit() is called. In exit() the main thread is assumed to be 
asleep so stop() is called explicitly, followed by exit2(), which calls System.exit(0). This 
System.exit(0) does not throw an exception, but something odd is happening because it calls 
run() one last time instead of exiting. Because everything was shutdown in the first stop() 
call, run() skips its primary function and begins closing down the applet. Here, stop() is called 
again from run(), followed by exit2(), which completes as expected.

The second stop() called in run() seems odd, but its not hurting anything. It checks to see if it 
was already run, and then exits without doing anything in this instance because it has.

A few questions:
Is this really an issue? Stop() is normally called when the program is closing and again by 
destroy(), just in case the user has overwritten stop accidentally.

If this is an issue, why don't we move the stop() and exit2() calls from the end of run to the 
looping case for exit()? Right now we explicitly take care of this when looping is off, but when 
looping is on we let things run for one more frame and then stop? Seems cleaner to do both in 
exit(), but I can't test it right now.

I'm using Processing-0177 and it's talking to a Nexus One.

Using the following code:

PFont font;
void setup() {
  font = loadFont("Helvetica-48.vlw");
}
void draw() {
  background(0);
  fill(255);
  noStroke();
  textFont(font, 48);
  text("Hello", 10, 48);
}

It hangs at the loadFont line. I get the same error with other font files.
The fonts work fine in normal applet mode. Other data files (csv) in a
bigger sketch were loaded fine by my Android phone, but that sketch also
had trouble with fonts. I haven't had any success displaying text with
createFont, but it doesn't crash.

The Processing app's console reports:

processing.app.debug.RunnerException: RuntimeException: Could not load font
Helvetica-48.vlw. Make sure that the font has been copied to the data
folder of your sketch.
	at processing.app.Sketch.placeException(Sketch.java:1562)
	at processing.app.debug.Runner.findException(Runner.java:562)
	at processing.app.debug.Runner.reportException(Runner.java:537)
	at
processing.app.tools.android.AndroidRunner.exception(AndroidRunner.java:373)
	at processing.app.debug.EventThread.exceptionEvent(EventThread.java:367)
	at processing.app.debug.EventThread.handleEvent(EventThread.java:255)
	at processing.app.debug.EventThread.run(EventThread.java:89)

Using 'adb logcat' I find these further lovely error lines:

I/System.out( 1359): PApplet.onResume() called
D/dalvikvm(   51): GC freed 2 objects / 48 bytes in 107ms
I/System.out( 1359): surfaceChanged() 480 800
D/dalvikvm( 1359): GC freed 802 objects / 60088 bytes in 63ms
I/ActivityManager(   71): Displayed activity
processing.android.test.android_fonts/.android_fonts: 570 ms (total 570 ms)
W/System.err( 1359): java.lang.ArrayIndexOutOfBoundsException
W/System.err( 1359): 	at processing.android.core.PFont.(Unknown Source)
W/System.err( 1359): 	at processing.android.core.PApplet.loadFont(Unknown
Source)
W/System.err( 1359): 	at
processing.android.test.android_fonts.android_fonts.setup(android_fonts.java:12)
W/System.err( 1359): 	at processing.android.core.PApplet.handleDraw(Unknown
Source)
W/System.err( 1359): 	at
processing.android.core.PGraphicsAndroid2D.requestDraw(Unknown Source)
W/System.err( 1359): 	at processing.android.core.PApplet.run(Unknown Source)
W/System.err( 1359): 	at java.lang.Thread.run(Thread.java:1096)
V/RenderScript_jni(  152): surfaceDestroyed
V/RenderScript(  152): setSurface 0 0 0x0
D/dalvikvm(  170): GC freed 1574 objects / 93752 bytes in 1272ms
D/ViewFlipper(  152): updateRunning() mVisible=false, mStarted=true,
mUserPresent=true, mRunning=false
W/dalvikvm( 1359): threadid=15: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 1359): Uncaught handler: thread Animation Thread exiting
due to uncaught exception
E/AndroidRuntime( 1359): java.lang.RuntimeException: Could not load font
Helvetica-48.vlw. Make sure that the font has been copied to the data
folder of your sketch.
E/AndroidRuntime( 1359): 	at processing.android.core.PApplet.die(Unknown
Source)
E/AndroidRuntime( 1359): 	at processing.android.core.PApplet.die(Unknown
Source)
E/AndroidRuntime( 1359): 	at
processing.android.core.PApplet.loadFont(Unknown Source)
E/AndroidRuntime( 1359): 	at
processing.android.test.android_fonts.android_fonts.setup(android_fonts.java:12)
E/AndroidRuntime( 1359): 	at
processing.android.core.PApplet.handleDraw(Unknown Source)
E/AndroidRuntime( 1359): 	at
processing.android.core.PGraphicsAndroid2D.requestDraw(Unknown Source)
E/AndroidRuntime( 1359): 	at processing.android.core.PApplet.run(Unknown
Source)
E/AndroidRuntime( 1359): 	at java.lang.Thread.run(Thread.java:1096)
I/Process (   71): Sending signal. PID: 1359 SIG: 3
I/dalvikvm( 1359): threadid=7: reacting to signal 3
I/dalvikvm( 1359): Wrote stack trace to '/data/anr/traces.txt'
I/Process ( 1359): Sending signal. PID: 1359 SIG: 9

Created an attachment (id=405)
full sketch folder (800KB) with android build bits

Using Processing-0177 on Mac OS X.

e.g. call dataPath() with no arguments in setup() - or any other similar error.

I needed to import java.util.* to get some sketches to work - they work as
normal applets in the same version of Processing (0177).

I'm almost ashamed at how simple this report is, but I'm pretty sure it's
the case. Give me a shout if you need a test applet.

android.processing.org says "at least" but my experience with Processing
0177 indicates that version 5 is required. The android tools give you the
option to list available APIs, maybe that call could be used to derive the
available versions of the Google Tools and use the latest one where possible?

Or you could just update the doc to state that 5 is required :)

When testing existing sketches I needed to remove references to 'screen'.

I wasn't sure if this was an official Processing API member or just a
leftover convenience variable, but I see it listed here:
http://processing.org/reference/screen.html so I'm reporting it as a bug :)

Here's the error I got when I only had version 7 installed:

The following Android Virtual Devices could not be loaded:
    Name: Processing-Eclair
    Path: /Users/tom/.android/avd/Processing-Eclair.avd
   Error: Unknown target 'Google Inc.:Google APIs:5' in
/Users/tom/.android/avd/Processing-Eclair.ini

Here's the output of "android list target" now that I have v5 installed too:

tom% android list target
Available Android targets:
id: 1 or "android-5"
     Name: Android 2.0
     Type: Platform
     API level: 5
     Revision: 1
     Skins: HVGA (default), QVGA, WQVGA400, WQVGA432, WVGA800, WVGA854
id: 2 or "android-7"
     Name: Android 2.1
     Type: Platform
     API level: 7
     Revision: 1
     Skins: HVGA (default), QVGA, WQVGA400, WQVGA432, WVGA800, WVGA854
id: 3 or "Google Inc.:Google APIs:5"
     Name: Google APIs
     Type: Add-On
     Vendor: Google Inc.
     Revision: 1
     Description: Android + Google APIs
     Based on Android 2.0 (API level 5)
     Libraries:
      * com.google.android.maps (maps.jar)
          API for Google Maps
     Skins: WVGA854, WQVGA400, HVGA (default), WQVGA432, WVGA800, QVGA
id: 4 or "Google Inc.:Google APIs:7"
     Name: Google APIs
     Type: Add-On
     Vendor: Google Inc.
     Revision: 1
     Description: Android + Google APIs
     Based on Android 2.1 (API level 7)
     Libraries:
      * com.google.android.maps (maps.jar)
          API for Google Maps
     Skins: WVGA854, WQVGA400, HVGA (default), WQVGA432, WVGA800, QVGA

For those of you who still have this bug and run EVGA On-Screen Display
server, create an application profile for Processing\java\bin\javaw.exe and
set it to the Application detection level to None. It seems to work. If
java\bin\javaw.exe isn't there in your Processing installation directory,
download and install the version of Processing with Java.

fixed by jdf.

fixed by jdf for 0178.

have you fixed this one as well?

so this now works (yay!), but takes 15-30 seconds to take place on os x. is
it similar for windows? the environment appears to hang (presumably
blocking on a thread) after clicking stop giving the appearance of things
having crashed. thoughts?

so the move has started, but the other half of this is to package it as a
regular processing 'tool', that exists in its own tool folder (in
processing/tools like processing/libraries) so that the code can be removed
from Editor that explicitly adds it. 

we could temporarily move it to a Tool, or we can instead try to implement
the 'mode' support, which would probably be a better place for it to live
anyway.

if possible, would be great to automatically unlock the device (emulator or
phone) when running so that the sketch isn't running behind the lock screen.

Created an attachment (id=406)
example sketch

sorry about that. should be fixed now. 

confirmed to be fixed for 0178, thanks.

fixed in 0178.

fixed in 0178.

confirmed fixed in 0178.

ah, i've just removed the "at least" statement to avoid confusion.

yeah, it's screenW and screenH for android (in 0178.. it's not in the
current release). we shouldn't have documented it in the reference on the
desktop version, and i'll be added screenW/H to the desktop release and
marking 'screen' as deprecated. i wouldn't otherwise, but the
java.awt.Dimension class isn't available in android, and using an object
like that isn't in line w/ the rest of the api even for the desktop version. 

oops, that's screenWidth and screenHeight. tho maybe screenW/H is better
since it's more like mouseX/Y.

in fact, i'm going with screenW and screenH, and unlike 'screen', they'll
also be static like they should be. so i've added them to both releases of
core for 0178.

Unfortunately, it's pretty much instantaneous on my Windows box, so it's
hard for me to say where the delay is.

Keep a logcat open on the device in question, and see whether, once you've
pressed the stop button, it takes a long time to see the ActivityManager
report that it's "Starting activity: Intent {
act=android.intent.action.MAIN cat=[android.intent.category.HOME]".

Does is reliably take a long time, or intermittently?

If you held a gun to my head, I'd guess that it's adb being suck on OS X.

No, but that's because I can't reproduce the condition that makes it
necessary. In other words, when I launch Base in a sterile environment (no
JAVA_HOME, no java.exe in PATH), it still works. I'll attach an app that
works from the command line in a sterile environment.

Created an attachment (id=407)
Why does this work when no java is in the PATH?

Ha! I've just reproduced the problem, which shows up when doing the android
ant build. Yay.

Thanks for the report, I'll opt not to fix this, but here's the rationale
for posterity:

1) The emulator launches as the build starts. Both processes take a long
time, but are independent, making them suitable to start in parallel. If we
instead waited to see if the build failed, we'll have to do things
sequentially, which will make builds run more slowly. 

2) If you're running a sketch and get a compile error, chances are that's
not gonna keep you from continuing Android development. In fact, it's more
efficient to have the emulator up and running, since it'll be ready to go
when you've fixed the error. 

3) Because of the crazy amount of overhead on booting/starting the
emulator, we're keeping a single emulator instance open during the P5
session (until the user closes it, or closes Processing). So it'll seem
less weird over time.

OK, I've checked in an attempt at making JAVA_HOME and the existence of
java on PATH completely unnecessary. As always, works for me, please test.

Thank you for spamming your bug tracker.

OK, when I write a program that prints every frame, I can still interrupt
it in less than a second. This might be something we have to work on in
person, so I can kick your mac. Think different!

works for me, thanks.

I poked around the API and the android developers mailing list for resize code. The methods I see 
all rely on createBitmap(), which throws an IllegalArgumentException if the new image is larger 
than the image being resized. It doesn't look like the native android code allows the image to be 
sized up.

Top of the morning to you,

Just wondering why the IDE reopens 'previous projects', which one had
previously open?

Also wondering if we could unimplement this, especially in the case of one
already having processing windows open.

Thank you so much,

Alec Taylor

Created an attachment (id=408)
error message given

It also happens on Mac OS X (10.5.8 in my case). Some fonts can be created (like Serif) and 
others (like Monospaced) make the Processing App hang for a while and then give an error 
(added as attachment)

interesting. good to know. 

so that probably means the fix is to create a Bitmap of the new size, draw
the image into it (using Canvas if necessary) to fill it, then replace the
PImage.bitmap with the new one and dispose of the other. 

though i wonder how that actually fares in comparison to the current method
(in terms of speed and memory use). might not be an outright win.

Is there any way to change the status of this bug to "fixed"?

Is this still true?

As far as I know, I've fixed this. Confirm?

I suppose it could be added as a preference.

Line 263 in base.java would be changed to:

    if(Preferences.getBoolean("last.sketch.restore")){
    	boolean opened = restoreSketches();
	}

and the preference file would need to be modified to have last.sketch.restore, or whatever it 
would be called.

nope, marked as fixed in todo.txt but neglected to update this report.

yep, fixed.

fixed for 0179 and updating bug title.

Hi Ben -- no, I'm no longer noticing the issue. I haven't read over the
most recent code, but I presume it's been fixed.

great, thanks for checking.

already added to PGraphicsPDF for 0179, but might be useful for other
renderers. this is a follow-on from bug #1343.

k, adding this to PDF for the next release. the idea is to use:

PGraphicsPDF pdf = (PGraphicsPDF) createGraphics(w, h, PDF);
pdf.setOutput(yourOutputStream);

then i've added bug #1502 to look at the larger setOutput() issue.

Sayeth the SVG specification at http://www.w3.org/TR/SVG/paths.html :

"The command letter can be eliminated on subsequent commands if the same
command is used multiple times in a row (e.g., you can drop the second "L"
in "M 100 200 L 200 100 L -100 -200" and use "M 100 200 L 200 100 -100
-200" instead)."

...and...

"If a moveto is followed by multiple pairs of coordinates, the subsequent
pairs are treated as implicit lineto commands."

This is not supported by SVN HEAD Processing, which fails to parse SVG
documents which use this feature (including InkScape with default settings).

A patch is included.

Created an attachment (id=409)
Test case

Created an attachment (id=410)
Patch to fix described problem

NOTE: This patch has not been tested on implicit coordinates for shape types
other than polylines.

It would be nice if the select dialogs supported the AWT setFile() option
for the file name.
Perhaps something like selectOutput(String title, String filename);

i can no longer get this code to crash, so i think the problem has been
fixed along the way, either in processing or in more recent java releases.

thanks for the report. i probably won't be adding more features to
these--the idea is to just have a simple means of selecting files. after
that it's best to just use the awt/swing commands directly.

I'm having this problem too -- my problem was I reinstalled processing to a new 
folder, but then Windows wouldn't let me change the file association, neither would it 
let me open a PDE file with "Open with..." 

I had the problem with the registry key, noted in comments above -- but fixing that 
didn't completely clear the problem -- I still couldn't change the file association... and 
when I tried to use processing to change the file association -- java crashed -- I have 
a crash log file if you're interested... but I think it's an ACL security bug in NTFS -- I 
had the same problem with cygwin -- a couple of years back... cygwin also uses a 
non-standard installation method -- and the problem started with reinstallation.  The 
cygwin support people blamed the problem on NTFS/ACL -- and their files for one 
reason or another becoming owned by a phantom user. They actually told people not 
to avoid installing cygwin on an NTFS file system.

Now I have no choice, I'm running processing on an SD card with a FAT file system, 
and without file assocations.

I've now checked in changes that implement type arguments and type
parameters (a.k.a. "generics"), enhanced for loop, varargs, and static
import. Pending some testing, maybe this one is "fixed"?

I seem to have accidentally killed this bug when I stabbed #598. Fixed?

I believe that when I killed #598, it fell on top of this bug and
asphyxiated it. Please verify and mark "fixed" if you can find no pulse.

Please assign to me.

Processing 1.1
OSX 10.6.2

Many of my file paths are failing in Processing 1.1.  All the files exist
and the paths exist in the sketch.  It works fine in Processing 1.09.
[CODE]mainlogo = loadImage("bin/main.png");
logo = loadImage("bin/logo.png");
button = loadImage("bin/button3.png");
font = loadFont("Tahoma-32.vlw");[/CODE]
[color=#ff0000]
The file "bin/main.png" is missing or inaccessible, make sure the URL is
valid or that the file has been added to your sketch and is readable.
The file "bin/logo.png" is missing or inaccessible, make sure the URL is
valid or that the file has been added to your sketch and is readable.
The file "bin/button3.png" is missing or inaccessible, make sure the URL is
valid or that the file has been added to your sketch and is readable.
java.lang.NullPointerException
	at java.io.DataInputStream.readInt(DataInputStream.java:370)
	at processing.core.PFont.(PFont.java:289)
	at processing.core.PApplet.loadFont(PApplet.java:4060)
	at Helios.draw(Helios.java:99)
	at processing.core.PApplet.handleDraw(PApplet.java:1594)
	at processing.core.PApplet.run(PApplet.java:1496)
	at java.lang.Thread.run(Thread.java:637)
processing.app.debug.RunnerException: RuntimeException: Could not load font
Tahoma-32.vlw. Make sure that the font has been copied to the data folder
of your sketch.
	at processing.app.Sketch.placeException(Sketch.java:1565)
	at processing.app.debug.Runner.findException(Runner.java:568)
	at processing.app.debug.Runner.reportException(Runner.java:543)
	at processing.app.debug.Runner.exception(Runner.java:498)
	at processing.app.debug.EventThread.exceptionEvent(EventThread.java:367)
	at processing.app.debug.EventThread.handleEvent(EventThread.java:255)
	at processing.app.debug.EventThread.run(EventThread.java:89)
Exception in thread "Animation Thread" java.lang.RuntimeException: Could
not load font Tahoma-32.vlw. Make sure that the font has been copied to the
data folder of your sketch.
	at processing.core.PApplet.die(PApplet.java:2536)
	at processing.core.PApplet.die(PApplet.java:2545)
	at processing.core.PApplet.loadFont(PApplet.java:4063)
	at Helios.draw(Helios.java:99)
	at processing.core.PApplet.handleDraw(PApplet.java:1594)
	at processing.core.PApplet.run(PApplet.java:1496)
	at java.lang.Thread.run(Thread.java:637)
[/color]

Processing 1.1
OSX 10.6.2

I'm getting this error all over the place.. here is a very basic example.

String test (String x) {
  String ok = x;
  return ok;
}

expecting SEMI, found 'test'
processing.app.debug.RunnerException: Syntax error, maybe a missing semicolon?
	at processing.app.Sketch.preprocess(Sketch.java:1332)
	at processing.app.Sketch.preprocess(Sketch.java:1204)
	at processing.app.Sketch.build(Sketch.java:1590)
	at processing.app.Sketch.build(Sketch.java:1575)
	at processing.app.Editor$DefaultRunHandler.run(Editor.java:1656)
	at java.lang.Thread.run(Thread.java:637)

Not sure if this is a new "feature" or a bug.  I don't remember seeing it
in the revision.txt

If I have a sketch open, then go to open another sketch (I often have
several sketches open at once), it prompts me to save or close my other
sketch and won't open the new sketch until I do one of those or cancel.  I
have to go to file, new, then select the sketch to have it open the second
sketch without closing the other.  Don't like this change..

What would be a nice change regarding open sketches (not sure if this was
changed in 1.1)... if I click on a .pde file and it opens the sketch, don't
open a blank sketch with it.

Checked in fix; please verify.

please attach a sketch that has the problem.

what do you mean "go to" another sketch? you have two windows open and when
you switch to the other window it asks you to save? i don't follow.

confirmed fixed.

*** This bug has been marked as a duplicate of 1442 ***

*** Bug 1506 has been marked as a duplicate of this bug. ***

yep, let's update the status when testing is done.

yep, these ones are at least confirmed to work. great!

appears fixed.

If I open a sketch that I'm working on, then go to open another sketch
(File/Sketchbook/AnotherSketch) - it does one of two things.  It either
closes the first sketch (if no changes were made) or it asks you to save
the first sketch (if changes were made) so that it can close it.

I found out what is causing the issue.  I have this in my sketch, which 1.1
doesn't like.

static public void main(String args[]) {
  PApplet.main(new String[] { 
    "--bgcolor=#000000", "sketch"                                         
                                             }
  );
}

Could this be remedied by an 'open sketches in new window' preference, similar to the open links 
in current or open links in new window options in modern browsers?

I have a situation where the sketch window is partly off the top of the
screen.  Because the bar at the top of the window is not accessible, there
is no way to reposition it.

see revisions.txt: 

+ If you overwrite PApplet.main(), you're responsible for what happens.
  http://dev.processing.org/bugs/show_bug.cgi?id=1446

if you don't know what main() does, then it shouldn't be in your sketch. 

see Help -> Getting Started:
http://processing.org/reference/environment/#PDE

I don't see where this resolves the issue, or where the behavior changed in
the new version.  Could you explain how this is invalid based on the link?
 It still doesn't work as it did in 1.09, and doesn't make much sense to me
why it was changed.  Is there an option to change it back in the
preferences.txt?

Ben, this is taken directly from your example:
http://processing.org/reference/environment/#PDE

To quote you
"If running in "Java" mode, where your code starts "public class blah
extends PApplet", you'll need to write your own main() method in order for
Export to Application to work. It should look something like this:

static public void main(String args[]) {
  PApplet.main(new String[] { "YourClassName" });
}

Not doing this, or using your own main can cause problems internally with
variables not being properly set up. If you opt not to use PApplet.main(),
make sure you read the source code for it so that you understand how it
works, and don't whine if it breaks."

Personally, I don't need it.  I'm just letting you know that it worked in
the last version.  These are your examples and it no longer works.  If
that's your intent, I'm fine with that... just letting you know.

In the past, the behavior was that:

Sketchbook
Open a sketch in a new window from the sketchbook folder.

instead of

Sketchbook
Open a sketch from the sketchbook folder.

likewise, the examples would open in a new window.

If the first sketch is empty, this makes perfect sense but if your working
on a sketch and then want to open an example, it shouldn't try to close out
your other sketch.

Here is a change to the code to add this functionality.

  public String selectOutput(String prompt, String filestring) {
	return selectFileImpl(prompt, FileDialog.SAVE, filestring);
  }

  public String selectFileImpl(final String prompt, final int mode) {
	  return selectFileImpl(prompt, mode, "");
  }

  protected String selectFileImpl(final String prompt, final int mode,
final String filestring) {
    checkParentFrame();

    try {
      SwingUtilities.invokeAndWait(new Runnable() {
        public void run() {
          FileDialog fileDialog =
            new FileDialog(parentFrame, prompt, mode);
		  fileDialog.setFile(filestring);
          fileDialog.setVisible(true);
          String directory = fileDialog.getDirectory();
          String filename = fileDialog.getFile();
          selectedFile =
            (filename == null) ? null : new File(directory, filename);
        }
      });
      return (selectedFile == null) ? null : selectedFile.getAbsolutePath();

    } catch (Exception e) {
      e.printStackTrace();
      return null;
    }
  }

no, you aren't writing a java mode application that includes "public class
xxx extends PApplet", as described in that link. don't use a main() method.
the point is that if you think you know what you're doing, and extend
PApplet, then you have to add main() yourself. but you don't, and you're
not, so it's not a case where you should have a main() method.

Created an attachment (id=411)
copy misbehavior in PImage

Created an attachment (id=412)
fixed copy behavior in PImage

Created an attachment (id=413)
proposed changes to blit_resize

Changing the >= to > on lines 1560 and 1569 of PImage make things behave like
they in the provided test code. I changed the background to full green and
tested this using an image with a 1px pink border.

According to the documentation, "Rather than terminating immediately,
exit() will cause the sketch to exit after draw() has completed (or after
setup() completes if called during the setup()
method)." But, this is not the behavior that I'm seeing. My program appears
to continue running indefinitely, i.e., draw() and move() are invoked again
and again after my program has called exit().

> Changing the >= to > on lines 1568 and 1569 of PImage make things behave like
corrected the line numbers, there was a typo in the first one above

Also, please excuse the spam, I didn't realize it was creating all those independent posts.

i need an example.

awesome, thanks so much for the fix.

wow, i can't believe the OS allows you to do that. but i've added a fix to
avoid it for the next release.

thanks chris, i don't think this is quite right though. on a quick glance,
i wonder if this works better:

    if (srcX2 > img.width) srcX2 = img.width;
    if (srcY2 > img.height) srcY2 = img.height;

but the problem is that 

    if (srcX2 > img.width) srcX2 = img.width - 1;
    if (srcY2 > img.height) srcY2 = img.height - 1;

this seems to introduce a weird case where if the image is 100x100, and
srcX2 and srcY2 are 101x101, then it's gonna give up on that last row of
pixels (rather than scaling them in). 

I added a 4th test case to the sketch where the destination is img.width+1 img.height+1 and my 
fix scales in the last row and column fine. Curiously, I tried your proposed changes and it 
produces the exact same results as mine for the test code. I've reproduced it multiple times, 
altering between original, your fix, and my fix. Both are better than it sits now, though.

In 1.1 Pfont.size has become invisible while it was usable before. This
breaks a library which we are developing. I'd like to know whether this is
this a bug or a feature, so that
we can wait or change our code accordingly.

Example code:

PFont myFont;

void setup() {
  myFont = createFont("FFScala", 32);
  println(myFont.size);
}

works in older versions, e.g. 1.0.8 but in 1.1 gives:
The field Pfont.size is not visible.

OK.  It looks as though I've misunderstood how this is supposed to work.  I
was expecting `exit()` to terminate the processing environment, and it
doesn't do this.  This might just be a documentation issue.

Thanks!

Phillip

processing version: 1.1
mac os x 10.6.2, macbook pro

example code:
----------
// ß

/**
 * a
 */

import processing.pdf.*;
----------

when having two different types of comments before an import statement and
one of the comments contains non-ascii characters the following error occurs:
Exception in thread "Thread-46" java.lang.OutOfMemoryError: Java heap space
at antlr.ANTLRStringBuffer.append(ANTLRStringBuffer.java:36)
	at antlr.CharScanner.append(CharScanner.java:64)
	at antlr.CharScanner.consume(CharScanner.java:82)
	at antlr.CharScanner.match(CharScanner.java:205)
	at processing.app.preproc.PdeLexer.mML_COMMENT(PdeLexer.java:538)
	at processing.app.preproc.PdeLexer.nextToken(PdeLexer.java:249)
	at
antlr.TokenStreamHiddenTokenFilter.consume(TokenStreamHiddenTokenFilter.java:38)
	at
antlr.TokenStreamCopyingHiddenTokenFilter.consumeFirst(TokenStreamCopyingHiddenTokenFilter.java:134)
	at
antlr.TokenStreamCopyingHiddenTokenFilter.nextToken(TokenStreamCopyingHiddenTokenFilter.java:152)
	at antlr.TokenBuffer.fill(TokenBuffer.java:69)
	at antlr.TokenBuffer.LA(TokenBuffer.java:80)
	at antlr.LLkParser.LA(LLkParser.java:52)
	at processing.app.preproc.PdeRecognizer.pdeProgram(PdeRecognizer.java:63)
	at processing.app.preproc.PdePreprocessor.write(PdePreprocessor.java:337)
	at processing.app.Sketch.preprocess(Sketch.java:1271)
	at processing.app.Sketch.preprocess(Sketch.java:1204)
	at processing.app.Sketch.build(Sketch.java:1590)
	at processing.app.Sketch.build(Sketch.java:1575)
	at processing.app.Editor$DefaultRunHandler.run(Editor.java:1656)
	at java.lang.Thread.run(Thread.java:637)

i forgot: this seems to be new to processing version 1.1

Fixed; please test and confirm.

Fixed; please test and confirm.

Fixed; please verify.

 //=====================================================================  
 //Class definitions  
  
class Test {
 
  // some test doing nothing .. //
 
}
 
 /  
 ========================================================================   
 //Setup + Variables + Functions + Arrays  
  
 void setup()  {
   size(500,500);
 }  
 
 void loop()
 {
 } 

Here's a more minimal example:

println("hello");/println("world");

Fixed; please verify.

Example?

Cannot reproduce; please verify and close.

This is a duplicate of bug #6 (or, rather, has the same cause). Please close.

This program fails with an unterminated comment error:

println("oi/*");

I don't know if this is really a processing problem but i can't change the
file association for .pde's to processing or even arduino on processing
1.1, windows 7 home premium. I have tryed multiple times throught the
properties options on the file and the "open with" but no luck. I have been
into folder options in control panel - no luck. I can find the processing
programme but it just won't associate with the file format.If i want to
open a file i have to do it all through processing.

fixed.

fixed; please verify

cannot reproduce; please close

Please add example.

fixed by jdf for revision 0180.

fixed by jdf for 0180.

fixed by jdf for 0180.

confirmed fixed by jdf for 0180.

*** This bug has been marked as a duplicate of 6 ***

*** Bug 507 has been marked as a duplicate of this bug. ***

fixed by jdf for 0180.

fixed by jdf for 0180.

verified fixed by jdf for 0180.

can't reproduce either, may have been fixed in an earlier release. closing.

Version 1.1 - windows Vista - java 1.6.0_17

this piece of code produce this error :
processing.app.debug.RunnerException: unexpected token: /
	at processing.app.Sketch.preprocess(Unknown Source)
	at processing.app.Sketch.preprocess(Unknown Source)
	at processing.app.Sketch.build(Unknown Source)
	at processing.app.Sketch.build(Unknown Source)
	at processing.app.Editor$DefaultRunHandler.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:619)


CODE :
//----- èééèèéééàééèé''ééé
//----------------------------------------------------------------
//--- IMPORTS
//----------------------------------------------------------------
import ddf.minim.*;


=> working on version 1.0.9 (produce blank screen)

Note : it's an example, i'm not writing this kind of comments

One caracter left and another type of error :

CODE : (one "é" left on the line)
//----- èééèèéééàééèé''éé
//----------------------------------------------------------------
//--- IMPORTS
//----------------------------------------------------------------
import ddf.minim.*;


ERROR :
File C:\Users\Francois\AppData\Local\Temp\build20072.tmp\.java is missing


=> Test.java is in the directory

Fixed; please verify

Fixed; please verify and close.

I interpreted this to mean that the literal "d" on a numeric literal should
*always* be respected, even when substitute_floats is true. I have
implemented the fix this way. Please reopen if I misunderstood.

Fixed; please verify and close.

the following two statements should be valid, but cause syntax errors: 

// a class definition that does something with things that extend PApplet
class Heythere{
}

// method definition which can do things with papplet
public  void doSomething( T thing ){
}

interestingly it works in field definitions. this works just fine: 
Vector applets;

Awesome; thanks.

fixed.

wow... that was fast... 
now i have to see if can find another way to break it :) 

This is fixed.

version:

processing-0180

error:

Syntax error on token(s), misplaced construct(s)

source:

import java.util.ArrayList;
import java.util.List;
import java.util.Collections;
import java.util.Comparator;

void setup()
{
  List list = new ArrayList();
  list.add("foo");
  list.add("bar");
  list.add("baz");

  Comparator comparator = new Comparator()
  {
    public int compare(final String value0, final String value1)
    {
      return value0.compareTo(value1);
    }
  };

  Collections.sort(list, comparator);
}

version:

processing-0180

error:

Syntax error, insert ";" to complete ClassBodyDeclarations

source:

import java.util.ArrayList;
import java.util.List;
import java.util.Collections;
import java.util.Comparator;

Comparator comparator = new Comparator()
{
  public int compare(final String value0, final String value1)
  {
    return value0.compareTo(value1);
  }
};

void setup()
{
  List list = new ArrayList();
  list.add("foo");
  list.add("bar");
  list.add("baz");

  Collections.sort(list, comparator);
}

This works ok:

import java.util.ArrayList;
import java.util.List;
import java.util.Collections;
import java.util.Comparator;

Comparator comparator = new Comparator()
{
  public int compare(final Object value0, final Object value1)
  {
    return ((Comparable) value0).compareTo(value1);
  }
};

void setup()
{
  List list = new ArrayList();
  list.add("foo");
  list.add("bar");
  list.add("baz");

  Collections.sort(list, comparator);
}

Fixed; please verify.

version:

processing-0180

error:

The method binarySearch() in the type comparator is not applicable for the
arguments (List, String)

source:

import java.util.ArrayList;
import java.util.List;

void setup()
{
  List list = new ArrayList();
  list.add("foo");
  list.add("bar");
  list.add("baz");

  binarySearch(list, "bar");
}

static  int binarySearch(List> list, T
key) {
  return 0;
}


If the method call binarySearch(list, "bar") is removed the error is:

Syntax error, insert ">>" to complete ReferenceType2

source:

import java.util.ArrayList;
import java.util.List;

void setup()
{
  List list = new ArrayList();
  list.add("foo");
  list.add("bar");
  list.add("baz");
}

static  int binarySearch(List> list, T
key) {
  return 0;
}


A static method declaration using  without nesting works ok:

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

void setup()
{
  List list = new ArrayList();
  addAll(list, "foo", "bar", "baz");
}

static  boolean addAll(Collection c, T... elements) {
  return false;
}

version:

processing-0180

error:

processing.app.debug.RunnerException: (currentLtLevel != 0) || ltCounter ==
currentLtLevel
  at processing.app.Sketch.preprocess(...

source:

import java.util.ArrayList;
import java.util.List;

void setup()
{
  List list = new ArrayList();
  List>> listOfLists = new ArrayList>();
  listOfLists.add(list);
}


In this case PDE fails to compile and also fails to provide a compiler
error message.

Fixed.

Fixed.

To be more specific, PDE should fail to compile and should complain about
the extra ">" at String>>>.  I should have used a different summary.

This simpler declaration also fails to compile.

error:

Syntax error, insert ", TypeArgument2" to complete TypeArgumentList2

source:

import java.util.List;

static  void do(List> list) {
  // empty
}

Wow, MrFeinberg, you're quick.  :)

Fixed.

:)

I saw your post on the mailing list, and was just checking in the fix when
you created the official bug.

Ben, please change the title of this bug to "Unhelpful syntax error message
for extra > in type argument" or something

do is a keyword; that's why the second example is failing

sorry, can't verify because i cannot build an updated application. the
"./make.sh" described in the howto.txt doesn't work for me.

Can't reproduce. Please mark fixed.

how are you using it? i can certainly add an accessor for it, though i
think we'll keep the variable hidden since PFont needs to be more generic
as we start expanding to other platforms (like android). for that matter,
what other parts of PFont do you need access to?

i'd say try an example or two, remove brackets, and see how it responds.
there's a slightly massaged version, but what's thrown up from antlr is
kinda rough for the young'uns.

this is another one where it's just a matter of taking a couple of the
built-in examples and removing semicolons to see how it chokes. the antlr
message is being trapped, but the result is a split problem: 1) the message
is ugly, so it's being caught and altered to be a little friendlier, but 2)
since it's not always b/c a semicolon is missing, it can't just say
"missing ;" instead it's got that ? at the end. which isn't just because
the preprocessor as a passive and friendly character.

processing should set the registry key on startup, but if that's not
happening i'll have to check on a windows 7 machine.