plplot-general — PLplot user discussion group

Re: [Plplot-general] Enter graphics output file name:

[Arjen M. <arj...@de...>]

Hello Gérard,

you can use the -o option to specify the filename or in your
program:

(plsfnam 'somefilename)

(Mind you, I did a bit of guess work here, as I do not program in LISP
myself)

Regards,

Arjen

On 2013-02-13 11:12, Gérard Robin wrote:
> When I run this program:
> 
> (defpackage :system-examples
>   (:use :common-lisp
> 	:cl-plplot-system))
> 
> (in-package :system-examples)
> 
> (defparameter gdev "xfig")  ; (was aqt) set this to the appropriate plplot
> device for your system
> 
> (defun my-make-array (dims)
>   (make-array dims :initial-element 0.0 :element-type 'float))
> 
> (defun plotparabol ()
>   (plsdev gdev)
>   (plinit)
>   (plcol0 1)
>   (plwid 1) 
>   (plenv -6 6 0 36 0 0)
>   (plcol0 2)
>   (pllab "(x)" "(y)" "y = x#u2")
>   (let ((x (my-make-array 121))
> 	(y (my-make-array 121)))
>   
>     (dotimes (i 121)
>       (let ((tmp (* 0.1 (- i 60)))) 
> 	       (setf (aref x i) tmp)
> 	       (setf (aref y i) (* tmp tmp))))  
> 
>     (plcol0 3)  ;; color de la courbe
> 
>     (plline x y))
> 
>   (plend))
> (plotparabol)
> 
> I get : Enter graphics output file name:
> 
> How can I avoid this message? what I want is that the result is automatically
> stored in a file whose name is given by the program.(say : parab1.fig)
> 
> Then I want to add the line in the program :
> 
> (run-program "/usr/bin/xfig" '("-nosp"  "parab1.fig"))
> 
> for the curve appears on the screen.
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
> 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-general] Enter graphics output file name:

[Gérard R. <g.r...@fr...>]

When I run this program:

(defpackage :system-examples
  (:use :common-lisp
	:cl-plplot-system))

(in-package :system-examples)

(defparameter gdev "xfig")  ; (was aqt) set this to the appropriate plplot
device for your system

(defun my-make-array (dims)
  (make-array dims :initial-element 0.0 :element-type 'float))

(defun plotparabol ()
  (plsdev gdev)
  (plinit)
  (plcol0 1)
  (plwid 1) 
  (plenv -6 6 0 36 0 0)
  (plcol0 2)
  (pllab "(x)" "(y)" "y = x#u2")
  (let ((x (my-make-array 121))
	(y (my-make-array 121)))
  
    (dotimes (i 121)
      (let ((tmp (* 0.1 (- i 60)))) 
	       (setf (aref x i) tmp)
	       (setf (aref y i) (* tmp tmp))))  

    (plcol0 3)  ;; color de la courbe

    (plline x y))

  (plend))
(plotparabol)

I get : Enter graphics output file name:

How can I avoid this message? what I want is that the result is automatically
stored in a file whose name is given by the program.(say : parab1.fig)

Then I want to add the line in the program :

(run-program "/usr/bin/xfig" '("-nosp"  "parab1.fig"))

for the curve appears on the screen.

Re: [Plplot-general] Problem with plimagefr in Fortran or misunderstanding?

[Arjen M. <arj...@de...>]

Hi James,

hm, it is probably best to check this requirement in the
wrapping routines - and add it to the documentation.

Regards,

Arjen

On Mon, 11 Feb 2013 13:20:38 -0700
  James Tappin <jt...@gm...> wrote:
> On 11 February 2013 12:28, Alan W. Irwin 
><ir...@be...> wrote:
> 
>> On 2013-02-11 11:52-0700 James Tappin wrote:
>>
>>  Is there a problem with plimagefr in Fortran95 or am I 
>>misunderstanding
>>> how
>>> it should be used?
>>>
>>
>> I am not familiar with plimagefr, but have you had a 
>>look at
>> examples/f95/x20f.f90 which demonstrates a working 
>>Fortran95 example
>> that uses plimagefr?
>>
>>
>Found the answer -- it's not really obvious without 
>poking quite deep into
> the code that the X & Y arrays should be 1-element 
>bigger than the Z array.
> 
> James


 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-general] Problem with plimagefr in Fortran or misunderstanding?

[James T. <jt...@gm...>]

On 11 February 2013 12:28, Alan W. Irwin <ir...@be...> wrote:

> On 2013-02-11 11:52-0700 James Tappin wrote:
>
>  Is there a problem with plimagefr in Fortran95 or am I misunderstanding
>> how
>> it should be used?
>>
>
> I am not familiar with plimagefr, but have you had a look at
> examples/f95/x20f.f90 which demonstrates a working Fortran95 example
> that uses plimagefr?
>
>
Found the answer -- it's not really obvious without poking quite deep into
the code that the X & Y arrays should be 1-element bigger than the Z array.

James

Re: [Plplot-general] Problem with plimagefr in Fortran or misunderstanding?

[Alan W. I. <ir...@be...>]

On 2013-02-11 11:52-0700 James Tappin wrote:

> Is there a problem with plimagefr in Fortran95 or am I misunderstanding how
> it should be used?

I am not familiar with plimagefr, but have you had a look at
examples/f95/x20f.f90 which demonstrates a working Fortran95 example
that uses plimagefr?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] 1st Call For Papers, 19th Annual Tcl/Tk Conference 2012

[Andreas K. <and...@ac...>]

20'th Annual Tcl/Tk Conference (Tcl'2013)
http://www.tcl.tk/community/tcl2013/

September 23 - 27, 2013
Bourbon Orleans Hotel
New Orleans, Louisiana, USA

Important Dates:

Abstracts and proposals due   June      22, 2013
Notification to authors       August     5, 2013
Author materials due          September  2, 2013
Tutorials Start               September 23, 2013
Conference starts             September 25, 2013

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2013 will be held in New Orleans, Louisiana, USA from September
23 - 27, 2013. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2013. Authors of accepted abstracts will have until September 2, 2013
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 5, 2013. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 3, 2013. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2013/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp			General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.	Program Chair
Gerald Lester           KnG Consulting, LLC		Site/Facilities Chair
Arjen Markus            Deltares
Brian Griffin           Mentor Graphics
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB Michigan State University
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2013 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

Re: [Plplot-general] Axis label scaling problem

[Alan W. I. <ir...@be...>]

On 2013-01-31 11:48-0600 RM wrote:

> Hi Alan and all,
> 
> We're using the wxWidgets driver.  c++ 
> 
> Below is a sampling of code to calculate the viewport.  Our devs found that the wx driver expected a 10mm x 7.5mm window size and had to
> do a lot of fiddling to get things to work right.
> 
> We use the slabelfunc() to create custom labels (not shown).
> 
> And, we do *not* use any special font scaling as defined by: plschr().  We're just accepting the defaults.
> 
> Could this be an issue with the wx driver or are we doing something incorrectly?

The short answer is I think you must be doing something incorrectly.

Now for the longer story....

The wxwidgets device doesn't have the same popularity as say the cairo
and qt device drivers which provide alternative to wxwidgets which
also work on all platforms. However, we fully support the wxwidgets
device in the sense if users send in patches for wxwidgets that appear
also to work for us, we are happy to apply those patches.

That said, I don't think a wxwidgets patch will be necessary in this
case.

To prove that for yourself, please run

examples/c/x01c -dev wxwidgets -a 1.

and

examples/c/x01c -dev wxwidgets -a 2.

which produce wxwidgets results at two different aspect ratios.

Those results look good on my own Linux box (using the wxGC version of
that device by default). If they don't give you good looking results,
we should start comparing screenshots (off list).  However, I expect
they will give you good looking results in which case you should be
copying the broader aspects of how any of our standard examples (such
as the first one) are implemented so your own code starts producing
good looking results with wxwidgets as well.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Axis label scaling problem

[RM <rc...@ve...>]

<div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>Hi Alan and all,</div><div><br /></div><div>We're using the wxWidgets driver. &nbsp;c++&nbsp;</div><div><br /></div><div>Below is a sampling of code to calculate the viewport. &nbsp;Our devs found that the wx driver expected a 10mm x 7.5mm window size and had to do a lot of fiddling to get things to work right.</div><div><br /></div><div>We use the slabelfunc() to create custom labels (not shown).</div><div><br /></div><div>And, we do *not* use any special font scaling as defined by: plschr(). &nbsp;We're just accepting the defaults.</div><div><br /></div><div>Could this be an issue with the wx driver or are we doing something incorrectly?</div><div><br /></div><div><br /></div><div><div>//</div><div>// Figure out what is going on around the edges of the plot and calculate</div><div>// how much room is left for the plot.</div><div>// Note:</div><div>// All of the numbers are &quot;magic numbers&quot; that were empirically determined.</div><div>// Don't fiddle with them without lots of testing on plots with different</div><div>// options!</div><div>void PlotRenderer::CalcViewPort()</div><div>{</div><div>&nbsp; &nbsp; if (!m_obj || !m_pls)</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return;</div><div><br /></div><div>&nbsp; &nbsp; const PLFLT DEF = .02; // default buffer around the edge of the screen</div><div>&nbsp; &nbsp; DAPlotConfig config = m_obj-&gt;GetConfig();</div><div>&nbsp; &nbsp; DAPlotAxisConfig x_config = m_obj-&gt;GetAxisConfig(::X_PLOT_AXIS);</div><div>&nbsp; &nbsp; DAPlotAxisConfig y_config = m_obj-&gt;GetAxisConfig(::Y_PLOT_AXIS);</div><div>&nbsp; &nbsp; DAPlotAxisConfig z_config = m_obj-&gt;GetAxisConfig(::Z_PLOT_AXIS);</div><div>&nbsp; &nbsp; bool plot3d = (config.Type == ::WAVEFORM_3D); // 3d plotting</div><div><br /></div><div>&nbsp; &nbsp; //</div><div>&nbsp; &nbsp; // rather than using the actual dimensions of the plot area, the wxwidgets driver for plplot</div><div>&nbsp; &nbsp; // defines a default size of 10&quot; wide x 7.5&quot; height. This complicates my life.</div><div>&nbsp; &nbsp; const PLFLT CANVAS_WIDTH = 10.0 * 25.4; // default width in MM from &lt;drivers/wxwidgets.h&gt;</div><div>&nbsp; &nbsp; const PLFLT CANVAS_HEIGHT = 7.5 * 25.4; // default height in MM from &lt;drivers/wxwidgets.h&gt;</div><div><br /></div><div>&nbsp; &nbsp; //</div><div>&nbsp; &nbsp; // everything in plplot seems to be set up for a default aspect ratio of 4:3. Our&nbsp;</div><div>&nbsp; &nbsp; // aspect ratio fluctuates. So, calculate our aspect ratio and divide by the default</div><div>&nbsp; &nbsp; // ratio of 4:3.</div><div>&nbsp; &nbsp; PLFLT aspect = (PLFLT)m_height / (PLFLT)m_width / (CANVAS_HEIGHT / CANVAS_WIDTH);</div><div><br /></div><div>&nbsp; &nbsp; //</div><div>&nbsp; &nbsp; // Calculate the amount of space needed around the plot for the legend, Title, SubTitle</div><div>&nbsp; &nbsp; // and axis titles</div><div>&nbsp; &nbsp; PLFLT default_mm, char_height_mm;</div><div>&nbsp; &nbsp; plgchr( &amp;default_mm, &amp;char_height_mm ); &nbsp; &nbsp;// character height in MM</div><div>&nbsp; &nbsp; PLFLT char_height = char_height_mm / CANVAS_HEIGHT; // height of a character as a fraction of the total screen height.</div><div>&nbsp; &nbsp; PLFLT char_height_x = char_height_mm / CANVAS_WIDTH; // character height as a fraction of width used for the sideways Y axis label</div><div><br /></div><div>&nbsp; &nbsp; //</div><div>&nbsp; &nbsp; // These variables are tracking the space we need to leave at the top/bottom/left/right side</div><div>&nbsp; &nbsp; // of the plot for titles and labels and the legend.</div><div>&nbsp; &nbsp; PLFLT topspace = DEF, bottomspace = DEF, leftspace = DEF*aspect, rightspace = DEF*aspect;</div><div>.</div><div>.</div><div>.</div><div>&nbsp; &nbsp; //</div><div>&nbsp; &nbsp; // final viewport dimensions...</div><div>&nbsp; &nbsp; m_vpxmin = leftspace;</div><div>&nbsp; &nbsp; m_vpxmax = 1 - rightspace;</div><div>&nbsp; &nbsp; m_vpymax = 1 - topspace;</div><div>&nbsp; &nbsp; m_vpymin = bottomspace;</div><div><br /></div><div>&nbsp; &nbsp; m_pls-&gt;vpor (m_vpxmin, m_vpxmax, m_vpymin, m_vpymax); // configure the size of the plot window</div><div><br /></div><div><br /></div></div><div><br /></div><div><br /></div><div>&nbsp;</div><div>&nbsp;</div><div style="border-top:1px solid #bcbcbc;margin:5px 0px;"></div><span style="font-size:12;font-family:arial;color:#000000;">On 01/30/13, <span>Alan W. Irwin&lt;<a class="parsedEmail" href="mailto:ir...@be..." target="_blank">ir...@be...</a>&gt;</span> wrote:</span><div>&nbsp;</div><div style="font-size:12;font-family:arial;color:#000000;">On 2013-01-30 15:16-0600 RM wrote:<br /><br />&gt; We've been having a lot of trouble trying to create plots with readable axis numbers for &quot;non-standard&quot; plot aspect ratio's. Â&nbsp;[I say<br />&gt; non-standard, because plplot seems to be set up to support an aspect ratio of 4x3. Â&nbsp;Please correct me if I'm wrong.]<br />&gt; <br />&gt; We'd like to create plots that are resizable -- not infinitely resizable -- but resizable in a few fixed increments. Â&nbsp;This means we<br />&gt; create plots that are sometimes either more rectangular or more square than 4x3.<br />&gt; <br />&gt; The problem is that the Axis numbering does not handle a square aspect ratio well at all.<br />&gt; <br />&gt; The Axis numbers appear to scale off the *vertical* size of the plot window -- which in the case of a square-ish plot, causes the<br />&gt; numbers to appear unnaturally large and often run into one another.<br />&gt; <br />&gt; Please see the following example of an identical plot scaled to two different aspect ratios (heights). Â&nbsp;Both plots are the same width,<br />&gt; but the taller version creates enormous axis numbers that run into each other.<br />&gt; Â&nbsp;<a class="parsedLink" href="http://imageshack.us/a/img259/5944/plotteraxisproblem.png" target="_blank">http://imageshack.us/a/img259/5944/plotteraxisproblem.png</a><br /><br />&gt;<br /><br />Those character sizes seem unusual so you may be running into a bug for a<br />particular device driver or you may be specifying aspect ratio in an<br />unsupported way.  So exactly what device driver are you using to<br />create your plots, and for a given plot exactly how do you change the<br />aspect ratio?<br /><br />I get reasonable looking character sizes for<br /><br />examples/c/x01c -dev xcairo -a 1.<br />examples/c/x01c -dev xcairo -a 2.<br /><br />Do you also replicate those good results for that device?<br /><br />&gt; Or, are there any plans to include the ability to rotate the x-axis numbers 45 degrees (like gnuplot) to avoid issues like these?<br /><br />No plans that I am aware of for the generic API, but PLplot does have<br />the ability to use custom axis labelling that is implemented by the<br />user. So basically you have complete labelling freedom.  The key<br />function you have to call to set it up is<br /><a class="parsedLink" href="http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.9/plslabelfunc.html." target="_blank">http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.9/plslabelfunc.html.</a><br />Also take a look at example 19 to see an example of how to use that<br />plslabelfunc capability.<br /><br />Alan<br />__________________________<br />Alan W. Irwin<br /><br />Astronomical research affiliation with Department of Physics and Astronomy,<br />University of Victoria (astro<a class="parsedLink" href="http://www.phys.uvic.ca" target="_blank">www.phys.uvic.ca</a>).<br /><br />Programming affiliations with the FreeEOS equation-of-state<br />implementation for stellar interiors (freeeos.sf.net); the Time<br />Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br />software package (plplot.sf.net); the libLASi project<br />(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br />and the Linux Brochure Project (lbproject.sf.net).<br />__________________________<br /><br />Linux-powered Science<br />__________________________<br /></div></div>

[Plplot-general] Test - please ignore

[Arjen M. <arj...@de...>]

I am sending this message, because I have not received a copy of a
message to the list yet that I sent several hours ago. The original
was caught in the spam filter.

So this is just to see if the list is active or not

Regards,

Arjen

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-general] On your axis label scaling problem

[Arjen M. <arj...@de...>]

Hello RM,

I found this message in my spam box:

We've been having a lot of trouble trying to create plots with readable 
axis numbers for "non-standard" plot aspect ratio's.  [I say 
non-standard, because plplot seems to be set up to support an aspect 
ratio of 4x3.  Please correct me if I'm wrong.]

We'd like to create plots that are resizable -- not infinitely resizable 
-- but resizable in a few fixed increments.  This means we create plots 
that are sometimes either more rectangular or more square than 4x3.

The problem is that the Axis numbering does not handle a square aspect 
ratio well at all.

The Axis numbers appear to scale off the *vertical* size of the plot 
window -- which in the case of a square-ish plot, causes the numbers to 
appear unnaturally large and often run into one another.

Please see the following example of an identical plot scaled to two 
different aspect ratios (heights).  Both plots are the same width, but 
the taller version creates enormous axis numbers that run into each other.

(AM: Not sure if this was the reason for it to be intercepted by the 
spam filter, but just in case the image is in: http: // imageshack.us  / 
a / img259 / 5944 / plotteraxisproblem.png)
____________

Is this a known issue, or are we perhaps not using the API correctly?

If known, are there plans to fix this in an upcoming release?

Or, are there any plans to include the ability to rotate the x-axis 
numbers 45 degrees (like gnuplot) to avoid issues like these?

Thanks for any help,
RM
-----

Could you show us the source code for these plots? Or a simplified
version exhibiting the phenomenon. This may help track down the issue.

Regards,

Arjen

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-general] On your axis label scaling problem

[Arjen M. <arj...@de...>]

Hello RM,

I found this message in my spam box:

We've been having a lot of trouble trying to create plots with readable 
axis numbers for "non-standard" plot aspect ratio's.  [I say 
non-standard, because plplot seems to be set up to support an aspect 
ratio of 4x3.  Please correct me if I'm wrong.]

We'd like to create plots that are resizable -- not infinitely resizable 
-- but resizable in a few fixed increments.  This means we create plots 
that are sometimes either more rectangular or more square than 4x3.

The problem is that the Axis numbering does not handle a square aspect 
ratio well at all.

The Axis numbers appear to scale off the *vertical* size of the plot 
window -- which in the case of a square-ish plot, causes the numbers to 
appear unnaturally large and often run into one another.

Please see the following example of an identical plot scaled to two 
different aspect ratios (heights).  Both plots are the same width, but 
the taller version creates enormous axis numbers that run into each other.

(AM: Not sure if this was the reason for it to be intercepted by the 
spam filter, but just in case the image is in: http: // imageshack.us  / 
a / img259 / 5944 / plotteraxisproblem.png)
____________

Is this a known issue, or are we perhaps not using the API correctly?

If known, are there plans to fix this in an upcoming release?

Or, are there any plans to include the ability to rotate the x-axis 
numbers 45 degrees (like gnuplot) to avoid issues like these?

Thanks for any help,
RM
-----

Could you show us the source code for these plots? Or a simplified
version exhibiting the phenomenon. This may help track down the issue.

Regards,

Arjen

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-general] Axis label scaling problem

