Stipplegen Linux problem

Home › Evil Mad Scientist Forums › Software Tools › Stipplegen Linux problem

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • March 22, 2013 at 1:57 pm #20207
    drjinglespsyd
    Participant

    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!
    March 22, 2013 at 2:01 pm #21259
    Windell Oskay
    Keymaster

    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.
    March 22, 2013 at 4:49 pm #21260
    drjinglespsyd
    Participant

    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. 

    March 22, 2013 at 4:51 pm #21261
    Windell Oskay
    Keymaster

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

    March 22, 2013 at 4:53 pm #21262
    drjinglespsyd
    Participant

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

    March 22, 2013 at 4:56 pm #21263
    Windell Oskay
    Keymaster

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

    March 22, 2013 at 4:59 pm #21264
    drjinglespsyd
    Participant

    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?

    March 22, 2013 at 5:30 pm #21265
    drjinglespsyd
    Participant

    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
    March 22, 2013 at 5:33 pm #21266
    Windell Oskay
    Keymaster

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

    Do I understand correctly that it still runs correctly on the “Grace” image?
    March 22, 2013 at 5:38 pm #21267
    drjinglespsyd
    Participant

    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. 

    March 22, 2013 at 5:42 pm #21268
    Windell Oskay
    Keymaster

    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.

    March 22, 2013 at 5:52 pm #21269
    drjinglespsyd
    Participant

    I seem to find the worst bugs in things :D 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. 

    March 22, 2013 at 6:27 pm #21270
    drjinglespsyd
    Participant

    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! 
    March 22, 2013 at 6:37 pm #21271
    Windell Oskay
    Keymaster

    Wow– great! That’s a pretty strange bug, indeed….

    May 25, 2022 at 6:48 am #29918
    BrainPhilipenko
    Participant

    sorry

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.