gnuplot-beta — Developers and beta testers of new gnuplot code

Re: gnuplot fails in background.

[<pl...@pi...>]

On 06/04/10 22:27, Hans-Bernhard Bröker wrote:
> pl...@pi... wrote:
>
>> I have a cgi responder written in C that works fine when running
>> gnuplot directly but if I add "&" to the command string it fails.
>
> Well, so don't do that, then!
>
Well that one approach, I'd rather debug the problem.

> Whatever did you hope to achieve by that, in the first place?
>

  I was "hoping" for exactly what I have had working for the last two 
years. Calling gnuplot NON-INTERACTIVELY to plot some real-time data.

>> Why is gnuplot failing when I detach the process?
>
> Possibly because non-interactive shells don't support backgrounding
> interactive processes?
>

Your attempts at being a sarcastic smart-arse would look less stupid if 
you did not make sweeping assumptions. No where did I suggest I was 
running gnuplot interactively.

Ethan's suggestion has enabled me to establish that this problem is more 
general than the call to gnuplot. So I won't discuss this further on 
this list.

Now fixed.

Thanks Ethan.

Re: gnuplot fails in background.

[Hans-Bernhard B. <HBB...@t-...>]

pl...@pi... wrote:

> I have a cgi responder written in C that works fine when running gnuplot 
> directly but if I add "&" to the command sting it fails.

Well, so don't do that, then!

Whatever did you hope to achieve by that, in the first place?

> Why is gnuplot failing when I detach the process?

Possibly because non-interactive shells don't support backgrounding 
interactive processes?

Re: gnuplot fails in background.

[Ethan M. <merritt@u.washington.edu>]

On Friday 04 June 2010 06:11:47 am pl...@pi... wrote:
> Hi,
> 
> I'm not really sure this is a gnuplot problem , I'm having trouble 
> seeing where the problem lies.
> 
> I have a cgi responder written in C that works fine when running gnuplot 
> directly but if I add "&" to the command sting it fails.
> 
> I have both post.cgi and test.gnu in my cgi directory , it is called by 
> lighttpd in response to a FORM post method.
> 
> within post.c :
> 
> system("gnuplot test.gnu" );
> OK.
> system("gnuplot test.gnu &" );
> Fails to produce output but the call returns zero since it apparently 
> succeeds in creating the gnuplot process and backgrounding it before 
> gnuplot  fails.
> 
> It looks like a permissions problem or file path but testing from 
> command line it works and not backgrounding the process works for the cgi.
> 
> First line in test.gnu fails to create the file:
> system("touch /www/apache/htdocs/gnuplot.ran");
> 
> Equally , calling gnuplot with the full path of the .gnu file also fails.
> 
> Why is gnuplot failing when I detach the process?

I don't know. Perhaps the lighttpd thread that spawned your gnuplot command
has already exited by the time gnuplot tries to do anything.
What happens if you take gnuplot out of the picture while debugging?
E.g. try testing
   system("ls test.gnu > /www/apache/htdocs/debug.out")
vs
   system("ls test.gnu > /www/apache/htdocs/debugbg.out&")

	

Re: gnuplot fails in background.

[Thomas S. <t.s...@fz...>]

without '&' the c-program waits for gnuplot to terminate and then
goes on. so it is guaranteed that gnuplot did its job when the
c-program finishes.
with '&' the c-program starts gnuplot without waiting and goes
on directly.
so it may happen that the c-program has finished while the gnuplot
process is still running in background or waits to get some cpu time.


Plotter-2 wrote:
> 
> Hi,
> 
> I'm not really sure this is a gnuplot problem , I'm having trouble 
> seeing where the problem lies.
> 
> I have a cgi responder written in C that works fine when running gnuplot 
> directly but if I add "&" to the command sting it fails.
> 
> I have both post.cgi and test.gnu in my cgi directory , it is called by 
> lighttpd in response to a FORM post method.
> 
> within post.c :
> 
> system("gnuplot test.gnu" );
> OK.
> system("gnuplot test.gnu &" );
> Fails to produce output but the call returns zero since it apparently 
> succeeds in creating the gnuplot process and backgrounding it before 
> gnuplot  fails.
> 
> It looks like a permissions problem or file path but testing from 
> command line it works and not backgrounding the process works for the cgi.
> 
> First line in test.gnu fails to create the file:
> system("touch /www/apache/htdocs/gnuplot.ran");
> 
> Equally , calling gnuplot with the full path of the .gnu file also fails.
> 
> Why is gnuplot failing when I detach the process?
> 
> TIA.
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://old.nabble.com/gnuplot-fails-in-background.-tp28780509p28783036.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

gnuplot fails in background.

[<pl...@pi...>]

Hi,

I'm not really sure this is a gnuplot problem , I'm having trouble 
seeing where the problem lies.

I have a cgi responder written in C that works fine when running gnuplot 
directly but if I add "&" to the command sting it fails.

I have both post.cgi and test.gnu in my cgi directory , it is called by 
lighttpd in response to a FORM post method.

within post.c :