[Alan W. I. <ir...@be...>]

On 2013-01-30 15:16-0600 RM wrote:

> We've been having a lot of trouble trying to create plots with readable axis numbers for "non-standard" plot aspect ratio's.  [I say
> non-standard, because plplot seems to be set up to support an aspect ratio of 4x3.  Please correct me if I'm wrong.]
> 
> We'd like to create plots that are resizable -- not infinitely resizable -- but resizable in a few fixed increments.  This means we
> create plots that are sometimes either more rectangular or more square than 4x3.
> 
> The problem is that the Axis numbering does not handle a square aspect ratio well at all.
> 
> The Axis numbers appear to scale off the *vertical* size of the plot window -- which in the case of a square-ish plot, causes the
> numbers to appear unnaturally large and often run into one another.
> 
> Please see the following example of an identical plot scaled to two different aspect ratios (heights).  Both plots are the same width,
> but the taller version creates enormous axis numbers that run into each other.
>  http://imageshack.us/a/img259/5944/plotteraxisproblem.png

>

Those character sizes seem unusual so you may be running into a bug for a
particular device driver or you may be specifying aspect ratio in an
unsupported way.  So exactly what device driver are you using to
create your plots, and for a given plot exactly how do you change the
aspect ratio?

I get reasonable looking character sizes for

examples/c/x01c -dev xcairo -a 1.
examples/c/x01c -dev xcairo -a 2.

Do you also replicate those good results for that device?

> Or, are there any plans to include the ability to rotate the x-axis numbers 45 degrees (like gnuplot) to avoid issues like these?

No plans that I am aware of for the generic API, but PLplot does have
the ability to use custom axis labelling that is implemented by the
user. So basically you have complete labelling freedom.  The key
function you have to call to set it up is
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.9/plslabelfunc.html.
Also take a look at example 19 to see an example of how to use that
plslabelfunc capability.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Axis label scaling problem

[RM <rc...@ve...>]

<div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div>We've been having a lot of trouble trying to create plots with readable axis numbers for &quot;non-standard&quot; plot aspect ratio's. &nbsp;[I say non-standard, because plplot seems to be set up to support an aspect ratio of 4x3. &nbsp;Please correct me if I'm wrong.]</div><div><br /></div><div>We'd like to create plots that are resizable -- not infinitely resizable -- but resizable in a few fixed increments. &nbsp;This means we create plots that are sometimes either more rectangular or more square than 4x3.</div><div><br /></div><div>The problem is that the Axis numbering does not handle a square aspect ratio well at all.</div><div><br /></div><div>The Axis numbers appear to scale off the *vertical* size of the plot window -- which in the case of a square-ish plot, causes the numbers to appear unnaturally large and often run into one another.</div><div><br /></div><div>Please see the following example of an identical plot scaled to two different aspect ratios (heights). &nbsp;Both plots are the same width, but the taller version creates enormous axis numbers that run into each other. &nbsp;http://imageshack.us/a/img259/5944/plotteraxisproblem.png</div><div>____________</div><div><br /></div><div>Is this a known issue, or are we perhaps not using the API correctly?</div><div><br /></div><div>If known, are there plans to fix this in an upcoming release?</div><div><br /></div><div>Or, are there any plans to include the ability to rotate the x-axis numbers 45 degrees (like gnuplot) to avoid issues like these?</div><div><br /></div><div>Thanks for any help,</div><div>RM</div><div><br /></div><div><br /></div></div>

Re: [Plplot-general] Should line width thinner than 1.0 be supported?

[Alan W. I. <ir...@be...>]

On 2013-01-28 17:18-0800 Alan W. Irwin wrote:

> On 2013-01-15 12:47+0800 Hǎiliàng Wáng wrote:
>
>> Hello,
>>
>> I'm plotting a small PDF graph (128x96) with cairopdf driver, and the
>> line width looks too thick with line width 1.
>>
>> To solve the problem, I modify the code within the cairo driver
>> (cairo.c) to set the the line width to 0.2 directly, and the result
>> looks pretty good.
>>
>> I have read the thread below so I know there is no plan to change
>> function plwid's parameter from int to float:
>> http://www.mail-archive.com/plp...@li.../msg00429.html
>
> Hi Hǎiliàng:
>
> "there is no plan to change" is a literally correct summation of what
> I said before, but I also emphasize now (if it wasn't clear before) I
> would like to see such a plan developed because integer widths for
> plwid are just too much of an API limitation these days.
>
> I think what we should do is deprecate plwid(PLINT width)
> and write a new function declared as
>
> void plwidth(PLFLT width);
>
> I will contine this discussion further on the PLplot development list.

Just to give everyone an update on this plplot-general list about the
results of that discussion on plplot-devel, the problem has been
almost entirely solved.  That solution involved touching a lot of
different files, and there are still some minor issues that need to be
polished up, but it is clear the next release of Plplot will have
floating point line widths.  So that is a big improvement on integer
line widths, and my thanks to Hǎiliàng for resurrecting the discussion
of this old issue and thus inspiring us to make the fix.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Should line width thinner than 1.0 be supported?

[Alan W. I. <ir...@be...>]

On 2013-01-15 12:47+0800 Hǎiliàng Wáng wrote:

> Hello,
>
> I'm plotting a small PDF graph (128x96) with cairopdf driver, and the
> line width looks too thick with line width 1.
>
> To solve the problem, I modify the code within the cairo driver
> (cairo.c) to set the the line width to 0.2 directly, and the result
> looks pretty good.
>
> I have read the thread below so I know there is no plan to change
> function plwid's parameter from int to float:
> http://www.mail-archive.com/plp...@li.../msg00429.html

Hi Hǎiliàng:

"there is no plan to change" is a literally correct summation of what
I said before, but I also emphasize now (if it wasn't clear before) I
would like to see such a plan developed because integer widths for
plwid are just too much of an API limitation these days.

I think what we should do is deprecate plwid(PLINT width)
and write a new function declared as

void plwidth(PLFLT width);

I will contine this discussion further on the PLplot development list.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] PG2PLplot updates

[Joseph W. <joe...@gm...>]

Just wanted to let people know that there have been a lot of additions
to PG2PLplot at

https://github.com/AstroFloyd/PG2PLplot

I was working on the stellar evolution code Mesa which uses pgplot,
and unfortunately the license would not allow for distribution of that
package on a linux distribution.  So I took the work that was already
there in PG2PLplot, and added enough new features so that it is now
drop in compatible for that project, and it has things like multiple
X11 windows and animation.

This hasn't been packaged into an RPM, but I have this on my TODO list.

[Plplot-general] Should line width thinner than 1.0 be supported?

[Hǎiliàng W. <hwa...@gm...>]

Hello,

I'm plotting a small PDF graph (128x96) with cairopdf driver, and the
line width looks too thick with line width 1.

To solve the problem, I modify the code within the cairo driver
(cairo.c) to set the the line width to 0.2 directly, and the result
looks pretty good.

I have read the thread below so I know there is no plan to change
function plwid's parameter from int to float:
http://www.mail-archive.com/plp...@li.../msg00429.html

I'm wondering if it is good idea to add another function to set the
line width with a ratio, e.g. void plwidr(double)? So that the real
line width becomes a product: linewidth*ratio. By default the ratio is
1.0 so it will not affect the current user, but if the user want finer
line width, just set linewidth=1 and the ratio any floating point
value they want.

Hailiang

Re: [Plplot-general] Closing a plot window.Device is qtwidget

[Owens, T. <Tho...@gt...>]

Arjun,

Try calling plspause(0) prior to plend().

Tom

From: Arjun Nadh [mailto:arj...@gm...]
Sent: Wednesday, January 09, 2013 4:30 AM
To: plp...@li...
Subject: [Plplot-general] Closing a plot window.Device is qtwidget

Hello all
            I use plplot with C in Ubuntu 12.04.
My program generates data at regular intervals.I want to plot them using qtwidget driver.
The problem I face is after plotting one set of data the program does not execute further.
plend() is called at the end,but still the window is not closed.
Is there any way to close this window and continue the execution of the code and again generate another plot
when the next dataset is ready?
Please help
Thanks in advance
Arjun

[Plplot-general] Closing a plot window.Device is qtwidget

[Arjun N. <arj...@gm...>]

Hello all
            I use plplot with C in Ubuntu 12.04.
My program generates data at regular intervals.I want to plot them using
qtwidget driver.

The problem I face is after plotting one set of data the program does not
execute further.
plend() is called at the end,but still the window is not closed.

Is there any way to close this window and continue the execution of the
code and again generate another plot
when the next dataset is ready?

Please help
Thanks in advance
Arjun

Re: [Plplot-general] pcolorbar and next PLplot release

[Andrew R. <and...@us...>]

We have now finalised the plcolorbar API and are in the processes of 
porting this to all our language bindings and examples. This has changed
since 5.9.9. Please take a look at the latest svn code to see the new API. 
Once the porting to all languages is done I would like us to make a new 
release fairly quickly. There are a number of other minor updates and bug 
fixes since the last release that it would be good to get into a proper 
release. I hope that this will be in the next month or two. Unfortunately 
several of our key developers have been busy with other projects / 
committments and that had slowed this work down.

Regards

Andrew

On Fri, Jan 04, 2013 at 12:16:05PM +0100, Jos? Luis Garc?a Pallero wrote:
> Hello:
> 
> I was user of PLplot about two years ago and the package was very
> helpful, specially the experimental (then) plcolorbar function.
> Probably I wil need again PLplot and plcolorbar. Surfing the Plplot
> page I see that the last release 5.9.9 if October 2011, i.e. more than
> a year ago. When is planned the next stable release 5.9.10 (or 6.0.0)?
> What is the status of plcolorbar? Is definitely stable? Is yet in
> 5.9.9?
> 
> Thanks
> 
> -- 
> *****************************************
> Jos? Luis Garc?a Pallero
> jgp...@gm...
> (o<
> / / \
> V_/_
> Use Debian GNU/Linux and enjoy!
> *****************************************
> 
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
> 

[Plplot-general] pcolorbar and next PLplot release

[José L. G. P. <jgp...@gm...>]

Hello:

I was user of PLplot about two years ago and the package was very
helpful, specially the experimental (then) plcolorbar function.
Probably I wil need again PLplot and plcolorbar. Surfing the Plplot
page I see that the last release 5.9.9 if October 2011, i.e. more than
a year ago. When is planned the next stable release 5.9.10 (or 6.0.0)?
What is the status of plcolorbar? Is definitely stable? Is yet in
5.9.9?

Thanks

-- 
*****************************************
José Luis García Pallero
jgp...@gm...
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

Re: [Plplot-general] can't run plplot with sbcl (wheezy debian)

[Hazen B. <hba...@ma...>]

On 12/19/2012 07:49 PM, gerard wrote:
> Hello,
> in the file system-examples.lisp I have : (defparameter gdev "svg")
>
> *
> (load "system-examples.lisp")
> T
>
> * (system-examples::plot )
> Enter graphics output file name: dessin2.svg
>
> *
> nothing happens : no error, no graphic

If you are using slime/sbcl, my guess is that the file "dessin2.svg" is 
being generated in the directory that emacs considers to be it's home 
directory which might not be your current directory. If you are just 
using sbcl, then there should be a file of that name created in the 
current directory.

> How can I make flplot run  correctly ?
>
> Thanks in advance for help or a link to an understandable tutorial.

I'm not aware of any tutorial, but cl-plplot functions are pretty much a 
one-to-one mapping onto the functions in the plplot API. Also in the 
same folder as the system-examples.lisp file there are cl-plplot 
examples that mirror the standard plplot examples. You can go to the 
plplot website, check the examples to find the type of plot you want, 
then look at the corresponding lisp example to see how to make such a plot.

-Hazen

[Plplot-general] can't run plplot with sbcl (wheezy debian)

[gerard <g.r...@fr...>]

Hello,
in the file system-examples.lisp I have : (defparameter gdev "svg")  

*
(load "system-examples.lisp") 
T

* (system-examples::plot )
Enter graphics output file name: dessin2.svg

*
nothing happens : no error, no graphic

How can I make flplot run  correctly ?

Thanks in advance for help or a link to an understandable tutorial.

Gerard

Re: [Plplot-general] Memory leaks in several plplot functions

[Andrew R. <and...@us...>]

On Fri, Nov 23, 2012 at 09:48:58AM -0800, Alan Irwin wrote:
> On 2012-11-23 12:13-0000 Andrew Ross wrote:
> 
> > Alan,
> >
> > This is odd, because there definitely seems to be a bug in the plplot
> > code path for plotting text. I've just fixed it now. This gave
> > problems for both pngcairo and pscairo for me.
> 
> That is odd indeed that the valgrind run for me for pngcairo was fine,
> but not for you.  However, I have just run the same two tests again
> with your change (at revision 12279)
> 
> valgrind examples/c/x02c -dev pngcairo -o test.png -fam
> valgrind examples/c/x02c -dev pngcairo -o test.png
> 
> and all continues to be well for me.  However, I still get
> valgrind problems with pscairo, e.g.,
> 
> software@raven> valgrind --num-callers=40 \
> examples/c/x02c -dev pscairo -o test.ps
> ==4666== Memcheck, a memory error detector
> ==4666== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==4666== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
> info
> ==4666== Command: examples/c/x02c -dev pscairo -o test.ps
> ==4666== 
> ==4666== Invalid read of size 4
> ==4666==    at 0x74E2145: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3742: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3C20: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x75109C9: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E09DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x7511067: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C6ACC: cairo_surface_finish (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74A1AD3: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C679C: cairo_surface_destroy (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x6E019A9: plD_tidy_cairo (in
> /home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
> ==4666==    by 0x4E4F0FE: c_plend1 (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x4E4F162: c_plend (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x400D8A: main (in
> /home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
> ==4666==  Address 0xb8280b8 is 8 bytes inside a block of size 11 alloc'd
> ==4666==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
> ==4666==    by 0x74E21F1: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3742: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E3C20: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x75109C9: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74E09DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x7511067: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C6ACC: cairo_surface_finish (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74A1AD3: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C668B: ??? (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x74C679C: cairo_surface_destroy (in
> /usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
> ==4666==    by 0x6E019A9: plD_tidy_cairo (in
> /home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
> ==4666==    by 0x4E4F0FE: c_plend1 (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x4E4F162: c_plend (in
> /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
> ==4666==    by 0x400D8A: main (in
> /home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
> ==4666== 
> ==4666== 
> ==4666== HEAP SUMMARY:
> ==4666==     in use at exit: 387,975 bytes in 2,703 blocks
> ==4666==   total heap usage: 19,606 allocs, 16,903 frees, 4,869,363
> bytes allocated
> ==4666== 
> ==4666== LEAK SUMMARY:
> ==4666==    definitely lost: 4,440 bytes in 8 blocks
> ==4666==    indirectly lost: 16,160 bytes in 503 blocks
> ==4666==      possibly lost: 56,513 bytes in 157 blocks
> ==4666==    still reachable: 310,862 bytes in 2,035 blocks
> ==4666==         suppressed: 0 bytes in 0 blocks
> ==4666== Rerun with --leak-check=full to see details of leaked memory
> ==4666== 
> ==4666== For counts of detected and suppressed errors, rerun with: -v
> ==4666== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
> 
> If you cannot replicate that, then presumably the update between my
> version (pango-1.30.0-1, cairo-1.12.2-2) and yours (or else an
> improved valgrind suppressions file in your case) solved this problem,
> and the issue is nothing for us to worry about.

Alan,

I don't see this warning at all. Instead, for both pscairo and pngcairo 
I see invalid reads inside pango_layout_get_pixel_size called from 
text_end_cairo. The block is allocated from within the same function. 
This, along with the fact you don't see the messages makes me suspect 
that this is a cairo / pango leak. I suspect yours is also a cairo 
related problem for similar reasons. It's just our different respective
versions have different problems!

There are still a number of smaller leaks in both our cases that may be 
worth some further checks by someone with a better grasp of cairo.

Andrew

Re: [Plplot-general] Memory leaks in several plplot functions

[Alan W. I. <ir...@be...>]

On 2012-11-23 12:13-0000 Andrew Ross wrote:

> Alan,
>
> This is odd, because there definitely seems to be a bug in the plplot
> code path for plotting text. I've just fixed it now. This gave
> problems for both pngcairo and pscairo for me.

That is odd indeed that the valgrind run for me for pngcairo was fine,
but not for you.  However, I have just run the same two tests again
with your change (at revision 12279)

valgrind examples/c/x02c -dev pngcairo -o test.png -fam
valgrind examples/c/x02c -dev pngcairo -o test.png

and all continues to be well for me.  However, I still get
valgrind problems with pscairo, e.g.,

software@raven> valgrind --num-callers=40 \
examples/c/x02c -dev pscairo -o test.ps
==4666== Memcheck, a memory error detector
==4666== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4666== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
info
==4666== Command: examples/c/x02c -dev pscairo -o test.ps
==4666== 
==4666== Invalid read of size 4
==4666==    at 0x74E2145: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3742: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3C20: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x75109C9: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E09DD: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x7511067: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C6ACC: cairo_surface_finish (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74A1AD3: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C679C: cairo_surface_destroy (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x6E019A9: plD_tidy_cairo (in
/home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
==4666==    by 0x4E4F0FE: c_plend1 (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x4E4F162: c_plend (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x400D8A: main (in
/home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
==4666==  Address 0xb8280b8 is 8 bytes inside a block of size 11 alloc'd
==4666==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==4666==    by 0x74E21F1: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3742: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E3C20: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x75109C9: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74E09DD: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x7511067: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C6ACC: cairo_surface_finish (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74A1AD3: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C668B: ??? (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x74C679C: cairo_surface_destroy (in
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11200.2)
==4666==    by 0x6E019A9: plD_tidy_cairo (in
/home/software/plplot_svn/HEAD/build_dir/drivers/cairo.so)
==4666==    by 0x4E4F0FE: c_plend1 (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x4E4F162: c_plend (in
/home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11.0.0)
==4666==    by 0x400D8A: main (in
/home/software/plplot_svn/HEAD/build_dir/examples/c/x02c)
==4666== 
==4666== 
==4666== HEAP SUMMARY:
==4666==     in use at exit: 387,975 bytes in 2,703 blocks
==4666==   total heap usage: 19,606 allocs, 16,903 frees, 4,869,363
bytes allocated
==4666== 
==4666== LEAK SUMMARY:
==4666==    definitely lost: 4,440 bytes in 8 blocks
==4666==    indirectly lost: 16,160 bytes in 503 blocks
==4666==      possibly lost: 56,513 bytes in 157 blocks
==4666==    still reachable: 310,862 bytes in 2,035 blocks
==4666==         suppressed: 0 bytes in 0 blocks
==4666== Rerun with --leak-check=full to see details of leaked memory
==4666== 
==4666== For counts of detected and suppressed errors, rerun with: -v
==4666== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)

If you cannot replicate that, then presumably the update between my
version (pango-1.30.0-1, cairo-1.12.2-2) and yours (or else an
improved valgrind suppressions file in your case) solved this problem,
and the issue is nothing for us to worry about.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________