plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Fw: Obtain Co-ordiantes

[Rayal <ra...@da...>]

Hi,

I am using Plplot5.1.0 for Tcl/Tk 8.4 on Windows NT. I am trying to plot =
real
time data using plplot. My requirement is, when an User clicks on the =
plot, I
should be able to show (x, y) values of that point ?

Does anybody have an idea how this can be done using tcl-tk and plplot =
library?

Thanks.

-Rayal

RE: [Plplot-devel] Plans for the release

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Does a short official pre-release period with wide advertising seem
 > reasonable?

Although I am woefully behind in my PLplot email, my answer to this is
"absolutely yes".

[Plplot-devel] Plans for the release

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

Now I have had a chance to relax after the AT effort, I have been thinking
about the timing of the forthcoming release.  The conclusion I have drawn is
there is just so much in the current CVS HEAD (both new features and
important bug fixes) that our users will greatly appreciate compared to
PLplot-5.1.0, that it is really important to get this release out as soon
as possible.  Thus, I think we should forgo worrying about most of the
minor issues that I have detailed in PROBLEMS.  That really just leaves
two issues:

* More cross-platform testing required especially for platforms with tcl/tk.

* Fix the -dev tk problem.

Once those two are addressed I will want to move fast for the reasons above.
So any help you can give on either issue would be most appreciated.

While discussing the situation with Joao, he has come up with an excellent
idea; we have a short pre-release period (after the two issues above are
dealt with since we don't want to embarrass ourselves) where we invite our
users to try everything they can to find bugs in the new plplot.  I think we
would get a lot of tests if we widely advertised this pre-release period
(which I assume would be a week), and it is all great publicity for PLplot.
Also, I think there should be a prize of Maurice and Geoffrey taking the guy
who finds the most bugs out to dinner....;-)

Does a short official pre-release period with wide advertising seem
reasonable?

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] Linux (Debian potato, Debian woody, and SuSe), Solaris, and OSF1 are all looking good with the new configuration scheme

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

On Wed, 11 Dec 2002, Alan W. Irwin wrote:

> All is not perfect for OSF1 (but it is pretty close....;-))
> [...] For dynamic drivers there is only one issue, namely, a
> change has to be made in the name of the dynamic drivers that are produced
> on OSF1.

That issue has now been fixed so OSF1 is now officially perfect except for
expected problems with c++ and octave associated with the gcc-3.0 compiler
that Joao is stuck with on that particular platform.

That concludes my OSF1 effort.

I also just generated a test tarball from cvs checkout and running
.bootstrap.sh.  I tried that tarball on two computers at the SourceForge
compile farm, and the results were good.

An old Debian potato computer there builds (with dynamic drivers) and runs
plplot-test.sh (the complete test of all available examples with the default
psc device) fine with the tarball approach.  Same for a solaris computer.
Both computers are limited to just the c, c++, and f77 interfaces.  I didn't
bother trying a static driver build on either computer, but I am sure it
would be fine.  I have run both a dynamic driver build and a static driver
build on my home Debian woody system, and Joao has done the same on the OSF1
system available to him and on his own SuSe system so all signs are looking
good....

Time for the next person to step forward with a test of our new
configuration system either on their own Linux system of any Unix system
that is available to them.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Re: driver-dependent options

[<jc...@fe...>]

On Thursday 12 December 2002 17:27, Joachim Wuttke wrote:
| Now I really need your help:
|
|    plSetOpt("drvopt", "<name>=3D<value>");
|
| works only once. If I use it a second time to transmit
| a second driver-dependent option, I obtain nonsense
| values.
|
| Who is able to disentangle the option-setting mechanism
| (and to propose me an ad-hoc solution...) ???
|
| Btw a fundamental question: do we really want the drvopt
| keyword ? As far as I see, there are also driver-dependent
| options (e.g. for X windows) in what is now formally the
| driver-independent section preceeding that keyword.

