Struggles exporting sketch

morty

Hi! I am in desperate need of help.

I just downloaded processing and took a deep dive trying to learn it on my own and create a project for school. I am VERY new to the program and coding in general.

.......

Just to get a feel for the program I took some sample code and made a little prototype. The app runs smooth as butta, but upon attempting to export I get a whole slew of error messages I am unable to decode.

Here is my code:

// setup - runs one time
void setup()
  {
  // set a stage size of 500 x 500 pixels
  size (500,500);

  // smooth all drawing
  smooth();

  // don't draw an outline around your shapes
  noStroke();

  }

  void draw() {
  // Call the variableEllipse() method and send it the
  // parameters for the current mouse position
  // and the previous mouse position
  variableEllipse(mouseX, mouseY, pmouseX, pmouseY);
}
void variableEllipse(int x, int y, int px, int py) {
  float speed = abs(x-px) + abs(y-py);
  stroke(speed);
  ellipse(x, y, speed, speed);
}

// mousePressed - runs every time the mouse is pressed
void mousePressed()
  {
  fill (random(0,255), random(0,255), random(0,255), 50);
  }

And here are the error messages

Thank you SOOO much I feel so frustrated I could cry and this is due next Thursday. I would be eternally grateful for any assistance.

GoToLoop

Perhaps you should try older Processing versions which IMO are better at deployment! 3:-O
Try these out in particular: v2.0.3 & v1.5.1

https://code.google.com/p/processing/downloads/list

KevinWorkman

Telling the OP to always downgrade Processing before exporting seems like a pretty bad idea, imho.

This error message is telling you that it can't find the MacOSX library, which makes sense because it looks like you're on a Windows machine. You can't export to MacOSX on a Windows machine. I suspect that this error isn't really an error, it's just telling you that it tried to export a Mac app and failed, which is the expected behavior.

It also says that the .exe was created successfully. What happens when you try to run it?

KevinWorkman

I just tried it on my computer, and I get the same error. However, like I said, that' s because I'm on a Windows computer and therefore can't export to MacOSX.

This isn't an error. It's just Processing telling you that it tried to export to MacOSX and couldn't, which is what you want to happen.

The solution is not to downgrade your Processing, but to simply uncheck the MaxOSX option on the export window, or to not pay attention to this warning.

GoToLoop

Telling the OP to always downgrade Processing...

I didn't tell him to downgrade/uninstall anything! We can have various versions "installed" in their own folders!

This isn't an error. It's just Processing telling you that it tried to export to MacOSX and couldn't,...

This is just how bad & negligent in deployment newer Processing versions are.
Good old v1.5.1 is still unbeatable about it! Hit CTRL+E and we got a ".jar" file ready to run in any OS w/ Java!

KevinWorkman

I've seen you give this advice before, and I simply disagree with it. Processing doesn't go out of its way to honor reverse compatibility, so switching to an old version isn't always an option.

I agree that exporting as a jar is the best way, which is why I've created SvgExe (renaming that soon) to do exactly that in the newer versions of Processing.

GoToLoop

... which is why I've created "SvgExe"... to do exactly that in the newer versions of Processing.

It's a cool & important tool indeed, @KevinWorkman! :-bd
But I wonder how hard will be to keep it working w/ Processing 3.
Heard somewhere that devs may end up dropping Applet inheritance from PApplet! :-SS
Dunno how hard that'd make things packing as a ".jar" file? :-S

KevinWorkman

Yeah, I need to update everything. Static Void Games just went open-source, so things are being moved around in the shuffle, but tonight I'm going to take a closer look at SvgExe (soon to be called JarMatey) and make sure it still works with the latest version of Processing. Note that I probably won't try to honor backwards compatibility either.

Dropping the Applet inheritance is probably the way to go. It should probably extend Component (or a JavaFX Canvas). That won't impact SvgExe/JarMatey at all though, since the whole point of it is to create an application, not an applet.

Sorry for hijacking your thread, OP!

GoToLoop

While devs are at it, they should also rename PApplet class for something else (PComponent?). >:)

quark

In Processing 1.5.1 it was possible to export to different platforms, and at some point in V2 the developers changed it so you could only export to the same platform you were using. The reasons given were

1) that the user could not validate the other exports (IMO a rubbish excuse) and

2) it reduced the size of the Processing download (IMO makes sense if your bandwidth is restricted)

Recently they reintroduced this feature and I have just tried it on my machine running OSX and was able to export Windows and Linux versions.

This isn't an error. It's just Processing telling you that it tried to export to MacOSX and couldn't, which is what you want to happen.

I disagree, I believe it is an error.

If you are on a Windows machine and if Processing gives you the option to export to OSX (which it does) and it fails to do so (which it appears to do) then it is a bug.

@morty do you really need an OSX export of your sketch, will the teacher not accept a Windows export?

KevinWorkman

I disagree, I believe it is an error.

