Re: [Plplot-devel] Plplot - CMake - Qt

[Arjen Markus <arjen.markus@de...>]

Hello Walter,

PLplot is built via CMake. I regularly build it on Windows XP using
"plain" Windows compilers or MinGW.

The trick for including Qt in the mix is that you add the Qt libraries
and such to the path. On my system:

set path=c:\qtdsk\desktop\4.7.3\mingw\bin;%PATH%
cmake ..\plplot -G "MinGW Makefiles"

does the trick. (Well, I also include the path to the DLLs in the PATH
variable, because these are required at certain stages of the build
process, but you get the drift)

Regards,

Arjen

On 2011-12-21 18:40, Development iTEC wrote:
> Hello,
> 
>  
> 
> I am a complete newbie and I want to generate plplot with Qt.
> 
>  
> 
> Is there a batch file, CMakeList or something else, which works with
> 
>  
> 
> Windows7 (64bit), Cmake 2.8 or higher, Qt 4.7.4 or higher, MinGW.
> 
>  
> 
> I`ve read many internet articles but it is not easy, to find the 
> starting point.
> 
>  
> 
> Thanks
> 
> Walter
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

 

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

[Plplot-devel] Plplot - CMake - Qt

[Development iTEC <dev@it...>]

Hello,

 

I am a complete newbie and I want to generate plplot with Qt.

 

Is there a batch file, CMakeList or something else, which works with

 

Windows7 (64bit), Cmake 2.8 or higher, Qt 4.7.4 or higher, MinGW.

 

I`ve read many internet articles but it is not easy, to find the starting
point.

 

Thanks

Walter

 

 

Re: [Plplot-devel] Hardcoded margins color in Qt widget

[Alan W. Irwin <irwin@be...>]

On 2011-12-15 00:47+0100 Alexandre Becoulet wrote:

>
> Hi,
>
> I noticed the Qt widget adds gray margins when the plot aspect ratio is different
> from the window ratio. There is nothing wrong with that, but the hardcoded color
> choice makes my application look odd. Maybe it would be better to use the current
> plplot background color instead of this Qt::gray/Qt::Dense4Pattern brush for the
> margins.

Hi Alexandre:

I think the result looks considerably better so I have applied your
patch (revision 12110).  Thanks for your help with PLplot!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Hardcoded margins color in Qt widget

[Alexandre Becoulet <alexandre.becoulet@fr...>]

Hi,

I noticed the Qt widget adds gray margins when the plot aspect ratio is different
from the window ratio. There is nothing wrong with that, but the hardcoded color
choice makes my application look odd. Maybe it would be better to use the current
plplot background color instead of this Qt::gray/Qt::Dense4Pattern brush for the
margins.

Here are some screenshots of the plplot example application with and without
the proposed change:

http://diaxen.ssji.net/pl/

BR,

Index: bindings/qt_gui/plqt.cpp
===================================================================
--- bindings/qt_gui/plqt.cpp	(revision 12109)
+++ bindings/qt_gui/plqt.cpp	(working copy)
@@ -1267,8 +1267,7 @@
         painter->begin( m_pixPixmap );
 
         // Draw the margins and the background
-        painter->fillRect( 0, 0, width(), height(), QBrush( Qt::white ) );
-        painter->fillRect( 0, 0, width(), height(), QBrush( Qt::gray, Qt::Dense4Pattern ) );
+        painter->fillRect( 0, 0, width(), height(), QColor( bgColour.r, bgColour.g, bgColour.b ) );
 
         // Re-initialise pens etc.
         resetPensAndBrushes( painter );

-- 
Alexandre

[Plplot-devel] [ plplot-Bugs-3458200 ] Linear gradient in rgb space, plscmap1l

[SourceForge.net <noreply@so...>]

