plplot-devel — Technical discussion about PLplot development

[Plplot-devel] pythondemos.py and xw??.py

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

I have just finished the reorganization of the xw??.py demos.  They are now
no longer standalone scripts with install filtering (done via sed) and logic
to make each of them work on their own.  Instead, they have been changed to
modules which are imported into the pythondemos.py script.  That script is
the only one that is install-filtered now.

plplot-test.sh now indirectly runs pythondemos.py, and I have checked this
gives a good result (other than xw09.py which is commented out to avoid
the segfault problem) both in tmp and the install location.

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] PLPlot on MS Windows

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

On Fri, 9 Nov 2001, Alan W. Irwin wrote:

> Hello Olof:
>
> Our windows expertise is limited so we welcome any help we can get with the
> windows platform for plplot.  So thanks very much for your patches to the
> two files. They are isolated to the win32 directory and only a few lines so
> unless any expert here (which I don't pretend to be) sees a problem, I will
> put them into cvs.

I have thought better of immediately putting this patch into CVS.  The
current cvs version of PLplot is different from 5.0.4 in that a mechanism
has been introduced to allow dynamically loaded drivers.  The old static
method is still available as well, but I am not sure whether or not anything
extra will have to be done in the win32 tree to continue to use the static
method. Anyhow, Olof, would you be willing to try out the plplot cvs version
under w2k?  If the required changes to get it working are as simple as in
the 5.0.4 case, I will be happy to put those changes into the CVS version.
Such effort would be well worthwhile since I am planning to bring out a new
stable release of plplot in the near future based on the current CVS
version, and it would be nice for me to be able to state that you have
introduced changes to make it work under w2k.

To get the latest cvs version of plplot follow the anonymous cvs
instructions at http://sourceforge.net/cvs/?group_id=2915.  For the second
cvs command, "modulename" should be plplot.  The result will be a directory
tree called plplot in your current directory so make sure nothing in your
current directory is called plplot before you invoke that second command.

I am also most interested (for both 5.0.4 and the present cvs version) whether
you can build all the test plots using plplot-test.sh under w2k.

Alan

Re: [Plplot-devel] PLPlot on MS Windows

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

Hello Olof:

Our windows expertise is limited so we welcome any help we can get with the
windows platform for plplot.  So thanks very much for your patches to the
two files. They are isolated to the win32 directory and only a few lines so
unless any expert here (which I don't pretend to be) sees a problem, I will
put them into cvs.

It is great you got plplot-5.0.4 to work with w2k.  Can you build all the
plots in our test suite?  (Run plplot-test.sh --help to see the
possibilities.)

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
__________________________

On Fri, 9 Nov 2001, Olof Svensson wrote:

> Dear Alan,
>
> I'm working with Alessandro Mirone on the PyQt port of plplot.
> I'm trying to compile plplot version 5.0.4 on Windows 2000 using MS
> Visual Studio 6.0. I ran into several problems however I succeeded
> finally to build the package and use the win3 device. I have listed
> at the end of this message some of the patches I had to do to
> plplot.h in order to compile the plplot.lib win32 library (if you
> are interested I can provide a complete list of patches.)
>
> I'd like to know if the win32 port of plplot is still supported.
>
> Best regards,
>
> Olof Svensson
>
> --------------------------------------
> plplot-5.0.4, patch to plplot/sys/win32/msdev/src/plplot.h:
>
> < #define PLESC_DOUBLEBUFFERING 15      /* configure double buffering */
> < #define PLESC_XORMOD          16      /* jc: set xor mode */
> < #define PLESC_SET_COMPRESSION 17      /* AFR: set compression */
> < #define PLESC_CLEAR           18      /* RL: clear graphics region */
> < #define PLESC_DASH            19      /* RL: draw dashed line */
> < #define PLESC_HAS_TEXT                20      /* jc: driver draws text */
>
> < c_plshade(PLFLT **a, PLINT nx, PLINT ny, PLINT (*defined) (PLFLT, PLFLT),
> ---
> > c_plshade(PLFLT **a, PLINT nx, PLINT ny, const char **defined,
>
> < c_plshade1(PLFLT *a, PLINT nx, PLINT ny, PLINT (*defined) (PLFLT, PLFLT),
> ---
> > c_plshade1(PLFLT *a, PLINT nx, PLINT ny, const char *defined,
>
>
> patches to plplot/sys/win32/msdev/src/win3.cpp:
>
> <        wndclass.hbrBackground = (struct HBRUSH__ *)GetStockObject(WHITE_BRUSH);
> ---
> >        wndclass.hbrBackground = GetStockObject(WHITE_BRUSH);
>
> <                 if( SetAbortProc( dev->hdc, (int(__stdcall *)(struct HDC__ *,int))AbortProc ) ==
> SP_ERROR ) {
> ---
> >                 if( SetAbortProc( dev->hdc, (int(__stdcall *)(void))AbortProc ) == SP_ERROR ) {
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] PLPlot on MS Windows

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

Dear Alan,

I'm working with Alessandro Mirone on the PyQt port of plplot.
I'm trying to compile plplot version 5.0.4 on Windows 2000 using MS
Visual Studio 6.0. I ran into several problems however I succeeded
finally to build the package and use the win3 device. I have listed
at the end of this message some of the patches I had to do to 
plplot.h in order to compile the plplot.lib win32 library (if you
are interested I can provide a complete list of patches.)

I'd like to know if the win32 port of plplot is still supported.

Best regards,

Olof Svensson

--------------------------------------
plplot-5.0.4, patch to plplot/sys/win32/msdev/src/plplot.h:

< #define PLESC_DOUBLEBUFFERING 15      /* configure double buffering */
< #define PLESC_XORMOD          16      /* jc: set xor mode */
< #define PLESC_SET_COMPRESSION 17      /* AFR: set compression */
< #define PLESC_CLEAR           18      /* RL: clear graphics region */
< #define PLESC_DASH            19      /* RL: draw dashed line */
< #define PLESC_HAS_TEXT                20      /* jc: driver draws text */

< c_plshade(PLFLT **a, PLINT nx, PLINT ny, PLINT (*defined) (PLFLT, PLFLT),
---
> c_plshade(PLFLT **a, PLINT nx, PLINT ny, const char **defined,

< c_plshade1(PLFLT *a, PLINT nx, PLINT ny, PLINT (*defined) (PLFLT, PLFLT),
---
> c_plshade1(PLFLT *a, PLINT nx, PLINT ny, const char *defined,


patches to plplot/sys/win32/msdev/src/win3.cpp:

<        wndclass.hbrBackground = (struct HBRUSH__ *)GetStockObject(WHITE_BRUSH);
---
>        wndclass.hbrBackground = GetStockObject(WHITE_BRUSH);

<                 if( SetAbortProc( dev->hdc, (int(__stdcall *)(struct HDC__ *,int))AbortProc ) ==
SP_ERROR ) {
---
>                 if( SetAbortProc( dev->hdc, (int(__stdcall *)(void))AbortProc ) == SP_ERROR ) {

Re: [Plplot-devel] Task manager

[Joao C. <jca...@in...>]

On Thursday 25 October 2001 07:12, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
|  > On Thursday 25 October 2001 00:42, Geoffrey Furnish wrote:
|  > | I've added a task in the SF project page, for the Java binding
|  > | development, and dumped a few items into it which I think capture
|  > | the spirit of some of the recent discussion.
|  >
|  > Nice. But how can one add tasks or add items to a task? Only
|  > administrators can do it?
|
| Looks like only admins can add a new sub project.  I /assume/,
| although I have not tested, that any logged-in developer can add a
| task to a sub project (topical task list).  Click on the "java binding
| development" task list, and you should see a way to add a new task.
| If you want me to make you a new sub project to which you can
| associate tasks, let me know.  If developers who are not admins want
| admin privilege in order to reach some of this project tracking
| machinery, let me know.

Geoffrey/admins, it would be nice to add a task for each language binding=
s,=20
and another for the library itself (and another for drivers?). After a su=
rge=20
of work I had lots of e-mail to read, and lots of things will be forgoten=
!

Joao

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

[<jca...@in...>]

On Thursday 01 November 2001 23:37, Alan W. Irwin wrote:
=2E..
| P.S. Allesandro, in response to your plimage question, I cannot
| commit to anything at this time.  I would prefer to make sure the
| GUI base is fine (all license issues resolved and everybody happy
| with the configuration [which is a time-consuming issue, I am
| willing to work on]) and installed into CVS before even considering
| anything else.
|
| Alan

I must say that a plimage API is a recurrent demand from many Octave=20
and Plplot users, and I have made one attempt to naively implement=20
it. Now I don't have the time to evaluate Allesandro plimage, but it=20
is certainly welcome, and will not be forgot.

Joao

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

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

On Fri, 2 Nov 2001, Rafael Laboissiere wrote:

> To the best of my knowledge, the QT library is released under a dual
> license, both GPL and QPL, at the users choice, I remember vaguely that the
> QPL and the LGPL are claimed to be compatible (cannot remember where,
> probably in the mailing list debian-legal).  If it is true, this means
> that any LGPL product can be linked against QPL.  I may be wrong, though.

Thanks, Rafael for that reminder of the dual-license (GPL and QPL) for QT.
It turns out that solves everything without us having to change any of
our licensing for any of our programmes.

After some further research I found the LGPL-QPL compatibility question
asked on Debian legal
http://lists.debian.org/debian-legal/2000/debian-legal-200004/msg00005.html.
I found this via a google search so this is probably the most-linked
reference on this subject.

The two separate answers (that you can find in thread-next) are categorical
that there is no incompatibility between QPL and LGPL so it looks like we
are absolutely fine with regard to using this donated software under the
LGPL.  Maurice and Geoffrey were pretty smart when they picked the LGPL
for PLplot!

(The Debian-legal question also made some wishful prediction about pyqt
license that raised some warning flags with me, but I just checked the most
recent pyqt license, and I believe it is an MIT-X style license.  Anyhow,
the license is extremely short and understandable.  You are completely free
to do virtually anything with that software so our LGPL software links fine
with it as well.)

So I believe the original licensing concern I brought up has been completely
answered.

Alan

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

[Rafael L. <ra...@ic...>]

* Alan W. Irwin <ir...@be...> [2001-11-01 15:37]:      
      
> We have had a discussion fairly recently on this list about when the GPL
> would be required, and I was summarizing my recollection of what Rafael
> said.  But I may have it wrong, and the situation here is more complicated
> then the situation we were discussing before.  However, *something* is
> linked to QT in order to run the pyqt GUI since I must set LD_LIBRARY_PATH
> to point to where I have libqt located in order for your example to work.
> Thus, I think some minimal amount of stuff will have to be GPLed, but I am
> not sure of exactly what.  I don't have an axe to grind about GPL versus
> LGPL, but I do want to get this right so it does not come back to haunt
> us later.
>
> What do you think, Rafael?  (I suspect you don't have time to comment much
> so what is the fundamental principle I should follow here to decide
> what needs to be GPLed taking into account that some of the "linking" is
> simply a user choice to read in the source from some of the xw??.py demos.)

You are right, I am too busy right now, but since you mentioned my name in
public, I feel myself in the obligation to reply :-)

To the best of my knowledge, the QT library is released under a dual
license, both GPL and QPL, at the users choice, I remember vaguely that the
QPL and the LGPL are claimed to be compatible (cannot remember where,
probably in the mailing list debian-legal).  If it is true, this means
that any LGPL product can be linked against QPL.  I may be wrong, though.

--
Rafael

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

[Rafael L. <ra...@ic...>]

* Alan W. Irwin <ir...@be...> [2001-10-30 20:36]:

> [...] Certainly, I am happy if xw??.py are licensed this way. However, when
> I created those files, I edited a copy of the x??.py examples, which I
> think were originally created by Geoffrey.  Also Rafael made some
> contributions so I believe I need agreement with both Geoffrey and Rafael
> for this license change to the xw??.py examples.

IIRC, I contributed five lines or so.  That was the only piece of Python
code I ever wrote in my life.  I decline any intelectual property on that.
Do whatever you want with my "code".

-- 
Rafael

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

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

Thanks Allesandro, for your willingness to at least LGPL your donated
software.

We have had a discussion fairly recently on this list about when the GPL
would be required, and I was summarizing my recollection of what Rafael
said.  But I may have it wrong, and the situation here is more complicated
then the situation we were discussing before.  However, *something* is
linked to QT in order to run the pyqt GUI since I must set LD_LIBRARY_PATH
to point to where I have libqt located in order for your example to work.
Thus, I think some minimal amount of stuff will have to be GPLed, but I am
not sure of exactly what.  I don't have an axe to grind about GPL versus
LGPL, but I do want to get this right so it does not come back to haunt
us later.

What do you think, Rafael?  (I suspect you don't have time to comment much
so what is the fundamental principle I should follow here to decide
what needs to be GPLed taking into account that some of the "linking" is
simply a user choice to read in the source from some of the xw??.py demos.)

Alan

P.S. Allesandro, in response to your plimage question, I cannot commit to
anything at this time.  I would prefer to make sure the GUI base is fine
(all license issues resolved and everybody happy with the configuration
[which is a time-consuming issue, I am willing to work on]) and installed
into CVS before even considering anything else.

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
__________________________

On Thu, 1 Nov 2001, Alessandro Mirone wrote:

> Hello Alan,
>
> For me it's fine if you take my patches in plplot under LGPL.
> None of the changes  to plmodule.c need libqt and
> Libqt is just needed by pyqt if you want to run the new qplplot
> widget. On the other hand qplplot.py  is just a code that
> does not  not contain libqt, so I think that you can license it
> in the form that you prefer (LGPL).
>

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

[Alessandro M. <mi...@es...>]

Hello Alan,

For me it's fine if you take my patches in plplot under LGPL.
None of the changes  to plmodule.c need libqt and
Libqt is just needed by pyqt if you want to run the new qplplot
widget. On the other hand qplplot.py  is just a code that
does not  not contain libqt, so I think that you can license it
in the form that you prefer (LGPL).

I am happy that you like qplplot.py.
My group  (scientific software) and also our collegues
working in the  software group for data acquisition and processing at the 
Esrf ( european synchrotron) use a lot, and more and more, python.
We have a also  strong demand from the users for image analysys.
This is the reason why I and my collegues are so interested
in having  plimage.

If you agree I would like to submit to  your kind evaluation, in the next
weeks, small bunches of code ( as you suggested)  in order to implement
step by step a plimage that fits our needs and hopefully those
of the plplot community.

Best regards

     Alessandro Mirone

RE: [Plplot-devel] single<-->double

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

On Thu, 1 Nov 2001, Geoffrey Furnish wrote:

> Right, this is called overloading.
>
>  > Java sorts it out (I assume through the magic of OOP) into a call
>
> Overloading is accomplished through a technique known as "name
> mangling", whereby the compiler synthesizes the name of the function
> to be called from a combination of its given name, plus the number and
> types of the presented arguments.  Once the name is generated, the
> linker just has to hook up the name to the address of the function.

Thanks for that explanation.  I had heard of name mangling in the context
that g++ was having to deal with some name mangling issues for the
transition to 3.0, but this is the first time I have understood the purpose
of name mangling. One of the real pleasures of my participation in the
plplot project is it gives me a chance to greatly expand my programming
knowledge. I have always enjoyed learning new programming concepts, but only
if there was some practical focus, such as plplot, for that learning effort.

Alan

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

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

On Tue, 30 Oct 2001, Alan W. Irwin wrote:

> Note, example1 is a modification of xw03.py.  Ultimately, this
> should not go into CVS. Instead, I will put my thinking cap on to figure out
> how to make the required changes for all the xw??.py examples so they can be
> run either as scripts (probably called from a main script) or from the GUI.

To the plplot developers (and interested pyqt GUI developers):

I have just figured out what changes have to be made to our xw16.py example
to run it from the pyqt gui for plplot.  I assume these changes will work
for any of our xw??.py examples so that gives Allesandro a ton of examples
to show off.

(1) I have trimmed out everything until the line "def main():" The GUI only
needs main() (or whatever you want to call it) defined and does not need all
these preliminary imports.

(2) Remove the plParseOpts, plinit and plend commands within main.
The first is irrelevant, the second works, but bypasses the GUI, and the
third makes it impossible to re-run the example from the GUI.

With the above two changes, the modified xw16.py result looks good when
displayed by the GUI with one exception.  In the current primitive state of
the GUI there is no page control so all the pages run through without
stopping.  I assume page control is something that Allesandro will want to
address with high priority.

BTW, all these pages are built and displayed so rapidly that you can just
barely see them until the last one displays.  This is a reflection of the
building efficiency of Numeric and the display efficiency of pyqt and libqt.

But don't take my word for it.  See for yourself with any of our xw??.py
examples (after you make the recommend changes to your local copies
of xw??.py).

*******************

I would now like to move on to a related issue: how to organize the python
examples for the *non-GUI* case.  What I am thinking of is making the above
two changes for all the xw??.py examples, and renaming main in each case to
the appropriate name of the example (x01, etc).  Then I would create an
overall examples script called pythondemos.py which does the preliminary
required imports once (including all the examples), executes plParseOpts and
plinit once, executes all examples as python modules, then executes plend. I
also would do the necessary reconfiguration to make this new approach work
smoothly. This python module approach would make our python examples much
less cluttered for non-GUI testing.  Also, it makes the examples much easier
to work with for the current pyqt GUI case and potentially for a native
Tkinter GUI case.

Comments, please? Unless there are objections I plan to go ahead with this
reorganization fairly soon.

Alan

RE: [Plplot-devel] single<-->double

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

Alan W. Irwin writes:
 > On Wed, 31 Oct 2001, Geoffrey Furnish wrote:
 > 
 > > Also, I think the java binding is probably the only one that does the
 > > automatic float<-->double conversion thing.  I'm undecided about
 > > whether that is something we want in a compiled binding like C++, but
 > > I am pretty sure we /do/ want this kind of functionality for the
 > > script language bindings.  Not that "script language" is an accurate
 > > characterization of java, but you know what I mean.  OTOH, I haven't
 > > ever looked deeply at the Perl or Octave work, so perhaps there is
 > > coolness there that I don't even know about.
 > 
 > Could you summarize in one or two sentences how your treatment of
 > single-precision or double-precision java arguments relates to
 > object-oriented programming concepts such as classes, sub-classes,
 > instances, etc? 

I don't really think of it has having anything to do with OOP.  We're
just overloading each of the PLplot API calls with two versions, and
implmeenting them both.  One passes directly to the PLplot C call, the
other transforms its arguments to PLFLT and then makes the call.  This
fits easily enough in the realm of procedural thinking.

The only reall OO-ness in any of this, is the PLStream class.  Here I
do feel like a stream is the central object modelling concept for
wrapping the PLplot API.  Were PLplot itself implemented in C++, we'd
probalby also have abstract classes for things like devices, maybe
coordinate transformers, etc.

 > I am really new to these concepts (I only read the general
 > Java tutorial on OOP, yesterday, plus some of the equivalent part of my
 > python book) so I am trying to relate what you have done to my limited
 > knowledge of OOP.
 > 
 > Anyhow, the result is the java user can use the same name of plplot routine
 > regardless of type of argument and regardless of whether the back-end was
 > built --with-double or not.  

Right, this is called overloading.  

 > Java sorts it out (I assume through the magic of OOP) into a call

Overloading is accomplished through a technique known as "name
mangling", whereby the compiler synthesizes the name of the function
to be called from a combination of its given name, plus the number and
types of the presented arguments.  Once the name is generated, the
linker just has to hook up the name to the address of the function.  

 > to one of two versions of the function in javabind.c with either
 > single or double-precision arguments.  Once the appropriate version
 > is entered, the code handles the assignment (with appropriate cast
 > if needed) of the single (or double) precision quantities to PLFLT
 > quantities in a nice way.

Right.  It would actually be nice if we could support mixed types.
That is, in java the user calls PLStream.whatever() with any sort of
numeric type he's got, and then we sort it out on the other side.  You
can probably pull off something like that in Python, which is not
staticaly typed.  But for languages like C++ and Java, which are
staticaly typed, you're gonna have to write a separate overloading for
each combination you want to be allowable.  I choose two, one with all
floats, and one with all doubles.

Don't get me wrong.  I like static typing, and don't really like
dynamic typing.  Stroustrup's published arguments about the merits of
static typing hold a lot of weight with me.  But I'm just saying,
since Python is dynamically typed, it would be /possible/ to support a
totally flexible approach there.  I haven't really reviewed the Python
binding code (plmodule.c) lately, so maybe it already does this in
some cases.  I don't really remember clearly.  I seem to remember you
had to configure --with-double for the python binding, and that you
couldn't use float numpy arrays, but my memory on this point is foggy
at best.

 > Assuming this transparent (for the user) implementation of transforming
 > float or double arguments to PLFLT depends to a certain extent on OOP, then
 > it would be natural as a *long-term* goal to use the same idea for the other
 > front-ends such as c++, python, and perl that also give access to OOP.  I

It's na overloading thing.

Yeah, I think I agree.  The argument seems strong for these VHLL's
like Python, Perl, even Java (dunno if it qualifies stictly as a VHLL,
but it sure ain't C++ no matter what the hypists say).

In the case of C++, you're dealling with a language environment that
/can/ be very computationaly efficient (if you don't do idiotic things
in the C++ code).  So a silent buffering scheme might provide a
convenient binding, but be simultaneously annoying by virtue of
masking substantial performance sinks.  

What I would rather do in C++, is use templates to support floating
point type flexibility.  But to implement it right might mean
implementing large parts of the PLplot core library itself in C++.  

Left to myself, I'd convert all PLplot C files to C++ in a day.  But
previous discussions on the plplot mailing list over the years made it
clear this was an unpopular notion.  Sufficiently unpopular to
threaten PLplot's market share.  So I've never pursued it.  I think
the reality is that somehow we have to think of a C++ binding as a
"wraper" around the C PLplot API, pretty much like we do with Java
now. 

The current C++ binding falls short of this.  Maybe after we have the
Java binding in good shape, we could revisit how to spiff up the C++
binding. 

 > don't know whether octave allows OOP.  Yorick certainly doesn't so yplot
 > only works with the double-precision version of the PLplot library.

Without having looked, I would still expect that it would be possible
for the yorick wrappers to do something like the buffering scheme
currently exhibited in javabind.c, so that yorick could be hooked up
to a libplplot even if it was the float version.

-- 
Geoffrey Furnish         fu...@ga...

RE: [Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

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

On Wed, 31 Oct 2001, Geoffrey Furnish wrote:

>  > [Alan said] (I also inadvertently changed back the CVS version of PLStream.c so
>  > it refers to the single-precision library, but I will probably
>  > leave that as is until Geoffrey fixes the configuration.)
>
> Hopefully what I have just committed will be adequate.  Let me know
> how it serves you.

Works great!  Thanks, Geoffrey, for dealing with this.

Alan

[Plplot-devel] single<-->double

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

On Wed, 31 Oct 2001, Geoffrey Furnish wrote:

> Also, I think the java binding is probably the only one that does the
> automatic float<-->double conversion thing.  I'm undecided about
> whether that is something we want in a compiled binding like C++, but
> I am pretty sure we /do/ want this kind of functionality for the
> script language bindings.  Not that "script language" is an accurate
> characterization of java, but you know what I mean.  OTOH, I haven't
> ever looked deeply at the Perl or Octave work, so perhaps there is
> coolness there that I don't even know about.

Could you summarize in one or two sentences how your treatment of
single-precision or double-precision java arguments relates to
object-oriented programming concepts such as classes, sub-classes,
instances, etc? I am really new to these concepts (I only read the general
Java tutorial on OOP, yesterday, plus some of the equivalent part of my
python book) so I am trying to relate what you have done to my limited
knowledge of OOP.

Anyhow, the result is the java user can use the same name of plplot routine
regardless of type of argument and regardless of whether the back-end was
built --with-double or not.  Java sorts it out (I assume through the magic
of OOP) into a call to one of two versions of the function in javabind.c
with either single or double-precision arguments.  Once the appropriate
version is entered, the code handles the assignment (with appropriate cast
if needed) of the single (or double) precision quantities to PLFLT
quantities in a nice way.

Assuming this transparent (for the user) implementation of transforming
float or double arguments to PLFLT depends to a certain extent on OOP, then
it would be natural as a *long-term* goal to use the same idea for the other
front-ends such as c++, python, and perl that also give access to OOP.  I
don't know whether octave allows OOP.  Yorick certainly doesn't so yplot
only works with the double-precision version of the PLplot library.

Alan

RE: [Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

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

Just winking in for a moment, in an otherwise massively out of control
week.

Alan W. Irwin writes:
 > On Tue, 30 Oct 2001, Alan W. Irwin wrote:
 > 
 > > There does seem to be one java bug for the single-precison back end which
 > > needs further investigation. For the double-precision back end, x01 gives
 > > gives identical good results to the double-precision C example, but for the
 > > single-precision back end the java example badly screws up the placement of
 > > the line symbols.
 > 
 > I found the bug in javabind.c and fixed it in CVS.  

Thanks.

 > x01 for java now gives identical results to x01c regardless of
 > whether single-precision or double-precison is configured for the
 > PLplot back end.

Thanks for noticing the problem, and for all th testing you have been doing.

 > (I also inadvertently changed back the CVS version of PLStream.c so
 > it refers to the single-precision library, but I will probably
 > leave that as is until Geoffrey fixes the configuration.)

Hopefully what I have just committed will be adequate.  Let me know
how it serves you.

 > So aside from that one configuration issue, I am happy with the java
 > frontend codebase we now have both for single and double precision.
 > 
 > To follow up on this nice achievement lead by Geoffrey, I will concentrate
 > on implementing x09, x12, x13, x15, x16, and x18 in that order.  Once
 > Geoffrey has done the additional API binding required by those examples, the
 > java front end will actually be better off than the current python front end
 > (which does not have the 15th example implemented yet and which currently
 > segfaults for the 9th example).

Also, I think the java binding is probably the only one that does the
automatic float<-->double conversion thing.  I'm undecided about
whether that is something we want in a compiled binding like C++, but
I am pretty sure we /do/ want this kind of functionality for the
script language bindings.  Not that "script language" is an accurate
characterization of java, but you know what I mean.  OTOH, I haven't
ever looked deeply at the Perl or Octave work, so perhaps there is
coolness there that I don't even know about.

Anyway, lest anyone get consumed by anticipation, there is still a
/lot/ of work to do on the Java binding.  Many many API function
wrappers remain to be implemented.

But we're certainly getting there, and thanks again to Alan for
helping out.

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

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

On Tue, 30 Oct 2001, Alan W. Irwin wrote:

> There does seem to be one java bug for the single-precison back end which
> needs further investigation. For the double-precision back end, x01 gives
> gives identical good results to the double-precision C example, but for the
> single-precision back end the java example badly screws up the placement of
> the line symbols.

I found the bug in javabind.c and fixed it in CVS.  x01 for java now gives
identical results to x01c regardless of whether single-precision or
double-precison is configured for the PLplot back end.  (I also
inadvertently changed back the CVS version of PLStream.c so it refers to the
single-precision library, but I will probably leave that as is until
Geoffrey fixes the configuration.)

So aside from that one configuration issue, I am happy with the java
frontend codebase we now have both for single and double precision.

To follow up on this nice achievement lead by Geoffrey, I will concentrate
on implementing x09, x12, x13, x15, x16, and x18 in that order.  Once
Geoffrey has done the additional API binding required by those examples, the
java front end will actually be better off than the current python front end
(which does not have the 15th example implemented yet and which currently
segfaults for the 9th example).

Alan

Re: [Plplot-devel] quick bug fix for postscript driver?

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > BTW, for those who have not had a look, the patch Joao pointed out is just a
 > one-line change.  I am not a driver expert so I am hesitant to apply it.
 > But I feel it is important for the overall health of the plplot project and
 > our sanity to give small changes like this high priority because then our
 > ToDo lists don't get bogged down with zillions of petty details. Thus, would
 > some driver expert here take a quick look at this and either apply it or not
 > so we can close the bug?

Done.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

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

To Alessandro and the plplot development team:

With a relatively small amount of work, I got sip and pyqt installed, and
after that getting the pyqt plplot gui to work without problems was
extremely easy.  (See notes at the end).  Thanks very much for your help,
Alessandro. The only change to existing plplot files is to plmodules.c where
no existing function is changed and 3 additional functions to control the
gui are patched in by the patch. All the rest is handled by the magic of
dynamic loading.

As you can see from the edited comments below, two python source files are
required to run the gui. In addition, there are the current plmodule.c
changes which ultimately, I think should be separated from plmodules.c. That
separated source file could then be compiled into a separate shared object
that was loaded independently from plmodule.so by the application (See
license comments at the end.)

The relevant files are attached to this message if you want to play with
this gui.  Note, example1 is a modification of xw03.py.  Ultimately, this
should not go into CVS. Instead, I will put my thinking cap on to figure out
how to make the required changes for all the xw??.py examples so they can be
run either as scripts (probably called from a main script) or from the GUI.

I am sure there is lots more that can be done with the GUI, but even in its
present preliminary state, there is a source code window and plotting
window.  So you can enter python commands (or read them from a file and
subsequently edit them) in the source code window and run those commands to
see what the immediate effect on the plot will be.  Once you are satisfied
you would currently have to use cut and paste to output the results to a
file, but I am sure file output can easily be added as one of the GUI
features.

Anyhow, this preliminary GUI result seems quite promising to me, and
I hope other members of the plplot development team will evaluate it
as well.

LICENSING: This must be discussed because we don't want any licensing
uncertainties or incompatibilities.  libqt is GPLed.  The way KDE handles
this is their libraries and applications that are independent of qt are
LGPLed and everything else is GPLed.  If we follow a similar approach, I
believe there is a way to do it so that only the xw??.py example scripts
(assuming I modify them to use the pyqt GUI) would have to be switched from
LGPL to GPL.  For example, libplplot remains completely independent of qt so
it retains its current LGPL status. From a functional perspective the add-on
gui functions should probably be separated from plmodules.c in any case, and
that way plmodules.c can retain its LGPL license since it also won't depend
on qt. Thus, I propose that we ultimately separate out the current
plmodules.c add-ons in the patch to plmodules.c and assign a GPL license to
that separated C code.  (The qplplot.py and prova.py files must also be
GPLed.) Will you confirm you are in agreement with this GPL licensing
approach, Allesandro? (I am asking you this because I presume you are the
principal copyright holder of these plmodules.c add-ons and the added python
files, but if not, please make sure the question gets answered by the
copyright holder, and please inform me of who the copyright holder is.) That
of course means the xw??.py applications that will actually use the add-on
GUI shared object and libqt must also be GPLed. Certainly, I am happy if
xw??.py are licensed this way. However, when I created those files, I
edited a copy of the x??.py examples, which I think were originally
created by Geoffrey.  Also Rafael made some contributions so I believe I
need agreement with both Geoffrey and Rafael for this license change to the
xw??.py examples.

Aside from the xw??.py license question, we also need to discuss our
willingness to accept GPLed code (so long as it is done in a way that is
legally acceptable and which does not force us to change our other licenses)
into the plplot project. I think with some care (as is employed, e.g., in
the KDE project) our principal LGPL licensed material and these GPLed
add-ons can live peaceably and legally together.  I am willing to take that
licensing care by doing the configuration and programming work so the
current plmodules.c add-ons are separated into their own GPLed C code file
which gets compiled to a separate shared object file.

I am most impressed by the promising start for this pyqt GUI and hope to see
it as part of PLplot.  Let me know what you think of the GUI and also the
licensing issues (if I have failed to cover any aspect of 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
__________________________

On Tue, 30 Oct 2001, Alessandro Mirone wrote (shortend by AWI and edited
for what he used.)

> hello Alan,
> I used --with-double,
> and specified --with-python=/our/non/trivial/location.
> Double libs are necessary for Numeric to work without any problem
> of typecasting.

> About qt:
> --------------
> I use libqt 2.3.1, and  my version of python is 2.0.1.
>
> You get PyQt-2.5.tar.gz and sip-2.5.tar.gz from
> http://www.thekompany.com/projects/pykde/download.php3
>
> you need the pyqt version that matches your qt, and you must have
> the qt headers installed.

>
> Sip is mandatory. Sip has to be compiled first
> ----------------------------------------------
> You get sip options by
> ./configure --help
> You have to specify the good path to qt directories.
>
>
> The PyQt compilation follows the usual configure path
> -----------------------------------------------------
> specifying the variables with_sip_includes,  with_sip_libraries  and
> with_qt_dir
> or passing them as options to configure should be enough
>
>
> TESTING
> ---------------
>  I compiled the patched version, put qplplot.py, prova.py  and example1
> in the tmp/ melting pot directory where everything gets compiled.
> Then you can test by
> python prova.py
> You can then popup the file menu, choose example1, and run it

[Plplot-devel] java example precision changes and results

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

I made the following precision changes to all implemented java examples
where appropriate:

I have used the java-defined constant Math.PI instead of defining a
low-precision local PI or using inverse trig functions to get PI.  I found
this solution in the very helpful and detailed java tutorial at
http://java.sun.com/docs/books/tutorial/java/index.html.

All float --> double

Drop f suffix on numerical constants (e.g., 1.0f --> 1.0).  According to
the tutorial, floating point numbers without a suffix are interpreted as
double just like as in C.  The f suffix forces the constant to be single
precision which is exactly what we don't want.

The reason for these changes is to extirpate low-precison (as in PI) or
single precision for the reason (noted before) of getting more consistent
comparisons between demos on different machines.  In this case, the machine
is mixed; on the front end we have the JVM which we are comparing with gcc
results generated on ix86 for the C front end.  However, the back end
(libplplot) is identical for both front-end cases.

With these changes, all java examples other than the following noted
exceptions now give identical postscript results to the equivalent C
examples when double precision is configured for the back end.

x03: If I commented out the two plptex calls in the C and java code I got
identical results.  If you don't comment out these calls, you will visually
notice the "270" label produced by plptex is slightly different (different
pixelization).  So there is likely some floating-point logic in the
calculations that go into drawing the characters (in fact such logic must be
there by necessity, I believe). Thus, for characters at just the right
coordinates, the slightest change in those floating-point coordinates can
make a pixelization change in the the way the character is rendered.

x05: diff shows a minor discrepancy between the two plots which visually,
under high magnification seems to correspond to one more column of pixels in
the "l" in "probability" (at the top of the plot).  This x05 label
discrepancy might have a similar cause (floating-point logic in the
pixelization of the drawn characters) as the x03 label problem.

I have also done the comparisons between java and C front-end results using
the single-precision back end.  (To be clear about what I did, I did a make
clean, ./configure and make for both single and double precision with the
only configure difference being --with-double.  I also had to change the
name of the library appropriately in PLStream.java.) Since double-precision
is forced in both front-ends, and you are using the same (single-precision)
back-end in both cases, you would expect discrepancies between the java and
C results to be as small when single-precision is configured as for the case
when double-precison is configured.  This expectation seems to be confirmed
by the following results:

x03: similar discrepancy as in double-precision case.

x05: No discrepancy  in this case in contrast to double-precison case.

x08: shows a minor but opposite discrepancy to x05.  The double precision
versions are identical, but the single-precision versions differ slightly.

There does seem to be one java bug for the single-precison back end which
needs further investigation. For the double-precision back end, x01 gives
gives identical good results to the double-precision C example, but for the
single-precision back end the java example badly screws up the placement of
the line symbols.

So the current status of the java front end is that x01 through x11 (except
for x09) are done.  For these implemented examples, there is one clear bug
noted above that shows up in x01 for the single-precison back end.  Also the
plplot library name has to be configured in PLStream.java. Otherwise, we are
in pretty good shape with exact agreement in results with the C examples or
else for the few minor character-drawing discrepancies that do occur we have
a reasonable explanation.

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] cvs activity

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

To address the issue of how well the java examples produce identical results
to the C examples, it is important to have double precision.  Thus, I have
just committed the change to PLStream.java to use libplplotd rather than
libplplot.  This is just a temporary convenience for my tests and will
presumably be superseded by Geoffrey's eventual configuration change to deal
with this issue.

I have just changed x08.java and x11.java following the casts from integer
in the C code (see comments below in the context of Geoffrey's comments).
The result is these java examples now produce identical results to x08c and
x11c.  This means that at least for this subset of the java plplot API, it
appears with-double is working.

Now I have these two java examples giving consistent results with the C
examples, I intend to sytematically check all java example results against
their C example counterparts.

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
__________________________

On Fri, 26 Oct 2001, Geoffrey Furnish wrote:

> I confess to finding such matters
> confusing in the C case.  What does the C (double) cast do?  Is that
> an integer division the result of which is then cast to double?

That's my understanding.

> In
> which case I wouldn't expect hte abscissa to be smooth.

I agree they are not completely smooth, but the degree of non-smoothness is
so low it does not detract from the plot.

> Think you can figure it out?

Done, see above.

Alan

Re: [Plplot-devel] plplot versus old JDK's

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

The "." syntax works fine under jdk-1.2.2 so I think you have found a way to
refer to packages that works from JDK 1.1.7 onward.  Great!

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
__________________________

On Sat, 27 Oct 2001, Geoffrey Furnish wrote:

> Turns out I have JDK 1.1.7 on my home machine (way old, RH60).  I have
> been able to build plplot with java support, and run the demos.  I had
> to make one tiddly change in sysloc.in to find the jni_md.h file,
> which I will commit.  Beyond that, the only difficulty was that I had
> to change from:
>    java plplo/examples/x01
> to
>    java plplot.examples.x01

Re: [Plplot-devel] Plplot embedded in pyqt + plimage function

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

Hello Alessandro:

Thanks very much for this interesting contribution.  There has been some
debate here (perhaps that is an understatement) about how to obtain a widget
under python, and apparently you have managed to do it under pyqt.  So I am
most interested in what you have done, but I am going to need some
additional help from you to get this working on my system because I am still
in the middle of learning python, and I have never tried pyqt (although I
saw a recent book about it that was downloadable from the web).

So will you please do the following to help me get started:

(1) Get your changes working with the latest plplot from cvs.  The current
plplot is almost as stable as 5.0.4, a fair amount of new functionality has
been added, and I don't have time right now to try to understand your
changes in enough detail to port them (where necessary) to the latest
plplot. Note to obtain the latest plplot from CVS, follow the anonymous cvs
access directions at http://sourceforge.net/cvs/?group_id=2915.  The
modulename is plplot.  So the last direction translates to

cvs -z3 \
-d:pserver:ano...@cv...:/cvsroot/plplot \
checkout plplot

This will create a directory plplot, and fill it with the directory tree
corresponding to the latest plplot.

(2) Make a clean recursive patch of your changes once you have got them to
work with the latest plplot.  (I looked at the organization of your recent
patch, and I would like to see some changes to that organization.) There are
many ways to do a clean recursive patch, but here is what I recommend:

cp the latest plplot tree that you just downloaded from cvs twice.
cp -a plplot plplot_working
cp -a plplot plplot_patched

You do not touch plplot in any way to keep it as a reference. In
plplot_working you make and test all your changes.  This will add lots of
files that you don't want in your patch.  However, any changes to an
existing file in plplot you copy to the plplot_patched tree, and any new
source files that you want to be part of your patch you copy to the
plplot_patched tree.

diff -Nar -U 5 plplot plplot_patched  > plplot_patch

I use -U 5 rather -u so that plenty of context is given.

IMPORTANT: Look at your recursive patch, plplot_patch, to review all the
changes you have made and to make sure no additional files have gotten into it
that you don't want.

Once I have access to your plplot_patch (e-mailing it to me as an attachment
should be fine) I should be able to apply it to the existing latest tree
from cvs with no muss or fuss with all new files in the directories where
you want them to go.  Put some thought into which directories (or which new
directories) you use for the new files in plplot_patched. Once I get your
changes working, we may want to change locations of files, but it would be
nice if you found good places for them right from the start following what
has already been done for python.

(2) IMPORTANT.  It is important to incorporate new software in as small
chunks as possible to make it more easy for our group to evaluate the
changes.  So for now, in the interests of having your patch accepted, please
exclude *all* changes having to do with plimage.  So for every difference
that appears in the patch, ask the question is this *absolutely necessary*
to get the basic widget to work? Once we sort out any problems associated
with getting the widget to work, then a second patch to implement plimage
should be evaluted on its own merits.

(3) I need a cookbook of how to get this new widget to work.  What version
of libqt?  (I have 2.3.1.) What version of python?  (I have access both to
1.5.2 and 2.0.1, but my Numeric module [version 20.1.0] is for 2.0.1.) What
version of pyqt?  (pyqt is not accessible as a regular Debian package,
AFAIK, so what version, so where should I download your favorite version?)
What plplot ./configure options do you use?  Once you have run make, what
are all the remaining steps you do to get your examples working (excluding
examples, such as example3, which use plimage).  In addition, what changes
have to be made (if any) to the existing xw??.py examples to get them to
work with the new widget.?

Thanks in advance for the additional work I have requested.  But once I have
a clean recursive patch from you against the latest plplot (*excluding
everything to do with plimage for now*), and a cookbook of exactly
what to do to run some examples, I will be most interested in further
evaluation of your work.  It sounds promising, and thanks very much
for the effort you have already put into this.

I would be willing to look at the plimage stuff much later once we get
the basic pyqt widget patch evaluated.

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
__________________________

On Mon, 29 Oct 2001, Alessandro Mirone wrote:

> Hi,
>  I have posted the following into the patch
> pages on sourceforge :
> -----------------------------------------------------------
>
> By exporting few more xwin basic functions
> it is possible to obtain a qplplot widget
> embedded into pyqt WITHOUT recompiling pyqt ;).
>
>
> I put here the patch. It contains a patch
> for plplot and the qplplot.py module that
> extends pyqt
>
> By the way... the plplot patch also contains
> a plimage new function. it is accelerated
> for the xwin driver.
>
> You can discard it if you dont like it
> but I think that it is useful.
> The other drivers are slow with plimage
> but I hope someone could write the analogous
> to make it fast.
>
> Also the qplplot.py needs volonteers to
> be ported to windows... any volonteer?
>
> Best regards Alessandro Mirone
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Plplot embedded in pyqt + plimage function

[Alessandro M. <mi...@es...>]

Hi,
 I have posted the following into the patch
pages on sourceforge :
-----------------------------------------------------------

By exporting few more xwin basic functions
it is possible to obtain a qplplot widget
embedded into pyqt WITHOUT recompiling pyqt ;).


I put here the patch. It contains a patch
for plplot and the qplplot.py module that 
extends pyqt

By the way... the plplot patch also contains
a plimage new function. it is accelerated
for the xwin driver.

You can discard it if you dont like it
but I think that it is useful. 
The other drivers are slow with plimage
but I hope someone could write the analogous
to make it fast.

Also the qplplot.py needs volonteers to 
be ported to windows... any volonteer?

Best regards Alessandro Mirone