plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] plimage

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

Joao Cardoso wrote:
>
> What about "plimage" for the new function and "plimagefe" (front end) for the
> current one? Or, if compatibility with PGPLOT is not mandatory, "plimages"
> (straight) for the new function? hum, this could be misleading, Pick your own
> names, I'm not concerned with that.

How about calling the existing function "plgridimage" and the new 
function "plimage"? You could even think of make it possible to pass 
the list of co-ordinates for the pixels (however I have no idea
if this would be useful or not...):

plimage(PLFLT *idata, PLINT nx, PLINT ny,
        PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
        PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)

plgridimage(PLFLT **idata, PLFLT *x, PLFLT *y, PLINT nx, PLINT ny,
            PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
            PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)

> Yesterday I though that plimage() structure was steady, but today I'm not
> certain of that. It looks like that it is not possible to save a displayed
> image in another format, opening another device and replaying the plot
> buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend1 way of saving
> plots).

I noticed a problem when resizing a plot with several subplots 
containing images - Alessandro and I solved this problem by saving 
and restoring the Dxmin etc parameters in plbuf_image and rdbuf_image. 
Here's the patch:

--- plplot/drivers/plbuf.c      Thu Jan 10 06:39:36 2002
+++ plplot_new/drivers/plbuf.c  Fri Jan 11 17:27:18 2002
@@ -230,6 +230,10 @@
     fwrite(pls->dev_ix, sizeof(PLINT), (pls->dev_nptsX)*(pls->dev_nptsY), pls->plbufFile);
     fwrite(pls->dev_iy, sizeof(PLINT), (pls->dev_nptsX)*(pls->dev_nptsY), pls->plbufFile);
     fwrite(pls->dev_z, sizeof(PLFLT), (pls->dev_nptsX-1)*(pls->dev_nptsY-1), pls->plbufFile);
