gnuplot-py-users

[Gnuplot-py-users] hardcopy termdef defnition for pdf

[Jim K. <jek...@kl...>]

I added the code below to termdefs.py to allow hardcopy
to work with pdf.  However, I found that to get printout
without an interactive session, I was better off just sending
the appropriate commands to gnuplot and going around hardcopy.
Note that I am using cygwin but with a compiled version of
gnuplot for X11.

I also found that the temporary file was being removed before
the gnuplot process was done with it.  Adding a sleep() of a
few seconds made it work but that was kind of a kludge.
Adding a g.gnuplot.gnuplot.close() worked fine since it
causes a wait for the popen() process to exit (if not using
inline).  I wonder if there is some way to put this into
the __del__() function at a place where this would happen
naturally?  I tried the obvious on Gnuplot but it didn't work.

Jim

This is vs. the CVS archive:

Index: termdefs.py
===================================================================
RCS file: /cvsroot/gnuplot-py/gnuplot-py/termdefs.py,v
retrieving revision 2.4
diff -u -r2.4 termdefs.py
--- termdefs.py    21 Apr 2003 09:44:09 -0000    2.4
+++ termdefs.py    17 Oct 2003 20:25:40 -0000
@@ -386,6 +386,21 @@
      BareStringArg(argname='fontsize'),
      ]

+terminal_opts['pdf'] = [
+    KeywordOrBooleanArg(
+        options=['landscape', 'portrait', 'eps', 'default'],
+        argname='mode',
+        ),
+    KeywordOrBooleanArg(options=['color', 'monochrome']),
+    KeywordOrBooleanArg(options=['solid', 'dashed']),
+    KeywordOrBooleanArg(
+        options=['defaultplex', 'simplex', 'duplex'],
+        argname='duplexing',
+        ),
+    StringArg(argname='fontname'),
+    BareStringArg(argname='fontsize'),
+    ]
+
  terminal_opts['png'] = [
      KeywordOrBooleanArg(
          options=['small', 'medium', 'large'],

Re: [Gnuplot-py-users] hardcopy termdef defnition for pdf

[<kai...@t-...>]

Jim Kleckner wrote:

> I added the code below to termdefs.py to allow hardcopy
> to work with pdf.


Thanks, I just added this to CVS.  Sorry I didn't get it into the release.

> I also found that the temporary file was being removed before
> the gnuplot process was done with it.  Adding a sleep() of a
> few seconds made it work but that was kind of a kludge.
> Adding a g.gnuplot.gnuplot.close() worked fine since it
> causes a wait for the popen() process to exit (if not using
> inline).  I wonder if there is some way to put this into
> the __del__() function at a place where this would happen
> naturally?  I tried the obvious on Gnuplot but it didn't work.


The temporary-file removal problem is discussed in FAQ.txt.  Under what 
circumstances exactly did calling close() help?  It would probably make 
more sense to add a close() method to the GnuplotProcess objects because 
its implementation is likely to be platform-specific.  Then I guess 
Gnuplot should call the close() method in its own __del__ method.  Hmmm, 
I guess this helps by ensuring that the pipe is closed before the 
plotitems are destroyed.

OK, I just implemented this in CVS, too.

Thanks for your note and suggestions!

Michael

-- 
Michael Haggerty
mh...@al...

Re: [Gnuplot-py-users] hardcopy termdef defnition for pdf

[Jim K. <jek...@kl...>]

Michael Haggerty wrote:

> Jim Kleckner wrote:
> 
>> I added the code below to termdefs.py to allow hardcopy
>> to work with pdf.
> 
> Thanks, I just added this to CVS.  Sorry I didn't get it into the release.


Great, thanks!


>> I also found that the temporary file was being removed before
>> the gnuplot process was done with it.  Adding a sleep() of a
>> few seconds made it work but that was kind of a kludge.
>> Adding a g.gnuplot.gnuplot.close() worked fine since it
>> causes a wait for the popen() process to exit (if not using
>> inline).  I wonder if there is some way to put this into
>> the __del__() function at a place where this would happen
>> naturally?  I tried the obvious on Gnuplot but it didn't work.
> 
> The temporary-file removal problem is discussed in FAQ.txt.  Under what 
> circumstances exactly did calling close() help?  It would probably make 
> more sense to add a close() method to the GnuplotProcess objects because 
> its implementation is likely to be platform-specific.  Then I guess 
> Gnuplot should call the close() method in its own __del__ method.  Hmmm, 
> I guess this helps by ensuring that the pipe is closed before the 
> plotitems are destroyed.
> 
> OK, I just implemented this in CVS, too.
> 
> Thanks for your note and suggestions!
> 
> Michael
> 


Yes, when I upgraded to 1.7 CVS I noticed that cygwin
implemented inline by default now and that is the strongest
way to guarantee that the data will be synchronized.  I ended
up switching everything over to that.

I switched back over to "not inline" and it still fails when

you reuse an existing plot process.  The race seems to be that
when you perform a new plot (without closing the process)
and the piped command hasn't finished processing the last file,
it can get deleted by the next rapid fire g.plot() request that
replaces the plot items.  A total hack could be to keep an
invisible list of plot items not in the queue that gets set to
None at close time resulting in file deletion.  Quite a hack.
Proabably better to tell people to just use inline or create
a new plot object for each plot.


Thanks!
Jim