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

Re: Files BUGS and README.1ST

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

On Saturday 09 October 2004 08:08 am, Harald Harders wrote:
>  *) Arrows and labels are not clipped (2D and 3D).
>
> I often use labels and arrows with the intention to generate things
> outside the plot margins, for example special axis labels (according to
> the DIN style for diagrams). If they were clipped I would not be able to
> do so anymore. Thus, I think it is not a bug and should be removed from
> BUGS.

That is a good point.  But the bug is real.  If you use zoom on a plot
containing vectors you will see all sorts of garbage on the screen as the
individual vectors span the plot margins.  Perhaps the rule should be to
clip auto-generated arrows (i.e. 'plot with vectors') but not arrows 
requested individually by the user.

> In README.1ST, it is stated that only old versions of gd generate gif
> files. If I remember correctly, the current gd version includes gif
> support again. Shoudn't README.1ST be updated accordingly?

Eventually, yes.  That new libgd version has not yet made it into general
distribution, and it has some other problems with regard to gnuplot. 
Tom Boutell has promised to include additional gnuplot fixes in the next
release (2.0.29), but I don't know when that will happen.

Files BUGS and README.1ST

[Harald H. <h.h...@tu...>]

In the file BUGS, one thing is listed that I don't see as a bug:

 *) Arrows and labels are not clipped (2D and 3D).

I often use labels and arrows with the intention to generate things
outside the plot margins, for example special axis labels (according to
the DIN style for diagrams). If they were clipped I would not be able to
do so anymore. Thus, I think it is not a bug and should be removed from
BUGS.

In README.1ST, it is stated that only old versions of gd generate gif
files. If I remember correctly, the current gd version includes gif
support again. Shoudn't README.1ST be updated accordingly?

Yours
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: How to specify a different path for gnuplot.gih

[Hans-Bernhard B. <br...@ph...>]

Per Persson wrote:

> I naively install gnuplot into a dir and then copy the contents to the 
> installer. The path to gnuplot.gih gets hardwired to that install 
> location. Setting --with-gihdir= didn't help, since it then tries to 
> install gnuplot.gih at that location.

It's supposed to work like this:

1) you ./configure all the files to the places they will have in the
actual installation at the user's end, so all internal hardcoded 
relations between are set up correctly.

2) You make

3) Now, it depends on how your installation package generator works. 
Either you just "make install", then tell the generator which files to
put into the installer (and it picks them up from that same location), 
or you
	make install prefix=/some/where
or	make install DESTDIR=/some/where

then build the installation package from what's under /some/where, and 
install that package on your own machine to make sure that everything 
worked out.

For more information about this, read the GNU automake and autoconf 
manuals, and possibly the GNU coding standard.  We're not following that
latter standard strictly, but the GNU auto tools try to, so most things 
will work as described there.

Re: How to specify a different path for gnuplot.gih

[Lars H. <lhe...@us...>]

Per Persson writes:
> Hi,
> there was a small problem with the way I built gnuplot for my binary 
> installer.
> I naively install gnuplot into a dir and then copy the contents to the 
> installer. The path to gnuplot.gih gets hardwired to that install 
> location. Setting --with-gihdir= didn't help, since it then tries to 
> install gnuplot.gih at that location.
> 
> How do other people deal with this?
> Skipping the install phase and just copy the files from the built 
> sources?
> Or, is there packaging support in the makefiles that I'm missing?
 
 I don't know how your installer works, but there a little bit of support
 for package builds in the makefiles. If you install using

 make install DESTDIR=/path/to/dir ,

 the complete hierarchy gets installed under /path/to/dir and you can build
 a package from there. E.g.

$ make install DESTDIR=/tmp/package
...
$ find /tmp/package
/tmp/package/usr/local/bin/gnuplot
/tmp/package/usr/local/man/man1/gnuplot.1
...

How to specify a different path for gnuplot.gih

[Per P. <per...@ma...>]

Hi,
there was a small problem with the way I built gnuplot for my binary 
installer.
I naively install gnuplot into a dir and then copy the contents to the 
installer. The path to gnuplot.gih gets hardwired to that install 
location. Setting --with-gihdir= didn't help, since it then tries to 
install gnuplot.gih at that location.