Bugs item #3458200, was opened at 2011-12-12 04:51
Message generated for change (Tracker Item Submitted) made by pascal22p
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3458200&group_id=2915

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal (pascal22p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linear gradient in rgb space, plscmap1l

Initial Comment:
Could be a feature request depending how you see the problem.

The documention states that the gradient is linear. However this is only valid in hls. When using rgb coding it is no longer the case.
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.9/plscmap1l.html
"Set color map1 colors using a piece-wise linear relationship between position in the color map (from 0 to 1) and position in HLS or RGB color space"

This is due to the conversion from rgb space to hls when the input is rgb:

n plctrl.c,
void
plcmap1_calc( void )
//! Bin up cmap 1 space and assign colors to make inverse mapping easy.
//! Always do interpolation in HLS space.

This works:
call plscmap1l(.false., &
&   (/0.0_plflt, 0.499_plflt, 0.501_plflt, 1.0_plflt  /),&
&   (/0.0_plflt, 0.0_plflt, 120.0_plflt, 120.0_plflt  /),&
&   (/0.2_plflt, 1.0_plflt, 1.0_plflt, 0.2_plflt  /),&
&   (/1.0_plflt, 1.0_plflt, 1.0_plflt, 1.0_plflt  /) )  

But not this:
call plscmap1l(.true., &
&   (/0.0_plflt,  0.5_plflt, 1.0_plflt  /),&
&   (/1.0_plflt,  1.0_plflt, 0.0_plflt  /),&
&   (/0.0_plflt,  1.0_plflt, 1.0_plflt  /),&
&   (/0.0_plflt,  1.0_plflt, 0.0_plflt  /) )  

Either the documention should mention this but it stills buggy for me as this function accepts rgb input.
Or remove the hls transformation and do the gradient with rgb values when the input is in rgb.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3458200&group_id=2915

Re: [Plplot-devel] Debian update plans

[Andrew Ross <andrewross@us...>]

On Sun, Dec 04, 2011 at 12:32:31PM -0800, Alan Irwin wrote:
> On 2011-12-04 09:15-0000 Andrew Ross wrote:
> 
> > Incidentally, for testing with debian unstable I'm using pbuilder. It
> > provides a clean chroot environment, primarily for building Debian
> > packages, but you can also log in to test normal compiles etc. The
> > big advantage over virtual machine approaches is that it is much
> > lighter weight and quicker. Alan, you might want to look at this too.
> 
> Hi Andrew:
> 
> pbuilder (documented, by the way, at http://pbuilder.alioth.debian.org/)
> sounds very useful for quickly switching back and forth
> between various Debian platforms, but I only have time to test one
> Debian platform.
> 
> For now that is squeeze = stable, but I plan to move to wheezy =
> testing in the next several months.  At that time I will preview
> wheezy using the live CD approach. Creating such CD's should be 
> straightforward with the live-build package.  I used the live-helper
> ancestor of that package to help preview Debian squeeze before I
> installed it. That package was a bit rough around the edges, but I did
> get it to work, and I presume live-build implements a much smoother
> experience for building live CD's of Debian.  The live CD idea would
> also allow access to multiple Debian platforms (similar to
> multi-booting), but obviously pbuilder would be more convenient for
> that purpose for those who have the time to test multiple
> Debian/Ubuntu platforms at once.
> 
> Live CD previews of Debian and Ubuntu upgrades are especially
> important right now because of the continued volatility of the X stack
> especially for those with Intel hardware.  My 4-year-old hardware has
> Intel g33 integrated graphics which works well with the old X stack
> for Debian squeeze, but I am not sure that will be the case for the
> new X stack for Debian wheezy because the Intel open-source graphics
> group stopped release testing g33 two years ago.  They still claim
> that the new X stack _should_ work with that hardware but a certain
> amount of fear, uncertainty, and doubt about that has been introduced
> by their lack of release testing, and you know how paranoid I am
> about the completeness of release testing in any case. :-)
> 
> If previewing wheezy with a live CD shows there are issues with the
> new X stack for Intel g33 graphics hardware, my backup plan is to buy
> a cheap ATI video card, but my hope is that complication will not be
> necessary.
> 
> By the way, one of my motivations for moving to wheezy fairly soon is
> I am hoping that _much_ newer kernel will solve the start-up latency
> and associated total system slowdown that make testing PLplot on the
> latest wine such a major hassle for me on Debian squeeze. (My working
> hypothesis for the cause of these issues is the wine developers have
> tuned wine for modern Linux kernel capabilities that are just not as
> well implemented or maybe not even present for the old kernel that you
> get for Debian squeeze.) I am also looking forward to using the much
> more mature KDE-4.x desktop that is available on wheezy, later Qt4,
> later pango/cairo stack, etc.

Alan,

I realise you haven't much time for testing on top of your already
extensive testing, but others might find pbuilder useful too. For 
me it is a relatively painless way of testing the latest versions of
libraries etc without having to risk an unstable system or download 
and compile myself.

Andrew

Re: [Plplot-devel] -std-c99 generates lots of warnings and a Java example segfault

[Andrew Ross <andrewross@us...>]

Alan,

My recommended settings following the discussion on the list are 
documented in README.release. I've been using

CFLAGS='-O3 -std=c99 -pedantic -D_POSIX_C_SOURCE=200112L -Wall  \
-Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs \
-Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings'

CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra '

FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic \
-Wall -Wextra '

Andrew

On Wed, Dec 07, 2011 at 10:05:04AM -0800, Alan Irwin wrote:
> Hi Andrew:
> 
> Some time ago in connection with the Time Ephmerides project I built
> the Debian unstable gcc-4.6 packages (version 4.6.1-13) on my Debian
> stable platform to get access to gfortran quadruple precision.  These
> compilers are not suitable for comprehensive testing of PLplot because
> they don't include Ada and D so I have not used them before for that
> purpose, but out of curiosity today I did some limited testing (just
> the test_noninteractive target in the build tree) for the following
> environment variables:
> 
> CC=gcc-4.6
> CXX=g++-4.6
> FC=gfortran-4.6
> CFLAGS=-O3 -fvisibility=hidden
> CXXFLAGS=-O3 -fvisibility=hidden
> FFLAGS=-O3
> 
> and the following cmake options:
> 
> -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \
> -DENABLE_f95=ON -DENABLE_f77=ON
> 
> As expected, the result was no compiler warnings and no run-time errors
> for the test_noninteractive target in the build tree.
> 
> What do you now recommend for CFLAGS, CXXFLAGS, and FFLAGS for the most
> rigourous code-quality testing for the above compilers?
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] -std-c99 generates lots of warnings and a Java example segfault

