Stipplegen Linux problem

drjinglespsyd

Hello all! 

I want to start by saying how awesome my new EggBot has been (and still is, and will be) and im really glad there is plenty of support for the project. I was really impressed by Stipplegen and have been messing with it for a few days. Recently something happened with my linux version of stipplegen and now it freezes up every time i try to open any image in any format including images i have ran before. I noticed that the program would freeze sort of at random sometimes a few generations into an image, but now it is persistent every time on trying to load an image. The weird thing is that it seems to load the default grace image just fine every time. Im running Linux Mint 14 and the rough system specs are 4 core 3ghz intel and 16GB ram. Ive tried "reinstalling" the program by deleting the zip and redownloading but that didnt help. Ive also tried restarting the computer (duh) but that didnt help either. If anyone has any ideas it would be great, i really like the program and how it translates to the bot. If anyone has any ideas on how to make it stop freezing at random too that would be great. 

Thanks again!

Windell Oskay

Hmmm.  That's very strange, and I'm not sure what the problem could be. 

You might try resizing your initial image to be smaller in number of pixels.  The image window is only 800 x 600, so if you start with an image that size, you should reduce the memory requirements somewhat.

drjinglespsyd

I thought that too, so i tried a couple different ways to lower memory use (even though i have 16 gigs mostly unused). I tried using a smaller image but got the same problem. I tried setting the default image to generate with less ( i played with some ranges) stipples and then load a new image. I tried pausing the program before loading. Nothing seems to work, its super weird. The oddest thing is that some images im testing with are images that just yesterday worked perfect (i even got two of them onto golf balls). Im going to try the images later on a different machine but i dont want to break that one too. Unless the programmers use learning machine algorithms i have no idea why this is only just now happening. 

Windell Oskay

Which version of processing are you using?  I wonder if you need to downgrade....

drjinglespsyd

Version of processing? Not sure what exactly that refers to. The generator is on v2.02 if thats what you mean

Windell Oskay

The change on your computer could have been the Java version...?

drjinglespsyd

Java version hasnt changed and i didn't run any updates on the system. It was literally overnight that it stopped working. Using OpenJDK 7 and i thought that was the issue so i tried it with Sun Java but that didn't help either. Is there a way that you know of the run the program with console to check error output?

drjinglespsyd

Of course i feel dumb, my brain isnt the best right now. Of course you can run it in terminal its a shell script. Got a verification on the error. Heres the log

ControlP5 0.7.2 infos, comments, questions at http://www.sojamo.de/libraries/controlP5

Generation = 1

Generation = 2

Generation = 3

:::LOAD JPG, GIF or PNG FILE:::

Exception in thread "Thread-1" java.lang.NullPointerException

        at sun.awt.X11.GtkFileDialogPeer.setFileInternal(Unknown Source)

        at sun.awt.X11.GtkFileDialogPeer.run(Native Method)

        at sun.awt.X11.GtkFileDialogPeer.showNativeDialog(Unknown Source)

        at sun.awt.X11.GtkFileDialogPeer.access$000(Unknown Source)

        at sun.awt.X11.GtkFileDialogPeer$1.run(Unknown Source)

good ol java nullpointers

Windell Oskay

Hmm.  Unfortunately, I don't immediately know how to fix that. 

Do I understand correctly that it still runs correctly on the "Grace" image?

drjinglespsyd

Yes, it does to a creepy degree. Granted i dont know how this thing is programmed but this next bit really boggles me. I noticed that grace.jpg file in the data folder and i figured that was how it referenced the default image. I looked at what code i could find and it looked like it did pull that image. So as a test i renamed that file to see what it would do. When i launch it still loads the grace image just fine. I also tried deleting the image, putting a new image in, naming that image 'grace.jpg' (really lame hack but whatever) but it still generated the same old grace picture. It runs that image perfectly, even if i crank it to 10k stipples. I really hope im just not understanding the programming that loads that first Grace image because if im right about how that works then something is seriously wacky. 

Windell Oskay

The distribution includes the source code, and the image along with it.  I would have guessed that the executable includes the actual "grace.jpg" image internally, and doesn't look at the version from the source code, but from the sizes of the files, it looks like that is not the case-- that it must actually be pulling the file from the data folder.  Hmm.

drjinglespsyd

I seem to find the worst bugs in things leave it to me. Ive been toying with it a bit on console and found that it throws the same error when saving. Im trying to sift through the source code (ive always hated java) and see what might be causing it. Im almost positive its an issue with my system somehow, or at least compatibility with my system. 

drjinglespsyd

OH HEY! I think i tracked it down, and it totally is my system being stupid. I sort of stumbled upon this idea after glancing through the Processing code (i know what you mean now by that, its the library that runs the loading and saving of images basically, though i think it does more). Like i said im on Mint 14 but i forgot to mention im also on KDE. I think this is a KDE thing, though it might be around in GNOME as well, where they have a 'recently used' section in the open/save dialog. It looks totally normal, but ive noticed that it uses some wacky symlink nonsense in how it funds that stuff and that flipped a switch in my head. I hadn't noticed it before (like i said before my brain isnt working today so well) but i guess i was always selecting files from that 'recently used' section in  the dialog. Just for giggles i tried navigating manually to the file and BAM it totally works go figure. 

Long and short of it, Mint 14 KDE has an odd bug with Stipplegen and Java where you cant load things from the recently used files. Its not a bug on Stipplegen, its a bug with Mint. I dont have a machine to test on any other Distro or on GNOME, but it might do the same there. To fix it just dont use the recently used files bit of the dialog. Always navigate to the file manually. For some reason the dialog doesn't pass its values back to loadImage() properly. 

Thanks Windell for the help and i hope this gets to Google so other people that run across this can figure it out! 

Windell Oskay

Wow-- great! That's a pretty strange bug, indeed....