How do other people deal with this?
Skipping the install phase and just copy the files from the built 
sources?
Or, is there packaging support in the makefiles that I'm missing?

/Per

Re: Cygwin compilation broken by bin_hook.c

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Sun, 3 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>> (Either bin_hook.o is a replica of binary.o or it is empty, depending 
>>on a configure switch.)
>>    
>>
>
>That's terminally ugly.  We will have to find a better way of doing that.
>

I should say more.  I wonder if it is worth the effort to find a better 
way.  If there is one candidate of the "experimental" code that could be 
removed from the #ifdef's it may be the new binary construction, in 
which case gnuplot will no longer need the "binary.c" file; only 
bf_tests will.  Then there will be no need for this odd compilation.

There are elements of the binary code that are open for discussion, but 
since Ethan suggested de-entangling binary from "df_readline", I think 
something like

int
df_readline(double v[], int max)
{
    if (df_read_binary)
    /* General binary, matrix binary or matrix ascii
     * that's been converted to binary.
     */
    return df_readbinary(v, max);
    else
    return df_readascii(v, max);
}

is the way to go.  I think there is a big advantage to gnuplot, at the 
higher application level, having just one way to bring in data and not 
having to know if the data came from a binary file or an ascii file.  It 
cuts down some code (tradeoff the df_readbinary() routine for all that 
is in "binary.c".)  It enables 2D and 3D plots to be more similar which 
in the long run should prove beneficial.

If there are aspects of binary data that people think should still 
remain in the experimental realm, then move some #ifdefs around to 
isolate those elements, but leave the above construction so that 
"binary.o" is no longer necessary.  Just wait a bit so that everyone is 
comfortable with the new df_readbinary(), which is on by default.

Dan

Re: Cygwin compilation broken by bin_hook.c

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Sun, 3 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>>Hans-Bernhard Broeker wrote:
>>    
>>
>>For the main gnuplot executable, binary.o should not be linked in. 
>>    
>>
>
>Well, then it shouldn't be listed in gnuplot_SOURCES, should it?
>

It isn't.  I took that out.  But in the case of Cygwin it appears 
"makefile.all" sources are constructed from all *.c files and then there 
is a list of ones not to include.

>> (Either bin_hook.o is a replica of binary.o or it is empty, depending 
>>on a configure switch.)
>>    
>>
>
>That's terminally ugly.
>

It works.

>  We will have to find a better way of doing that.
>

That's fine.

>BTW: it *is* possible to compile the same .c file into more than one .o
>file using different switches.
>

I couldn't think of a way to do that.  I'm assuming you mean the .o 
files will have different names.  There can't be a "binary.o" for 
gnuplot and a "binary.o" for bf_tests.  Otherwise the date check would 
end up causing confusion, I think.  "binary_this.o" and "binary_that.o" 
doesn't win a beauty contest either.

Dan

UCC web and ftp site

[Lars H. <lhe...@us...>]

 Hi all,

 I am changing jobs shortly, and will therefore be unable to continue
 maintenance of the gnuplot web and ftp sites at www.ucc.ie - they do not
 allow access for non-staff/students.

 The web site is not a problem, I'll have a redirector setup for
 www.gnuplot.info. The ftp site, however, is a different story;
 many, if not all mirror services mirror off UCC.

 What is the status of ftp.gnuplot.info, is it up to date, and should
 it take over from UCC? I.e. can I tell the CTAN admins to use it instead
 of UCC? Any other suggestions?

 I will continue to be available under my SF address.

Re: Cygwin compilation broken by bin_hook.c

[Hans-Bernhard B. <br...@ph...>]

On Sun, 3 Oct 2004, Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:
> 
> >Basically, the problem is that both bin_hook.o and binary.o end up
> >listed in makefile.all, so they will both be compiled and linked.

> For the main gnuplot executable, binary.o should not be linked in. 

Well, then it shouldn't be listed in gnuplot_SOURCES, should it?

>  (Either bin_hook.o is a replica of binary.o or it is empty, depending 
> on a configure switch.)

That's terminally ugly.  We will have to find a better way of doing that.
BTW: it *is* possible to compile the same .c file into more than one .o
file using different switches.  The Windows makefiles have to do that
all the time (because of the stdout/stderr tricks they pull).