Ben Fry disagrees with you. More specifically, the only bug is that the MacOSX checkbox shouldn't even exist on Windows. This has been fixed in Processing 3.

This "error" is exactly what you would expect to happen, so it isn't really a bug. OP should either not worry about it, or just uncheck the MacOSX checkbox. The other executables are created successfully.

See also: https://github.com/processing/processing/issues/2642 https://github.com/processing/processing/issues/2569

GoToLoop

It reduced the size of the Processing download (IMO makes sense if your bandwidth is restricted)

The fact that Processing bundles Java, while most major Java-based apps asks their users to download Java by themselves, is the utmost nonsense of all! :-L
And the fact it's targeted for programmers and not final users makes bundled Java even dumber! :O)

... the only bug is that the MacOSX checkbox shouldn't even exist on Windows.
This "error" is exactly what you would expect to happen,...

I wonder why Processing got a "Java Mode" after all, since it fails to produce a ".jar" executable!
Isn't Java supposed to be program once and deploy everywhere or something like that?
It's funny that Processing v1.5.1 was able to deliver that but "modern" versions are incompetent? [-(

This has been fixed in Processing 3.

Was that to laugh about? :P It's more likely "officially" axed out! >:)
Even series 2 couldn't reach a "true stable" version. I wonder how will series 3 fare? :(|)

KevinWorkman

Yeah, my only/biggest problem with Processing is that it doesn't allow you to export to a runnable jar. I understand why (native libraries), but that's easily fixed via the techniques I used in SvgExe/JarMatey. These techniques aren't particularly complicated, and they're what everybody else uses too: JOGL, libGDX, and LWJGL all do the same thing with their native libraries (secretly export them to a temp file).

I'd be very willing to do the coding myself, which wouldn't be too hard since all of the logic already exists in SvgExe/JarMatey, but nobody seemed very interested in the feature.

Exporting as a runnable jar leaves the rest of deployment up to the user (programmer), which I think is the way to go.

quark

The software provides the user what appears to be a valid option (i.e. OSX export) and then throws an unhandled exception because it can't perform the operation and that's not a bug? Amazing, awesome, I can't believe it.

The fact that the error was providing the option in the first place does not make it a non-bug, it just explains the cause.

@morty Sorry about that but I have fallen into the trap of hijacking this thread as well.

@KevinWorkman Please don't speak for others, I know that Ben Fry is more than capable of doing that for himself. Anyway I have said my piece but if you want to continue this discussion on what makes a bug start a new topic in General Discussions and I would be more than willing to take part. Regards :)

KevinWorkman

Please don't speak for others, I know that Ben Fry is more than capable of doing that for himself.

Um, I wasn't speaking for anybody. The links I posted contain quotes from Ben Fry saying that the stack trace was the correct behavior.

Here is the link again: https://github.com/processing/processing/issues/2642

And here is the "bug" reported there:

Hitting the export button, checking the "Mac OS X" button, and then hitting "Export" fails with a stacktrace on linux (and windows?).

Note that this is exactly what our OP is talking about.

Ben Fry then comments:

That's correct: http://wiki.processing.org/w/Export_Info_and_Tips

The bug is that the OS X checkbox should be disabled on other platforms.

So the stack trace itself is not a bug, but expected and correct behavior. The solution is to either ignore the error or simply uncheck the OS X checkbox. The OS X checkbox has been removed in Processing 3.

If you have any sources saying that any of what I've said is incorrect, I'd love to see them.

quark

Quote from Ben Fry

"The bug is that the OS X checkbox should be disabled on other platforms."

Nice to know that Ben Fry agrees with me, and that there is a bug :D

KevinWorkman

Nice to know that Ben Fry agrees with me, and that there is a bug

Head -> Desk.

The only bug is that the checkbox is there. The stack trace itself is not a bug. That's what Ben Fry said, and that's what I'm trying to explain.

The OP is under the impression that the stack trace means something is wrong which isn't really the case. It's just a result of only being able to export to Mac OS X from Mac OS X, which is known and correct behavior.

I guess we're both just being pedantic, but my only goal was to explain to the OP that this isn't something that we need to worry about. In that sense, it's not an error or a bug.

GoToLoop

Pedantic discussion! :D
They decided to axe it out but forgotten to remove the "ghost" Mac option in v2.1.2. So it became a GUI bug! :-B

quark

Head -> Desk.

Same here

The stack trace itself is not a bug

I never said that read my posts. The fact that it is a known bug and is to be fixed in a later release doesn't stop it being a bug.

my only goal was to explain to the OP that this isn't something that we need to worry about

Good point. The problem is not caused by anything the OP did, so good point

I guess we're both just being pedantic

I agree with you there, it is easy for this type of discussion to become an irresistible force <> immovable object scenario and in the end benefits no one.

I suggest that we agree to differ and shake hands (metaphorically that is) :D