[Alan W. Irwin <irwin@be...>]

Hi Andrew:

Some time ago in connection with the Time Ephmerides project I built
the Debian unstable gcc-4.6 packages (version 4.6.1-13) on my Debian
stable platform to get access to gfortran quadruple precision.  These
compilers are not suitable for comprehensive testing of PLplot because
they don't include Ada and D so I have not used them before for that
purpose, but out of curiosity today I did some limited testing (just
the test_noninteractive target in the build tree) for the following
environment variables:

CC=gcc-4.6
CXX=g++-4.6
FC=gfortran-4.6
CFLAGS=-O3 -fvisibility=hidden
CXXFLAGS=-O3 -fvisibility=hidden
FFLAGS=-O3

and the following cmake options:

-DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \
-DENABLE_f95=ON -DENABLE_f77=ON

As expected, the result was no compiler warnings and no run-time errors
for the test_noninteractive target in the build tree.

What do you now recommend for CFLAGS, CXXFLAGS, and FFLAGS for the most
rigourous code-quality testing for the above compilers?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Debian update plans

[Alan W. Irwin <irwin@be...>]

On 2011-12-04 12:32-0800 Alan W. Irwin wrote:

> Live CD previews of Debian and Ubuntu upgrades are especially
> important right now because of the continued volatility of the X stack
> especially for those with Intel hardware.  My 4-year-old hardware has
> Intel g33 integrated graphics which works well with the old X stack
> for Debian squeeze, but I am not sure that will be the case for the
> new X stack for Debian wheezy because the Intel open-source graphics
> group stopped release testing g33 two years ago.  They still claim
> that the new X stack _should_ work with that hardware but a certain
> amount of fear, uncertainty, and doubt about that has been introduced
> by their lack of release testing, and you know how paranoid I am
> about the completeness of release testing in any case. :-)

Hmm.  I was being too tough on Intel, see
http://intellinuxgraphics.org/2011Q4.html.  They did drop release
testing of g33 for quite a while up to and including the first
quarterly release this year.  Apparently there was no second quarterly
release, but g33 testing has been reinstated for their last two
quarterly releases this year, and the versions of the
components (kernel, mesa, libdrm, libva, X server, and X intel driver)
of the Intel graphics stack mentioned at the above URL have already
mostly made it into Debian testing.  That makes me feel a lot better
about the chances that my g33 graphics will work properly with the X
stack for Debian testing.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Debian update plans

[Alan W. Irwin <irwin@be...>]