> I've looked at this.  I can't seem to generate a representative 
> makefile.all.  (I'm not on windows.)  

You don't have to be.  Just delete it and watch it magically get
recreated, from the contents of Makefile.am.

> BTW, why is makefile.all in the CVS source tree, if it is to be 
> generated by automake?

Because it isn't.  It's generated by Makefile.maint, which is supposed
to be run only by us maintainers (usually by Lars), *before* automake.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Cygwin compilation broken by bin_hook.c

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

> >the strange construction of bin_hook.c #include'ing binary.c currently
> >causes a complete break of the Cygwin build.

I've added breaders to makefile.all, and all makefile.os2, .mgw and .cyg are
compiling OK.

> BTW, why is makefile.all in the CVS source tree, if it is to be
> generated by automake?

makefile.all is used by all those config/makefile.* who do not use
automake/configure.

--
PM

Re: x11 memory leak bugs

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

> >That's part of something that Petr added in Dec 2003.
> >I don't understand what it's for, even after reading the code and
> >the comments.
> >
> >(And what is a "multitab console" anyhow?  I use KDE on all my
> >machines, but I have no idea what piece or feature of the KDE
> >desktop this code affects).

Mozilla, Konqueror, Konsole can have several sessions open simultaneously as
"tabs" in one window. For KDE Konsole, a tab is one window shell or shell
session.

See gplt_x11.c:

static char*
getMultiTabConsoleSwitchCommand(unsigned long *newGnuplotXID)

which says:

 * Currently implemented for:
 *	- KDE's Konsole.
...
 /* now test for GNOME multitab console */
 /* ... if somebody bothers to implement it ... */
...


What it does:
1. Konsole session 1: run gnuplot, "plot x"
2. Open/switch to another session
3. Hit "Space" in gnuplot's X11 => gnuplot sends focus to the correct
konsole and browses it to the appropriate session

I think that GNOME has also multitab consoles -- that could be useful if
someones adds the same functionality there.

> Or, if the code should just check for the command once, under the
> assumption that if it tries again it'll just get the same thing, then:
>
>             if (!cmd_tried) {
>                 cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
>                 cmd_tried = 1; /* or TRUE, or something */
>             }

That's the correct fix, I've just cvs'ed it.

Petr

Re: problems revealed by new demos

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

> > I think that the epslatex driver should use postscript_gpoutfile for its
> > aux output, not its new gpauxfile. That's because there are tests within the
> > gnuplot core for this output, and then a postscript-optimized code is
> > shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d
> > output? I guess it would fail.
>
> I have never understood the sence of postscript_gpoutfile. What it is ment
> for?

Added for the (e)ps(la)tex family:

ChangeLog.0-2000-11-20  Petr Mikulik  <mi...@ph...>
ChangeLog.0-
ChangeLog.0-    * src/: color.c pm3d.c term.c term_api.h
ChangeLog.0-      term/: epslatex.trm pslatex.trm post.trm
ChangeLog.0:    pm3d: added 'FILE *postscript_gpoutfile' which is set to
ChangeLog.0-    'PSLATEX_auxfile' or 'gpoutfile' or '0' according to 'set term',
ChangeLog.0-    i.e. to the file where the postscript code goes to (if outputted).
ChangeLog.0:    Condition 'if (!postscript_gpoutfile)' can be used to distinguish
ChangeLog.0-    postscript terminals family (used in postscript optimized output
ChangeLog.0-    in pm3d).

That's why I think your epslatex should use it as well. Now I see that the
surrounding #ifdef PM3D ... #endif should be removed, and that
postscript_gpoutfile should be always useable.

See also here:

term_api.h-#ifdef PM3D
term_api.h-/* Output file where the PostScript output goes to.
term_api.h-   In particular:
term_api.h:     postscript_gpoutfile == gpoutfile
term_api.h-             for 'set term': postscript, pstex
term_api.h:     postscript_gpoutfile == PSLATEX_auxfile
term_api.h-             for 'set term': pslatex
term_api.h:     postscript_gpoutfile == 0
term_api.h-             for all other terminals
term_api.h-   It is non-zero for for the family of postscript terminals, thus making
term_api.h-   this a unique check for postscript output (pm3d has some code optimized
term_api.h-   for PS, for instance).
term_api.h-*/
term_api.h:extern FILE *postscript_gpoutfile;
term_api.h-#endif


--
PM

Re: x11 memory leak bugs

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

On Sunday 03 October 2004 11:49 am, Ethan Merritt wrote:
> On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
> > It is the QF causing problems which is executed as:
> >     case 'F':
> >         /* Strip out just the font name */
> >         c = &(buffer[strlen(buffer)-1]);
> >         while (*c <= ' ') *c-- = '\0';
> >             pr_font(&buffer[2]);
> >         XSetFont(dpy,gc,font->fid);
> >         break;
> >
> > When I comment out the "XSetFont" function, the memory leak goes away.

OK. I confirm the leak, although I don't see any processes other than 
gnuplot_x11 itself being affected.

I thought I knew how x11 fonts worked, but clearly I don't.

Three observations. I can't really explain any of them, but I'd be interested 
whether you see the same:

1) The biggie.
X11 font handling has broken badly sometime since I first wrote it.
I'm not at all sure when, and I don't know how much it has to do with
the problem you have identified.  It seems broken in the V4.0.0
release version also.  The upshot is that if you open new plot windows
with new fonts, then old windows do not keep their original fonts.
I can't figure out exactly whose font they get instead, but there
must be a bookkeeping error somewhere.