system("gnuplot test.gnu" );
OK.
system("gnuplot test.gnu &" );
Fails to produce output but the call returns zero since it apparently 
succeeds in creating the gnuplot process and backgrounding it before 
gnuplot  fails.

It looks like a permissions problem or file path but testing from 
command line it works and not backgrounding the process works for the cgi.

First line in test.gnu fails to create the file:
system("touch /www/apache/htdocs/gnuplot.ran");

Equally , calling gnuplot with the full path of the .gnu file also fails.

Why is gnuplot failing when I detach the process?

TIA.

Re: gnuplot tries to build amiga

[Tatsuro M. <tma...@ya...>]

Hello

Sorry for my misleading for the matter.
 
Tatsuro

--- Mojca Miklavecwrote:

> 2010/6/3 Tatsuro MATSUOKA wrote:
> >
> >> Maybe the option should be switched off on Mac by default (unless one
> >> would enable it with --enable-wxwidgets)? Configuration step usually
> >> doesn't detect any problem, it's only the building step that fails.
> >
> > On the cygwin build, there is no wxwidgets dependencies. �The configure script generated by
> ./prepare
> > from the current cvs source detects correctly detects that wxwidgets dependencies (include
> files and
> > libraries) does not exist and build process goes well without any problem.
> >
> > Perhaps the detection mechanism of the configure on the Mac OS might not work correctly.
> > How config.log told that if you execute the configure without �--disable-wxwidgets ?
> 
> The detection mechanism is not the problem. wxWidgets *are* present,
> but the building scripts have never been properly configured to
> compile wx programs on Mac.
> 
> I know about the thread from March (report about working wxt), but I
> need to devote some more time to carefully try out every step (I don't
> have much expertise in building sources).
> 
> Mojca
> 