On 2011-12-04 09:15-0000 Andrew Ross wrote:

> Incidentally, for testing with debian unstable I'm using pbuilder. It
> provides a clean chroot environment, primarily for building Debian
> packages, but you can also log in to test normal compiles etc. The
> big advantage over virtual machine approaches is that it is much
> lighter weight and quicker. Alan, you might want to look at this too.

Hi Andrew:

pbuilder (documented, by the way, at http://pbuilder.alioth.debian.org/)
sounds very useful for quickly switching back and forth
between various Debian platforms, but I only have time to test one
Debian platform.

For now that is squeeze = stable, but I plan to move to wheezy =
testing in the next several months.  At that time I will preview
wheezy using the live CD approach. Creating such CD's should be 
straightforward with the live-build package.  I used the live-helper
ancestor of that package to help preview Debian squeeze before I
installed it. That package was a bit rough around the edges, but I did
get it to work, and I presume live-build implements a much smoother
experience for building live CD's of Debian.  The live CD idea would
also allow access to multiple Debian platforms (similar to
multi-booting), but obviously pbuilder would be more convenient for
that purpose for those who have the time to test multiple
Debian/Ubuntu platforms at once.

Live CD previews of Debian and Ubuntu upgrades are especially
important right now because of the continued volatility of the X stack
especially for those with Intel hardware.  My 4-year-old hardware has
Intel g33 integrated graphics which works well with the old X stack
for Debian squeeze, but I am not sure that will be the case for the
new X stack for Debian wheezy because the Intel open-source graphics
group stopped release testing g33 two years ago.  They still claim
that the new X stack _should_ work with that hardware but a certain
amount of fear, uncertainty, and doubt about that has been introduced
by their lack of release testing, and you know how paranoid I am
about the completeness of release testing in any case. :-)

If previewing wheezy with a live CD shows there are issues with the
new X stack for Intel g33 graphics hardware, my backup plan is to buy
a cheap ATI video card, but my hope is that complication will not be
necessary.

By the way, one of my motivations for moving to wheezy fairly soon is
I am hoping that _much_ newer kernel will solve the start-up latency
and associated total system slowdown that make testing PLplot on the
latest wine such a major hassle for me on Debian squeeze. (My working
hypothesis for the cause of these issues is the wine developers have
tuned wine for modern Linux kernel capabilities that are just not as
well implemented or maybe not even present for the old kernel that you
get for Debian squeeze.) I am also looking forward to using the much
more mature KDE-4.x desktop that is available on wheezy, later Qt4,
later pango/cairo stack, etc.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] [ plplot-Bugs-3450518 ] plcont, coordinate transformation

[SourceForge.net <noreply@so...>]

Bugs item #3450518, was opened at 2011-12-04 09:47
Message generated for change (Tracker Item Submitted) made by pascal22p
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3450518&group_id=2915

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal (pascal22p)
Assigned to: Nobody/Anonymous (nobody)
Summary: plcont, coordinate transformation

Initial Comment:
Hi,

It seems that there is a bug in plcont when using f90 binding

Using the same parameters for coordinate transformations compare to plimagefr gives a wrong contour.
See example 16:
http://plplot.sourceforge.net/examples.php?demo=16&lbind=F95

I also have a test case attached. data to use it are here:
http://pascal.parois.net/public/data (quite big, sorry)

I need to transform xtrans(i,j) this way to fix it:
xtrans(i,j)= mod(xtrans(i,j)+ytrans(i,j), 2*planerealhalfwidth)

PS: the use of mod causes glitches in the contour, it's not a bug of plplot

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102915&aid=3450518&group_id=2915

Re: [Plplot-devel] Changing 2-d arrays

[Andrew Ross <andrewross@us...>]