The drvopt option was an atempt to give some order to a multitude of=20
driver dependant options. What matters to a postscript user to know the=20
tk, xwin, png, tex or other drivers options?
I only didn't remove those driver dependent options from the comon=20
options for "compatibility" reasons, but I was very tempted to do it...

Anyway there are also *program* dependent options, so why not driver=20
dependent options?

Usage:
        lt-x01c [options]

x01c options:
    -locate              Turns on test of API locate function
    -xor                 Turns on test of XOR
    -font number         Selects stroke font set (0 or 1, def:1)
    -save filename       Save plot in color postscript `file'

Make sure you get it right!

PLplot options:
 *  -showall             Turns on invisible options
    -h                   Print out this message
    -v                   Print out the PLplot library version number
    -verbose             Be more verbose than usual
    -debug               Print debugging info (implies -verbose)
 *  -hack                Enable driver-specific hack(s)
<--------------
    -dev name            Output device name
    -o name              Output filename
    -display name        X server to contact
<--------------
    -px number           Plots per page in x
    -py number           Plots per page in y
    -geometry geom       Window size, in pixels (e.g. -geometry 400x300)=20
<--------------
 *  -geo geom            Window size, in pixels (e.g. -geo 400x300)
    -wplt xl,yl,xr,yr    Relative coordinates [0-1] of window into plot
    -mar margin          Margin space in relative coordinates (0 to 0.5,=20
def 0)
    -a aspect            Page aspect ratio (def: same as output device)
    -jx justx            Page justification in x (-0.5 to 0.5, def 0)
    -jy justy            Page justification in y (-0.5 to 0.5, def 0)
    -ori orient          Plot orientation=20
(0,1,2,3=3Dlandscape,portrait,seascape,u
pside-down)
    -freeaspect          Allow aspect ratio to adjust to orientation=20
swaps
    -portrait            Sets portrait mode (both orientation and aspect=20
ratio)
    -width width         Sets pen width (0 <=3D width)
    -bg color            Background color (0=3Dblack, FFFFFF=3Dwhite)
    -ncol0 n             Number of colors to allocate in cmap 0 (upper=20
bound)
    -ncol1 n             Number of colors to allocate in cmap 1 (upper=20
bound)
    -fam                 Create a family of output files
    -fsiz size[kKmMgG]   Output family file size (e.g. -fsiz 0.5G, def=20
MB)
    -fbeg number         First family member number on output
    -finc number         Increment between family members
    -fflen length        Family member number minimum field width
    -nopixmap            Don't use pixmaps in X-based drivers=20
<--------------
    -db                  Double buffer X window output
<--------------
    -np                  No pause between pages
 *  -bufmax              bytes sent before flushing output
    -server_name name    Main window name of PLplot server (tk driver)
<--------------
    -server_host name    Host to run PLplot server on (dp driver)
<--------------
    -server_port name    Port to talk to PLplot server on (dp driver)
<--------------
    -user name           User name on remote node (dp driver)
<--------------
 *  -plserver name       Invoked name of PLplot server (tk or dp driver)
<--------------
 *  -plwindow name       Name of PLplot container window (tk or dp
<-------------- driver)
 *  -tcl_cmd command     TCL command string run at startup (note:
<-------------- disabled)
 *  -auto_path dir       Additional directory(s) to autoload (tk or dp
<-------------- driver)
 *  -tk_file file        file for plserver (tk or dp driver)
<--------------
    -dpi dpi             Resolution, in dots per inch (e.g. -dpi=20
360x360)
    -compression num     Sets compression level in supporting devices
<--------------
    -drvopt option[=3Dvalue][,option[=3Dvalue]]* Driver specific options

All parameters must be white-space delimited. =20
Some options are driver dependent.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Please see the PLplot reference document for more detail.


At this pace, one would get the one million options award :)

Joao

|
| Joachim
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:
| With Great Power, Comes Great Responsibility
| Learn to use your power at OSDN's High Performance Computing Channel
| http://hpc.devchannel.org/
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Re: driver-dependent options

[<jc...@fe...>]

On Thursday 12 December 2002 17:40, Joachim Wuttke wrote:
| Well, for almost every problem there is some clue somewhere
| in the source code ... in the present case in plargs.c in
| the comment to opt_drvopt(). The solution is: use only one
| call of
|     plSetOpt("drvopt", "<name>=3D<value>[,<name>=3D<value>]");
|
| It works, but it is one more undocumented feature, and you
| certainly agree that a clean solution should look otherwise.

As I told, The original intention was to setup up options once before=20
plinit(), as if set from the cmd line.
To change driver behaviour after plinit(), then

/* Escape function, for driver-specific commands. */

void
plP_esc(PLINT op, void *ptr)

should be used.

Joao

|
| - Joachim
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:
| With Great Power, Comes Great Responsibility
| Learn to use your power at OSDN's High Performance Computing Channel
| http://hpc.devchannel.org/
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plParseDrvOpts

[<jc...@fe...>]

On Thursday 12 December 2002 16:35, Joachim Wuttke wrote:
| As far as I see, the variables to be set by plParseDrvOpts
| need to be declared as static globals, which would be nice
| to avoid ...

The problem is that some options that one might want to setup must be=20
set before plinit(), and at that point the driver does not yet=20
"exists". That's why in most (all?) drivers it is at the driver open=20
entry point that the driver options are scanned. But perhaps that could=20
be changed... I don't remember very well.

Joao

| - Joachim

[Plplot-devel] Re: driver-dependent options

[Joachim W. <wu...@cr...>]

Well, for almost every problem there is some clue somewhere
in the source code ... in the present case in plargs.c in=20
the comment to opt_drvopt(). The solution is: use only one
call of=20
    plSetOpt("drvopt", "<name>=3D<value>[,<name>=3D<value>]");

It works, but it is one more undocumented feature, and you
certainly agree that a clean solution should look otherwise.

- Joachim
=20

[Plplot-devel] Re: driver-dependent options

[Joachim W. <wu...@cr...>]

Now I really need your help:

   plSetOpt("drvopt", "<name>=3D<value>");

works only once. If I use it a second time to transmit
a second driver-dependent option, I obtain nonsense
values.

Who is able to disentangle the option-setting mechanism
(and to propose me an ad-hoc solution...) ???

Btw a fundamental question: do we really want the drvopt
keyword ? As far as I see, there are also driver-dependent
options (e.g. for X windows) in what is now formally the
driver-independent section preceeding that keyword.

Joachim

[Plplot-devel] plParseDrvOpts

[Joachim W. <wu...@cr...>]

As far as I see, the variables to be set by plParseDrvOpts
need to be declared as static globals, which would be nice
to avoid ...
- Joachim

[Plplot-devel] Re: driver-dependent options

[Joachim W. <wu...@cr...>]

> > The W2000 driver has the option "hwnd" which takes
> > as argument a pointer to a HWND handle. To use
> > this, one has to convert the pointer through
> > something like sprintf(drvopt_arg, "hwnd=3D%x", m_hwnd)
> > to a string.

It works! Note however one error in my previous mailing:
we need "%d", not "%x", because the back conversion will
also be done assuming decimal representation of integers.

> You mean using plSetOpt() to do it? I'm afraid I don't follow you.
> Why don't you just write an API entry (and submit it), say=20
> plDrvOpt("<option_name", "<value>")?

Sorry, Joao, I won't do it because the whole option passing
mechanism is terribly complicated; someone who understands
the whole structure of plcore, plargs &c. could do it in a
fraction of the time I would need.

- Joachim

[Plplot-devel] OSF1 is looking pretty good with the new configuration scheme

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

Joao reported to me just now that the new configuration scheme works pretty
well both with static and dynamic drivers on his OSF1 system!

uname -a
OSF1 alf.fe.up.pt V4.0 1091 alpha

Previously, I had made sure the new configuration scheme worked for an
extremely limited solaris system on the SourceForge compile farm, but it
is really nice to see other good results start coming in as well.

All is not perfect for OSF1 (but it is pretty close....;-)) There are some
OSF1 issues with octave that Joao is still working on.  Also, g++-3.0.x on
OSF1 doesn't work very well with our c++ front end (but that compiler
version is notorious so we expect that).  There are no known issues with
static drivers.  For dynamic drivers there is only one issue, namely, a
change has to be made in the name of the dynamic drivers that are produced
on OSF1.  ("lib" is prefixed to the name, and that screws everything up.) I
am still looking at the most natural way to fix that since there was no such
problem for the dynamic drivers produced in either the Linux or solaris
cases.  Such renaming issues are bread and butter to libltdl so I am sure
there is an easy solution without fooling around with a bunch of mv commands
just for the OSF1 platform, but I have to find what that natural solution
is.

Anyhow, I am extremely pleased with Joao's hard work in iterating through a
fairly large number of rounds of OSF1 tests for me while I made the easy
changes that his tests showed were necessary to the various Makefile.am
files.  Together we have solved many common cross-platform issues so the
next round of testing on a new platform should be much easier.  Who is going
to be the next volunteer?

Even trying the new configuration scheme on a variety of Linux platforms
and/or with a variety of options would be most helpful.

Finally, my autoconf skills are virtually nil so there is also some work to
do in configure.ac and associated files to smooth out the warnings and get
rid of other glitches in the way that the configuration options are
processed.  Help in that area would be most appreciated!

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

On Wed, 11 Dec 2002, Joao Cardoso wrote:

> In that case, a pllib_end() makes sense! Symmetry is something I like (I'm a
> physicist...).
> >From your description, pllib_end should release the memory allocated by
> pllib_init. And plend should call pllib_end, as plinit calls pllib_init.
>
> Sure. knowing that a pllib_end() exists will encourage us to not loose the
> track of allocated memory.
>
> > So has a consensus been reached here to use plend for this library memory
> > release task with appropriate plend =>plend1 adjustments to the x octave
> > scripts?
>
> OK. But don't you want to accept my idea of a pllib_end()?

That sounds fine to me.

For now, I have reactivated what I did to release libltdl memory in plend,
and changed your octave x examples (plend ==> plend1) so they still work.  I
encourage you to follow up on that with implementing the pllib_end idea.  I
prefer you to do that aspect since I always seem to have trouble creating
new C functions correctly.  Also, you will probably want to set a flag
in pllib_end so that any attempt to call plinit afterward fails gracefully
rather than just crashing because the memory resources are gone.

Obviously, this is just the start of pllib_end.  I encourage those who are
familiar with the dynamic driver's memory allocation to release it properly
in pllib_end to respond to the bug report that Joao mentioned in a later
e-mail as well as to get a clean bill of health from valgrind.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Makefile for DLL submitted as a patch

[<jc...@fe...>]

On Wednesday 11 December 2002 07:38, Joachim Wuttke wrote:
| Hi Olof, and whoever might help us in testing:
|
| I exported a makefile from Visual Studio, and
| submitted it as a patch

FYI, Joachim as posted the patch in the patch section of=20
http://sourceforge.net/projects/plplot

Joao

> not with the intention
| to have it included as is into the distribution,
| but in order to make it available to you for
| further experimenting.
|
| Please let me know if the information given in
| my previous mails is not sufficient to assemble
| a working DLL.
|
| Regards, Joachim
=20

[Plplot-devel] multiple plinit/plend, memory leak

[<jc...@fe...>]

Hi,

It seems that nobody uses the sf facilities. In our project page, bugs,=20
I saw the following:

[ 636689 ] multiple plinit/plend, memory leak

Date:
2002-11-11 09:15 Priority:
5
Submitted By:
Nobody/Anonymous (nobody) Assigned To:
Nobody/Anonymous (nobody)
Category:
None Status:
Open
Summary:
multiple plinit/plend, memory leak
i called plinit()/plend() multiple times from different program points
and got some problems with options and memory leaks.

It
seems that plend does not free all all the allocated memory, I could
track some leaks to opt_drvopt and plInitDispatchTable, and that
the static variables are not reset properly.

Is there some
way to fix this?

[Plplot-devel] Makefile for DLL submitted as a patch

[Joachim W. <wu...@cr...>]

Hi Olof, and whoever might help us in testing:

I exported a makefile from Visual Studio, and
submitted it as a patch: not with the intention
to have it included as is into the distribution,
but in order to make it available to you for
further experimenting.

Please let me know if the information given in
my previous mails is not sufficient to assemble
a working DLL.

Regards, Joachim

Re: [Plplot-devel] problems with plSetOpt: driver-dependent options; no-pause mode under MSWindows

[Joao C. <jc...@fe...>]

On Tuesday 10 December 2002 14:10, Joachim Wuttke wrote:
> Since plSetOpt is not yet documented in the
> on-line reference, here a clue:
> For generic options, use
>     plSetOpt("<option_name>", "<argument>"),
> e.g.
>     plSetOpt("np", "").
> For driver-specific options, in contrast, use
>     plSetOpt("drvopt", "<option_name>=3D<argument>"),
> e.g.
>     plSetOpt("drvopt", "color=3D0").

Amazing! Since I introduced the drvopt cmd line option that I had the=20
intention to provide an API entry to do the same. And it already existed!=
 Not=20
with a clean syntax, tough!

> The W2000 driver has the option "hwnd" which takes
> as argument a pointer to a HWND handle. To use
> this, one has to convert the pointer through
> something like sprintf(drvopt_arg, "hwnd=3D%x", m_hwnd)
> to a string; I doubt whether this has ever been
> tested. A more sensible way to influence the
> plot window from the main application would be
> to pass a number of individual parameters like
> xpos, xwidth, title, ... Is there any convention
> I should follow in introducing such parameters ?

You mean using plSetOpt() to do it? I'm afraid I don't follow you.
Why don't you just write an API entry (and submit it), say=20
plDrvOpt("<option_name", "<value>")?
Ah, "value" must be a string, as different options can ask for different=20
types, ints, floats or strings... this was done in a ugly way when I=20
implemented the drvopt, but I see no other way.

> The option "np" has hitherto been ineffective in
> the Win binding. To correct this, it might be
> sufficient to chnge one line in win3.cpp into
>    dev->nextPlot =3D pls->nopause;

Yes, this is the way interactive drivers work. The plplot core routines e=
ither=20
advance the page or ask the user to hit a key/mouse click, depending on t=
he=20
value of pls->nopause, that can be set/reset using plspause(). Try it and=
=20
submit a patch!

Joao
>
> - Joachim
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

[Joao C. <jc...@fe...>]

On Tuesday 10 December 2002 21:42, Alan W. Irwin wrote:
> On Tue, 10 Dec 2002, Joao Cardoso wrote:
=2E..
> > Also, our library does not has a specific entry point to initialize i=
t,
> > and thus it doesn't make much sense to have one to finish using it.
>
> Maurice set this up some time ago.  It has not been well advertised so =
I
> will mention the details again.  plinit (which every initialization of
> plplot must go through) calls pllib_init.  The first call to pllib_init
> initializes the library including memory for the dynamic driver
> infrastructure as well as the memory for libltdl.  Thus, it makes sense=
 to
> have a function (the very last call to libplplot) which releases the me=
mory
> that was allocated as part of the library initialization

In that case, a pllib_end() makes sense! Symmetry is something I like (I'=
m a=20
physicist...).
=46rom your description, pllib_end should release the memory allocated by=
=20
pllib_init. And plend should call pllib_end, as plinit calls pllib_init. =
=20

> > This is a difficult problem to solve, releasing all allocated memory.=
 For
> > example, when one use strdup(), or our plstrdup() version, we might l=
ost
> > the track of the allocated memory -- that's why valgrind reports
> > "definitively lost fragments"
>
> Yes, you would have to be careful.  But a start is to at least release
> the libltdl memory which is easy to do.

Sure. knowing that a pllib_end() exists will encourage us to not loose th=
e=20
track of allocated memory.

> So has a consensus been reached here to use plend for this library memo=
ry
> release task with appropriate plend =3D>plend1 adjustments to the x oct=
ave
> scripts?

OK. But don't you want to accept my idea of a pllib_end()?
I will only commit my changes after AT stabilizes.

Joao

>
> Alan

Re: [Plplot-devel] breakthrough in porting plplot to MS Windows:DLL generated

[Olof S. <sve...@es...>]

Hi Alan,

I've indeed been in contact with Joachim however I have a hard time to
keep up with him because of work priorities. I think that Joachim's
development is very valuable and I'll help him make a patch.

Regards,

Olof
 

"Alan W. Irwin" wrote:
> 
> Olof, I encourage you to come to a consensus with Joachim on the best way to
> further develop the windows port.  After that, I would be happy to apply any
> patches that were necessary.
> 
> Alan
> 
> email: ir...@be...
> phone: 250-727-2902     FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
> 
> Linux-powered astrophysics
> __________________________
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

On Tue, 10 Dec 2002, Joao Cardoso wrote:

> > Actually, with sunos, memory had to be specifically released by the
> > programme.
>
> Hard to believe! sunos is unix. Unless you are talking of shared memory, as in
> that case the shared memory will stay (usable by other processes) in the
> system, even when the program who allocate it exits. It must be explicitly
> released.

I was probably talking about shared memory.....(with my further questions
about this carried on privately).

> > My own feeling is not too many of our users currently use the
> > plinit/plend/plinit sequence so it wouldn't be too much of a burden to ask
> > them to shift to plinit/plend1/plinit. But if this really is too much of a
> > burden, we also have the option of adding another function (pllibfree?)
>
> remember to not polute the API. We should be carefull with this issue. I think
> that plinit/plend1 will be fine.

Good.

> Also, our library does not has a specific entry point to initialize it, and
> thus it doesn't make much sense to have one to finish using it.

Maurice set this up some time ago.  It has not been well advertised so I
will mention the details again.  plinit (which every initialization of
plplot must go through) calls pllib_init.  The first call to pllib_init
initializes the library including memory for the dynamic driver
infrastructure as well as the memory for libltdl.  Thus, it makes sense to
have a function (the very last call to libplplot) which releases the memory
that was allocated as part of the library initialization

> This is a difficult problem to solve, releasing all allocated memory. For
> example, when one use strdup(), or our plstrdup() version, we might lost the
> track of the allocated memory -- that's why valgrind reports "definitively
> lost fragments"

Yes, you would have to be careful.  But a start is to at least release
the libltdl memory which is easy to do.

So has a consensus been reached here to use plend for this library memory
release task with appropriate plend =>plend1 adjustments to the x octave
scripts?

Alan

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

[Joao C. <jc...@fe...>]

On Tuesday 10 December 2002 16:43, Alan W. Irwin wrote:
> On Tue, 10 Dec 2002, Joao Cardoso wrote:
> > [...]The problem is an user program finish doing a plot,
> > and thus closing the plot using plend(). Latter on, in the same progr=
am,
> > another plot is needed, thus plinit() is again called.
> > The x??c examples all finish with plend(), thus the octave counterpar=
ts
> > also do the same. But *one* instance of Octave wants to run *all* x??=
c
> > demos, thus the several plinit/plend.
> >
> > I often do that in Octave, closing a plot figure, opening another, ..=
=2E
> > and all users of interactive languages certainly do the same. Of cour=
se,
> > I could use plinit/plend1(),
>
> I woke up this morning with this same idea.
>
> Maurice, would that work (if the interactive user always stuck with ple=
nd1
> and never called plend)?

Actually, if the Octave users use the script functions in plplot_octave, =
i.e.,=20
if they use figure() to open a new plot window and closefigure() to close=
 it,=20
then they will be using plinit/plend1. Only if they call closeallfig() th=
en=20
plend() will be called.
And, yet, when figure() is called, I register closeallfig() with atexit()=
,=20
thus efectively calling plend() when Octave exits!
Thus I have done it right from the beginning, back in 98.

The x??c issue is different, as I wanted to mimic the most exactly possib=
le=20
the c examples. I can replace plend with plend1 without problems. What ot=
hers=20
front-ends do when emulating x??c?

>  I assumed it would even with default stream 0,
> but you introduced the interesting topic of stream 0 class versus strea=
m >0
> instance, and now I don't know whether that is a separate issue or
> not....;-)
>
> > I never bother releasing memory that will be relased anyway by the OS
> > when a program finish. At least in unix, when a program finish, the
> > memory owned by the program will be released.
>
> Actually, with sunos, memory had to be specifically released by the
> programme.

Hard to believe! sunos is unix. Unless you are talking of shared memory, =
as in=20
that case the shared memory will stay (usable by other processes) in the=20
system, even when the program who allocate it exits. It must be explicitl=
y=20
released.

> So if you killed the programme rather than normally exiting, you
> never got the memory back.  I had first-hand experience of this many ti=
mes
> in the first half of the 90's

I used shared memory back in 89/91, first in xenix, then on sco-unix. Whe=
n I=20
worked in embedded system, I had to implement malloc/free from scratch,=20
functions that use sbrk(), that only extends the data segment of the prog=
ram,=20
segment which is naturally released when the program finish. This is why =
we=20
sometimes gets "segmentation violation", i.e., one is acessing memory fro=
m=20
other process segments (or the own process other segments).

But this is history, and I believe that other OSes (such as MS-ones ;-) d=
on't=20
work this way.

> and the only recourse was to reboot the
> system to get all the memory back if newbie users were making the mista=
ke
> of killing programmes rather than letting them normally exit.  Part of =
my
> prejudice against Unix (and love of Linux since it does release memory =
as
> you indicated) originates from those difficult days.  Hopefully not too
> many unices have inherited this memory misfeature from sunos.  But I kn=
ow
> of at least one of our users, who does not have the financial resources=
 to
> pay the solaris license fees, who still uses sunos!
>
> Assuming the plinit/plend1 sequence will work without ever calling plen=
d,
> then the user can simply use this sequence when it is impossible to pre=
dict
> when the last plot will occur. Then, plend could be strictly reserved f=
or
> situations where you *know* this is the last plot before exit if you ca=
re
> about cleaning up memory use and not relying on the OS to do it for you=
=2E
> (I believe this was the original intent from the way it is documented, =
see
> http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0=
=2E4.1
>/plend.html).
>
> My own feeling is not too many of our users currently use the
> plinit/plend/plinit sequence so it wouldn't be too much of a burden to =
ask
> them to shift to plinit/plend1/plinit. But if this really is too much o=
f a
> burden, we also have the option of adding another function (pllibfree?)

remember to not polute the API. We should be carefull with this issue. I =
think=20
that plinit/plend1 will be fine.
Also, our library does not has a specific entry point to initialize it, a=
nd=20
thus it doesn't make much sense to have one to finish using it.

> to
> our API to systematically free all the memory that was allocated when t=
he
> library was opened.

This is a difficult problem to solve, releasing all allocated memory. For=
=20
example, when one use strdup(), or our plstrdup() version, we might lost =
the=20
track of the allocated memory -- that's why valgrind reports "definitivel=
y=20
lost fragments", or somethink like that. Also, there are leaks in system=20
libraries, when you open a file, e.g.. Not to mention other libraries lea=
ks.=20
Well, not leaks. I only call something a leak when it is continuously=20
leaking, i.e. successively allocating more and more memory.

Joao

>  I would at least like to have such a function to use
> in our non-interactive example programmes. I don't care whether that
> function is called plend or something else like pllibfree so long as we
> have it.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] breakthrough in porting plplot to MS Windows: DLL generated

[Joao C. <jc...@fe...>]

On Tuesday 10 December 2002 13:41, Joachim Wuttke wrote:
> I succeeded in generating a shared library
> under Win2000 with Visual Studio C++ 6.0
> (as opposed to the static library generated
> by the makefiles of the current plplot
> distribution 5.1.0). This is certainly a
> breakthrough in making plplot acceptable
> for industrial applications.
>
> There was not one single clue to the problem:
> I just had to overcome a number of misunderstandings,
> and to change a very few lines in the code. I have
> still think about how to document my experiences.

Joachim, why don't you create a *minimum* (i.e., only essencial things) "=
diff=20
-c" of your changes against a fresh 5.1.0 release, apply them to a fresh=20
copy, see if it works as intended, and submit the patch?

Become a supporter/developper!

Be welcome,
Joao

>
> To start, I will answer some of the questions I posed
> in the course of the last ten days, and pose some new
> questions to the maintainers of plplot. To facilitate
> later search in the archive, I will break my feedback
> into a couple of short mailings. Stay tuned.
>
> - Joachim
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] breakthrough in porting plplot to MS Windows: DLL generated

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

Olof, I encourage you to come to a consensus with Joachim on the best way to
further develop the windows port.  After that, I would be happy to apply any
patches that were necessary.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

On Tue, 10 Dec 2002, Joao Cardoso wrote:

> [...]The problem is an user program finish doing a plot,
> and thus closing the plot using plend(). Latter on, in the same program,
> another plot is needed, thus plinit() is again called.
> The x??c examples all finish with plend(), thus the octave counterparts also
> do the same. But *one* instance of Octave wants to run *all* x??c demos, thus
> the several plinit/plend.
>
> I often do that in Octave, closing a plot figure, opening another, ... and all
> users of interactive languages certainly do the same. Of course, I could use
> plinit/plend1(),

I woke up this morning with this same idea.

Maurice, would that work (if the interactive user always stuck with plend1
and never called plend)?  I assumed it would even with default stream 0, but
you introduced the interesting topic of stream 0 class versus stream >0
instance, and now I don't know whether that is a separate issue or not....;-)

> I never bother releasing memory that will be relased anyway by the OS when a
> program finish. At least in unix, when a program finish, the memory owned by
> the program will be released.

Actually, with sunos, memory had to be specifically released by the
programme. So if you killed the programme rather than normally exiting, you
never got the memory back.  I had first-hand experience of this many times
in the first half of the 90's and the only recourse was to reboot the system
to get all the memory back if newbie users were making the mistake of
killing programmes rather than letting them normally exit.  Part of my
prejudice against Unix (and love of Linux since it does release memory as
you indicated) originates from those difficult days.  Hopefully not too many
unices have inherited this memory misfeature from sunos.  But I know of at
least one of our users, who does not have the financial resources to pay the
solaris license fees, who still uses sunos!

Assuming the plinit/plend1 sequence will work without ever calling plend,
then the user can simply use this sequence when it is impossible to predict
when the last plot will occur. Then, plend could be strictly reserved for
situations where you *know* this is the last plot before exit if you care
about cleaning up memory use and not relying on the OS to do it for you.
(I believe this was the original intent from the way it is documented, see
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.1/plend.html).

My own feeling is not too many of our users currently use the
plinit/plend/plinit sequence so it wouldn't be too much of a burden to ask
them to shift to plinit/plend1/plinit. But if this really is too much of a
burden, we also have the option of adding another function (pllibfree?) to
our API to systematically free all the memory that was allocated when the
library was opened.  I would at least like to have such a function to use in
our non-interactive example programmes. I don't care whether that function is
called plend or something else like pllibfree so long as we have it.

Alan

[Plplot-devel] Re: necessary modifications for building a DLL

[Joachim W. <wu...@cr...>]

Continuation:

one further essential modification for building a DLL
(with Settings->General->Use MFC in a shared DLL):

in the #include's in plconsole.cpp, plstub.cpp,=20
and win3.cpp we must replace windows.h and wincon.h
by afxwin.h.

- Joachim