2) the above call to XSetFont() returns BadResource, which is strange
because clearly the call is actually working.  Also strange because
that's not listed on the man page as a possible return code.

3) adding the following to the head of pr_font() seems to make the
leak go away for a single-window test case. 
But what if another plot is using this font?????
On the other hand, see problem (1); this is already messed up.
--- gplt_x11.c.orig
+++ gplt_x11.c
@@ -5078,6 +5085,11 @@
 
     if (!fontname)
        fontname = FallbackFont;
+
+    /* EAM DEBUG!!!!  Release current font, if any */
+    if (font)
+       XFreeFont(dpy, font);
+

Re: Cygwin compilation broken by bin_hook.c

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>Daniel, or whoever has time to look into this:
>
>the strange construction of bin_hook.c #include'ing binary.c currently 
>causes a complete break of the Cygwin build.  It essentially introduces
>to complete copies of binary.c into the build, which causes a multiple 
>definition error from the linker for everything defined in there.
>
>Basically, the problem is that both bin_hook.o and binary.o end up
>listed in makefile.all, so they will both be compiled and linked.
>  
>

For the main gnuplot executable, binary.o should not be linked in. 
 (Either bin_hook.o is a replica of binary.o or it is empty, depending 
on a configure switch.)

I've looked at this.  I can't seem to generate a representative 
makefile.all.  (I'm not on windows.)  But I think the attached patch 
should fix the problem.  Please give it a try.

Dan

BTW, why is makefile.all in the CVS source tree, if it is to be 
generated by automake?

Re: x11 memory leak bugs

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
>
>  
>
>>PS:  There may be another potential minor leak, but I don't think it
>>happens by default.  This bit of code:
>>            if (!cmd_tried)
>>                cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
>>            if (cmd) system(cmd);
>>    
>>
>
>That's part of something that Petr added in Dec 2003.
>I don't understand what it's for, even after reading the code and
>the comments.  
>
>(And what is a "multitab console" anyhow?  I use KDE on all my
>machines, but I have no idea what piece or feature of the KDE
>desktop this code affects).
>
>It does seem that the code above should be changed to
>	if (cmd) {
>		system(cmd);
>		free(cmd);
>	}
>  
>

Or, if the code should just check for the command once, under the 
assumption that if it tries again it'll just get the same thing, then:

            if (!cmd_tried) {
                cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
                cmd_tried = 1; /* or TRUE, or something */
            }

Re: x11 memory leak bugs

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
>  
>
>>It is the QF causing problems which is executed as:
>>    case 'F':
>>        /* Strip out just the font name */
>>        c = &(buffer[strlen(buffer)-1]);
>>        while (*c <= ' ') *c-- = '\0';
>>            pr_font(&buffer[2]);
>>        XSetFont(dpy,gc,font->fid);
>>        break;
>>
>>When I comment out the "XSetFont" function, the memory leak goes away.
>>    
>>
>
>So are you saying this is a memory leak in your X-server?
>That's not really surprising, but it's not something we can fix.
>
>How are you testing for memory leaks?
>

I watch the processes, specifically the memory size parameter, as 
windows are open and closed.  (My window manager has a convenient system 
monitor for watching memory... but "ps" will do too.)  When a window is 
open, the memory size increases, naturally.  But when the window is 
closed, the memory size doesn't necessarily have to drop back down to 
its previous value because sometimes the heap isn't cleared immediately. 
 (Perhaps the kernel thinks the process will want the memory again.) 
 However, if you plot the same exact plot, the memory should not grow 
any higher than the previous.  In other words, keep plotting and closing 
the same plot; we shouldn't see memory keep on growing, just stay within 
some limit.

Now, for the unsolved leak, just resizing the very first plot should 
keep making the memory for the process "gnuplot_x11" keep growing.

Dan

Re: problems revealed by new demos

[Daniel J S. <dan...@ie...>]

Harald Harders wrote:

>On Fri, 1 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>>>I also just tried running gnuplot's "test" image through the epslatex
>>>terminal.  Running the "xdvi" on the compiled output files results in
>>>the polyfill not appearing.  Doing "dvips test -o test.ps" created a
>>>PostScript file that crashed on the polyfill.  As you are arguing
>>>above, if it works in PostScript, a seemless transition to related
>>>terminals should be expected.
>>>      
>>>
>
>Have you used a patched epslatex terminal or the original one?
>

Original.

>My patch uses PS_init in the TERM_TABLE of the epslatex terminal which
>itself calls PS_common_init. Thus, my patch should fix this problem. In
>all test I have done I have compared the output of the postscript terminal
>with the epslatex output using 'diff'. The only difference was the missing
>text definitions in epslatex (which of course must be missing there).
>

Ah...  I didn't look at the tables, just in the code.  Thanks,

Dan

Re: x11 memory leak bugs

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

On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:

> PS:  There may be another potential minor leak, but I don't think it
> happens by default.  This bit of code:
>             if (!cmd_tried)
>                 cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
>             if (cmd) system(cmd);

That's part of something that Petr added in Dec 2003.
I don't understand what it's for, even after reading the code and
the comments.  

(And what is a "multitab console" anyhow?  I use KDE on all my
machines, but I have no idea what piece or feature of the KDE
desktop this code affects).

It does seem that the code above should be changed to
	if (cmd) {
		system(cmd);
		free(cmd);
	}

Petr?

Re: x11 memory leak bugs

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

On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
> It is the QF causing problems which is executed as:
>     case 'F':
>         /* Strip out just the font name */
>         c = &(buffer[strlen(buffer)-1]);
>         while (*c <= ' ') *c-- = '\0';
>             pr_font(&buffer[2]);
>         XSetFont(dpy,gc,font->fid);
>         break;
>
> When I comment out the "XSetFont" function, the memory leak goes away.

So are you saying this is a memory leak in your X-server?
That's not really surprising, but it's not something we can fix.

How are you testing for memory leaks?

Re: problems revealed by new demos

[Harald H. <h.h...@tu...>]

On Fri, 1 Oct 2004, Daniel J Sebald wrote:

> > I also just tried running gnuplot's "test" image through the epslatex
> > terminal.  Running the "xdvi" on the compiled output files results in
> > the polyfill not appearing.  Doing "dvips test -o test.ps" created a
> > PostScript file that crashed on the polyfill.  As you are arguing
> > above, if it works in PostScript, a seemless transition to related
> > terminals should be expected.

Have you used a patched epslatex terminal or the original one?

> Oh, I see that none of the common definitions are put inside the PS
> portion of the epslatex terminal scheme.  So the "PolyFill" command
> fails because it isn't defined in the files header.  Somewhere epslatex
> needs to call PS_common_init().  Skimming through Harald's epslatex
> patch, I don't see that it does that.  Should this be fixed before or
> after the patch is applied?

My patch uses PS_init in the TERM_TABLE of the epslatex terminal which
itself calls PS_common_init. Thus, my patch should fix this problem. In
all test I have done I have compared the output of the postscript terminal
with the epslatex output using 'diff'. The only difference was the missing
text definitions in epslatex (which of course must be missing there).

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Cygwin compilation broken by bin_hook.c

[Hans-Bernhard B. <br...@ph...>]

Daniel, or whoever has time to look into this:

the strange construction of bin_hook.c #include'ing binary.c currently 
causes a complete break of the Cygwin build.  It essentially introduces
to complete copies of binary.c into the build, which causes a multiple 
definition error from the linker for everything defined in there.

Basically, the problem is that both bin_hook.o and binary.o end up
listed in makefile.all, so they will both be compiled and linked.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: problems revealed by new demos

[Hans-Bernhard B. <br...@ph...>]

On Sat, 2 Oct 2004, Harald Harders wrote:

> The cause for introducing the new API routine was that it allows some
> interesting things that were not possible with the standard routine:
> 
> - The use is able to leave out the file extensions.
>   For the user the question is: Since epslatex generates two files, which
>   of these is the correct one? With the new routine it is possible to
>   give 'outfile.eps', 'outfile.tex', or 'outfile' as output filename.

That sounds like a sensible reason, indeed.  The difference between
pslatex and epslatex about which of the two file names you have to
specify, and which will be generated by the driver, has been a pain in the
lower back to explain to people.

> - The option fullheader made it necessary to use another file open
>   routine. The fullheader mode is ment for producing a stand alone
>   postscript or pdf output file that can be included by any application,
>   using TeX texts. 

I think you've lost me there.  How exactly is this different from 'aux
file' mode of pslatx, or the default mode of operation of the existing
epslatex?

> This is done by producing a full LaTeX file with the
>   given output file name and an additional eps file with a prefix before
>   the extension. This is done to prevent mixing up the gnuplot-produced
>   eps file without text information and the final ps or pdf file produced
>   by dvips or pdflatex.

You say "_the_ final... file" here as if it was sure such a tex'ed version
was pretty much guaranteed to be produced --- whereas in actuality, that's
not really the original intended mode of usage of either of these drivers.  
They're (originally, at least) meant for inclusion into larger LaTeX
documents, not for producing postscript figures by a detour through TeX.

Actually, if this is the kind of usage you have in mind, you could
just do pslatex without the auxfile option.

> I think, the new set_output routine could also be interesting for other
> terminals, escpecially these with binary output or with more than one
> output file.

We have binary output covered quite fine as it is.  It's really only
"split stream" drivers, i.e. only epslatex and "pslatex aux", where this
would actually make a difference, I think.

> > I have some questions about your new terminal entry.
> >
> > Right now it is permitted (though discouraged) to call
> > 'set output'  before calling 'set term'.   Would we have to
> > forbid this absolutely?
> 
> Mmh, I think it is a design bug that 'set output' immediately opens an
> output file before it knows for which terminal the file will be used. 

I don't quite agree that this should count as a bug.  A file is a file.
It's quite a simple thing, really. Drivers shouldn't need a written
instruction or a diploma to handle one ;-)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