On Sat, Dec 03, 2011 at 09:51:29AM -0800, Alan Irwin wrote:
> On 2011-12-03 09:01-0000 Andrew Ross wrote:
> 
> >
> > I have just committed a fairly large update to change the 2d arrays in
> > our API from const PLFLT ** to const PLFLT * const *. Gcc warns about
> > the use of const PLFLT ** because it only guarantees that the data is
> > constant not the array of pointers to the data. It is therefore trivial
> > to change the data by changing the pointers which is not what is
> > intended. Both the pointer array and the data need to be marked const.
> >
> > This is quite intrusive, but it seems to work ok for me. Please check.
> > It is strictly an API change however existing code should still
> > compile fine (possibly with warnings depending on the gcc settings).
> >
> > This does not remove all warnings - just shifts them (more later). It
> > does however make the API and the examples clean which I think is
> > more important for users.
> >
> > The const PLFLT * const * is a bit unwieldy however, so I propose
> > making a new typedef (something like PLFLT_2D_CONST) to tidy up
> > the code.
> 
> Assuming PLFLT is #defined like we have done, is "PLFLT * const *"
> something all c99-compliant compilers should understand or is that
> just a gcc extension?  Even if the answer to that question is all
> c99-compliant compilers should understand it, it is possible their c99
> implementations are buggy.  Therefore, I think using a PLFLT_2D_CONST
> typedef (which we could #define differently for any major
> non-compliant compilers) might be a good idea from cross-platform
> point of view as well.

This should be a standard feature. Of course, whether all compilers
support it or not is another matter. I suspect they do.

> For what it is worth, revision 12095 passes a limited test
> (just test_noninteractive in the build tree) on my Debian stable platform
> (gcc (Debian 4.4.5-8) 4.4.5). Furthermore, for that test using
> 
> CXXFLAGS=-O3 -fvisibility=hidden
> CFLAGS=-O3 -fvisibility=hidden
> FFLAGS=-O3
> 
> there were no compiler warnings at all.  That good result surprised me
> because there used to be tonnes of Java warnings and a sprinkling of C
> warnings.  I don't know whether the Java warnings disappeared due to
> your efforts, but in any case we have come a long way in getting our
> code cleaned up thanks to your much appreciated efforts.

That is good to know. I've been testing again with all the warning flags
on. The new version of gcc (4.6) in debian unstable includes even more
warnings. Usefully it also now includes details of which warning flags
triggered the message. 

Incidentally, for testing with debian unstable I'm using pbuilder. It
provides a clean chroot environment, primarily for building Debian
packages, but you can also log in to test normal compiles etc. The
big advantage over virtual machine approaches is that it is much 
lighter weight and quicker. Alan, you might want to look at this too.

Andrew

Re: [Plplot-devel] Changing 2-d arrays

[Alan W. Irwin <irwin@be...>]

On 2011-12-03 09:01-0000 Andrew Ross wrote:

>
> I have just committed a fairly large update to change the 2d arrays in
> our API from const PLFLT ** to const PLFLT * const *. Gcc warns about
> the use of const PLFLT ** because it only guarantees that the data is
> constant not the array of pointers to the data. It is therefore trivial
> to change the data by changing the pointers which is not what is
> intended. Both the pointer array and the data need to be marked const.
>
> This is quite intrusive, but it seems to work ok for me. Please check.
> It is strictly an API change however existing code should still
> compile fine (possibly with warnings depending on the gcc settings).
>
> This does not remove all warnings - just shifts them (more later). It
> does however make the API and the examples clean which I think is
> more important for users.
>
> The const PLFLT * const * is a bit unwieldy however, so I propose
> making a new typedef (something like PLFLT_2D_CONST) to tidy up
> the code.

Assuming PLFLT is #defined like we have done, is "PLFLT * const *"
something all c99-compliant compilers should understand or is that
just a gcc extension?  Even if the answer to that question is all
c99-compliant compilers should understand it, it is possible their c99
implementations are buggy.  Therefore, I think using a PLFLT_2D_CONST
typedef (which we could #define differently for any major
non-compliant compilers) might be a good idea from cross-platform
point of view as well.

For what it is worth, revision 12095 passes a limited test
(just test_noninteractive in the build tree) on my Debian stable platform
(gcc (Debian 4.4.5-8) 4.4.5). Furthermore, for that test using

CXXFLAGS=-O3 -fvisibility=hidden
CFLAGS=-O3 -fvisibility=hidden
FFLAGS=-O3

there were no compiler warnings at all.  That good result surprised me
because there used to be tonnes of Java warnings and a sprinkling of C
warnings.  I don't know whether the Java warnings disappeared due to
your efforts, but in any case we have come a long way in getting our
code cleaned up thanks to your much appreciated efforts.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Changing 2-d arrays

[Andrew Ross <andrewross@us...>]

