forked from PLplot/PLplot
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathChangeLog.release
2376 lines (1852 loc) · 117 KB
/
ChangeLog.release
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
commit 4f88e45dbd85468a96364548f8d06a9b52dac14a
Author: Alan W. Irwin <[email protected]>
Date: Sat Jun 1 16:10:17 2019 -0700
Prepend README.release for 5.15.0 to README.cumulated_release
M README.cumulated_release
commit 3f343c78072b0a8567434f0eb5ce41cb947a66c6
Author: Alan W. Irwin <[email protected]>
Date: Sat Jun 1 16:08:00 2019 -0700
Update README.Release_Manager_Cookbook to reflect what has occurred during the PLplot-5.15.0 release process
M README.Release_Manager_Cookbook
commit ae52e0496603d9cb63433b6baf54a82d5deb6b33
Author: Alan W. Irwin <[email protected]>
Date: Sat Jun 1 16:05:59 2019 -0700
Update website for plplot-5.15.0
Fix a broken Homebrew link and update the version to 5.15.0.
M doc/docbook/src/CMakeLists.txt
M www/downloads.php
commit d9755e1210ba41bc692fbcbe43c62bfb8310e823
Author: Alan W. Irwin <[email protected]>
Date: Sat Jun 1 11:53:27 2019 -0700
Fix the -DBUILD_DOX_DOC=ON case for the _plplotc -> plplotc target name change
Recent versions of CMake including 3.13.2 and above (where 3.13.2 is
our minimum acceptable version) have dropped the leading underscore in
the target names for swig-generated target names for Python modules.
I have previously corrected our build system for this change, but I
had missed the -DBUILD_DOX_DOC=ON case which is now fixed in this
commit.
I also took this opportunity to impose the PLPLOT:: namespace prefix
(e.g., plplotc => PLPLOT::plplotc) on all read-only target names used
in doc/CMakeLists.txt since that is the preferred modern CMake style
for referring to read-only target names. (I had previously run a test
to detect all instances in our build-system logic of references to
read-only target names which did not have a namespace prefix, but that
test did not cover the -DBUILD_DOX_DOC=ON case.)
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by successfully building and testing the doxygen documentation
following the procedure in doc/README.doxygen.
M doc/CMakeLists.txt
M doc/README.doxygen
commit b2530e3ca4b047f1db2e30d25c15a247bf090afc
Author: Alan W. Irwin <[email protected]>
Date: Fri May 31 15:15:01 2019 -0700
Style bindings/swig-support/plplotcapi.i after its recent #defines update commit, and document why this styling is necessary.
The check_plplotcapi_defines target collects all the numerical
#defines in include/plplot.h in a generated file and then compares
that file with the collected numerical #defines in
swig-support/plplotcapi.i and complains if there is a non-whitespace
difference. The reason we have to ignore whitespace differences is
that uncrustify's algorithm for styling alignment takes account of the
different context lines around the lines that are being aligned. So
as a result the whitespace of the #defines in those styled files is
necessarily different. So after inserting (typically by replacing the
#defines section of swig-support/plplotcapi.i with the above generated
file) #defines that have been aligned in a variety of ways depending
on context lines for include/plplot.h into swig-support/plplotcapi.i,
it is necessary to run
scripts/style_source.sh --apply
and follow the directions emitted by that script to smooth out the
variable alignment issues for the unified #defines section of
swig-support/plplotcapi.i.
Document this change in procedure!
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by building the above check_plplotcapi_defines target
(which demonstrated there are no #defines inconsistencies [other than
tahe necessary whitespace differences] between include/plplot.h and
swig-support/plplotcapi.i), and running scripts/style_source.sh (which
verifies no styling is necessary for swig-support/plplotcapi.i).
M bindings/swig-support/CMakeLists.txt
M bindings/swig-support/plplotcapi.i
commit 41bff5992c3cdb0b44a551d748c5ca64aa477224
Author: Alan W. Irwin <[email protected]>
Date: Fri May 31 14:41:15 2019 -0700
Remove trailing white space from recently created documentation file
M README.PLplot_Contract_Testing
commit 7fd04b611ed7d7009f51f298dcac5bf53278f849
Author: Alan W. Irwin <[email protected]>
Date: Fri May 31 12:44:31 2019 -0700
Update PLplot version to 5.15.0 and update PLplot library version numbers
I use semantic library versioning rules (see
cmake/modules/plplot_version.cmake for the details of how this is
implemented for PLplot) to determine a separate version number (and
associated SONAME) for each of our versioned libraries.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by simply looking at
git diff www
to check the version change in that subdirectory and
git diff cmake/modules/plplot_version.cmake |grep '^[+-]' |sort --key=1.2 |less
to summarize all version changes known to the build system..
I used these simple tests to look just for obvious typographical
errors in this commit because PLplot will be tested by a final
comprehensive test just prior to the release.
M cmake/modules/plplot_version.cmake
M www/examples.php
commit 361c6bef52eadd61783404dfe4a4093f8c686b0c
Author: Alan W. Irwin <[email protected]>
Date: Fri May 31 00:03:33 2019 -0700
Propagate new cmap0 and cmap1 symbolic constants to most of our bindings
These new symbolic constants (implemented in this release cycle in
include/plplot.h) are
#define PL_DEFAULT_NCOL0 16
#define PL_DEFAULT_NCOL1 128
#define MIN_PLINT_RGB 0
#define MAX_PLINT_RGB 255
#define MIN_PLFLT_CMAP1 0.
#define MAX_PLFLT_CMAP1 1.
#define MIN_PLFLT_ALPHA 0.
#define MAX_PLFLT_ALPHA 1.
This commit propates these new symbolic constants from our core C
library and also (automatically since C++ includes plplot.h) our C++
binding to our swig-generated bindings (Java, Python, Octave, and Lua)
and our Fortran and Tcl bindings. These changes to improve internal
consistency are essential to the forthcoming release of PLplot-5.15.0
and were implemented by building the "check_all" target, and
when any of those subtargets which are dependencies of that target
errored out due to a detected internal inconsistency, I took the
appropriate action (usually copying a generated file back to the
source tree) to resolve that issue.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by configuring PLplot with the
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON option, putting the golang
program plplot-doc-check (see comments in
doc/docbook/src/CMakeLists.txt for how to build that programme) on the
PATH and building the check_all and check_api_xml_consistency targets.
There were no build errors for those targets which shows PLplot
currently passes *all* our internal consistency checks (this result is
essential to the forthcoming release of PLplot-5.15.0) including the
ones that demand consistency (established by this commit) for symbolic
constants defined in plplot.h for our core C library (and therefore
our C++ binding which also includes plplot.h) and the six
swig-generated, Fortran, and Tcl bindings.
M bindings/fortran/included_plplot_parameters.f90
M bindings/swig-support/plplotcapi.i
M bindings/tcl/plplot_parameters.h
commit 4baf2b49a8ab61ef5b6922ab6cb96963fa5da1f7
Author: Alan W. Irwin <[email protected]>
Date: Thu May 30 18:03:16 2019 -0700
Finalize release notes for the forthcoming PLplot-5.15.0 release
I used a preliminary Changelog for all commits in this release cycle
to determine the major changes for this release, and I
updated the release notes for the forthcoming
PLplot-5.15.0 accordingly.
M README.release
commit 4ae06fd6c498a3e4e59ae67bbe4d3ce049a72a14
Author: Alan W. Irwin <[email protected]>
Date: Sun May 26 13:54:10 2019 -0700
Summarize my (Alan W. Irwin's) recent Linux (Debian Testing) comprehensive test result in our wiki (part II)
Part I of this change was a previous commit (with the same core title
as this commit) which summarized my (good) comprehensive test results
for CMake-3.13.2 (our minimum allowed CMake version) in our
"Testing_Reports" wiki page. This commit (Part II) does the same
thing for my (good) comprehensive test results for CMake-3.14.4 (the
latest release of CMake that is available at this time). So these two
commits document in our wiki that the current development version of
PLplot works well on Linux (Debian Testing) for the range of CMake
versions from 3.13.2 to 3.14.4.
M doc/wiki_source/Testing_Reports
commit e8888b193205fa12e5fbde7eb8b3783cd128af05
Author: Alan W. Irwin <[email protected]>
Date: Sat May 25 13:43:22 2019 -0700
Document the PLplot contract test that is available as part of CMake
Note that this contract test helps CMake developers discover
regressions in the CMake source code, helps the PLplot project
indirectly by avoiding such regressions in CMake releases, and helps
the PLplot project directly in case the issue is a bug or some
deficiency in the PLplot build system that is exposed by the latest
development version of CMake.
Therefore, I strongly encourage all PLplot developers to
configure the PLplot contract test for their platform following
this documentation.
Note I (AWI) have been running this contract test on a nightly basis
for both my previous Debian Jessie system and my current Debian Buster
system, and I have discovered both CMake regressions and PLplot
build system issues this way.
A README.PLplot_Contract_Testing
commit 9c113444cc9a0ddfe49b675da972647dd4b1edfb
Author: Alan W. Irwin <[email protected]>
Date: Thu May 23 11:59:22 2019 -0700
Summarize my (Alan W. Irwin's) recent Linux (Debian Testing) comprehensive test result in our wiki
M doc/wiki_source/Testing_Reports
commit 15ffb9d106958690e754246a7280635a0c80cec3
Author: Alan W. Irwin <[email protected]>
Date: Wed May 22 22:12:24 2019 -0700
Summarize Arjen's recent MinGW-w64/MSYS2 comprehensive test result in our wiki
N.B. I made consistent changes in our git copy of the wiki markdown
source and the SourceForge version of the same following the file edit
and subsequent cut and paste method described in README.developers.
M doc/wiki_source/Testing_Reports
commit b766e84b408fb4ae37e86f4e3a4864dbddeb8547
Author: Alan W. Irwin <[email protected]>
Date: Wed Apr 3 12:32:52 2019 -0700
Build System: fix recently introduced PLPLOT::plfortrandemolib target bug on Windows platforms
This bug causes CMake errors concerning a missing
PLPLOT::plfortrandemolib target on Arjen's Cygwin platform.
The issue was that PLPLOT::plfortrandemolib was created inside a
if(USE_RPATH AND NOT WIN32_OR_CYGWIN)
if block which is true on Unix platforms (which explains why
PLPLOT::plfortrandemolib has been created properly on my Debian
Testing platform for all my recent tests) but false otherwise (as
Arjen discovered on Cygwin). This commit fixes this bug by moving the
relevant CMake code outside this if block.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by configuring a PLplot build with cmake. There were
no CMake errors created by a missing PLPLOT::plfortrandemolib target so
it appears all continues to be well on this platform. However, this
fix does need to be checked by Arjen to confirm it completely settles
the issue he discovered on Cygwin.
M examples/CMakeLists.txt
commit ad53c055d066d731f077a6ab8daa82e92e409300
Author: Alan W. Irwin <[email protected]>
Date: Wed Apr 3 12:08:42 2019 -0700
Build system: set CMP0086 to NEW if that policy exists to suppress CMake warnings concerning this policy
CMP0086 is implemented for CMake-3.14.0, and to suppress the warnings issued
by CMake-3.14.0 when this policy is not set, set CMP0086 to NEW when this policy exists.
This policy substantially affects the UseSWIG module and therefore our Python, Java, Octave, and Lua
bindings. Therefore, it needs extensive testing (see below).
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by building the test_noninteractive target in the
(shared) core build tree for both CMake-3.13.2 and CMake-3.14.0. For each
of these CMake versions, the resulting cmake.out and
test_noninteractive.out files were evaluated as follows:
# Check for errors
grep -i error *.out
# Check for regressions in configuration warnings:
grep -i warning cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING'
# Currently on Cygwin systems you get a mixture of Unix and Windows line endings so
# make those equivalent with the "tr" stanza (which does not harm on other platforms).
grep -A1 --no-filename "PLPLOT WARNING" *.out |tr --delete $'\r' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated
# above, spurious gfortran warnings, and warnings concerning test_diff differences:
grep -i warning *.out|grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic|Some graphical' |less
# Check for any file device (which defaults to the svg device, see below) or stdout
# differences between all non-C languages and the corresponding C results:
grep -B1 -A3 "Missing examples" *.out |less
For both versions of CMake, these evaluations showed there were no
configuration, build, or run-time issues with the results, and the
difference report (for the default svg device) was perfect.
M CMakeLists.txt
M examples/CMakeLists.txt
commit d1c621d028f192b6efd67467e7460e82ffec83dc
Author: Alan W. Irwin <[email protected]>
Date: Sat Mar 30 16:42:36 2019 -0700
Build system: implement ctest for installed examples tree
Prior to this commit, ctest was only implemented for the core build
tree, but now it has been implemented for the installed examples tree
as well. This change required a substantial rewrite of the CMake
logic in plplot_test/CMakeLists.txt to divide that logic into two
blocks (one for CORE_BUILD only and one for both CORE_BUILD and the
build of the installed examples). That file is now used in two
contexts (once for the core build and once for the installed examples
build). Because of the rewrite of that file, the comprehensive test
below was done with no constraints to skip any part of it.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) with the following steps:
# Choose these prefixes to assure that the source, build, and install tree have
# blanks in their pathname (to test that case during this comprehensive test)
COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
SOURCE_PREFIX="/home/software/plplot/HEAD/plplot blank .git"
# Set CMAKE_PREFIX_PATH to access local versions of lua and libLASi to
# avoid important bugs in the Debian Testing versions of those
# packages. Also access a local version of libqhull to test
# that additional rpath possibility.
# Put a local build of CMake-3.13.2 first on the PATH to thoroughly test our
# build system for our new minimum version of CMake.
# Use the -DUSE_INCRTCL_VERSION_4=ON option to help CMake find Tcl/Tk
# components. (This step will not be necessary as soon as the PLplot
# build system is modified to make Tcl/Tk/Itcl/Itk/Iwidgets finding
# more robust.)
# Use -DSWIG_EXECUTABLE=/home/software/swig/install/bin/swig to test a pre-release version
# of swig-4.0.0.
# Apply no constraints to limit the tests.
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5:/home/software/lasi_svn/install:/home/software/qhull/install PATH="/home/software/cmake/install-3.13.2/bin:$PATH" "$SOURCE_PREFIX"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DSWIG_EXECUTABLE=/home/software/swig/install/bin/swig" --build_command "make -j16" --ctest_command "ctest -j16")
This command ran without issues (e.g., hangs or other obvious errors)
and was followed up by the evaluation procedure documented in
doc/wiki_source/Testing_PLplot. That evaluation showed no configure,
build, or obvious run-time errors (i.e., no non-zero return codes for
any of the steps in this comprehensive test), and the difference test
results (done with the default svg device) were perfect. Finally, since
the script itself was changed for this test, I confirmed that the
script did all steps it was supposed to in the correct order, e.g.,
the new execution of ctest in the installed examples tree after the "all"
target was built there.
M CMakeLists.txt
R100 CTestCustom.ctest.in CTestCustom.cmake.in
M examples/CMakeLists.txt
M plplot_test/CMakeLists.txt
M scripts/comprehensive_test.sh
commit ae398a4e64a4bbe4bb78f40a6a20334fc29530a1
Author: Alan W. Irwin <[email protected]>
Date: Wed Mar 27 16:31:41 2019 -0700
Fix bug in octave binding
For octave 4.4, I was obtaining the following result when building the
test_octave_xwin target.
Testing interactive octave examples for device xwin
p1
p2
p3
p8
p9
p12
error: string(1): out of bound 0
error: called from
ginput at line 56 column 11
p12 at line 27 column 9
where line 56 of bindings/octave/PLplot/ginput.m
was
str = double(string(1));
and the issue was string was empty (which apparently it always is if
you click with a mouse button). I fixed this issue by making sure
that string(1) was not converted by double unless string had a
non-zero length.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by successfully building the test_octave_xwin target.
M bindings/octave/PLplot/ginput.m
commit 6b00b9717a6c98ee16e49f991957f91cb5b76c1f
Author: Alan W. Irwin <[email protected]>
Date: Mon Mar 18 15:47:21 2019 -0700
Future-proof PLplot against changes in a pre-release version of swig-4.0.0
This commit is a response to the swig bug report at <https://sourceforge.net/p/swig/mailman/message/36603481/> where it is shown that a pre-release version of swig-4.0.0 does not work correctly with
plplot-5.14.0. I verified this issue for myself with swig git version rel-3.0.12-1639-gd3ae85ee7
(i.e., 1639 commits beyond the 3.0.12 release of swig) and fixed the issue in PLplot corresponding
to William Fulton's advice in the above mailing-list discussion, i.e., replaced
- if ( strcmp( str, "<built-in function pltr0>" ) == 0 )
+ if ( strstr( str, "function pltr0" ) != 0 )
etc., for pltr0, pltr1, and pltr2 where he stated this change
should work both for swig3 (which implements these functions as build-ins) and swig4
(which implements these functions in raw form rather than as build-ins).
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) as part of the unconstrained comprehensive test used
for the previous commit (that test was done with the current change in
the working directory). That comprehensively tested the current
change for only the system version of swig (i.e., swig-3.0.12 from
Debian Testing).
In addition I tested the current change for a pre-release version of
swig-4.0.0 (swig git version rel-3.0.12-1639-gd3ae85ee7) by
configuring PLplot using
-DSWIG_EXECUTABLE=/home/software/swig/install/bin/swig (to access that
locally built and installed version) and building the
test_noninteractive target in the (shared) core build tree. The
resulting cmake.out and test_noninteractive.out files were evaluated
as follows:
# Check for errors
grep -i error *.out
# Check for regressions in configuration warnings:
grep -i warning cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING'
# Currently on Cygwin systems you get a mixture of Unix and Windows line endings so
# make those equivalent with the "tr" stanza (which does not harm on other platforms).
grep -A1 --no-filename "PLPLOT WARNING" *.out |tr --delete $'\r' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated
# above, spurious gfortran warnings, and warnings concerning test_diff differences:
grep -i warning *.out|grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic|Some graphical' |less
# Check for any file device (which defaults to the svg device, see below) or stdout
# differences between all non-C languages and the corresponding C results:
grep -B1 -A3 "Missing examples" *.out |less
These evaluations demonstrated that William Fulton's suggested PLplot
fix of the Python binding issue was backwards compatible with swig3 and
fixed the swig4 issue (as he expected). Furthermore, there were no
other PLplot issues introduced by this pre-release version of
swig-4.0.0. That is, for both the octave3 case tested previously and
the current octave4 test there were no configuration, build, or
run-time issues with these results and the difference report (for the
default svg device) was perfect.
M bindings/python/plplotc.i
commit daafa7b60a8eedfad9084dbf703a6a3954489c6f
Author: Alan W. Irwin <[email protected]>
Date: Mon Mar 18 15:00:19 2019 -0700
Drop our own version of UseSWIG.cmake so that users access the upstream CMake version of this file
Our own version of this file that this commit drops corresponds to the
upstream version for CMake-3.9.1, but since our own minimum version of
CMake (3.13.2) is far beyond that version it is better to allow our users to
take advantage of all the upstream development that has gone into
UseSWIG.cmake since 3.9.1.
That said, it appears our build-system logic was relying on internal details of version 3.9.1 of
UseSWIG.cmake because the new version replaces all swig target names with leading
underscores with that same name without the underscore. As a result we
had to make the following changes throughout our build system to be consistent
with the new version(s) of UseSWIG.cmake for CMake-3.13.2 (our minimum version)
and beyond:
- PLPLOT::_plplotc
+ PLPLOT::plplotc
- PLPLOT::_Pltk_init
+ PLPLOT::Pltk_init
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by the following steps:
# Choose these prefixes to assure that the source, build, and install tree have
# blanks in their pathname (to test that case during this comprehensive test)
COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
SOURCE_PREFIX="/home/software/plplot/HEAD/plplot blank .git"
# Set CMAKE_PREFIX_PATH to access local versions of lua and libLASi to
# avoid important bugs in the Debian Testing versions of those
# packages. Also access a local version of libqhull to test
# that additional rpath possibility.
# Put a local build of CMake-3.13.2 first on the PATH to thoroughly test our
# build system for our new minimum version of CMake.
# Use the -DUSE_INCRTCL_VERSION_4=ON option to help CMake find Tcl/Tk
# components. (This step will not be necessary as soon as the PLplot
# build system is modified to make Tcl/Tk/Itcl/Itk/Iwidgets finding
# more robust.)
# Apply no constraints to limit the tests.
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5:/home/software/lasi_svn/install:/home/software/qhull/install PATH="/home/software/cmake/install-3.13.2/bin:$PATH" "$SOURCE_PREFIX"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j16" --ctest_command "ctest -j16")
This command ran without issues (e.g., hangs or other obvious errors)
and was followed up by the evaluation procedure documented in
doc/wiki_source/Testing_PLplot. That evaluation showed no configure,
build, or obvious run-time errors (i.e., no non-zero return codes for
any of the steps in this comprehensive test), and the difference test
results (done with the default svg device) were perfect.
D cmake/modules/UseSWIG.cmake
M examples/CMakeLists.txt
M examples/python/CMakeLists.txt
commit 902c8882bc3ba98aeecac37f23bfd492fc736887
Author: Alan W. Irwin <[email protected]>
Date: Fri Mar 8 17:28:53 2019 -0800
Core library bug fixes: Substantial upgrade to the opt_bg logic for parsing the -bg command-line option
These bug fixes were motivated by a fairly recent adventure where I
specified the -bg 00F0.3 option when trying to debug a transparency
"issue". Because I forgot the underscore delimiter (i.e., I should
have specified -bg 00F_0.3 instead) it *silently* gave me the
equivalent of -bg 00F which wasted a lot of my time and the time of
others I was communicating with about esoteric reasons why that 0.3
was being ignored.
To deal with this and other "non-robust" bugs when parsing the -bg
command-line option I rewrote the opt_bg logic.
That logic is now implemented as follows:
1. Split the argument string at the first "_" delimiter, with
color_field being a pointer to the (now null-terminated at the
position of the delimiter) string before the delimiter and
alpha_field being a pointer to the string after the delimiter. But
if no delimiter exists then color_field points to the whole
argument string and alpha_pointer points to the string constant
"1.0".
2. Parse color_field as hexadecimal using strtol with base 16 with
full checking of possible error conditions with appropriate response
(warning message + corrective action of setting color to (warning)
red) for integer overflow and invalid string conditions
detected by strtol, and appropriate action (just a warning message)
when there was a non-hexadecimal garbage suffix detected by strtol.
N.B. According to the strtol man page, "The string may begin with
an arbitrary amount of white space (as determined by isspace(3))
followed by a single optional '+' or '-' sign. If base is [...]
16, the string may then include a "0x" or "0X" prefix, and the
number will be read in base 16".
3. Convert those signed hexadecimal characters stored in a long result
to r, g, b with evaluation of a possible error condition (i.e.,
color_field without isspace, sign, and 0x or 0X optional prefixes
and without trailing non-hex digits is not either exactly 3 or 6
hex digits) with appropriate response (warning message + corrective
action of set color to (warning) red) for this error condition.
Note in the case of 3 hex digits the result is "doubled", e.g.,
"001" ==> 000011 and "fab" ==> "ffaabb" before the final r,g,b
results are determined for the background colour. Also note that
negative signs are interpreted as the hexadecimal two's complement,
i.e., "-fff" ==> "001" (before the "doubling" to "000011") and
"-ffffff " ==> "000001".
4. Parse alpha_field as double using strtod with full evaluation of
possible error conditions with appropriate action (warning message
+ corrective action of set alpha to 1. = opaque) for
floating overflow and invalid string to parse conditions
detected by strtod, and appropriate action (just a warning message)
when there was a non-floating-point garbage suffix detected by strtod.
N.B. According to the strtod man page, "The expected form of the
(initial portion of the) string is optional leading white space as
recognized by isspace(3), an optional plus ('+') or minus sign
('-') and then either (i) a decimal number, or (ii) a hexadecimal
number, or (iii) an infinity, or (iv) a NAN (not-a-number).
Thus, opt_bg simply propagates certain invalid alpha values which
the user might specify such as several different variants of signed
upper or lower-case versions of "nan" and "inf" strings or ordinary
floating point numbers that are out of the valid alpha range from
0. to 1. (MIN_PLFLT_ALPHA to MAX_PLFLT_ALPHA) to the function
plscolbga which it calls, and that function is responsible for
handling all such out-of-range alpha issues. Which it does by
issuing a warning message and using the appropriate substituted
value, i.e, for +/- inf or ordinary out of range the substituted
value is MIN_PLFLT_ALPHA or MAX_PLFLT_ALPHA (whichever is closest
to the user-specified value) while for +/- nan the substituted
value is MAX_PLFLT_ALPHA = 1., i.e., opaque.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by building the x00c and svg targets for a locally
modified version of src/plargs.c that printed out derived
r, g, b, and alpha values and by running
valgrind examples/c/x00c -dev svg -o test.svg -bg "<some string>"
In all <some string> cases, the valgrind
results were perfect ("All heap blocks were freed -- no leaks are
possible" and "ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0
from 0)"), and the derived r, g, b, and alpha values as expected.
To summarize these tests for various <some string> values, the "_"
delimiter appears to work properly; strtol (color field) and strtod
(alpha field) appear to work properly with correct detection and
warning of certain issues (i.e., invalid strings that cannot be
converted, trailing garbage, integer [strol] or floating [strtod]
overflow) with warning messages and appropriate corrective action as
described above; detection of either 3 hex or 6 hex digits in the
color field appears to work correctly with the 3-digit case correctly
"doubled" as described above; and for the alpha field case floating
point strings corresponding to positive and negative Inf and NaN
values are silently accepted without strtod error, but those invalid
alpha values are then detected, warned, and substituted for in the
plscolbga routine as described above.
M src/plargs.c
commit e59bc623794e26430da331be474bce340ebcf936
Author: Alan W. Irwin <[email protected]>
Date: Thu Mar 7 14:07:57 2019 -0800
Core library: Improve range checks and use of symbolic constants for the color map routines
The following symbolic constants are now used extensively in our colour map routines.
+// Color limits:
+
+// Default number of colors for cmap0 and cmap1.
+#define PL_DEFAULT_NCOL0 16
+#define PL_DEFAULT_NCOL1 128
+// minimum and maximum PLINT RGB values.
+#define MIN_PLINT_RGB 0
+#define MAX_PLINT_RGB 255
+// minimum and maximum PLFLT cmap1 color index values.
+#define MIN_PLFLT_CMAP1 0.
+#define MAX_PLFLT_CMAP1 1.
+// minimum and maximum PLFLT alpha values.
+#define MIN_PLFLT_ALPHA 0.
+#define MAX_PLFLT_ALPHA 1.
Furthermore, those colour map routines now use these symbolic
constants to do much more extensive checking of the validity of cmap1
index values and cmap0 and cmap1 colours that are specified by the
user using the above limits. And this is now done for RGB(A) colours
in a standardized way using the new static routine limit_rgba_range.
As implemented in that routine when the user does specify an invalid
RGB(A) color the recovery is now a much smoother one (plwarn + fixup)
rather than the prior plabort and return. That same "soft landing"
approach is also now used in several places in src/plctrl.c when an
invalid cmap1 index is specified by the user.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by building the test_noninteractive and
test_interactive targets in the (shared) core build tree. The
resulting cmake.out, test_noninteractive.out and test_interactive.out
files were evaluated as follows:
# Check for errors
grep -i error *.out
# Check for regressions in configuration warnings:
grep -i warning cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING'
# Currently on Cygwin systems you get a mixture of Unix and Windows line endings so
# make those equivalent with the "tr" stanza (which does not harm on other platforms).
grep -A1 --no-filename "PLPLOT WARNING" *.out |tr --delete $'\r' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated
# above, spurious gfortran warnings, and warnings concerning test_diff differences:
grep -i warning *.out|grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic|Some graphical' |less
# Check for any file device (which defaults to the svg device, see below) or stdout
# differences between all non-C languages and the corresponding C results:
grep -B1 -A3 "Missing examples" *.out |less
In addition I viewed examples that used cmap0 and cmap1 colours extensively as follows:
pqiv -i examples/test_examples_output_dir/x02c0[12].svg
pqiv -i examples/test_examples_output_dir/x12c01.svg
pqiv -i examples/test_examples_output_dir/x15c0[1-9].svg
pqiv -i examples/test_examples_output_dir/x16c0[1-9].svg
In sum, the above evaluations of the *.out results showed there were
no concerns with any configuration, build, or run-time issues with
these results and the difference report (for the default svg device)
was perfect. Furthermore, the above rendering of the svg results
showed no obvious colour rendering bugs.
M include/plplot.h
M src/plctrl.c
commit 3d00e8ddc85ec3068d148493dd771288fa7df429
Author: Alan W. Irwin <[email protected]>
Date: Wed Mar 6 15:22:16 2019 -0800
Core library: check hershey_to_unicode_lookup_table array access for index out of range conditions
For those occasions when the index is out of range, substitute
(PLUNICODE) 0x00 ("unknown" unicode character) for the unicode value
and 0 (apparently unknown font face according to notes in the
generated include/plhershey-unicode.h file) for the font face. Note,
however, that I looked through our source code for all instances of
font_face, and I could not find any place where it was actually used.
Therefore, it may just be a place holder where the actual value
does not matter.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by building the test_noninteractive and test_interactive
targets in the (shared) core build tree. The resulting cmake.out, test_noninteractive.out and
test_interactive.out files were evaluated as follows:
# Check for errors
grep -i error *.out
# Check for regressions in configuration warnings:
grep -i warning cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING'
# Currently on Cygwin systems you get a mixture of Unix and Windows line endings so
# make those equivalent with the "tr" stanza (which does not harm on other platforms).
grep -A1 --no-filename "PLPLOT WARNING" *.out |tr --delete $'\r' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated
# above, spurious gfortran warnings, and warnings concerning test_diff differences:
grep -i warning *.out|grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic|Some graphical' |less
# Check for any file device (which defaults to the svg device, see below) or stdout
# differences between all non-C languages and the corresponding C results:
grep -B1 -A3 "Missing examples" *.out |less
The above evaluations of the *.out results showed there were no
concerns with configuration, build, or run-time issues with these
results and the difference report (for the default svg device) was
perfect.
M src/plcore.c
M src/plsym.c
commit d19b7f06d90ae327bab32483517d769e50acb398
Author: Alan W. Irwin <[email protected]>
Date: Tue Mar 5 20:43:58 2019 -0800
Remove unneeded libplplot dependency on qhull headers
Before this commit, libplplot (via src/plgridd.c) implemented a
run-time check concerning the size of the realT type used by libqhull
which forced this library be dependent on qhull headers even though
(unlike the csironn library) libplplot is not directly dependent on
the qhull library. This commit removes this unnecessary complication
by implementing a CMake-based configuration check concerning the size
of the realT type used by libqhull. If that check is not satisfied,
then our build system now simply drops use of qhull by dropping the
build and use of the csironn library.
N.B. src/plgridd.c now does include source code that depends directly
on both the qhull headers and qhull library. However, this code is
protected by by the conditional compilation macro PLPLOT_NONN. This
macro (previously named NONN) has not been #defined in our official
source tree for more than a decade which is why our build system
currently ignores the PLPLOT_NONN possibility and simply directly
links libplplot to the csironn library instead of using this internal
functionality. Of course, if someone wants to try out use of this
internal functionality, the required build system changes would nearly
be trivial. That is, the build system would need changes to provide
the PLPLOT_NONN cmake option, convert it to a C macro of the same name
which is #defined or not depending on whether the option is true or
not, and if the option is true drop the build of the csironn library
and drop the libplplot dependency on that library.
This commit also provides a change (preferring the libqhull form of
includes over the old qhull form) so that the headers for a local
build of upstream qhull (which always uses the libqhull form now)
can be found consistently with the library for
that local build that is found.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) using the same extensive tests described for
the prior commit which used all these qhull-related changes
to PLplot that were in the working directory but not committed
at that time.
M cmake/modules/FindQHULL.cmake
M cmake/modules/csiro.cmake
M src/CMakeLists.txt
M src/plgridd.c
commit 03e06049d828cb817df163ee8c1f980efebef0be
Author: Alan W. Irwin <[email protected]>
Date: Tue Mar 5 19:27:55 2019 -0800
Build system: Rewrite the rpath configuration of the traditionally built examples
This commit follows the same rigourous rpath method for the
traditionally built examples that was used previously to set the
INSTALL_RPATH property of installed targets. See the README.release
file for full details concerning this change. Note this commit solves
an ocaml rpath bug that was not exposed for my tests of the earlier
INSTALL_RPATH commit because those earlier tests were constrained too
much. So as far as I know the combination of this commit and the
INSTALL_RPATH changes described in the earlier commit eliminates the
last known regression against the good unconstrained comprehensive
test results I historically achieved for the Debian Jessie platform.
Tested by: Alan W. Irwin <[email protected]> on Linux
(Debian Testing) by the following steps:
# Choose these prefixes to assure that the source, build, and install tree have
# blanks in their pathname (to test that case during this comprehensive test)
COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
SOURCE_PREFIX="/home/software/plplot/HEAD/plplot blank .git"
# Set CMAKE_PREFIX_PATH to access local versions of lua and libLASi to
# avoid important bugs in the Debian Testing versions of those
# packages. Also access a local version of libqhull to test
# that additional rpath possibility. (This only works because of additional
# qhull configuration changes for our build system that are in my working
# directory but not commmitted yet. However, if I had used the system
# version of qhull instead, the test would have been weaker and therefore
# would very likely also succeed as well.)
# Put a local build of CMake-3.13.2 first on the PATH to thoroughly test our
# build system for our new minimum version of CMake.
# Use the -DUSE_INCRTCL_VERSION_4=ON option to help CMake find Tcl/Tk
# components. (This step will not be necessary as soon as the PLplot
# build system is modified to make Tcl/Tk/Itcl/Itk/Iwidgets finding
# more robust.)
# Apply no constraints to limit the tests.
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5:/home/software/lasi_svn/install:/home/software/qhull/install PATH="/home/software/cmake/install-3.13.2/bin:$PATH" "$SOURCE_PREFIX"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j16" --ctest_command "ctest -j16")
N.B. the above command is a convenient summary of what I actually
tested in a piece-meal way due to typographical errors in the ocaml
rpath configuration that were fixed between when the interactive part
(with failing noninteractive part) and noninteractive part
(constrained by --do_interactive_testing no) of the above test were
done.
The interactive part of the first attempt and the (noninteractive)
second attempt of the above command ran without issues (e.g., hangs or
other obvious errors) and was followed up by the evaluation procedure
documented in doc/wiki_source/Testing_PLplot. That evaluation showed
no configure, build, or obvious run-time errors (i.e., no non-zero
return codes for any of the steps in this comprehensive test), and the
difference test results (done with the default svg device) were
perfect.
In addition I checked all installed targets (for the noninteractive
case, but the interactive case should be identical) with readelf as
follows:
pushd "$COMPREHENSIVE_TEST_PREFIX/nondynamic/noninteractive/install_tree/lib"
(for SO in $(find . -name "*.so") ; do echo $SO; readelf -d $SO |grep -E 'NEEDED|PATH'; done) |less
(for SO in $(find ../bin -type f) ; do echo $SO; readelf -d $SO |grep -E 'NEEDED|PATH'; done) |less
readelf -d octave/plplot_octave.oct |grep -E 'NEEDED|PATH'
I also used "readelf -d" to check the traditionally built nondynamic examples as follows:
# 1. OCaml example in the CMake-based build tree for the core build:
cd ../../build_tree/
# Need to remake because script cleans up all these results
make target_x00ocaml
readelf -d examples/ocaml/x00ocaml |grep -E 'NEEDED|PATH' |less
# 2. OCaml example in the CMake-based build tree for the installed examples:
cd ../install_build_tree/
# Need to remake because script cleans up all these results
make target_x00ocaml
readelf -d ocaml/x00ocaml |grep -E 'NEEDED|PATH' |less
# 3. All *00* compiled examples in the traditionally built installed examples:
cd ../install_tree/share/plplot5.14.0/examples
# Rebuild everything because script cleans up all these results
make -j16
# Drop source code and some scripts by eliminating all file names with a "." in them.
# Drop tcl and python "00" examples since those are not compiled.
(for example in $(\ls */*00* |grep -vE "\\.|tcl|python") ; do echo $example; readelf -d $example|grep -E 'NEEDED|PATH'; done) |less
# 4. All "special" traditionally built executables.
(for example in c/ext-cairo-test c++/qt_example c++/wxPLplotDemo tk/xtk0[124] ; do echo $example; readelf -d $example|grep -E 'NEEDED|PATH'; done) |less
I also repeated all the above readelf checks for the shared
cd "$COMPREHENSIVE_TEST_PREFIX/shared/noninteractive/install_tree/lib"
...
and static
cd "$COMPREHENSIVE_TEST_PREFIX/static/noninteractive/install_tree/lib"
...
cases. Note that in the static case there are no *.so (or *.oct)
results to analyze but the runpath results for installed executable
targets and traditionally built examples are larger due to the
transitive rpath method that must be used for this case.
These readelf results showed the expected NEEDED and RUNPATH results in all cases.
In sum, this set of *unconstrained* comprehensive tests and follow-up
readelf tests appears to confirm that the new rigourous rpath method
is working properly for both the installed targets AND traditionally
built examples for the (modern DT_RUNPATH) Debian Testing = Buster
platform.
M README.release
M cmake/modules/plplot_functions.cmake
M examples/CMakeLists.txt
M examples/ada/Makefile.examples.in
M examples/c++/Makefile.examples.in
M examples/c/Makefile.examples.in
M examples/d/Makefile.examples.in
M examples/fortran/CMakeLists.txt
M examples/fortran/Makefile.examples.in
M examples/ocaml/CMakeLists.txt
M examples/ocaml/Makefile.examples.in
M examples/plplot_configure.cmake_installed_examples.in
M examples/tk/Makefile.examples.in
commit c99bc660f3edd7262ce8148a21b23aad4ae879f7
Author: Alan W. Irwin <[email protected]>
Date: Fri Mar 1 09:51:10 2019 -0800
Tweak the wording of the discussion of the recent INSTALL_RPATH configuration rewrite
M README.release
commit fc0ba06b8db38c477a055b605cd186861b2bcf36
Author: Alan W. Irwin <[email protected]>
Date: Thu Feb 28 12:44:16 2019 -0800
Add discussion of recent INSTALL_RPATH configuration rewrite to our (future) release notes
This discussion was copied from what I recently wrote to the plplot-devel mailing list
concerning these recent changes.
M README.release
commit 3b140b22f7c8e038c16369d3612327b22bef3dd9
Author: Alan W. Irwin <[email protected]>
Date: Thu Feb 28 03:06:40 2019 -0800
Build system: Implement transitive treatment for rpath which is used for the static case