x11 memory leak bugs

[Daniel J S. <dan...@ie...>]

I discovered memory leak problems in gnuplot_x11 a few days ago and have 
uncovered a couple things so far.

The first bug I have fixed with the attached patch.  Please apply this 
short patch to CVS immediately.  The problem also exists in 4.0.0, 
unfortunately, so perhaps it should be fixed there as well.  It isn't a 
severe leak.  When a plot is deleted, the commands in the buffer are 
cleared.  However, the plot->commands array is also dynamic and I 
overlooked freeing that when building the linked list.  (So my bad.)  In 
the 16 window scheme previous, this was not a problem because the 
pointer "plot" was not discarded.  However, when removing the link from 
the list, "plot" is discarded and hence a valid plot->commands array is 
discarded.  The memory usage grows at a noticeable rate when there are a 
lot of commands in windows that are closed often, so likely not too 
noticeable.

Now the second problem.  I haven't solved this one yet and I may need 
some help from Ethan.  Here is what I am noticing in CVS and in 4.0.0 on 
my machine.  When I start up gnuplot and do a plot, say "plot x", and 
then resize the window with the mouse or redisplay it in some way, the 
memory usage climbs at an appreciable rate.  However, creating another 
X11 plot and resizing does not show this behavior.  I eventually noticed 
that there is one extra command in the plot buffer for only the very 
first plot.  In the case of "plot x" it is 223 commands for the first 
plot, 222 thereafter; and here is how they differ:

