torch / DEPRECEATED-torch7-distro

Torch7: state-of-the-art machine learning algorithms

Home Page:www.torch.ch

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gnuplot is broken

rgoroshin opened this issue · comments

gnuplot appears to be broken in the newest release.
I can't provide many details as I'm running on the servers with no qt, but the the plots I'm saving are broken .png images. Soumith get's seg faults when using gnuplot.

Do you have an example? I could try running it on my build (that has qt).

gnuplot.plot(torch.rand(100))

Yep, I just get seg fault and no other stderr/stdout output...

@jucor I see that you recently sent in gnuplot pull requests. What is the status on your side? Do you see segfaults as well?

My machine is an Ubuntu 13.04

Indeed, I submitted pull-requests for gnuplot, which enable pngcairo output if gnuplot is compiled with cairo, and enable qt terminal if gnuplot is compiled with qt support, as a fallback if wxt is not available (and keeping x11 as the final fallback).

I had no segfault here when sending to screen via qt and wxt on OSX 10.8.5, and the png are fine both with figprint() and with pngfigure(). However my build was not using the latest C89-compliant commits. I am trying with those now, and will report here -- hopefully with a pull-request fixing it.

OK, with latest build here, no problem with gnuplot. I suspect this might be due to different compile options for gnuplot -- although in theory my patches were checking for it. Can you please post here the output of

gnuplot -e "show version long"

Here is what I have:

    G N U P L O T
    Version 4.6 patchlevel 3    last modified 2013-04-12
    Build System: Darwin x86_64

    Copyright (C) 1986-1993, 1998, 2004, 2007-2013
    Thomas Williams, Colin Kelley and many others

    gnuplot home:     http://www.gnuplot.info
    faq, bugs, etc:   type "help FAQ"
    immediate help:   type "help"  (plot window: hit 'h')
Compile options:
-READLINE  +LIBREADLINE  +HISTORY
-BACKWARDS_COMPATIBILITY  +BINARY_DATA
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
-USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE  +HIDDEN3D_QUADTREE
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  +USER_LINETYPES +STATS

GNUPLOT_DRIVER_DIR = "/usr/local/Cellar/gnuplot/4.6.3/libexec/gnuplot/4.6"
GNUPLOT_PS_DIR     = "/usr/local/Cellar/gnuplot/4.6.3/share/gnuplot/4.6/PostScript"
HELPFILE           = "/usr/local/Cellar/gnuplot/4.6.3/share/gnuplot/4.6/gnuplot.gih"

@soumith : if you want, to diagnose that faster, you can ping me on skype (ID: julien_cornebise).
In the meantime, I will try without QT and Cairo here.

Update: with the same gnuplot but without QT nor Cairo support, I still plot correctly. I will ask someone with an Ubuntu VM around me to try and reproduce.

I am testing on Ubuntu and Gnuplot is fine, but something else is broken :)

If you run

torch-lua -l torch-env

Everything should be fine. It looks like something in pipefile is broken when used with qt on Linux ?

Clarification of the above, after having discussed with Koray: the problem is independent of the recent gnuplot pull-requests (pfew), but is a problem between qt and PipeFile on Linux.

A simple workaround for Linux users is to call torch-lua -l torch-env instead of just torch: this will avoid loading qt, thus allowing PipeFile to work, thus allowing gnuplot to work as intended.

ah yes, koray's solution works on Linux. great.

I might be using an old version of libpng (on NYU servers), but gnuplot.figprint('./name.png') dumps a png that is 0 bytes large. gnuplot.figprint('./name.eps') works fine.

You have to call gnuplot.close or plotflush to close/flush the figures.

( http://www.torch.ch/manual/gnuplot/index#gnuplotfilesdok)
On 18 Oct 2013 16:52, "rgoroshin" notifications@github.com wrote:

I might be using an old version of libpng (on NYU servers), but
gnuplot.figprint('./name.png') dumps a png that is 0 bytes large.
gnuplot.figprint('./name.eps') works fine.


Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-26606928
.