+    fwrite(&pls->Dxmin, sizeof(PLINT), 1, pls->plbufFile);
+    fwrite(&pls->Dxmax, sizeof(PLINT), 1, pls->plbufFile);
+    fwrite(&pls->Dymin, sizeof(PLINT), 1, pls->plbufFile);
+    fwrite(&pls->Dymax, sizeof(PLINT), 1, pls->plbufFile);
 }
 
 /*--------------------------------------------------------------------------*\
@@ -553,6 +557,11 @@
     fread(dev_ix, sizeof(PLINT), npts, pls->plbufFile);
     fread(dev_iy, sizeof(PLINT), npts, pls->plbufFile);
     fread(dev_z, sizeof(PLFLT), (nptsX-1)*(nptsY-1), pls->plbufFile);
+
+    fread(&pls->Dxmin, sizeof(PLINT), 1, pls->plbufFile);
+    fread(&pls->Dxmax, sizeof(PLINT), 1, pls->plbufFile);
+    fread(&pls->Dymin, sizeof(PLINT), 1, pls->plbufFile);
+    fread(&pls->Dymax, sizeof(PLINT), 1, pls->plbufFile);
 
     plP_image(dev_ix, dev_iy, dev_z, nptsX, nptsY);
 
Maybe the problem you site above can be solved by the same patch.

> But the modifications should be minor, so you can start to code your
> modifications and send a patch.

Ok, if you agree on the naming and argument scheme above I'll start making a patch.

> PS-Did you see the current know bugs of plimage, described in a comment in
> x20c.c?

Well, (* blush *) I must admit that I read the code of x20c but skipped the 
comments (like a compiler). I'll look more carefully on the comments next time!

Regards,

Olof

Re: [Plplot-devel] Please try out xw09.py as a prototype for the rest of the front ends

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

On Thu, 10 Jan 2002, Joao Cardoso wrote:

> Hi,
>
> On Suse-7.2, with python-2.0, ./pythondemos.py, demo 9, with device xwin
> gives the following error after the "polar contour plot" (plot #7).
>
> Traceback (most recent call last):
>   File "./pythondemos.py", line 31, in ?
>     import xw09
>   File "/home/jcard/plplot-devel/tmp/xw09.py", line 277, in ?
>     main()
>   File "/home/jcard/plplot-devel/tmp/xw09.py", line 269, in main
>     potential()
>   File "/home/jcard/plplot-devel/tmp/xw09.py", line 117, in potential
>     clevelpos = compress(clevel > 0., clevel)
> TypeError: Comparison of multiarray objects other than rank-0 arrays is not
> implemented.

I am not going to worry about this one since such comparisons work great for
my version of numpy (20.1, brought out in September).  This version is part
of Debian woody because woody hadn't gone into freeze at that point.  I
think other distributions will also soon adopt numpy 20.1 (or even 20.2
which was brought out in December).  If you have further interest you could
download the latest versions of numpy from
http://sourceforge.net/projects/numpy.  Otherwise, just set clevpos = clevel
on your local machine to get around this non-implementation in your version
of numpy.

>
> Also, on xw05, it fails with error
>
> *** PLPLOT ERROR ***
> plcol0: Please call plinit first, aborting operation
>
> and lots of errors after that, ending with a seg. fault.
>
> xw01, xw02, xw03 and xw04 runs OK.
> I have not tried the other examples.

Thanks very much for spotting this one!  (I missed it because I did all my
recent tests with single examples.) It turned out that xw04.py (and also
x04.tcl) were terminated with plend.  As you discovered, this is not
appropriate for multiplot examples such as pythondemos.py (and
tcldemos.tcl).  I also had to get rid of a nameclash that I had introduced
recently between x04.tcl and x01.tcl proc names.  All changes have now been
committed, and I now get good results for pythondemos.py and tcldemos.tcl.
Could you check these scripts again, please, (by running plplot-test.tcl)
for my newly committed changes?  Thanks in advance....

Alan

Re: [Plplot-devel] Please try out xw09.py as a prototype for the rest of the front ends

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

On Tuesday 08 January 2002 3:58 am, Alan W. Irwin wrote:
> I have just finished the python front end example 9 according to my pla=
n of
> taking the union of all contour example pages.  I would appreciate you
> having a look at this example, because if you would like to see some
> changes it is easier to change this protype now rather than changing
> everything later after I have programmed the equivalent for the rest of=
 the
> front ends.
>
> For those who have not played with the python front-end to plplot, simp=
ly
> copy pythondemos.py to test.py, edit that file to remove all the exampl=
es
> except xw09, then
>
> ./test.py -dev psc - o test.ps; gv test.ps

Hi,

On Suse-7.2, with python-2.0, ./pythondemos.py, demo 9, with device xwin=20
gives the following error after the "polar contour plot" (plot #7).

Traceback (most recent call last):
  File "./pythondemos.py", line 31, in ?
    import xw09
  File "/home/jcard/plplot-devel/tmp/xw09.py", line 277, in ?
    main()
  File "/home/jcard/plplot-devel/tmp/xw09.py", line 269, in main
    potential()
  File "/home/jcard/plplot-devel/tmp/xw09.py", line 117, in potential
    clevelpos =3D compress(clevel > 0., clevel)
TypeError: Comparison of multiarray objects other than rank-0 arrays is n=
ot=20
implemented.

Also, on xw05, it fails with error

*** PLPLOT ERROR ***
plcol0: Please call plinit first, aborting operation

and lots of errors after that, ending with a seg. fault.

xw01, xw02, xw03 and xw04 runs OK.=20
I have not tried the other examples.

Joao

[jcard@feup] python
Python 2.0 (#1, May 16 2001, 00:02:45)=20
[GCC 2.95.3 20010315 (SuSE)] on linux2

Re: [Plplot-devel] plimage

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

On Thursday 10 January 2002 3:49 pm, Olof Svensson wrote:
> Joao Cardoso wrote:
> > > The best solution is probably to create a second entry point for
> > > passing an image as a PLFLT * pointer. There are two possibilities,
> > > either by using a flag telling plimage which type of pointer is pas=
sed
> > > (to avoid creation of unused arrays in the case of rectangular imag=
es)
> > > or by creating a new plplot image command.
> >
> > Perhaps the latter will be more user understandable. It could just se=
t a
> > variable in plstrm.h (that could be used  also by drivers), and call =
the
> > standard plimage().
>
> This sounds to us as a good idea - however, just a thought, since
> PLFLT * is used internally by plimage, wouldn't it be better to let the
> current version of plimage call the new function?

Yes, of course.

> (In fact, to be more compatible with PGPLOT

Is PLplot API compatible with PGPLOT? I didn't knew that. I knew that PLp=
lot=20
start after, or was inspired by, PGPLOT.

> the new function should be called plimage and the
> existing one should be renamed, however we have nothing against keeping
> the current version as plimage). Could you suggest a name for the new
> plimage function?

What about "plimage" for the new function and "plimagefe" (front end) for=
 the=20
current one? Or, if compatibility with PGPLOT is not mandatory, "plimages=
"=20
(straight) for the new function? hum, this could be misleading, Pick your=
 own=20
names, I'm not concerned with that.

Yesterday I though that plimage() structure was steady, but today I'm not=
=20
certain of that. It looks like that it is not possible to save a displaye=
d=20
image in another format, opening another device and replaying the plot=20
buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend1 way of savi=
ng=20
plots).
But the modifications should be minor, so you can start to code your=20
modifications and send a patch.

Bye,
Joao

PS-Did you see the current know bugs of plimage, described in a comment i=
n=20
x20c.c?

Re: [Plplot-devel] plimage

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

Joao Cardoso wrote:
> 
> > The best solution is probably to create a second entry point for passing
> > an image as a PLFLT * pointer. There are two possibilities, either by
> > using a flag telling plimage which type of pointer is passed (to avoid
> > creation of unused arrays in the case of rectangular images) or by
> > creating a new plplot image command.
> 
> Perhaps the latter will be more user understandable. It could just set a
> variable in plstrm.h (that could be used  also by drivers), and call the
> standard plimage().

This sounds to us as a good idea - however, just a thought, since 
PLFLT * is used internally by plimage, wouldn't it be better to let the
current version of plimage call the new function? (In fact, to be more
compatible with PGPLOT the new function should be called plimage and the
existing one should be renamed, however we have nothing against keeping
the current version as plimage). Could you suggest a name for the new
plimage function?
 
> > Maybe it is not a very important problem, but for some applications that
> > we plan to do in the future we would like to keep the possibility to
> > keep the PLESC commands.
> 
> OK, but probably I will changes their names, as I found the current ones too
> cryptic.

Fine with us!

Regards,

Olof

Re: [Plplot-devel] plimage

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

On Tuesday 08 January 2002 9:22 am, Olof Svensson wrote:
> Hi Jo=E3o,
>
> thanks for you answer! Now I understand better why you you need the
> pixel co-ordinates and I think your planned improvements of plimage
> sound great. I had a discussion with Alessandro this morning and we
> agreed on the following points:
>
> The best solution is probably to create a second entry point for passin=
g
> an image as a PLFLT * pointer. There are two possibilities, either by
> using a flag telling plimage which type of pointer is passed (to avoid
> creation of unused arrays in the case of rectangular images) or by
> creating a new plplot image command.

Perhaps the latter will be more user understandable. It could just set a=20
variable in plstrm.h (that could be used  also by drivers), and call the=20
standard plimage().

> Concerning plxormod, I made some tests with the xwin and win3 devices
> and found that everything works fine unless you resize the window
> between two selections. What happens is that since plxormod is turning
> the plbuf_write off the selection rectangle is not redisplayed when
> resizing the window, and when you make a new selection the program
> (x20c) retraces the old rectangle and it becomes visible. (In fact, wit=
h
> the xwin device the resizing of the window makes the image disappear
> completely, however the old selection reappears as on the win3 device).

There are other resize/redraw issues in the new xwin plimage implementati=
on.=20
The worse being that, as I now use XGetImage(), it fails if the plot wind=
ow=20
is not completely visible!

> Maybe it is not a very important problem, but for some applications tha=
t
> we plan to do in the future we would like to keep the possibility to
> keep the PLESC commands.

OK, but probably I will changes their names, as I found the current ones =
too=20
cryptic.

Jo=E3o

>
> Regards,
>
> Olof

Re: [Plplot-devel] sysloc.in patch for IBM J2RE 1.3.0 java

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

I agree with Geoffrey it looks fine, but please put a short comment in
about why you have to do this.  (e.g.,

# IBM java-1.3 JDK does not have linux or solaris subdirectories for
# java/include

.)

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, 8 Jan 2002, Joao Cardoso wrote:

>
> Hi,
>
> I enclose a patch that enables my IBM java-1.3 JDK to work with plplot. I
> don't commit it to CVS as I'm not sure about it's correctness. There is no
> subdirectory "linux" in the include subdir:
>
> bash-2.05# lc /usr/lib/java/include/
> jawt.h  jawt_md.h  jni.h  jni_md.h  jvmdi.h  jvmpi.h
>
>  bash-2.05# java -version
> java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
> Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled:
> itc))
>
> bash-2.05# rpm -qa | fgrep IBM
> IBMJava2-JRE-1.3-67
> IBMJava2-SDK-1.3-61
>
> Joao
>
>

RE: [Plplot-devel] sysloc.in patch for IBM J2RE 1.3.0 java

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

Joao Cardoso writes:
 > I enclose a patch that enables my IBM java-1.3 JDK to work with plplot. I 
 > don't commit it to CVS as I'm not sure about it's correctness. There is no 
 > subdirectory "linux" in the include subdir:

That looks pretty safe to me, I think you can go ahead and commit it.
I guess IBM's Linux jdk isn't really intended to be used on multiple
os's the way Sun's jdk is, so maybe that's why they drop the linux
subdir for the _md part.

[Plplot-devel] sysloc.in patch for IBM J2RE 1.3.0 java

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

Hi,

I enclose a patch that enables my IBM java-1.3 JDK to work with plplot. I=
=20
don't commit it to CVS as I'm not sure about it's correctness. There is n=
o=20
subdirectory "linux" in the include subdir:

bash-2.05# lc /usr/lib/java/include/
jawt.h  jawt_md.h  jni.h  jni_md.h  jvmdi.h  jvmpi.h

 bash-2.05# java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled=
: =20
itc))

bash-2.05# rpm -qa | fgrep IBM=20
IBMJava2-JRE-1.3-67
IBMJava2-SDK-1.3-61

Joao

Re: [Plplot-devel] plimage

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

Hi João,

thanks for you answer! Now I understand better why you you need the
pixel co-ordinates and I think your planned improvements of plimage
sound great. I had a discussion with Alessandro this morning and we
agreed on the following points:

The best solution is probably to create a second entry point for passing
an image as a PLFLT * pointer. There are two possibilities, either by
using a flag telling plimage which type of pointer is passed (to avoid
creation of unused arrays in the case of rectangular images) or by
creating a new plplot image command.

Concerning plxormod, I made some tests with the xwin and win3 devices
and found that everything works fine unless you resize the window
between two selections. What happens is that since plxormod is turning
the plbuf_write off the selection rectangle is not redisplayed when
resizing the window, and when you make a new selection the program
(x20c) retraces the old rectangle and it becomes visible. (In fact, with
the xwin device the resizing of the window makes the image disappear
completely, however the old selection reappears as on the win3 device).
Maybe it is not a very important problem, but for some applications that
we plan to do in the future we would like to keep the possibility to
keep the PLESC commands.

Regards,

Olof

[Plplot-devel] Please try out xw09.py as a prototype for the rest of the front ends

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

I have just finished the python front end example 9 according to my plan of
taking the union of all contour example pages.  I would appreciate you
having a look at this example, because if you would like to see some changes
it is easier to change this protype now rather than changing everything
later after I have programmed the equivalent for the rest of the front ends.

For those who have not played with the python front-end to plplot, simply
copy pythondemos.py to test.py, edit that file to remove all the examples
except xw09, then

./test.py -dev psc - o test.ps; gv test.ps

For those of you who have not played with the python Numerical module yet, I
think you will be amazed at the high-level array manipulation that is
demonstrated by xw09.py and which executes at C speed.  It was high-level
array manipulation (and lack of typing hassles) that first attracted me to
yplot (yorick front end to plplot) back in 1995, but my loyalties are
rapidly switching to the python/Numerical front end.  Although I plan to use
that front end to plplot for all my future research plots, I will, of
course, continue to maintain yplot since there is still a band of ~200 loyal
users for it.

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] plimage

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

On Mon, 7 Jan 2002, Olof Svensson wrote:

> Hi Jo=E3o,
> [...] However, before sending Alan the patch I'd like to make a
> couple of suggestions for plimage.

It would probably be better to send plimage patches to Joao directly since
he is the core developer with the most interest in this code.

Alan

Re: [Plplot-devel] plimage

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

On Monday 07 January 2002 2:58 pm, Olof Svensson wrote:
> Hi Jo=E3o,
>
> I have started to work on making the Windows plplot device win3 a fast
> image device. I can now run the x20c example on Windows and the device
> is fast. However, before sending Alan the patch I'd like to make a
> couple of suggestions for plimage. I have discussed these suggestions
> with Alessandro and he have no objections.
>
> My primary concern about the current implementation of plimage is use o=
f
> memory. Here at the ESRF we would like to use plimage to plot relativel=
y
> large images, i.e. up to 2000 x 2000 pixels. One can do this with the
> current implementation however it uses a lot of memory and the bufferin=
g
> of the image takes quite some time. In order to solve this problem I
> have the following two suggestions:
>
> 1. I'd like to remove the two arrays containing the X and Y co-ordinate=
s
> for every pixel. From what I can see in the code these arrays are not
> yet used - please correct me if I'm wrong.

Yes, they are not yet used, but they will be used when making rotations. =
As a=20
matter of fact I'm ready to commit changes to plimage/plcore/xwin that=20
implement rotations and translations. I'm hesitating, as the solution is =
not=20
100% correct for all situations. And, as you say bellow, this could be ma=
de=20
by another function.

> If I understood Alessandro
> right the idea was that these arrays could be used to plot 2D data that
> were not on a regular grid.

That is on my todo list: a plgrid() function that receives irregularly=20
sampled data and returns grided data.

> I understand that this is desirable in some
> circumstances, I have myself worked with correcting 2D detector data fo=
r
> spatial distortion. However, I think it is wrong to delegate this task
> to plimage. I believe that it is better to have this code outside
> plimage, e.g. to have a function that accepts as arguments the image an=
d
> the co-ordinates for each pixel and then creates a new image which can
> be sent to plimage.

I agree, but that is the standard way of PLplot to do it.

> 2. I'd also like to go back to having the possibility of sending an
> image as a PLFLT * instead as a PLFLT **. I understand that it is easy
> to handle 2D data with plplot in the PLFLT ** format. However, large
> images are most conveniently stored as PLFLT * in C. Using a PLFLT *
> pointer has the advantage that it can be passed directly to a fast imag=
e
> device, thus avoiding allocating memory. This pointer could also be
> saved by plbuf_image instead of saving the whole image. (A solution
> could be to add a new plimage function in plplot. The "old" plimage
> could still be used with the PLFLT ** argument. The "new" plimage could
> accept a PLFLT * argument and not allocate any extra memory, except
> needed by the fast image device.)
>
> What do you think?

I think that it is OK to have an alternate API entry point to plimage() t=
hat=20
uses PLFLT*. As a matter of fact plimage() alreay uses it internally.

As for the X/Y arrays I'm not sure what the better solution is; I have al=
so=20
considered to use a row/column vector to store the pixels coordinates, bu=
t=20
abandomned it when implementing rotations.

As for your large 2000x2000 images, it could be possible to accelerate th=
e=20
driver, not performing fills and just ploting the point. But at 100dpi yo=
u=20
need a 20x20 inch monitor to display the image, so some kind of=20
under-sampling will be necessary, I think.

To Alessandro: have you managed to use plxormod(), so I can drop the=20
PLESC_IMAGEOPS?

To the list: should we consider plimage() so specific to not implement=20
difilt() rotations/translations on it? Remember that plimage() can be use=
d in=20
place of plshade() for big arrays.

Joao

>
> Regards,
>
> Olof
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] plimage

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

Hi João,

I have started to work on making the Windows plplot device win3 a fast
image device. I can now run the x20c example on Windows and the device
is fast. However, before sending Alan the patch I'd like to make a
couple of suggestions for plimage. I have discussed these suggestions
with Alessandro and he have no objections.

My primary concern about the current implementation of plimage is use of
memory. Here at the ESRF we would like to use plimage to plot relatively
large images, i.e. up to 2000 x 2000 pixels. One can do this with the
current implementation however it uses a lot of memory and the buffering
of the image takes quite some time. In order to solve this problem I
have the following two suggestions:

1. I'd like to remove the two arrays containing the X and Y co-ordinates
for every pixel. From what I can see in the code these arrays are not
yet used - please correct me if I'm wrong. If I understood Alessandro
right the idea was that these arrays could be used to plot 2D data that
were not on a regular grid. I understand that this is desirable in some
circumstances, I have myself worked with correcting 2D detector data for
spatial distortion. However, I think it is wrong to delegate this task
to plimage. I believe that it is better to have this code outside
plimage, e.g. to have a function that accepts as arguments the image and
the co-ordinates for each pixel and then creates a new image which can
be sent to plimage.

2. I'd also like to go back to having the possibility of sending an
image as a PLFLT * instead as a PLFLT **. I understand that it is easy
to handle 2D data with plplot in the PLFLT ** format. However, large
images are most conveniently stored as PLFLT * in C. Using a PLFLT *
pointer has the advantage that it can be passed directly to a fast image
device, thus avoiding allocating memory. This pointer could also be
saved by plbuf_image instead of saving the whole image. (A solution
could be to add a new plimage function in plplot. The "old" plimage
could still be used with the PLFLT ** argument. The "new" plimage could
accept a PLFLT * argument and not allocate any extra memory, except
needed by the fast image device.)

What do you think?

Regards,

Olof

[Plplot-devel] Progress on 9th example

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

I am trying to take the union of all 9th (contour) example pages and make
sure each front end has all of them identically.  I must say that going back
and forth between C, python, yorick, and tcl makes me a little dizzy....;-)

The C, tcl, and python 9th examples now all produce identical results, and
you might want to have a look at the recent additions.

However, there is still more to do; to finish the C, tcl, and python 9th
examples I want to add the shielded potential example (taken from x09f.f) to
all these front ends. Also, I want to bring the yorick (two more pages to
add) and java (all 8 pages to add) front ends into compliance as well.

I hope someone else is willing to bring the fortran 9th example into
compliance with the rest of the front ends.

I must say that all the spade work that Geoffrey did on the plcont wrapper
for python really paid off for me today.  I now have some nice looking
python results that demonstrate what is possible with plcont.  And the
really good news is the lack of segfaults continues.....

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] merging of plmodule2.c into plmodule.c

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

I have just merged plmodule2.c into plmodule.c for reasons which I have been
discussing with Geoffrey.  (The biggest of these is I will be working with
this code, and I prefer that style.) I agree with Geoffrey that
rearrangement of the executable by the new compilation style might be
avoiding the xw09 segfault rather than being a real fix, but so far so good.
Also, in the next week or so I will be making a number of additional changes
to plmodule.c which should substantially rearrange the code, and if the
segfault does not reappear I will take it!

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: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

On Wed, 26 Dec 2001, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Will it confuse cvs if I remove the 3 generated files from cvs control, but
>  > then change my mind later and want to put them under cvs control again?
>
> Sadly, yes.  I've never been able to resurrect dead files without directly
> modifying the repository.  I just tried now on a test file / test repository
> and still it doesn't work through the API.

Thanks for this information.  I am going to take my chances that I will
never have to modify the repository (which would require SF's help or other
extraordinary measures) to get these generated files back into cvs.

>
>  > ....I think the right thing to do is to treat
>  > these generated files the same way we do the configure script; exclude them
>  > from cvs control but generate them for the tarball release.  This only puts
>  > the onus on those of us here on the developer's list (and perhaps a few
>  > more) that are building from CVS to be sure that they have perl.
>
> I don't see any problem with this.  Previously, it was leaving the generated
> files out of the public distribution that caused all the trouble.
>
>  > Any objections to having perl on your machine from the developers here?
>
> I doubt there'll be any objections.  And as far as availability goes, IIRC
> perl's even available under Windows.

Thanks for your thoughts on this change.  Also, I have specifically
contacted Olof (our windows porter) on this question, and apparently it will
not be a problem for him.

Therefore, I have just made this change to CVS (and have already put a
reminder in my release self-instructions to generate these files for the
tarball release.)

Alan

RE: [Plplot-devel] Solved the xw09.py segfault

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

Hi Alan,

Thanks for your work, and progress.  I will confess to some
substantial skepticism that adding a static qualifier to a function is
really fixing anything.  I'm more inclined to think it is masking a
problem that still remains.  Sorry I've never gotten around to looking
into the matter.  Maybe I'll get to that one of these days, or, maybe
I never will :-).

It's fine to combine plmodule2.c into plmodule.c if you prefer it that
way.  I had them apart just to control compile time during a period
when I was mostly working on plmodule2.c, but not touching all the
other stuff in plmodule.c.  But that was years ago, and if I remember,
I was developing on a Linux box running a 486 DX/2 66 MHz at the
time, so compile times were much worse than what we experience with
modern hardware.

Alan W. Irwin writes:
 > The long-standing segfault problem with xw09 using python 2 disappears if I
 > define pl_cont (and pl_shade) as static to make them consistent with what is
 > done for the embedded examples in the python documentation.  In the past
 > with python 1.5 I didn't get segfaults, but I did have a number of instances
 > of peculiar behaviour with pl_cont (contours would either be plotted or not
 > with minor rearrangements of the wrapper code).  Thus, I am hoping this
 > static fix will address those problems as well.  The static fix seems to have
 > no effect on pl_shade, but there may have been trouble lurking for us there
 > without that fix.
 > 
 > In the next day or so I am going to be greatly extending the xw09 contour
 > example so this should provide a pretty good test of whether our python
 > contour problems are finally over or not.
 > 
 > Does anybody here mind if I get rid of plmodule2.c and simply incorporate
 > its lines of code into plmodule.c?  The previous arrangement of separate
 > compilation of plmodule.c and plmodule2.c wasn't working very well and was
 > confusing.  For now, I have returned to including plmodule2.c in plmodule.c,
 > but as a final step I would like to simply incorporate its lines of code
 > into plmodule.c rather than including it.

[Plplot-devel] Solved the xw09.py segfault

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

The long-standing segfault problem with xw09 using python 2 disappears if I
define pl_cont (and pl_shade) as static to make them consistent with what is
done for the embedded examples in the python documentation.  In the past
with python 1.5 I didn't get segfaults, but I did have a number of instances
of peculiar behaviour with pl_cont (contours would either be plotted or not
with minor rearrangements of the wrapper code).  Thus, I am hoping this
static fix will address those problems as well.  The static fix seems to have
no effect on pl_shade, but there may have been trouble lurking for us there
without that fix.

In the next day or so I am going to be greatly extending the xw09 contour
example so this should provide a pretty good test of whether our python
contour problems are finally over or not.

Does anybody here mind if I get rid of plmodule2.c and simply incorporate
its lines of code into plmodule.c?  The previous arrangement of separate
compilation of plmodule.c and plmodule2.c wasn't working very well and was
confusing.  For now, I have returned to including plmodule2.c in plmodule.c,
but as a final step I would like to simply incorporate its lines of code
into plmodule.c rather than including it.

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] examples 12 and 13 completed

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

Thanks to Geoffrey's finishing effort, java and C now give identical results
for examples 12 and 13.  Python, tcl (and yorick) were already done for
those examples so this completes the work for them.

Examples 9, 15, 16, and 18 still need to be done.  They look more difficult
than what I have done before so I expect it will take me a while.

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] missing java api for example 12

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

Geoffrey, I have just created another java example for you to work with.
When you get a chance could you put in the api for pls.psty, pls.fill, and
pls.lsty that are required by x12.java?

TIA.

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: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

Alan W. Irwin writes:
 > Will it confuse cvs if I remove the 3 generated files from cvs control, but
 > then change my mind later and want to put them under cvs control again?

Sadly, yes.  I've never been able to resurrect dead files without directly
modifying the repository.  I just tried now on a test file / test repository
and still it doesn't work through the API.

 > If changing my mind is no problem to cvs (meaning I can always go back if
 > there is a storm of protest), then I think the right thing to do is to treat
 > these generated files the same way we do the configure script; exclude them
 > from cvs control but generate them for the tarball release.  This only puts
 > the onus on those of us here on the developer's list (and perhaps a few
 > more) that are building from CVS to be sure that they have perl.

I don't see any problem with this.  Previously, it was leaving the generated
files out of the public distribution that caused all the trouble.  

 > Any objections to having perl on your machine from the developers here?

I doubt there'll be any objections.  And as far as availability goes, IIRC
perl's even available under Windows.

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

RE: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

On Wed, 26 Dec 2001, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Please let me know if there are any good reasons to keep these files under
>  > cvs control.
>
> [...] configure would work but the build
> would fail, and they'd send trouble reports in like the Great Flood.
>
> When I got so tired I could stand it no longer, I just added the files
> to the repo so that would-be users wouldn't be triped up over such a
> small thing.
>
> That was before we had binary releases.  I dunno, maybe it would be
> okay to go back to the "no generated files in the repo" posture now,
> figuring that anyone skipping the .rpms and just checking out the
> source directly, can handle a build.  But note that some users took
> particular exception to the fact that they had to have perl installed
> in order to build the Tcl binding :-).
>
> Checking the files in was the act that stemmed the tide.  If you want
> to unplug the dike, its on you.  :-).

I have a feeling that our users are a different bunch now.  For one thing most
of them probably use Linux which will have perl almost automatically.  Also,
one hopes that the perl/tcl/python scripting language flamefests have cooled
down a bit.  I prefer python for myself, but I don't give a damn if perl and
tcl are on my machine and are actively used in a number of ways to make
my life easier.

Will it confuse cvs if I remove the 3 generated files from cvs control, but
then change my mind later and want to put them under cvs control again?

If changing my mind is no problem to cvs (meaning I can always go back if
there is a storm of protest), then I think the right thing to do is to treat
these generated files the same way we do the configure script; exclude them
from cvs control but generate them for the tarball release.  This only puts
the onus on those of us here on the developer's list (and perhaps a few
more) that are building from CVS to be sure that they have perl.

Any objections to having perl on your machine from the developers here?

Alan

RE: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

Alan W. Irwin writes:
 > The files in the commit message below depend on pltclgen, plapi.tpl, and
 > tclcmd.tpl and are easily generated by
 > 
 > perl pltclgen
 > 
 > In the interest of keeping our cvs free of files which are generated from
 > other files I would like to remove these from cvs.
 > 
 > Please let me know if there are any good reasons to keep these files under
 > cvs control.

Maurice will probably be the only one besides me who will remember
that the use of a perl-based pltclgen was the source of the
overwhelming majority of plplot build problems trouble reports, for a
number of years.  People would fetch the snapshots, try to build,
wouldn'thave perl on their system, configure would work but the build
would fail, and they'd send trouble reports in like the Great Flood.

When I got so tired I could stand it no longer, I just added the files
to the repo so that would-be users wouldn't be triped up over such a
small thing.

That was before we had binary releases.  I dunno, maybe it would be
okay to go back to the "no generated files in the repo" posture now,
figuring that anyone skipping the .rpms and just checking out the
source directly, can handle a build.  But note that some users took
particular exception to the fact that they had to have perl installed
in order to build the Tcl binding :-).

Checking the files in was the act that stemmed the tide.  If you want
to unplug the dike, its on you.  :-).

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

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

The files in the commit message below depend on pltclgen, plapi.tpl, and
tclcmd.tpl and are easily generated by

perl pltclgen

In the interest of keeping our cvs free of files which are generated from
other files I would like to remove these from cvs.

Please let me know if there are any good reasons to keep these files under
cvs control.

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, 24 Dec 2001, Alan W. Irwin wrote:

> Update of /cvsroot/plplot/plplot/bindings/tcl
> In directory usw-pr-cvs1:/tmp/cvs-serv31978
>
> Modified Files:
> 	tclgen.c tclgen.h tclgen_s.h
> Log Message:
> Regenerate
>
>
> _______________________________________________
> Plplot-cvs mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-cvs
>