--------------------------------------
2010 FIFA World Cup News [Yahoo!Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/southafrica2010/

Re: gnuplot tries to build amiga

[Mojca M. <moj...@gm...>]

2010/6/3 Tatsuro MATSUOKA wrote:
>
>> Maybe the option should be switched off on Mac by default (unless one
>> would enable it with --enable-wxwidgets)? Configuration step usually
>> doesn't detect any problem, it's only the building step that fails.
>
> On the cygwin build, there is no wxwidgets dependencies.  The configure script generated by ./prepare
> from the current cvs source detects correctly detects that wxwidgets dependencies (include files and
> libraries) does not exist and build process goes well without any problem.
>
> Perhaps the detection mechanism of the configure on the Mac OS might not work correctly.
> How config.log told that if you execute the configure without  --disable-wxwidgets ?

The detection mechanism is not the problem. wxWidgets *are* present,
but the building scripts have never been properly configured to
compile wx programs on Mac.

I know about the thread from March (report about working wxt), but I
need to devote some more time to carefully try out every step (I don't
have much expertise in building sources).

Mojca

Re: gnuplot tries to build amiga

[Tatsuro M. <tma...@ya...>]

Hello

--- Mojca Miklavec wrote:

> On Tue, Jun 1, 2010 at 12:37, Mojca Miklavec wrote:
> > On Tue, Jun 1, 2010 at 05:52, Ethan Merritt wrote:
> >
> >> I suggest that you download the source from SourceForge, which is
> >> the only official distribution site.
> 
> I know that it's the only official source, but CVS is extremely
> painful to work with and I prefer github for several reasons (for me
> extremely important - I have some local patches that I can easily
> fetch from anywhere and merging works perfectly). Until now I have
> never experienced any major problem with the source on github (except
> that I already manage to report a problem that has been just fixed
> short before and the source didn't catch up with that fix yet).
> 
> >> Did you run ./prepare; ./configure ?
> >
> > I didn't run ./prepare (or rather: I ran it for a really long time).
> > I've been using the same "repository" for quite some time already, so
> > it's quite possible that some files accidentally stayed in the folder.
> 
> This in fact turned to be the reason for failure. After running
> ./prepare and ./configure and disabling wxt the compilation worked
> fine again. I'm sorry for the false alarm.
> 
> Maybe the option should be switched off on Mac by default (unless one
> would enable it with --enable-wxwidgets)? Configuration step usually
> doesn't detect any problem, it's only the building step that fails.
> 
> Thanks,
>     Mojca

On the cygwin build, there is no wxwidgets dependencies.  The configure script generated by ./prepare
from the current cvs source detects correctly detects that wxwidgets dependencies (include files and
libraries) does not exist and build process goes well without any problem.

Perhaps the detection mechanism of the configure on the Mac OS might not work correctly.
How config.log told that if you execute the configure without  --disable-wxwidgets ?

The below shows the corresponding part of config.log in the cygwin build as a reference.

configure:10650: checking for wx-config
configure:10681: result: no
configure:10690: WARNING: wxWidgets can't be found. You can try --with-wx-config-path to give the
right path to wx-config. The wxWidgets terminal will not be compiled.


Regards

Tatsuro


--------------------------------------
2010 FIFA World Cup News [Yahoo!Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/southafrica2010/

Re: gnuplot tries to build amiga

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 02 June 2010, Mojca Miklavec wrote:
> 
> This in fact turned to be the reason for failure. After running
> ./prepare and ./configure and disabling wxt the compilation worked
> fine again. I'm sorry for the false alarm.
> 
> Maybe the option should be switched off on Mac by default (unless one
> would enable it with --enable-wxwidgets)? Configuration step usually
> doesn't detect any problem, it's only the building step that fails.

Except that it does work for some people.
You will recall that Werner Smekal posted here recently with brief
instructions on how to do it.  Did that procedure not work for you?

Re: gnuplot tries to build amiga

[Mojca M. <moj...@gm...>]

On Tue, Jun 1, 2010 at 12:37, Mojca Miklavec wrote:
> On Tue, Jun 1, 2010 at 05:52, Ethan Merritt wrote:
>
>> I suggest that you download the source from SourceForge, which is
>> the only official distribution site.

I know that it's the only official source, but CVS is extremely
painful to work with and I prefer github for several reasons (for me
extremely important - I have some local patches that I can easily
fetch from anywhere and merging works perfectly). Until now I have
never experienced any major problem with the source on github (except
that I already manage to report a problem that has been just fixed
short before and the source didn't catch up with that fix yet).

>> Did you run ./prepare; ./configure ?
>
> I didn't run ./prepare (or rather: I ran it for a really long time).
> I've been using the same "repository" for quite some time already, so
> it's quite possible that some files accidentally stayed in the folder.

This in fact turned to be the reason for failure. After running
./prepare and ./configure and disabling wxt the compilation worked
fine again. I'm sorry for the false alarm.

Maybe the option should be switched off on Mac by default (unless one
would enable it with --enable-wxwidgets)? Configuration step usually
doesn't detect any problem, it's only the building step that fails.

Thanks,
    Mojca

Re: gnuplot tries to build amiga

[Werner S. <sm...@ia...>]

Hi Mojca,

>       vtable for wxCheckBoxBasein wxt_gui.o
>       vtable for wxStaticTextBasein wxt_gui.o
>       vtable for wxSliderBasein wxt_gui.o
>       vtable for wxButtonBasein wxt_gui.o
>   "wxInitAllImageHandlers()", referenced from:
>       wxtApp::OnInit()     in wxt_gui.o
>   "wxWindow::Enable(bool)", referenced from:
>       vtable for wxtPanelin wxt_gui.o
>       vtable for wxtConfigDialogin wxt_gui.o
>       vtable for wxCheckBoxBasein wxt_gui.o
>       vtable for wxStaticTextBasein wxt_gui.o
>       vtable for wxSliderBasein wxt_gui.o
>       vtable for wxButtonBasein wxt_gui.o
> 
> (Which again didn't happen before, but maybe also because I have
> disabled wx manually somehow.)

Disable the wxWidgets terminal with the configure option
--disable-wxwidgets - this terminal doesn't work on Mac OS X anyways.

Regards,
Werner

> 
> Mojca
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


-- 
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10/134
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...  (GPG: EDCAF4A79)
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Put a background image

[<Gui...@sa...>]

Hello

Excuse me for disturbing you, I have a question I can not solve. I'd
like to put a map on the bottom of this graph style :
http://www.espacemeteo.com/alexy/aaaa.png
Instead of the green background : put a picture card (France)

Thank you very much for your help.
 
Bests regards
 
Guillaume CHANTELOUBE
 

Re: gnuplot tries to build amiga

[Mojca M. <moj...@gm...>]

On Tue, Jun 1, 2010 at 05:52, Ethan Merritt wrote:
> On Monday 31 May 2010, Mojca Miklavec wrote:
>> Hello,
>>
>> I'm building gnuplot from this source:
>>      http://github.com/Reen/gnuplot
>> (dated May 24th).
>
> I have no idea where that source tree came from.
> From your report, it seems it is neither up-to-date nor self-consistent.

It may also be a problem of prepare/configure/make leftovers from long ago.

> The amiga (and atari and apollo) terminals and associated code have
> been entirely removed from the 4.5 source tree.  You can confirm
> this by running
>        cd gnuplot; grep -Ril amiga .
>
> I suggest that you download the source from SourceForge, which is
> the only official distribution site.  You might also want
> to send a note to whoever is maintaining that github mirror to point
> out that they have a problem.  That is assuming, of course, that the
> problem came from the source itself and not from some version
> incompatibility introduced by macports.
> Did you run ./prepare; ./configure ?

I didn't run ./prepare (or rather: I ran it for a really long time).
I've been using the same "repository" for quite some time already, so
it's quite possible that some files accidentally stayed in the folder.

I have tried to checkout again, but I'm now not able to compile any
more at all. (It might be that QuickTime is not ported to 64-bit
architecture; I need to check the details, but I'm sure that there are
some Apple libraries that have been dropped.)

But I need more time for some useful "debugging".

c++  -g -O2 -I/usr/lib/wx/include/mac-unicode-debug-2.8
-I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-D__WXDEBUG__ -D__WXMAC__  -D_REENTRANT -I/opt/local/include/cairo
-I/opt/local/include/pixman-1 -I/opt/local/include/freetype2
-I/opt/local/include -I/opt/local/include/libpng12
-I/opt/local/include/pango-1.0 -I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include    -L/opt/local/lib -L/opt/local/lib
-L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o gnuplot alloc.o
axis.o binary.o breaders.o bitmap.o color.o command.o contour.o
datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o
graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o
misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o
save.o scanner.o set.o show.o specfun.o standard.o stdfn.o tables.o
tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o
wxt_gui.o gp_cairo.o gp_cairo_helpers.o   -lreadline  -lncurses  -lz
-lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -liconv
-ljpeg -lfreetype -lpng -lpdf -L/opt/local/lib -llua -lm    -framework
IOKit -framework Carbon -framework Cocoa -framework System -framework
QuickTime -framework OpenGL -framework AGL  -lwx_macud-2.8
-L/opt/local/lib -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpixman-1
-lpng12 -lXrender -lX11 -lXau -lXdmcp -lpango-1.0 -lm -lfontconfig
-lexpat -lfreetype -lz -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0
-lglib-2.0 -lintl -liconv    -L/opt/local/lib -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lpixman-1 -lpng12 -lXrender -lX11 -lXau -lXdmcp
-lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv
ld: warning: in
/System/Library/Frameworks//QuickTime.framework/QuickTime, missing
required architecture x86_64 in file
ld: warning: in /usr/lib/libwx_macud-2.8.dylib, missing required
architecture x86_64 in file
Undefined symbols:
  "wxFrame::DoGetClientSize(int*, int*) const", referenced from:
      vtable for wxtFramein wxt_gui.o
  "wxApp::GetClassInfo() const", referenced from:
      vtable for wxtAppin wxt_gui.o
  "wxWindow::MacGetLeftBorderSize() const", referenced from:
      vtable for wxtPanelin wxt_gui.o
      vtable for wxtConfigDialogin wxt_gui.o
      vtable for wxtFramein wxt_gui.o
      vtable for wxCheckBoxBasein wxt_gui.o
      vtable for wxStaticTextBasein wxt_gui.o
      vtable for wxSliderBasein wxt_gui.o
      vtable for wxButtonBasein wxt_gui.o
  "wxMemoryInputStream::wxMemoryInputStream(void const*, unsigned
long)", referenced from:
      wxtApp::LoadPngIcon(unsigned char const*, int, int)in wxt_gui.o
  "wxDialogBase::OnChildFocus(wxChildFocusEvent&)", referenced from:
      vtable for wxtConfigDialogin wxt_gui.o
  "wxAppBase::OnRun()", referenced from:
      vtable for wxtAppin wxt_gui.o
  "_wxEVT_COMMAND_BUTTON_CLICKED", referenced from:
      __static_initialization_and_destruction_0(int, int)in wxt_gui.o
  "wxWindowBase::DoIsExposed(int, int, int, int) const", referenced from:
      vtable for wxtPanelin wxt_gui.o
      vtable for wxtConfigDialogin wxt_gui.o
      vtable for wxtFramein wxt_gui.o
      vtable for wxCheckBoxBasein wxt_gui.o
      vtable for wxStaticTextBasein wxt_gui.o
      vtable for wxSliderBasein wxt_gui.o
      vtable for wxButtonBasein wxt_gui.o
  "wxWindow::DoGetSize(int*, int*) const", referenced from:
      vtable for wxtPanelin wxt_gui.o
      vtable for wxCheckBoxBasein wxt_gui.o
      vtable for wxStaticTextBasein wxt_gui.o
      vtable for wxSliderBasein wxt_gui.o
      vtable for wxButtonBasein wxt_gui.o
  "wxInitAllImageHandlers()", referenced from:
      wxtApp::OnInit()     in wxt_gui.o
  "wxWindow::Enable(bool)", referenced from:
      vtable for wxtPanelin wxt_gui.o
      vtable for wxtConfigDialogin wxt_gui.o
      vtable for wxCheckBoxBasein wxt_gui.o
      vtable for wxStaticTextBasein wxt_gui.o
      vtable for wxSliderBasein wxt_gui.o
      vtable for wxButtonBasein wxt_gui.o

(Which again didn't happen before, but maybe also because I have
disabled wx manually somehow.)

Mojca

Re: gnuplot tries to build amiga

[Ethan M. <merritt@u.washington.edu>]

On Monday 31 May 2010, Mojca Miklavec wrote:
> Hello,
> 
> I'm building gnuplot from this source:
>      http://github.com/Reen/gnuplot
> (dated May 24th).

I have no idea where that source tree came from.
From your report, it seems it is neither up-to-date nor self-consistent.

The amiga (and atari and apollo) terminals and associated code have
been entirely removed from the 4.5 source tree.  You can confirm
this by running
	cd gnuplot; grep -Ril amiga .

I suggest that you download the source from SourceForge, which is
the only official distribution site.  You might also want
to send a note to whoever is maintaining that github mirror to point
out that they have a problem.  That is assuming, of course, that the
problem came from the source itself and not from some version
incompatibility introduced by macports.   
Did you run ./prepare; ./configure ?

	Ethan


> 
> Since recently (though I admit that I have not try to compile for a
> while) I started experiencing the following problem:
> 
> mv -f .deps/tabulate.Tpo .deps/tabulate.Po
> make[3]: *** No rule to make target `../term/amiga.trm', needed by
> `term.o'.  Stop.
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> I'm using 64-bit Mac OS X 10.6 with macports installed.
> 
> Mojca
> 
> 
> 
> checking for pdflatex... pdflatex
> checking for emacs version... 22.1.1
> checking whether info-look.el is needed... not needed with emacs 22.1.1
> configure: creating ./config.status
> config.status: creating Makefile
> 
> ** Configuration summary for gnuplot 4.5:
> 
> gnuplot will be compiled with the following terminals:
> 
>   Standalone terminals: yes (always builtin)
>     (canvas, cgm, corel, dumb, dxf, eepic, emf, emtex,
>     epslatex, epson_180dpi, epson_60dpi, epson_lx800, fig, gpic, hp2623A,
>     hp2648, hp500c, hpdj, hpgl, hpljii, hppj, imagen,
>     latex, metafont, metapost, mif, pbm, postscript, pslatex, nec_cp6, okidata,
>     pcl5, pstex, pstricks, qms, regis, svg, tandy_60dpi,
>     tek40xx, tek410x, texdraw, tgif, tkcanvas, tpic, vttek)
>   X Window System terminal: yes
>     (with multi-byte fonts)
>     (enable plotting to windows opened by external apps)
>     (without binary polygon protocol )
>   jpeg terminal: yes
>   gif terminal: yes (with animated gif)
>   png terminal: yes
>     (jpeg, gif and png terminals can use TTF fonts)
>   pdf terminal: yes
>   plot library terminal: no (use --with-plot to enable, requires GNU plotutils
>                              or UNIX plot)
>   linux terminal (vga console): no (use --with-linux-vga to enable,
>                                        requires SVGAlib)
>   vgagl terminal ((s)vga console): no (use --with-linux-vga to enable,
>                                        requires SVGAlib with vgagl)
>   ggi terminal: no (use --with-ggi to enable, requires libggi)
>   mgr terminal: no (use --enable-mgr to enable, requires libpixrect)
>   rgip/uniplex terminal: no (use --enable-rgip to enable)
>   svga terminal (MSDOS/djgpp): no
>   be terminal (BeOS): no
>   next terminal: no
>   aqua terminal (MacOS X): yes
>   wxt terminal: yes
>   cairo-based pdf and png terminals: yes
>   lua/TikZ terminal: yes
>   Qt terminal: no (requires C++, Qt >= 4.5)
> 
>   Additional terminals are availaible in platform-specific makefiles:
>    amiga (makefile.amg and makefile.ami), apollo/gpr (makefile.unx)
>    cgi (makefile.unx), pm (makefile.os2),
>    sun (makefile.unx), unixpc (makefile.unx), windows (various Windows
>    makefiles)
>   Additional terminals are built automatically if possible at compile-time:
>    vesa (MSDOS), emxvga (MSDOS, OS/2), ega/vga/svga/ssvga/hercules (Windows with
>    Zortec compiler), macintosh
> 
> gnuplot will be compiled with the following features:
> 
>   Mouse support in interactive terminals: yes
>   Fitting error variables: yes
>   Zooming or refresh of volatile data: yes (EXPERIMENTAL)
>   Typing <space> in plot window raises console
>   Command line macros: yes
>   Placement of rectangles and other objects: yes
> 
> gnuplot will be compiled with the following options:
> 
>   Readline library: GNU readline library with  -lncurses
>   Command-line history file: yes
>   Check current directory for .gnuplot file: no (use --with-cwdrc to enable)
>   Sort help/subtopic tables by column: no (use --without-row-help to enable)
>   Use TeX kpsexpand to search for fonts: no (use --with-kpsexpand to enable)
>   Thin plate splines: no (use --enable-thin-spline to enable)
>   Hidden3d optimization: quadtree
>   Deprecated syntax and terminal options : no (use
> --enable-backwards-compatibility to enable)
> 
> gnuplot will install the following additional materials:
> 
>   lasergnu printer script: no (use --with-lasergnu to enable)
>   gnuplot-mode for X/Emacs: yes
>   LaTeX tutorial: yes
>   cfg file for epslatex terminal: yes
>   TeX *.sty for lua/tikz terminal: yes
>   Help file: yes (always), in ${datarootdir}/gnuplot/4.5/gnuplot.gih
>   PostScript prologue files: yes (always)
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

gnuplot tries to build amiga

[Mojca M. <moj...@gm...>]

Hello,

I'm building gnuplot from this source:
     http://github.com/Reen/gnuplot
(dated May 24th).

Since recently (though I admit that I have not try to compile for a
while) I started experiencing the following problem:

mv -f .deps/tabulate.Tpo .deps/tabulate.Po
make[3]: *** No rule to make target `../term/amiga.trm', needed by
`term.o'.  Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I'm using 64-bit Mac OS X 10.6 with macports installed.

Mojca



checking for pdflatex... pdflatex
checking for emacs version... 22.1.1
checking whether info-look.el is needed... not needed with emacs 22.1.1
configure: creating ./config.status
config.status: creating Makefile

** Configuration summary for gnuplot 4.5:

gnuplot will be compiled with the following terminals:

  Standalone terminals: yes (always builtin)
    (canvas, cgm, corel, dumb, dxf, eepic, emf, emtex,
    epslatex, epson_180dpi, epson_60dpi, epson_lx800, fig, gpic, hp2623A,
    hp2648, hp500c, hpdj, hpgl, hpljii, hppj, imagen,
    latex, metafont, metapost, mif, pbm, postscript, pslatex, nec_cp6, okidata,
    pcl5, pstex, pstricks, qms, regis, svg, tandy_60dpi,
    tek40xx, tek410x, texdraw, tgif, tkcanvas, tpic, vttek)
  X Window System terminal: yes
    (with multi-byte fonts)
    (enable plotting to windows opened by external apps)
    (without binary polygon protocol )
  jpeg terminal: yes
  gif terminal: yes (with animated gif)
  png terminal: yes
    (jpeg, gif and png terminals can use TTF fonts)
  pdf terminal: yes
  plot library terminal: no (use --with-plot to enable, requires GNU plotutils
                             or UNIX plot)
  linux terminal (vga console): no (use --with-linux-vga to enable,
                                       requires SVGAlib)
  vgagl terminal ((s)vga console): no (use --with-linux-vga to enable,
                                       requires SVGAlib with vgagl)
  ggi terminal: no (use --with-ggi to enable, requires libggi)
  mgr terminal: no (use --enable-mgr to enable, requires libpixrect)
  rgip/uniplex terminal: no (use --enable-rgip to enable)
  svga terminal (MSDOS/djgpp): no
  be terminal (BeOS): no
  next terminal: no
  aqua terminal (MacOS X): yes
  wxt terminal: yes
  cairo-based pdf and png terminals: yes
  lua/TikZ terminal: yes
  Qt terminal: no (requires C++, Qt >= 4.5)

  Additional terminals are availaible in platform-specific makefiles:
   amiga (makefile.amg and makefile.ami), apollo/gpr (makefile.unx)
   cgi (makefile.unx), pm (makefile.os2),
   sun (makefile.unx), unixpc (makefile.unx), windows (various Windows
   makefiles)
  Additional terminals are built automatically if possible at compile-time:
   vesa (MSDOS), emxvga (MSDOS, OS/2), ega/vga/svga/ssvga/hercules (Windows with
   Zortec compiler), macintosh

gnuplot will be compiled with the following features:

  Mouse support in interactive terminals: yes
  Fitting error variables: yes
  Zooming or refresh of volatile data: yes (EXPERIMENTAL)
  Typing <space> in plot window raises console
  Command line macros: yes
  Placement of rectangles and other objects: yes

gnuplot will be compiled with the following options:

  Readline library: GNU readline library with  -lncurses
  Command-line history file: yes
  Check current directory for .gnuplot file: no (use --with-cwdrc to enable)
  Sort help/subtopic tables by column: no (use --without-row-help to enable)
  Use TeX kpsexpand to search for fonts: no (use --with-kpsexpand to enable)
  Thin plate splines: no (use --enable-thin-spline to enable)
  Hidden3d optimization: quadtree
  Deprecated syntax and terminal options : no (use
--enable-backwards-compatibility to enable)

gnuplot will install the following additional materials:

  lasergnu printer script: no (use --with-lasergnu to enable)
  gnuplot-mode for X/Emacs: yes
  LaTeX tutorial: yes
  cfg file for epslatex terminal: yes
  TeX *.sty for lua/tikz terminal: yes
  Help file: yes (always), in ${datarootdir}/gnuplot/4.5/gnuplot.gih
  PostScript prologue files: yes (always)

Re: color fill contouring

[Petr M. <mi...@ph...>]

> Anyhow, the closest equivalent in gnuplot would be something like:
> 
>    set pm3d
>    set palette maxcolors 10
>    set view map
>    splot 'ijx.dat' with pm3d
> 
> Note that these commands do not actually draw contour lines.
> Instead they say "color by quantized values of z".  You may
> have to set explicit bounds on the color range to get the
> color jumps at the values you want:
>    set cbrange [level0 : level10]

To make the map looking more smooth, you can also add:
    set pm3d interpolate 8,8

and
http://gnuplot.sourceforge.net/faq/faq.html#SECTION000513000000000000000

If you still don't like this, you can use contourf() function in Octave 
(gnuplot is used for final drawing).

---
PM

Re: color fill contouring

[Ethan M. <merritt@u.washington.edu>]

On Thursday 27 May 2010, Tom Rosmond wrote:
> Gnuplot users:
> 
> Maybe I am just slow, but I have been unable to find an easy way to make
> color filled contour plots with Gnuplot.  Attached are 3 PDF files:
> 
> 1. contour.pdf: a contour line plot from another graphics program
> 2. shaded.pdf: a color filled version of #1 from the same program
> 3. gnuplot.pdf: a contour line plot from gnuplot that I would like to
> color fill as in #2.
> 
> Here is the input file to Gnuplot used to produce #3:
> 
> set output "contour.ps"
> set term postscript color
> set title "CONTOURS" font "Helvetica,25"
> set ylabel "LOG P"  font "Helvetica,20"
> set xlabel "LOG P" font "Helvetica,20"
> set xrange[1:11]
> set yrange[1:11]
> set size square
> unset surface
> set view map
> set contour
> set data style lines
> set logscale xy
> set contour base
> set cntr levels 10
> splot 'ijx.dat'
> pause -1
> 
> None of the Gnuplot 'demo' examples really produce an equivalent to #2,
> in my opinion.  I have tried various options to 'pm3d' and 'palette',
> but nothing seems to work very well.  I have seen many online queries
> about the same problem, and all proposed solutions seem overly
> complicated for what should be a fairly simple problem.  Easy for me to
> say, of course.

Although filling in colors between contour lines may seem simple, it's not.
Sure, you can find examples where the fill color is "obvious".
But the general case is much harder.

Anyhow, the closest equivalent in gnuplot would be something like:

   set pm3d
   set palette maxcolors 10
   set view map
   splot 'ijx.dat' with pm3d

Note that these commands do not actually draw contour lines.
Instead they say "color by quantized values of z".  You may
have to set explicit bounds on the color range to get the
color jumps at the values you want:
   set cbrange [level0 : level10]


> 
> Anyway, if anyone has any suggestions or examples, I will appreciate it.
> 
> T. Rosmond
> 
> 

color fill contouring

[Tom R. <ro...@re...>]

Gnuplot users:

Maybe I am just slow, but I have been unable to find an easy way to make
color filled contour plots with Gnuplot.  Attached are 3 PDF files:

1. contour.pdf: a contour line plot from another graphics program
2. shaded.pdf: a color filled version of #1 from the same program
3. gnuplot.pdf: a contour line plot from gnuplot that I would like to
color fill as in #2.

Here is the input file to Gnuplot used to produce #3:

set output "contour.ps"
set term postscript color
set title "CONTOURS" font "Helvetica,25"
set ylabel "LOG P"  font "Helvetica,20"
set xlabel "LOG P" font "Helvetica,20"
set xrange[1:11]
set yrange[1:11]
set size square
unset surface
set view map
set contour
set data style lines
set logscale xy
set contour base
set cntr levels 10
splot 'ijx.dat'
pause -1

None of the Gnuplot 'demo' examples really produce an equivalent to #2,
in my opinion.  I have tried various options to 'pm3d' and 'palette',
but nothing seems to work very well.  I have seen many online queries
about the same problem, and all proposed solutions seem overly
complicated for what should be a fairly simple problem.  Easy for me to
say, of course.

Anyway, if anyone has any suggestions or examples, I will appreciate it.

T. Rosmond

Re: Why is depthfirst option of pm3d done in batches?

[Petr M. <mi...@ph...>]

> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=3004793&group_id=2055
> 
> It seems from the code that pm3d deliberately chooses not to merge
> multiple pm3d surfaces using "depthfirst" unless they are adjacent
> in the splot command line. That is, an intervening non-pm3d object
> causes the quadrangles making up the pm3d surfaces _not_ be sorted together.
> There may be a good reason for this, but I can't think of what it is.
> Do you recall?

I don't recall the reason. However, the plots do really look strange, so I 
vote for your patch.

Petr

Why is depthfirst option of pm3d done in batches?

[sfeam (E. Merritt) <eam...@gm...>]

Petr:

Could you take a look at bug report #3004793 on SourceForge?

https://sourceforge.net/tracker/?func=detail&atid=102055&aid=3004793&group_id=2055

It seems from the code that pm3d deliberately chooses not to merge
multiple pm3d surfaces using "depthfirst" unless they are adjacent
in the splot command line. That is, an intervening non-pm3d object
causes the quadrangles making up the pm3d surfaces _not_ be sorted together.
There may be a good reason for this, but I can't think of what it is.
Do you recall?

	Ethan

Re: gnuplot on vista?

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik  wrote:

> > > > If someone sends me suitable text for a Windows README, or uploads
> > > > it as a contributed patch to SourceForge, I will be happy to include
> > > > this in the documentation and point to it from the web site and
> > > > (if there's a spot for it) from SourceForge's download page.
> > > 
> > > Done
> > > 
> > > https://sourceforge.net/tracker/?func=detail&aid=2997442&group_id=2055&atid=302055
> > 
> > The file README.Windows is in the Windows binary package, but does
> > not exist in the cvs repository.  Where does it come from?
> > Should we add it to cvs?  In which directory?
> > 
> > While I'm thinking of it, are there instructions or a script somewhere
> > for creating the Windows binary packages?  This process should also be
> > documented somewhere, or if there is a script then it should be 
> > mentioned in the general install/build instuctions.

Sorry I have uploaded a diff file with comments without deep consideration.


> That file was traditionally in the binary releases of Windows, and similarly 
> for OS/2 and DJPGG. It's just in the respective zip package, not anywhere in 
> the CVS.
> 
> Maybe all of them could go to cvs; then I propose there is a separate 
> directory e.g. README.misc, where all of the would reside. There are already 
> too many READMEs and INSTALLs in the root.

If it is possible, it is better for binary release packages.

Regards

Tatsuro  



--------------------------------------
2010 FIFA World Cup News [Yahoo!Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/southafrica2010/

Re: gnuplot on vista?

[Petr M. <mi...@ph...>]

> > > If someone sends me suitable text for a Windows README, or uploads
> > > it as a contributed patch to SourceForge, I will be happy to include
> > > this in the documentation and point to it from the web site and
> > > (if there's a spot for it) from SourceForge's download page.
> > 
> > Done
> > 
> > https://sourceforge.net/tracker/?func=detail&aid=2997442&group_id=2055&atid=302055
> 
> The file README.Windows is in the Windows binary package, but does
> not exist in the cvs repository.  Where does it come from?
> Should we add it to cvs?  In which directory?
> 
> While I'm thinking of it, are there instructions or a script somewhere
> for creating the Windows binary packages?  This process should also be
> documented somewhere, or if there is a script then it should be 
> mentioned in the general install/build instuctions.

That file was traditionally in the binary releases of Windows, and similarly 
for OS/2 and DJPGG. It's just in the respective zip package, not anywhere in 
the CVS.

Maybe all of them could go to cvs; then I propose there is a separate 
directory e.g. README.misc, where all of the would reside. There are already 
too many READMEs and INSTALLs in the root.

BTW, there should be README.cvs with a hint to run ./prepare before 
./configure + link to web... or, a copy of section "Building from CVS" from
http://gnuplot.sourceforge.net/development/index.html

---
PM

Re: gnuplot on vista?

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday 05 May 2010, Tatsuro MATSUOKA wrote:
> 
> > If someone sends me suitable text for a Windows README, or uploads
> > it as a contributed patch to SourceForge, I will be happy to include
> > this in the documentation and point to it from the web site and
> > (if there's a spot for it) from SourceForge's download page.
> 
> Done
> 
> https://sourceforge.net/tracker/?func=detail&aid=2997442&group_id=2055&atid=302055

The file README.Windows is in the Windows binary package, but does
not exist in the cvs repository.  Where does it come from?
Should we add it to cvs?  In which directory?

While I'm thinking of it, are there instructions or a script somewhere
for creating the Windows binary packages?  This process should also be
documented somewhere, or if there is a script then it should be 
mentioned in the general install/build instuctions.

	Ethan

Re: strange plot title in parametric mode

[Ethan M. <merritt@u.washington.edu>]

On Monday 10 May 2010 07:50:46 am Thomas Sefzick wrote:
> 
> it seems that the new iteration mechanism made some changes
> regarding token counting ("start_token").
> 
> may it be that the if-blocks following the comment
>     /* Ok, fix up the title to include both the xp and yp plots. */
> in "parametric_fixup()" in "plot2d.c"
> and 
>     /* Ok, fix up the title to include xp and yp plots. */
> in "parametric_3dfixup()" in "plot3d.c"
> are not needed anymore?

I think you are correct. These sections are no longer needed.

Re: strange plot title in parametric mode

[Thomas S. <t.s...@fz...>]

it seems that the new iteration mechanism made some changes
regarding token counting ("start_token").

may it be that the if-blocks following the comment
    /* Ok, fix up the title to include both the xp and yp plots. */
in "parametric_fixup()" in "plot2d.c"
and 
    /* Ok, fix up the title to include xp and yp plots. */
in "parametric_3dfixup()" in "plot3d.c"
are not needed anymore?


Shigeharu TAKENO wrote:
> 
> shige 05/07 2010
> ----------------
> 
> In parametric mode, plot titles made by gnuplot-4.4.0 may be 
> strange.
> 
> For the commands
> 
>  set parametric
>  plot sin(t),cos(t)
> 
> gnuplot-4.4.0 makes the plot title "sin(t), sin(t),cos(t)" though
> gnuplot-4.2.6 makes "sin(t),cos(t)". For
> 
>  set parametric
>  splot f(u,v),g(u,v),h(u,v)
> 
> gnuplot-4.4.0 makes the title 
> 
>   "f(u,v), f(u,v),g(u,v), f(u,v),g(u,v),h(u,v)"
> 
> though gnuplot-4.2.6 makes "f(u,v),g(u,v),h(u,v)".
> 
> The cvs version of gnuplot may have the same feature as version 
> 4.4.0.
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://old.nabble.com/strange-plot-title-in-parametric-mode-tp28484392p28512274.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.