I have just committed a fairly large update to change the 2d arrays in 
our API from const PLFLT ** to const PLFLT * const *. Gcc warns about
the use of const PLFLT ** because it only guarantees that the data is
constant not the array of pointers to the data. It is therefore trivial
to change the data by changing the pointers which is not what is 
intended. Both the pointer array and the data need to be marked const.

This is quite intrusive, but it seems to work ok for me. Please check.
It is strictly an API change however existing code should still
compile fine (possibly with warnings depending on the gcc settings).

This does not remove all warnings - just shifts them (more later). It
does however make the API and the examples clean which I think is
more important for users. 

The const PLFLT * const * is a bit unwieldy however, so I propose 
making a new typedef (something like PLFLT_2D_CONST) to tidy up 
the code.

Andrew

Re: [Plplot-devel] Unnecessary library linkage

[Andrew Ross <andrewross@us...>]

On Thu, Dec 01, 2011 at 09:45:20AM +0000, Andrew Ross wrote:
> 
> To start with I have just copied the Debian LGPL-2 (not 2.1) license to
> replace the current COPYING.LIB. This does not change the terms of the
> license at all, merely the FSF address. Switching to version 2.1 would
> result in a small change in the license, so I've avoided doing this.
> 
> Now to go through the source files and check for inconsistency elsewhere.

There weren't than many (although there were 2 old addresses). I've just
done it by hand.

Andrew

Re: [Plplot-devel] Unnecessary library linkage

[Andrew Ross <andrewross@us...>]

On Wed, Nov 30, 2011 at 11:38:05AM -0800, Alan Irwin wrote:
> On 2011-11-30 11:11-0000 Andrew Ross wrote:
> 
> > On Tue, Nov 29, 2011 at 04:54:27PM -0700, Orion Poplawski wrote:
> >> plplot.i686: W: file-not-utf8 /usr/share/doc/plplot-5.9.9/README.release
> >> plplot.i686: E: incorrect-fsf-address
> >> /usr/share/doc/plplot-5.9.9/COPYING.LIB
> >> plplot-octave.i686: E: incorrect-fsf-address
> >> /usr/share/plplot_octave/struct_contains.m
> >
> > I agree with you Orion that this should probably be fixed. I recently
> > fixed up Copyright for the same reason (wrong address) as Debian lintian
> > complained about it. Debian doesn't install COPYING.LIB. I maintains
> > central copies of the GPL licenses and links to these so I didn't fix
> > COPYING.LIB as well.
> 
> In my rush, I misread some license dates at FSF and got confused by
> that into thinking we might have an even later LGPL version 2 license
> than published by FSF. But in fact our 2.0 license is much earlier
> (June 1991 not June 1999), than theirs (February 1999, see
> http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). Furthermore,
> I have never heard anybody quibble about 2.0 versus 2.1 licensing text
> so, Andrew, please go ahead and change to LGPL 2.1 so long as you make
> sure to get the definitive version from FSF.
> 
> Note there are some other licensing consistency issues you should
> address.  For example, the licensing summary that appears in our
> source code (e.g., src/plcore.c) refers to LGPL version 2, but the
> definitive version of that licensing summary(
> http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4) refers to
> version 2.1.  There are possibly other inconsistencies as well between
> the src/plcore.c licensing summary and the definitive version, and
> certainly inconsisentencies between the LGPL licensing summary for
> src/plcore.c and our other source files.
> 
> So I think what is needed here is a wholesale approach to replace our
> existing LGPL summaries everywhere in our source code files with the
> definitive 2.1 version from the above URL.  That change would be a
> pain to do by hand, but I trust you should be able to automate the
> work by using a find command and appropriate xargs and grep -l to find
> all files in our source tree that include some version of the LGPL
> summary.  Then for each of those files run a perl script to recognize
> the lines in the text that contain an existing variation of our
> licensing summary (by the first few words and last few words of that
> text to beat line-wrapping and other variations) and replace that text
> by the definitive version that has the correct comment tag ("//" for C
> code, "#" for Python code, etc.)

To start with I have just copied the Debian LGPL-2 (not 2.1) license to
replace the current COPYING.LIB. This does not change the terms of the
license at all, merely the FSF address. Switching to version 2.1 would
result in a small change in the license, so I've avoided doing this.

Now to go through the source files and check for inconsistency elsewhere.

Andrew