QAAWLMVMVJQTWL...
QAAWLMVMVJTWLM...

There is an extra 'Q' or font command at the tenth spot.  I did not go 
any further investigating why this extra Q is there for the first plot. 
 Perhaps Ethan can help.  Is it gnuplot that is putting in the extra 
command?  Is it a mouse feedback command?

In any case, the question is why is this causing memory to disappear so 
quickly?  Those two command strings in the first plot are "QD" and then 
later "QF".  It is the QF causing problems which is executed as:

    switch (buffer[1]) {
    case 'F':
        /* Strip out just the font name */
        c = &(buffer[strlen(buffer)-1]);
        while (*c <= ' ') *c-- = '\0';
            pr_font(&buffer[2]);
        XSetFont(dpy,gc,font->fid);
        break;

When I comment out the "XSetFont" function, the memory leak goes away.

So, upon redisplaying the plot, there is an XClearWindow().  Does there 
also need to be something that frees the fonts in the X window?  (I'm 
just guessing.)

Dan

PS:  There may be another potential minor leak, but I don't think it 
happens by default.  This bit of code:
 
        case ' ': {
            static int cmd_tried = 0;
            static char *cmd = NULL;
            static unsigned long newGnuplotXID = 0;
        
            /* If the "-ctrlq" resource is set, ignore ' ' unless 
control key is also pressed */
            if (ctrlq && !(modifier_mask & Mod_Ctrl))
                break;

            if (!cmd_tried)
                cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
            /* overwrite gnuplotXID (re)set after x11.trm:X11_options() */
                if (newGnuplotXID) gnuplotXID = newGnuplotXID;
            if (cmd) system(cmd);
            }
            if (gnuplotXID) {
                XMapRaised(dpy, gnuplotXID);
                XSetInputFocus(dpy, gnuplotXID, 0 /*revert */ , 
CurrentTime);
                XFlush(dpy);
            }
            return;

If successful "getMultiTab..." mallocs a command on the heap and returns 
it.  It is used by the above system command, but nowhere is that pointer 
freed after its use.  The variables are static, and "(!cmd_tried)" would 
protect against getting the command a second time if only it were set to 
1 after getting the command.

Re: GnuPlot and Aquaterm

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

On Friday 01 October 2004 10:46 am, jue...@ma... wrote:
> I was trying to use gnuplot with Aquaterm on OSX again after a time of
> disuse.
>
> Any ideas on this? I was depending on it for fixing up some graphs in my
> diploma thesis, and now I'm stuck.

Why would you need aquaterm in order to prepare graphs for a thesis?
gnuplot has many output modes for printed documents, and all of them
are probably superior to converting something from a screen image.

The aquaterm project looks interesting, but so far as gnuplot use is
concerned it is still at this time strictly less capable that x11 for screen
use, and anyway is not relevant to preparing printable output.

Re: problems revealed by new demos

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Fri, 1 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>>No doubt there.  What about this "pstricks".  Way back, I saw that one
>>and thought to update the image drivers in there.  Then looking at it,
>>it seemed so outdated that I wondered about its worth.  I tried running
>>'all.dem' under pstricks; that soon failed.  I tried 'image.dem'; image
>>don't pass through of course but some other elements in the plots
>>failed.  pstricks is falling behind a bit.
>>    
>>
>
>Well, that's what happens if none of its users bothers to speak up or
>participate in the maintenance.  I'm quite sure we have drivers that have
>accumulated even more dust than pstricks.
>

I'm not a user of pstricks, so I'm not advocating its update.  In fact, 
I'd be willing to let that one go.  The reason is that I think the 
e/pslatex approach is much superior.  There's the nice graphics features 
of PostScript combined with the font and math scripts of LaTeX.

Now, I looked at pstricks.sty on the web and see that there is a 2004 
copyright suggesting it has been updated recently.  Yet, it still looks 
rather skimpy.

Perhaps what could be done is a ./configure switch to leave pstricks out 
of the terminal list by default.  It's capabilities probably match 
pre-4.0 and its use may be limited (could ask the LaTeX developers).

It's just as well to leave it as is and if someone complains about lack 
of features see if something can be done.


>> From my understanding, EPS supposedly only differs from PS by the 
>>presence of the bounding box information.
>>    
>>
>
>I was talking about epslatex vs. pslatex.  Those two are almost completely
>independent of each other.
>  
>

Yes, I found that out.  They should be made very similar.

Dan