Menu
▾
▴
plplot-devel — Technical discussion about PLplot development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
| 2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
| 2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
| 2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
| 2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
| 2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
| 2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
| 2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
| 2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
| 2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
| 2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
| 2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
| 2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
| 2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
| 2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
| 2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
| 2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
| 2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
| 2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
| 2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
|
From: Pedro V. <ped...@sp...> - 2016-10-09 06:27:41
|
Hi Alan
>>So I don't understand why you end up building that independent target
>>using visual studio. Is there some capability for that IDE where you
>>can build every target whether they are independent of other targets
>>or not?
ok, I see the issue now.
yes, it's possible to build each individual project in Visual Studio
I just did a "build solution" , that builds all generated projects that were
generated by cmake
the fix then is not to have cmake generate "generate_announcements" for
Windows,
not only this but others too that fail
Build started: Project: create_staging_announce,
Build started: Project: check_plplotcapi_defines,
Build started: Project: create_staging,
Build started: Project: test_c_ps
Build started: Project: test_c_wingcc
Build started: Project: test_c_wxwidgets
all these fail because of similar issues like
'env' is not recognized as an internal or external command,
========== Build: 6 succeeded, 10 failed, 84 up-to-date, 20 skipped
==========
I send here the complete output
thanks
-Pedro
------ Build started: Project: deltaT.h_built, Configuration: Debug
Win32 ------
------ Build started: Project: tai-utc.h_built, Configuration: Debug
Win32 ------
------ Build started: Project: plhershey-unicode.h_built, Configuration:
Debug Win32 ------
------ Build started: Project: generate_announcements, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/www/announce/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\www\announce\CMakeFiles\generate.stamp is
up-to-date.
Generating announce-plplot-5.3.0.html
'xmlto' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: x19, Configuration: Debug Win32 ------
x19.obj : error LNK2019: unresolved external symbol "int __cdecl
plsnprintf(char *,int,char const *,...)" (?plsnprintf@@YAHPADHPBDZZ)
referenced in function "void __cdecl geolocation_labeler(int,double,char
*,int,void *)" (?geolocation_labeler@@YAXHNPADHPAX@Z)
M:\plot\plplot-5.11.1\build\examples\c++\Debug\x19.exe : fatal error
LNK1120: 1 unresolved externals
------ Build started: Project: create_staging_announce, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/www/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\www\CMakeFiles\generate.stamp is up-to-date.
Generating staging/htdocs/announce/ChangeLog-5.2.1-5.3.0
'cp' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: check_plplotcapi_defines, Configuration:
Debug Win32 ------
Building Custom Rule
M:/plot/plplot-5.11.1/bindings/swig-support/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\bindings\swig-support\CMakeFiles\generate.stamp
is up-to-date.
Check that numerical #defines in bindings/swig-support/plplotcapi.i are
consistent with the numerical #defines in include/plplot.h
An error for this target implies the numerical #defines section of
bindings/swig-support/plplotcapi.i needs updating following the directions
in that file
'grep' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 255.
------ Build started: Project: create_staging, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/www/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\www\CMakeFiles\generate.stamp is up-to-date.
Generating staging/htdocs/corefunctions.php
'cp' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_c_ps, Configuration: Debug Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/examples/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\examples\CMakeFiles\generate.stamp is
up-to-date.
Generating test_examples_output_dir/x00c.ps,
test_examples_output_dir/x00c_ps.txt, test_examples_output_dir/x01c.ps,
test_examples_output_dir/x01c_ps.txt, test_examples_output_dir/x02c.ps,
test_examples_output_dir/x02c_ps.txt, test_examples_output_dir/x03c.ps,
test_examples_output_dir/x03c_ps.txt, test_examples_output_dir/x04c.ps,
test_examples_output_dir/x04c_ps.txt, test_examples_output_dir/x05c.ps,
test_examples_output_dir/x05c_ps.txt, test_examples_output_dir/x06c.ps,
test_examples_output_dir/x06c_ps.txt, test_examples_output_dir/x07c.ps,
test_examples_output_dir/x07c_ps.txt, test_examples_output_dir/x08c.ps,
test_examples_output_dir/x08c_ps.txt, test_examples_output_dir/x09c.ps,
test_examples_output_dir/x09c_ps.txt, test_examples_output_dir/x10c.ps,
test_examples_output_dir/x10c_ps.txt, test_examples_output_dir/x11c.ps,
test_examples_output_dir/x11c_ps.txt, test_examples_output_dir/x12c.ps,
test_examples_output_dir/x12c_ps.txt, test_examples_output_dir/x13c.ps,
test_examples_output_dir/x13c_ps.txt, test_examples_output_dir/x14c.ps,
test_examples_output_dir/x14c_ps.txt, test_examples_output_dir/x14ac.ps,
test_examples_output_dir/x15c.ps, test_examples_output_dir/x15c_ps.txt,
test_examples_output_dir/x16c.ps, test_examples_output_dir/x16c_ps.txt,
test_examples_output_dir/x17c.ps, test_examples_output_dir/x17c_ps.txt,
test_examples_output_dir/x18c.ps, test_examples_output_dir/x18c_ps.txt,
test_examples_output_dir/x19c.ps, test_examples_output_dir/x19c_ps.txt,
test_examples_output_dir/x20c.ps, test_examples_output_dir/x20c_ps.txt,
test_examples_output_dir/x21c.ps, test_examples_output_dir/x21c_ps.txt,
test_examples_output_dir/x22c.ps, test_examples_output_dir/x22c_ps.txt,
test_examples_output_dir/x23c.ps, test_examples_output_dir/x23c_ps.txt,
test_examples_output_dir/x24c.ps, test_examples_output_dir/x24c_ps.txt,
test_examples_output_dir/x25c.ps, test_examples_output_dir/x25c_ps.txt,
test_examples_output_dir/x26c.ps, test_examples_output_dir/x26c_ps.txt,
test_examples_output_dir/x27c.ps, test_examples_output_dir/x27c_ps.txt,
test_examples_output_dir/x28c.ps, test_examples_output_dir/x28c_ps.txt,
test_examples_output_dir/x29c.ps, test_examples_output_dir/x29c_ps.txt,
test_examples_output_dir/x30c.ps, test_examples_output_dir/x30c_ps.txt,
test_examples_output_dir/x31c.ps, test_examples_output_dir/x31c_ps.txt,
test_examples_output_dir/x33c.ps, test_examples_output_dir/x33c_ps.txt
Generate C results for ps file device
'env' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_c_svg, Configuration: Debug Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/examples/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\examples\CMakeFiles\generate.stamp is
up-to-date.
Generating test_examples_output_dir/x00c01.svg,
test_examples_output_dir/x00c_svg.txt, test_examples_output_dir/x01c01.svg,
test_examples_output_dir/x01c_svg.txt, test_examples_output_dir/x02c01.svg,
test_examples_output_dir/x02c02.svg, test_examples_output_dir/x02c_svg.txt,
test_examples_output_dir/x03c01.svg, test_examples_output_dir/x03c_svg.txt,
test_examples_output_dir/x04c01.svg, test_examples_output_dir/x04c02.svg,
test_examples_output_dir/x04c_svg.txt, test_examples_output_dir/x05c01.svg,
test_examples_output_dir/x05c_svg.txt, test_examples_output_dir/x06c01.svg,
test_examples_output_dir/x06c02.svg, test_examples_output_dir/x06c03.svg,
test_examples_output_dir/x06c04.svg, test_examples_output_dir/x06c05.svg,
test_examples_output_dir/x06c_svg.txt, test_examples_output_dir/x07c01.svg,
test_examples_output_dir/x07c02.svg, test_examples_output_dir/x07c03.svg,
test_examples_output_dir/x07c04.svg, test_examples_output_dir/x07c05.svg,
test_examples_output_dir/x07c06.svg, test_examples_output_dir/x07c07.svg,
test_examples_output_dir/x07c08.svg, test_examples_output_dir/x07c09.svg,
test_examples_output_dir/x07c10.svg, test_examples_output_dir/x07c11.svg,
test_examples_output_dir/x07c12.svg, test_examples_output_dir/x07c13.svg,
test_examples_output_dir/x07c14.svg, test_examples_output_dir/x07c15.svg,
test_examples_output_dir/x07c16.svg, test_examples_output_dir/x07c17.svg,
test_examples_output_dir/x07c18.svg, test_examples_output_dir/x07c19.svg,
test_examples_output_dir/x07c20.svg, test_examples_output_dir/x07c_svg.txt,
test_examples_output_dir/x08c01.svg, test_examples_output_dir/x08c02.svg,
test_examples_output_dir/x08c03.svg, test_examples_output_dir/x08c04.svg,
test_examples_output_dir/x08c05.svg, test_examples_output_dir/x08c06.svg,
test_examples_output_dir/x08c07.svg, test_examples_output_dir/x08c08.svg,
test_examples_output_dir/x08c_svg.txt, test_examples_output_dir/x09c01.svg,
test_examples_output_dir/x09c02.svg, test_examples_output_dir/x09c03.svg,
test_examples_output_dir/x09c04.svg, test_examples_output_dir/x09c05.svg,
test_examples_output_dir/x09c_svg.txt, test_examples_output_dir/x10c01.svg,
test_examples_output_dir/x10c_svg.txt, test_examples_output_dir/x11c01.svg,
test_examples_output_dir/x11c02.svg, test_examples_output_dir/x11c03.svg,
test_examples_output_dir/x11c04.svg, test_examples_output_dir/x11c05.svg,
test_examples_output_dir/x11c06.svg, test_examples_output_dir/x11c07.svg,
test_examples_output_dir/x11c08.svg, test_examples_output_dir/x11c_svg.txt,
test_examples_output_dir/x12c01.svg, test_examples_output_dir/x12c_svg.txt,
test_examples_output_dir/x13c01.svg, test_examples_output_dir/x13c_svg.txt,
test_examples_output_dir/x14c01.svg, test_examples_output_dir/x14c02.svg,
test_examples_output_dir/x14c_svg.txt, test_examples_output_dir/x14ac01.svg,
test_examples_output_dir/x14ac02.svg, test_examples_output_dir/x15c01.svg,
test_examples_output_dir/x15c02.svg, test_examples_output_dir/x15c03.svg,
test_examples_output_dir/x15c_svg.txt, test_examples_output_dir/x16c01.svg,
test_examples_output_dir/x16c02.svg, test_examples_output_dir/x16c03.svg,
test_examples_output_dir/x16c04.svg, test_examples_output_dir/x16c05.svg,
test_examples_output_dir/x16c_svg.txt, test_examples_output_dir/x17c01.svg,
test_examples_output_dir/x17c_svg.txt, test_examples_output_dir/x18c01.svg,
test_examples_output_dir/x18c02.svg, test_examples_output_dir/x18c03.svg,
test_examples_output_dir/x18c04.svg, test_examples_output_dir/x18c05.svg,
test_examples_output_dir/x18c06.svg, test_examples_output_dir/x18c07.svg,
test_examples_output_dir/x18c08.svg, test_examples_output_dir/x18c_svg.txt,
test_examples_output_dir/x19c01.svg, test_examples_output_dir/x19c02.svg,
test_examples_output_dir/x19c03.svg, test_examples_output_dir/x19c04.svg,
test_examples_output_dir/x19c_svg.txt, test_examples_output_dir/x20c01.svg,
test_examples_output_dir/x20c02.svg, test_examples_output_dir/x20c03.svg,
test_examples_output_dir/x20c04.svg, test_examples_output_dir/x20c05.svg,
test_examples_output_dir/x20c06.svg, test_examples_output_dir/x20c_svg.txt,
test_examples_output_dir/x21c01.svg, test_examples_output_dir/x21c02.svg,
test_examples_output_dir/x21c03.svg, test_examples_output_dir/x21c_svg.txt,
test_examples_output_dir/x22c01.svg, test_examples_output_dir/x22c02.svg,
test_examples_output_dir/x22c03.svg, test_examples_output_dir/x22c04.svg,
test_examples_output_dir/x22c_svg.txt, test_examples_output_dir/x23c01.svg,
test_examples_output_dir/x23c02.svg, test_examples_output_dir/x23c03.svg,
test_examples_output_dir/x23c04.svg, test_examples_output_dir/x23c05.svg,
test_examples_output_dir/x23c06.svg, test_examples_output_dir/x23c07.svg,
test_examples_output_dir/x23c08.svg, test_examples_output_dir/x23c09.svg,
test_examples_output_dir/x23c10.svg, test_examples_output_dir/x23c11.svg,
test_examples_output_dir/x23c12.svg, test_examples_output_dir/x23c13.svg,
test_examples_output_dir/x23c14.svg, test_examples_output_dir/x23c15.svg,
test_examples_output_dir/x23c16.svg, test_examples_output_dir/x23c_svg.txt,
test_examples_output_dir/x24c01.svg, test_examples_output_dir/x24c_svg.txt,
test_examples_output_dir/x25c01.svg, test_examples_output_dir/x25c02.svg,
test_examples_output_dir/x25c03.svg, test_examples_output_dir/x25c04.svg,
test_examples_output_dir/x25c05.svg, test_examples_output_dir/x25c06.svg,
test_examples_output_dir/x25c07.svg, test_examples_output_dir/x25c08.svg,
test_examples_output_dir/x25c_svg.txt, test_examples_output_dir/x26c01.svg,
test_examples_output_dir/x26c02.svg, test_examples_output_dir/x26c_svg.txt,
test_examples_output_dir/x27c01.svg, test_examples_output_dir/x27c02.svg,
test_examples_output_dir/x27c03.svg, test_examples_output_dir/x27c04.svg,
test_examples_output_dir/x27c05.svg, test_examples_output_dir/x27c06.svg,
test_examples_output_dir/x27c07.svg, test_examples_output_dir/x27c08.svg,
test_examples_output_dir/x27c09.svg, test_examples_output_dir/x27c10.svg,
test_examples_output_dir/x27c11.svg, test_examples_output_dir/x27c12.svg,
test_examples_output_dir/x27c13.svg, test_examples_output_dir/x27c14.svg,
test_examples_output_dir/x27c15.svg, test_examples_output_dir/x27c16.svg,
test_examples_output_dir/x27c17.svg, test_examples_output_dir/x27c18.svg,
test_examples_output_dir/x27c19.svg, test_examples_output_dir/x27c20.svg,
test_examples_output_dir/x27c_svg.txt, test_examples_output_dir/x28c01.svg,
test_examples_output_dir/x28c02.svg, test_examples_output_dir/x28c03.svg,
test_examples_output_dir/x28c04.svg, test_examples_output_dir/x28c05.svg,
test_examples_output_dir/x28c_svg.txt, test_examples_output_dir/x29c01.svg,
test_examples_output_dir/x29c02.svg, test_examples_output_dir/x29c03.svg,
test_examples_output_dir/x29c04.svg, test_examples_output_dir/x29c05.svg,
test_examples_output_dir/x29c06.svg, test_examples_output_dir/x29c07.svg,
test_examples_output_dir/x29c08.svg, test_examples_output_dir/x29c09.svg,
test_examples_output_dir/x29c10.svg, test_examples_output_dir/x29c_svg.txt,
test_examples_output_dir/x30c01.svg, test_examples_output_dir/x30c02.svg,
test_examples_output_dir/x30c_svg.txt, test_examples_output_dir/x31c01.svg,
test_examples_output_dir/x31c_svg.txt, test_examples_output_dir/x33c01.svg,
test_examples_output_dir/x33c02.svg, test_examples_output_dir/x33c03.svg,
test_examples_output_dir/x33c04.svg, test_examples_output_dir/x33c_svg.txt
Generate C results for svg file device
'env' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_c_wingcc, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/examples/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\examples\CMakeFiles\generate.stamp is
up-to-date.
Generate C results for wingcc interactive device
'env' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_c_wxwidgets, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/examples/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\examples\CMakeFiles\generate.stamp is
up-to-date.
Generate C results for wxwidgets interactive device
'env' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_c_xfig, Configuration: Debug
Win32 ------
Building Custom Rule M:/plot/plplot-5.11.1/examples/CMakeLists.txt
CMake does not need to re-run because
M:\plot\plplot-5.11.1\build\examples\CMakeFiles\generate.stamp is
up-to-date.
Generating test_examples_output_dir/x00c01.xfig,
test_examples_output_dir/x00c_xfig.txt,
test_examples_output_dir/x01c01.xfig,
test_examples_output_dir/x01c_xfig.txt,
test_examples_output_dir/x02c01.xfig, test_examples_output_dir/x02c02.xfig,
test_examples_output_dir/x02c_xfig.txt,
test_examples_output_dir/x03c01.xfig,
test_examples_output_dir/x03c_xfig.txt,
test_examples_output_dir/x04c01.xfig, test_examples_output_dir/x04c02.xfig,
test_examples_output_dir/x04c_xfig.txt,
test_examples_output_dir/x05c01.xfig,
test_examples_output_dir/x05c_xfig.txt,
test_examples_output_dir/x06c01.xfig, test_examples_output_dir/x06c02.xfig,
test_examples_output_dir/x06c03.xfig, test_examples_output_dir/x06c04.xfig,
test_examples_output_dir/x06c05.xfig,
test_examples_output_dir/x06c_xfig.txt,
test_examples_output_dir/x07c01.xfig, test_examples_output_dir/x07c02.xfig,
test_examples_output_dir/x07c03.xfig, test_examples_output_dir/x07c04.xfig,
test_examples_output_dir/x07c05.xfig, test_examples_output_dir/x07c06.xfig,
test_examples_output_dir/x07c07.xfig, test_examples_output_dir/x07c08.xfig,
test_examples_output_dir/x07c09.xfig, test_examples_output_dir/x07c10.xfig,
test_examples_output_dir/x07c11.xfig, test_examples_output_dir/x07c12.xfig,
test_examples_output_dir/x07c13.xfig, test_examples_output_dir/x07c14.xfig,
test_examples_output_dir/x07c15.xfig, test_examples_output_dir/x07c16.xfig,
test_examples_output_dir/x07c17.xfig, test_examples_output_dir/x07c18.xfig,
test_examples_output_dir/x07c19.xfig, test_examples_output_dir/x07c20.xfig,
test_examples_output_dir/x07c_xfig.txt,
test_examples_output_dir/x08c01.xfig, test_examples_output_dir/x08c02.xfig,
test_examples_output_dir/x08c03.xfig, test_examples_output_dir/x08c04.xfig,
test_examples_output_dir/x08c05.xfig, test_examples_output_dir/x08c06.xfig,
test_examples_output_dir/x08c07.xfig, test_examples_output_dir/x08c08.xfig,
test_examples_output_dir/x08c_xfig.txt,
test_examples_output_dir/x09c01.xfig, test_examples_output_dir/x09c02.xfig,
test_examples_output_dir/x09c03.xfig, test_examples_output_dir/x09c04.xfig,
test_examples_output_dir/x09c05.xfig,
test_examples_output_dir/x09c_xfig.txt,
test_examples_output_dir/x10c01.xfig,
test_examples_output_dir/x10c_xfig.txt,
test_examples_output_dir/x11c01.xfig, test_examples_output_dir/x11c02.xfig,
test_examples_output_dir/x11c03.xfig, test_examples_output_dir/x11c04.xfig,
test_examples_output_dir/x11c05.xfig, test_examples_output_dir/x11c06.xfig,
test_examples_output_dir/x11c07.xfig, test_examples_output_dir/x11c08.xfig,
test_examples_output_dir/x11c_xfig.txt,
test_examples_output_dir/x12c01.xfig,
test_examples_output_dir/x12c_xfig.txt,
test_examples_output_dir/x13c01.xfig,
test_examples_output_dir/x13c_xfig.txt,
test_examples_output_dir/x14c01.xfig, test_examples_output_dir/x14c02.xfig,
test_examples_output_dir/x14c_xfig.txt,
test_examples_output_dir/x14ac01.xfig,
test_examples_output_dir/x14ac02.xfig, test_examples_output_dir/x15c01.xfig,
test_examples_output_dir/x15c02.xfig, test_examples_output_dir/x15c03.xfig,
test_examples_output_dir/x15c_xfig.txt,
test_examples_output_dir/x16c01.xfig, test_examples_output_dir/x16c02.xfig,
test_examples_output_dir/x16c03.xfig, test_examples_output_dir/x16c04.xfig,
test_examples_output_dir/x16c05.xfig,
test_examples_output_dir/x16c_xfig.txt,
test_examples_output_dir/x17c01.xfig,
test_examples_output_dir/x17c_xfig.txt,
test_examples_output_dir/x18c01.xfig, test_examples_output_dir/x18c02.xfig,
test_examples_output_dir/x18c03.xfig, test_examples_output_dir/x18c04.xfig,
test_examples_output_dir/x18c05.xfig, test_examples_output_dir/x18c06.xfig,
test_examples_output_dir/x18c07.xfig, test_examples_output_dir/x18c08.xfig,
test_examples_output_dir/x18c_xfig.txt,
test_examples_output_dir/x19c01.xfig, test_examples_output_dir/x19c02.xfig,
test_examples_output_dir/x19c03.xfig, test_examples_output_dir/x19c04.xfig,
test_examples_output_dir/x19c_xfig.txt,
test_examples_output_dir/x20c01.xfig, test_examples_output_dir/x20c02.xfig,
test_examples_output_dir/x20c03.xfig, test_examples_output_dir/x20c04.xfig,
test_examples_output_dir/x20c05.xfig, test_examples_output_dir/x20c06.xfig,
test_examples_output_dir/x20c_xfig.txt,
test_examples_output_dir/x21c01.xfig, test_examples_output_dir/x21c02.xfig,
test_examples_output_dir/x21c03.xfig,
test_examples_output_dir/x21c_xfig.txt,
test_examples_output_dir/x22c01.xfig, test_examples_output_dir/x22c02.xfig,
test_examples_output_dir/x22c03.xfig, test_examples_output_dir/x22c04.xfig,
test_examples_output_dir/x22c_xfig.txt,
test_examples_output_dir/x23c01.xfig, test_examples_output_dir/x23c02.xfig,
test_examples_output_dir/x23c03.xfig, test_examples_output_dir/x23c04.xfig,
test_examples_output_dir/x23c05.xfig, test_examples_output_dir/x23c06.xfig,
test_examples_output_dir/x23c07.xfig, test_examples_output_dir/x23c08.xfig,
test_examples_output_dir/x23c09.xfig, test_examples_output_dir/x23c10.xfig,
test_examples_output_dir/x23c11.xfig, test_examples_output_dir/x23c12.xfig,
test_examples_output_dir/x23c13.xfig, test_examples_output_dir/x23c14.xfig,
test_examples_output_dir/x23c15.xfig, test_examples_output_dir/x23c16.xfig,
test_examples_output_dir/x23c_xfig.txt,
test_examples_output_dir/x24c01.xfig,
test_examples_output_dir/x24c_xfig.txt,
test_examples_output_dir/x25c01.xfig, test_examples_output_dir/x25c02.xfig,
test_examples_output_dir/x25c03.xfig, test_examples_output_dir/x25c04.xfig,
test_examples_output_dir/x25c05.xfig, test_examples_output_dir/x25c06.xfig,
test_examples_output_dir/x25c07.xfig, test_examples_output_dir/x25c08.xfig,
test_examples_output_dir/x25c_xfig.txt,
test_examples_output_dir/x26c01.xfig, test_examples_output_dir/x26c02.xfig,
test_examples_output_dir/x26c_xfig.txt,
test_examples_output_dir/x27c01.xfig, test_examples_output_dir/x27c02.xfig,
test_examples_output_dir/x27c03.xfig, test_examples_output_dir/x27c04.xfig,
test_examples_output_dir/x27c05.xfig, test_examples_output_dir/x27c06.xfig,
test_examples_output_dir/x27c07.xfig, test_examples_output_dir/x27c08.xfig,
test_examples_output_dir/x27c09.xfig, test_examples_output_dir/x27c10.xfig,
test_examples_output_dir/x27c11.xfig, test_examples_output_dir/x27c12.xfig,
test_examples_output_dir/x27c13.xfig, test_examples_output_dir/x27c14.xfig,
test_examples_output_dir/x27c15.xfig, test_examples_output_dir/x27c16.xfig,
test_examples_output_dir/x27c17.xfig, test_examples_output_dir/x27c18.xfig,
test_examples_output_dir/x27c19.xfig, test_examples_output_dir/x27c20.xfig,
test_examples_output_dir/x27c_xfig.txt,
test_examples_output_dir/x28c01.xfig, test_examples_output_dir/x28c02.xfig,
test_examples_output_dir/x28c03.xfig, test_examples_output_dir/x28c04.xfig,
test_examples_output_dir/x28c05.xfig,
test_examples_output_dir/x28c_xfig.txt,
test_examples_output_dir/x29c01.xfig, test_examples_output_dir/x29c02.xfig,
test_examples_output_dir/x29c03.xfig, test_examples_output_dir/x29c04.xfig,
test_examples_output_dir/x29c05.xfig, test_examples_output_dir/x29c06.xfig,
test_examples_output_dir/x29c07.xfig, test_examples_output_dir/x29c08.xfig,
test_examples_output_dir/x29c09.xfig, test_examples_output_dir/x29c10.xfig,
test_examples_output_dir/x29c_xfig.txt,
test_examples_output_dir/x30c01.xfig, test_examples_output_dir/x30c02.xfig,
test_examples_output_dir/x30c_xfig.txt,
test_examples_output_dir/x31c01.xfig,
test_examples_output_dir/x31c_xfig.txt,
test_examples_output_dir/x33c01.xfig, test_examples_output_dir/x33c02.xfig,
test_examples_output_dir/x33c03.xfig, test_examples_output_dir/x33c04.xfig,
test_examples_output_dir/x33c_xfig.txt
Generate C results for xfig file device
'env' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
------ Build started: Project: test_wxPLplotDemo, Configuration: Debug
Win32 ------
plGetName: Maximum length of full pathname of file to be found is 45
plGetName: Full pathname of file to be found is
M:/plot/plplot-5.11.1\data\plxtnd5.fnt
plLibOpenPdfstr: Found file M:/plot/plplot-5.11.1\data\plxtnd5.fnt
------ Build started: Project: validate_announcement-5.3.0, Configuration:
Debug Win32 ------
The system cannot find the path specified.
------ Build started: Project: validate_announcement-5.3.1, Configuration:
Debug Win32 ------
The system cannot find the path specified.
------ Skipped Build: Project: Continuous, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: Experimental, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: Nightly, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: NightlyMemoryCheck, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: PACKAGE, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: RUN_TESTS, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: check_all, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: docbook_plplot-structs_txt, Configuration:
Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: docbook_plplot-symbols_txt, Configuration:
Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_c_psc, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_cxx_psc, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_interactive, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_noninteractive, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_tcl, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: test_tk, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: validate, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: validate_announcements, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: workaround_file_generate_bug, Configuration:
Debug Win32 ------
Project not selected to build for this solution configuration
------ Skipped Build: Project: www-install-base, Configuration: Debug
Win32 ------
Project not selected to build for this solution configuration
========== Build: 6 succeeded, 10 failed, 84 up-to-date, 20 skipped
==========
----- Original Message -----
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list"
<Plp...@li...>
Sent: Sunday, October 09, 2016 1:45 AM
Subject: Re: [Plplot-devel] New wxwidgets device does not
honor -bg - -DOLD_WXWIDGETS=ON PL_HAVE_SNPRINTF
> On 2016-10-09 00:49-0400 Pedro Vicente wrote:
>
>> Hi Alan, Phil
>>
>>> and the old (-DOLD_WXWIDGETS=ON) -dev wxwidgets, and in each case the
>>> requested blue background was rendered correctly.
>>
>>
>> I tried to reproduce this (-DOLD_WXWIDGETS=ON) in Windows , Visual Studio
>> 2015,
>> and I do get the blue backround
>>
>> but in the process of doing this I found another bug
>>
>> When you try to do the build with -DOLD_WXWIDGETS=ON (and only with this
>> option, in Windows)
>>
>> I get a linking error
>>
>>
>> plplot.lib(deprecated_wxwidgets_app.obj) : error LNK2019: unresolved
>> external symbol "int __cdecl plsnprintf(char *,int,char const *,...)"
>> referenced in function "public: bool __thiscall
>> wxPLplotFrame::SavePlot(char const *,char const *,int,int)"
>>
>>
>> wxPLplotFrame::SavePlot does include this call
>>
>>
>> snprintf( buf, 512, "File %s couldn't be saved", filename );
>>
>> and snprintf is defined as
>>
>>
>> #else // !PL_HAVE_SNPRINTF
>> // declare dummy functions which just call the unsafe
>> // functions ignoring the size of the string
>> int plsnprintf( char *buffer, int n, const char *format, ... );
>> int plsnscanf( const char *buffer, int n, const char *format, ... );
>> #define snprintf plsnprintf
>>
>> but this makes no sense to me because plsnprintf is defined in plctrl.c
>> that is part of the library
>>
>> int
>> plsnprintf( char *buffer, int n, const char *format, ... )
>> {
>>
>>
>> either way, this should not fall in the case of
>> !PL_HAVE_SNPRINTF
>>
>>
>> because Visual Studio does defines _snprintf
>>
>> so the fix is to manually define
>>
>> #ifndef PL_HAVE_SNPRINTF
>> #define PL_HAVE_SNPRINTF
>> #endif
>>
>>
>> so, the bug is that cmake does not detect _snprintf correctly, maybe in
>> this code
>>
>> check_function_exists(snprintf PL_HAVE_SNPRINTF)
>> if(NOT PL_HAVE_SNPRINTF)
>> check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
>> set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function
>> _sprintf")
>> endif(NOT PL_HAVE_SNPRINTF)
>
> @Phil:
>
> Will you take a look at the above linking issue with -G "Visual Studio 14"
> (or
> whatever visual studio version you have access to) and
> -DOLD_WXWIDGETS=ON and fix it?
>
> @Pedro:
>
> You report a completely unrelated issue below which I will attempt to
> answer below.
>
>> I used in cmake
>>
>>
>> cmake ".." -G "Visual Studio
>> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
>> -DCMA
>> KE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON
>> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_
>> DIR:PATH=%WXWIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF -DOLD_WXWIDGETS=ON
>>
>>
>>
>> I also do get some unrelated errors , but that's a separate bug
>>
>> the thing is that cmake has somewhere hardcoded Unix commands like
>>
>>
>> Generating announce-plplot-5.3.0.html
>> 'xmlto' is not recognized as an internal or external command,
>>
>> Generating staging/htdocs/announce/ChangeLog-5.2.1-5.3.0
>> 'cp' is not recognized as an internal or external command,
>>
>> 'grep' is not recognized as an internal or external command,
>>
>> 'env' is not recognized as an internal or external command,
>>
>> and this causes some projects to not build
>>
>> by the way this is not related to the -DOLD_WXWIDGETS=ON it also happens
>> in another builds
>
> @Pedro:
>
> I did some further investigation and "Generating
> announce-plplot-5.3.0.html" is the result of building the
> generate_announcements target. But that is a completely independent
> target which no other target (such as all) depends on so it is not
> built on Linux unless you specify the generate_announcements target
> directly, e.g.,
>
> make generate_announcements
>
> So I don't understand why you end up building that independent target
> using visual studio. Is there some capability for that IDE where you
> can build every target whether they are independent of other targets
> or not? If so, you should not do that since many of the independent
> targets such as generate_announcements are Unix only. Instead, you
> should stick to more general targets (e.g., "all" or "install") which
> depend only on targets that can be built on each of our supported
> platforms.
>
> 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
> __________________________
>
|
|
From: Alan W. I. <ir...@be...> - 2016-10-09 05:46:05
|
On 2016-10-09 00:49-0400 Pedro Vicente wrote:
> Hi Alan, Phil
>
>> and the old (-DOLD_WXWIDGETS=ON) -dev wxwidgets, and in each case the
>> requested blue background was rendered correctly.
>
>
> I tried to reproduce this (-DOLD_WXWIDGETS=ON) in Windows , Visual Studio
> 2015,
> and I do get the blue backround
>
> but in the process of doing this I found another bug
>
> When you try to do the build with -DOLD_WXWIDGETS=ON (and only with this
> option, in Windows)
>
> I get a linking error
>
>
> plplot.lib(deprecated_wxwidgets_app.obj) : error LNK2019: unresolved external
> symbol "int __cdecl plsnprintf(char *,int,char const *,...)" referenced in
> function "public: bool __thiscall wxPLplotFrame::SavePlot(char const *,char
> const *,int,int)"
>
>
> wxPLplotFrame::SavePlot does include this call
>
>
> snprintf( buf, 512, "File %s couldn't be saved", filename );
>
> and snprintf is defined as
>
>
> #else // !PL_HAVE_SNPRINTF
> // declare dummy functions which just call the unsafe
> // functions ignoring the size of the string
> int plsnprintf( char *buffer, int n, const char *format, ... );
> int plsnscanf( const char *buffer, int n, const char *format, ... );
> #define snprintf plsnprintf
>
> but this makes no sense to me because plsnprintf is defined in plctrl.c that
> is part of the library
>
> int
> plsnprintf( char *buffer, int n, const char *format, ... )
> {
>
>
> either way, this should not fall in the case of
> !PL_HAVE_SNPRINTF
>
>
> because Visual Studio does defines _snprintf
>
> so the fix is to manually define
>
> #ifndef PL_HAVE_SNPRINTF
> #define PL_HAVE_SNPRINTF
> #endif
>
>
> so, the bug is that cmake does not detect _snprintf correctly, maybe in this
> code
>
> check_function_exists(snprintf PL_HAVE_SNPRINTF)
> if(NOT PL_HAVE_SNPRINTF)
> check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
> set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function
> _sprintf")
> endif(NOT PL_HAVE_SNPRINTF)
@Phil:
Will you take a look at the above linking issue with -G "Visual Studio 14" (or
whatever visual studio version you have access to) and
-DOLD_WXWIDGETS=ON and fix it?
@Pedro:
You report a completely unrelated issue below which I will attempt to
answer below.
> I used in cmake
>
>
> cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON
> -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMA
> KE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF
> -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON
> -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_
> DIR:PATH=%WXWIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud
> -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
> -DOLD_WXWIDGETS=ON
>
>
>
> I also do get some unrelated errors , but that's a separate bug
>
> the thing is that cmake has somewhere hardcoded Unix commands like
>
>
> Generating announce-plplot-5.3.0.html
> 'xmlto' is not recognized as an internal or external command,
>
> Generating staging/htdocs/announce/ChangeLog-5.2.1-5.3.0
> 'cp' is not recognized as an internal or external command,
>
> 'grep' is not recognized as an internal or external command,
>
> 'env' is not recognized as an internal or external command,
>
> and this causes some projects to not build
>
> by the way this is not related to the -DOLD_WXWIDGETS=ON it also happens in
> another builds
@Pedro:
I did some further investigation and "Generating
announce-plplot-5.3.0.html" is the result of building the
generate_announcements target. But that is a completely independent
target which no other target (such as all) depends on so it is not
built on Linux unless you specify the generate_announcements target
directly, e.g.,
make generate_announcements
So I don't understand why you end up building that independent target
using visual studio. Is there some capability for that IDE where you
can build every target whether they are independent of other targets
or not? If so, you should not do that since many of the independent
targets such as generate_announcements are Unix only. Instead, you
should stick to more general targets (e.g., "all" or "install") which
depend only on targets that can be built on each of our supported
platforms.
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
__________________________
|
|
From: Pedro V. <ped...@sp...> - 2016-10-09 05:19:44
|
Hi Phil
> Traditionally colour 0 has always been the background colour, so
>plscol0 passing in colour 0 is the same as plscolbg. You should use
>plcol(1) or upwards for rendering.
ok, I understand now, it seems it was just me trying to redefine color index
0 2 times , and there is no need to
this code worked for me (white background with color 0, black plot with
color 1)
bool wxAppPlot::OnInit()
{
wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
frame->Show();
wx_PLplotstream* pls = frame->GetStream();
pls->init();
pls->adv(0);
pls->scol0(0, 255, 255, 255);
pls->clear();
pls->scol0(1, 0, 0, 0);
//render
plot_window(frame);
return true;
}
Note here that I am using my modified version "wx_PLplotstream" that does
not call
init();
but I am calling init(); right at start , so this is the same I think of
using the regular class "wxPLplotstream"
so, my confusion came because I was convinced that to modify the background,
this had to be done *before* calling
init();
but it seems we don't have to do it that way, is that right ?
the documenation says that it is needed
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/color.html
"There are a number of options for changing the default red on black colors.
The user may set the index 0 background color using the command-line bg
parameter or by calling plscolbg (or plscol0 with a 0 index) before plinit.
During the course of the plot, the user can change the foreground color as
often as desired using plcol0 to select the index of the desired color. "
or is just this sequence of calls that makes it not necessary to do it
before init() ?
pls->adv(0);
pls->scol0(0, 255, 255, 255);
pls->clear();
pls->scol0(1, 0, 0, 0);
> I don't think I can or should remove the plinit call in
> wxPLstream::Create because I think that has been there a long time and
> would break other users' existing code.
ok, understood, that makes sense , yes
>However I could overload the
> Create function so that it accepts some extra initialisation variables
> such as background colour.
that would be a must have if the only way to change the background was to do
it before init()
but since it seems that is not needed so not really a must have
but maybe there are other things that can only be done before init()
by the way, I have a small request , is that possible to keep the
"deprecated" wxWidgets classes around?
it seems the only difference is that new wxWidgets is the use of templates
as in
template< class WXWINDOW >
void plot_window(wx_PLplotwindow<WXWINDOW> *plotwindow);
my experience with templates is that they make the code more difficult to
track and find bugs
Maybe merge the "deprecated" wxWidgets and the new one just into one file or
class and give the option to use either one (don't know
if this makes sense)
-Pedro
----- Original Message -----
From: "Phil Rosenberg" <p.d...@gm...>
To: "Pedro Vicente" <ped...@sp...>
Cc: <plp...@li...>;
<plp...@li...>
Sent: Friday, October 07, 2016 7:51 AM
Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
thedefault blackbackground
> Hi Pedro
> Traditionally colour 0 has always been the background colour, so
> plscol0 passing in colour 0 is the same as plscolbg. You should use
> plcol(1) or upwards for rendering. In some ways it is up to you how
> you do that. You can either set up you pallet at the beginning using
> plscol0 or plscsol0a then use plcol0(1), plcol0(2) etc, or you can
> just always use plscol0(1), but use repeated calls to plscol0 or
> plscol0a to keep changing colour 1.
>
> Do you happen to call plenv() after setting colour 0 to black again? I
> have a feeling that plenv() may clear the page again. But I'm not
> sure. If you are still haing problems using colours 1 and above for
> drawing then let us know and I'll have a further look.
>
> I don't think I can or should remove the plinit call in
> wxPLstream::Create because I think that has been there a long time and
> would break other users' existing code. However I could overload the
> Create function so that it accepts some extra initialisation variables
> such as background colour.
>
> Phil
>
> On 6 October 2016 at 16:41, Pedro Vicente
> <ped...@sp...> wrote:
>> Phil
>>
>>
>> I believe there is stiil an issue with this solution
>>
>> my sample worked because I had
>>
>> plcol0(8);
>>
>> that does the plot in brown color
>>
>> if I try to plot in black color (on white bacground now) by doing
>>
>> plcol0(0);
>>
>> then I have no plot, since color 0 is now white
>>
>> is there a way with this solution to define color 0 as black for the
>> plot?
>>
>> I tried to call
>>
>> plscol0(0, 0, 0, 0);
>>
>> as
>>
>> wxPLplotstream* pls = plotwindow->GetStream();
>> pls->adv(0);
>> pls->scolbg(255, 255, 255);
>> pls->clear();
>> plscol0(0, 0, 0, 0);
>>
>> but like this I have the default red on black again
>>
>>
>> for now, the way I was able to have the black on white background was to
>> replicate all the code
>> of
>> wxPLplotwindow
>> wxPLplotwindow
>>
>> into new classes , giving them another name, commenting the init() call
>> on
>> them and then
>> doing this code (note that the classes are renamed to wx_PLplotwindow and
>> wx_PLplotstream)
>>
>>
>>
>>
>> bool wxAppPlot::OnInit()
>> {
>> wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>> wxDefaultPosition,
>> wxSize(900, 700));
>> frame->Show();
>>
>> //set background color (0) to white RGB(255,255,255)
>> //must be called before plinit()
>> plscolbg(255, 255, 255);
>>
>> wx_PLplotstream* pls = frame->GetStream();
>> pls->init();
>>
>> //change color (0) to black RGB(0, 0, 0)
>> //must be called after plinit()
>> plscol0(0, 0, 0, 0);
>>
>> Plot(frame);
>> return true;
>> }
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>> //Plot
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> template< class WXWINDOW >
>> void Plot(wx_PLplotwindow<WXWINDOW> *plotwindow)
>> {
>> wx_PLplotstream* pls = plotwindow->GetStream();
>>
>> //render
>> const int NSIZE = 101;
>> PLFLT x[NSIZE], y[NSIZE];
>> PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>>
>> for (int i = 0; i < NSIZE; i++)
>> {
>> x[i] = i;
>> y[i] = 5;
>> }
>>
>> plschr(0, 1.0);
>> plcol0(0);
>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>> pllab("x", "y", "Label");
>> plpoin(NSIZE, x, y, 46);
>>
>> plotwindow->RenewPlot();
>> }
>>
>>
>>
>>
>> ----- Original Message ----- From: "Pedro Vicente"
>> <ped...@sp...>
>> To: "Phil Rosenberg" <p.d...@gm...>
>> Cc: <plp...@li...>;
>> <plp...@li...>
>> Sent: Thursday, October 06, 2016 10:44 AM
>>
>> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
>> thedefault blackbackground
>>
>>
>>> Hi Phil, Alan
>>>
>>> This solution worked for me, thanks
>>>
>>>
>>>> The easiest way to do this at the moment is something like
>>>>
>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>> pls->adv( 0 );
>>>> pls->scolbg(255, 255, 255);
>>>> pls->clear();
>>>> //rest of your plotting code
>>>
>>>
>>>
>>>
>>>> I'm very open to better ways
>>>> to do this if you have suggestions.
>>>
>>>
>>> The only suggestion I have is the one I sent on my previous mail, that
>>> was *not* to have
>>>
>>> wxPLplotstream::Create
>>>
>>> call
>>>
>>> init()
>>>
>>> and let the user do that on his application.
>>>
>>>
>>> By looking at the samples, I believe they all call plinit() at start,
>>>
>>>
>>>
>>> my complete test code is now
>>>
>>>
>>> #include "wx/wxprec.h"
>>> #include "wx/wx.h"
>>> #include "wxPLplotwindow.h"
>>>
>>> template< class WXWINDOW >
>>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow);
>>>
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>> //wxAppPlot
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> class wxAppPlot : public wxApp
>>> {
>>> public:
>>> virtual bool OnInit();
>>> };
>>>
>>> IMPLEMENT_APP(wxAppPlot)
>>>
>>> bool wxAppPlot::OnInit()
>>> {
>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>> wxDefaultPosition,
>>> wxSize(900, 700));
>>> frame->Show();
>>> Plot(frame);
>>> return true;
>>> }
>>>
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>> //Plot
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> template< class WXWINDOW >
>>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>> {
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>> pls->adv(0);
>>> pls->scolbg(255, 255, 255);
>>> pls->clear();
>>>
>>> //render
>>>
>>> const int NSIZE = 101;
>>> PLFLT x[NSIZE], y[NSIZE];
>>> PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>>>
>>> for (int i = 0; i < NSIZE; i++)
>>> {
>>> x[i] = i;
>>> y[i] = 5;
>>> }
>>>
>>> plschr(0, 1.0);
>>> plcol0(8);
>>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>> pllab("x", "y", "Label");
>>> plpoin(NSIZE, x, y, 46);
>>>
>>> plotwindow->RenewPlot();
>>> }
>>>
>>>
>>> -Pedro
>>>
>>> ----- Original Message ----- From: "Phil Rosenberg"
>>> <p.d...@gm...>
>>> To: "Pedro Vicente" <ped...@sp...>
>>> Cc: <plp...@li...>;
>>> <plp...@li...>
>>> Sent: Thursday, October 06, 2016 5:55 AM
>>> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
>>> the
>>> default blackbackground
>>>
>>>
>>>> Hi Pedro
>>>> The easiest way to do this at the moment is something like
>>>>
>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>> pls->adv( 0 );
>>>> pls->scolbg(255, 255, 255);
>>>> pls->clear();
>>>> //rest of your plotting code
>>>>
>>>> If you have multiple subpages then you will need to do this on each
>>>> page. Also if your subpages don't cover all the windows then you can
>>>> call the SetBackgroundColour method of wxPLplotwindow and this will
>>>> clear the whole window to the given colour initially.
>>>>
>>>> Hope that helps. If not then let me know. I'm very open to better ways
>>>> to do this if you have suggestions.
>>>>
>>>> Phil
>>>>
>>>>
>>>> On 6 October 2016 at 06:00, Pedro Vicente
>>>> <ped...@sp...> wrote:
>>>>>
>>>>>
>>>>> so, there are at least 2 solutions for this :
>>>>> 1) the quick is just to modify the PLplot source code , in the call to
>>>>>
>>>>> void wxPLplotstream::Create
>>>>>
>>>>> comment the call to
>>>>>
>>>>> //init();
>>>>>
>>>>> then in our app code , do the init() call after Create() . as
>>>>>
>>>>> ~~~
>>>>> bool wxAppPlot::OnInit()
>>>>> {
>>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>>>> wxDefaultPosition,
>>>>> wxSize(900, 700));
>>>>> frame->Show();
>>>>>
>>>>> //set background color (0) to white RGB(255,255,255)
>>>>> //must be called before plinit()
>>>>> plscolbg(255, 255, 255);
>>>>>
>>>>> wxPLplotstream* pls = frame->GetStream();
>>>>> pls->init();
>>>>>
>>>>> //change color (0) to black RGB(0, 0, 0)
>>>>> //must be called after plinit()
>>>>> plscol0(0, 0, 0, 0);
>>>>>
>>>>> Plot(frame);
>>>>> return true;
>>>>> }
>>>>> ~~~
>>>>>
>>>>>
>>>>> since it seems the only way to modiy the background color is to do the
>>>>> above
>>>>> sequence
>>>>> this is a change that I recommend to be included in the libray, since
>>>>> I
>>>>> believe the other drivers require a call to init() too, but not the
>>>>> wxWidgets driver.
>>>>>
>>>>> 2) not modifying the source code. In this case , I think it should be
>>>>> possible to derive 2 classes ,
>>>>> a) one from wxPLplotwindow
>>>>> b) other from wxPLplotwindow
>>>>>
>>>>> then do everything in those classes as now except the call to init()
>>>>>
>>>>>
>>>>> but if the developers could do option 1) that probably would be the
>>>>> best
>>>>> thanks
>>>>>
>>>>>
>>>>> -Pedro
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Pedro Vicente
>>>>> To: plp...@li...
>>>>> Sent: Wednesday, October 05, 2016 6:42 PM
>>>>> Subject: [Plplot-general] wxWidgets driver -- change the default
>>>>> blackbackground
>>>>>
>>>>> Hi
>>>>>
>>>>>
>>>>> I am trying to change the default black background color using the
>>>>> wxWidgets
>>>>> driver
>>>>>
>>>>> If using the SVG driver this can be done as explained here
>>>>>
>>>>> https://sourceforge.net/p/plplot/mailman/message/2817799/
>>>>>
>>>>> the trick being calling
>>>>>
>>>>> plscolbg()
>>>>>
>>>>> before
>>>>>
>>>>> plinit();
>>>>>
>>>>> like the sample code below marked "SVG Driver" does
>>>>>
>>>>>
>>>>> However for the wxWidegts driver , it seems we do not do a call to
>>>>>
>>>>> plinit();
>>>>>
>>>>> but rather this is done inside the C++ stream initialization
>>>>>
>>>>> From the wxWidgets PLplot sample below
>>>>>
>>>>> the
>>>>>
>>>>> plinit();
>>>>>
>>>>> is made inside
>>>>>
>>>>>
>>>>>
>>>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>>>>>
>>>>>
>>>>> so I don't find a way to call the plscolbg() function before
>>>>>
>>>>>
>>>>> How can this be accomplished ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I also tried to modify the default colors of the default palette
>>>>>
>>>>> cmap0_default.pal
>>>>>
>>>>> 16
>>>>> #000000
>>>>>
>>>>> so that the first is white
>>>>>
>>>>> this does work *but* only after the window is redrawn (it first shows
>>>>> the
>>>>> default red on black);
>>>>> this seems like a bug to me
>>>>>
>>>>>
>>>>> Also, what's the call to increase the font size?
>>>>> On the wxWidgets driver the font looks tiny
>>>>>
>>>>> Thanks !
>>>>>
>>>>>
>>>>> Sample code wxWidgets
>>>>>
>>>>>
>>>>>
>>>>> bool
>>>>>
>>>>> wxAppPlot::OnInit()
>>>>>
>>>>> {
>>>>>
>>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>>
>>>>> frame->Create(
>>>>>
>>>>> NULL, wxID_ANY, wxT("wxPLplot"));
>>>>>
>>>>> frame->Show();
>>>>>
>>>>> Plot(frame);
>>>>>
>>>>> return true;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>
>>>>> //Plot
>>>>>
>>>>>
>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>
>>>>> template
>>>>>
>>>>> < class WXWINDOW >
>>>>>
>>>>> void
>>>>>
>>>>> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>>>>
>>>>> {
>>>>>
>>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>>>
>>>>> //render
>>>>>
>>>>> plotwindow->RenewPlot();
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sample code SVG driver
>>>>>
>>>>> void
>>>>>
>>>>> atms_dwell_granu_t::plot()
>>>>>
>>>>> {
>>>>>
>>>>> //set SVG device and output file name
>>>>>
>>>>> plsdev("svg");
>>>>>
>>>>> plsfnam("atms_dwell_granu.svg");
>>>>>
>>>>> //set background color (0) to white RGB(255,255,255)
>>>>>
>>>>> //must be called before plinit()
>>>>>
>>>>> plscolbg(255, 255, 255);
>>>>>
>>>>> //initialize plplot
>>>>>
>>>>> plinit();
>>>>>
>>>>> //change color (0) to black RGB(0, 0, 0)
>>>>>
>>>>> //must be called after plinit()
>>>>>
>>>>> plscol0(0, 0, 0, 0);
>>>>>
>>>>>
>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>
>>>>> //render
>>>>>
>>>>>
>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>
>>>>> PLFLT xmin, xmax, ymin, ymax;
>>>>>
>>>>> PLFLT *x, *y;
>>>>>
>>>>> const int NSIZE = iOrbit_all;
>>>>>
>>>>> xmin = 0;
>>>>>
>>>>> xmax = NSIZE;
>>>>>
>>>>> ymin = -1.0;
>>>>>
>>>>> ymax = 6.0;
>>>>>
>>>>> x =
>>>>>
>>>>> new PLFLT[NSIZE];
>>>>>
>>>>> y =
>>>>>
>>>>> new PLFLT[NSIZE];
>>>>>
>>>>> plcol0(0);
>>>>>
>>>>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>>>
>>>>> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>>>>>
>>>>> //time axis
>>>>>
>>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>>
>>>>> {
>>>>>
>>>>> x[idx_orb] = idx_orb;
>>>>>
>>>>> }
>>>>>
>>>>> //mean
>>>>>
>>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>>
>>>>> {
>>>>>
>>>>> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT -
>>>>> 1][idx_orb];
>>>>>
>>>>> }
>>>>>
>>>>> plpoin(NSIZE, x, y, 46);
>>>>>
>>>>> plend();
>>>>>
>>>>> delete[] x;
>>>>>
>>>>> delete[] y;
>>>>>
>>>>> }
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>
>>>>> ________________________________
>>>>>
>>>>> _______________________________________________
>>>>> Plplot-general mailing list
>>>>> Plp...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Plplot-devel mailing list
>>>>> Plp...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>
>
|
|
From: Pedro V. <ped...@sp...> - 2016-10-09 04:49:33
|
Hi Alan, Phil
> and the old (-DOLD_WXWIDGETS=ON) -dev wxwidgets, and in each case the
> requested blue background was rendered correctly.
I tried to reproduce this (-DOLD_WXWIDGETS=ON) in Windows , Visual Studio
2015,
and I do get the blue backround
but in the process of doing this I found another bug
When you try to do the build with -DOLD_WXWIDGETS=ON (and only with this
option, in Windows)
I get a linking error
plplot.lib(deprecated_wxwidgets_app.obj) : error LNK2019: unresolved
external symbol "int __cdecl plsnprintf(char *,int,char const *,...)"
referenced in function "public: bool __thiscall wxPLplotFrame::SavePlot(char
const *,char const *,int,int)"
wxPLplotFrame::SavePlot does include this call
snprintf( buf, 512, "File %s couldn't be saved", filename );
and snprintf is defined as
#else // !PL_HAVE_SNPRINTF
// declare dummy functions which just call the unsafe
// functions ignoring the size of the string
int plsnprintf( char *buffer, int n, const char *format, ... );
int plsnscanf( const char *buffer, int n, const char *format, ... );
#define snprintf plsnprintf
but this makes no sense to me because plsnprintf is defined in plctrl.c that
is part of the library
int
plsnprintf( char *buffer, int n, const char *format, ... )
{
either way, this should not fall in the case of
!PL_HAVE_SNPRINTF
because Visual Studio does defines _snprintf
so the fix is to manually define
#ifndef PL_HAVE_SNPRINTF
#define PL_HAVE_SNPRINTF
#endif
so, the bug is that cmake does not detect _snprintf correctly, maybe in this
code
check_function_exists(snprintf PL_HAVE_SNPRINTF)
if(NOT PL_HAVE_SNPRINTF)
check_function_exists(_snprintf _PL_HAVE_SNPRINTF)
set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function
_sprintf")
endif(NOT PL_HAVE_SNPRINTF)
I used in cmake
cmake ".." -G "Visual Studio
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
-DCMA
KE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON
-DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_
DIR:PATH=%WXWIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
-DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF -DOLD_WXWIDGETS=ON
I also do get some unrelated errors , but that's a separate bug
the thing is that cmake has somewhere hardcoded Unix commands like
Generating announce-plplot-5.3.0.html
'xmlto' is not recognized as an internal or external command,
Generating staging/htdocs/announce/ChangeLog-5.2.1-5.3.0
'cp' is not recognized as an internal or external command,
'grep' is not recognized as an internal or external command,
'env' is not recognized as an internal or external command,
and this causes some projects to not build
by the way this is not related to the -DOLD_WXWIDGETS=ON it also happens in
another builds
-Pedro
----- Original Message -----
From: "Alan W. Irwin" <ir...@be...>
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Saturday, October 08, 2016 12:55 PM
Subject: [Plplot-devel] New wxwidgets device does not honor -bg
> On 2016-10-06 00:13-0700 Alan W. Irwin wrote:
>
>> @Phil, will you look into this please?
>>
>> To verify this bug myself, I did the following steps which you should
>> be able to replicate for yourself.
>>
>> * Run cmake with the -DBUILD_TEST=ON option which configures
>> the build of our standard examples.
>>
>> * Build a standard example (the 00 standard example in C in this case,
>> but any other standard example will likely also demonstrate this bug).
>>
>> make x00c
>>
>> * Build several different devices to try.
>>
>> make svg
>> make xwin
>> make wxwidgets wxPLViewer #wxwidgets interacts with wxPLViewer at run
>> time so both have to be built
>>
>> * Run the 00 standard example with different devices and with a blue
>> background specified. (The -bg option is the same as calling plscolbg
>> before plinit in the standard example, and the -bg colour is specified
>> with the standard RRGGBB hexadecimal notation so 0000FF is saturated
>> blue)
>>
>> examples/c/x00c -dev svg -bg 0000FF -o test.svg
>> examples/c/x00c -dev xwin -bg 0000FF
>> examples/c/x00c -dev wxwidgets -bg 0000FF
>>
>> I found that the svg and xwin results had the specified blue
>> background, but the wxPLViewer instance that was automatically
>> launched and communicated with by -dev wxwidgets rendered the
>> background as the default black rather than the specified blue ==>
>> BUG. I don't know if that is a bug in -dev wxwidgets, a bug in the
>> way background colours are communicated to the wxPLViewer instance,
>> and/or a bug in the wxPLViewer code, but I assume you will be readily
>> able to figure this out from your knowledge of each of these
>> components of our wxwidgets-related code.
>>
>> To my mind, the highest priority is to get -dev wxwidgets to work
>> properly with -bg as requested above, but as a much lower priority it
>> would be good to build most of the standard PLplot command-line
>> parsing (likely mostly everything other than -dev and -o) into
>> examples/c++/wxPLplotDemo.cpp so that it would be possible, for
>> example to run
>>
>> examples/c++/wxPLplotDemo -bg 0000FF -geometry -geometry 500x1000
>>
>> and get the specified blue background and geometry for that example.
>>
>> Just to remind you and others here, please run, e.g.,
>>
>> examples/c/x00c -h
>>
>> to get help on all the PLplot options that can be parsed from the
>> command line.
>
> Hi Phil:
>
> I am switching further discussion of the -bg results for wxwidgets to
> plplot-devel.
>
> I haven't heard back from you yet concerning the new wxwidgets device
> test results with -bg that I reported above on plplot-general.
> Meanwhile, I have tried the same test with -dev xcairo, -dev qtwidget,
> and the old (-DOLD_WXWIDGETS=ON) -dev wxwidgets, and in each case the
> requested blue background was rendered correctly. So from the tests
> above and these further tests I am virtually certain that every PLplot
> device other than the new wxwidgets device honors the -bg option. And
> for this reason, I view this deficiency of the new wxwidgets device as
> a bug which I hope you are willing to fix.
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Alan W. I. <ir...@be...> - 2016-10-08 16:55:39
|
On 2016-10-06 00:13-0700 Alan W. Irwin wrote: > @Phil, will you look into this please? > > To verify this bug myself, I did the following steps which you should > be able to replicate for yourself. > > * Run cmake with the -DBUILD_TEST=ON option which configures > the build of our standard examples. > > * Build a standard example (the 00 standard example in C in this case, > but any other standard example will likely also demonstrate this bug). > > make x00c > > * Build several different devices to try. > > make svg > make xwin > make wxwidgets wxPLViewer #wxwidgets interacts with wxPLViewer at run time so both have to be built > > * Run the 00 standard example with different devices and with a blue > background specified. (The -bg option is the same as calling plscolbg > before plinit in the standard example, and the -bg colour is specified > with the standard RRGGBB hexadecimal notation so 0000FF is saturated > blue) > > examples/c/x00c -dev svg -bg 0000FF -o test.svg > examples/c/x00c -dev xwin -bg 0000FF > examples/c/x00c -dev wxwidgets -bg 0000FF > > I found that the svg and xwin results had the specified blue > background, but the wxPLViewer instance that was automatically > launched and communicated with by -dev wxwidgets rendered the > background as the default black rather than the specified blue ==> > BUG. I don't know if that is a bug in -dev wxwidgets, a bug in the > way background colours are communicated to the wxPLViewer instance, > and/or a bug in the wxPLViewer code, but I assume you will be readily > able to figure this out from your knowledge of each of these > components of our wxwidgets-related code. > > To my mind, the highest priority is to get -dev wxwidgets to work > properly with -bg as requested above, but as a much lower priority it > would be good to build most of the standard PLplot command-line > parsing (likely mostly everything other than -dev and -o) into > examples/c++/wxPLplotDemo.cpp so that it would be possible, for > example to run > > examples/c++/wxPLplotDemo -bg 0000FF -geometry -geometry 500x1000 > > and get the specified blue background and geometry for that example. > > Just to remind you and others here, please run, e.g., > > examples/c/x00c -h > > to get help on all the PLplot options that can be parsed from the > command line. Hi Phil: I am switching further discussion of the -bg results for wxwidgets to plplot-devel. I haven't heard back from you yet concerning the new wxwidgets device test results with -bg that I reported above on plplot-general. Meanwhile, I have tried the same test with -dev xcairo, -dev qtwidget, and the old (-DOLD_WXWIDGETS=ON) -dev wxwidgets, and in each case the requested blue background was rendered correctly. So from the tests above and these further tests I am virtually certain that every PLplot device other than the new wxwidgets device honors the -bg option. And for this reason, I view this deficiency of the new wxwidgets device as a bug which I hope you are willing to fix. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-10-07 11:52:06
|
Hi Pedro
Traditionally colour 0 has always been the background colour, so
plscol0 passing in colour 0 is the same as plscolbg. You should use
plcol(1) or upwards for rendering. In some ways it is up to you how
you do that. You can either set up you pallet at the beginning using
plscol0 or plscsol0a then use plcol0(1), plcol0(2) etc, or you can
just always use plscol0(1), but use repeated calls to plscol0 or
plscol0a to keep changing colour 1.
Do you happen to call plenv() after setting colour 0 to black again? I
have a feeling that plenv() may clear the page again. But I'm not
sure. If you are still haing problems using colours 1 and above for
drawing then let us know and I'll have a further look.
I don't think I can or should remove the plinit call in
wxPLstream::Create because I think that has been there a long time and
would break other users' existing code. However I could overload the
Create function so that it accepts some extra initialisation variables
such as background colour.
Phil
On 6 October 2016 at 16:41, Pedro Vicente
<ped...@sp...> wrote:
> Phil
>
>
> I believe there is stiil an issue with this solution
>
> my sample worked because I had
>
> plcol0(8);
>
> that does the plot in brown color
>
> if I try to plot in black color (on white bacground now) by doing
>
> plcol0(0);
>
> then I have no plot, since color 0 is now white
>
> is there a way with this solution to define color 0 as black for the plot?
>
> I tried to call
>
> plscol0(0, 0, 0, 0);
>
> as
>
> wxPLplotstream* pls = plotwindow->GetStream();
> pls->adv(0);
> pls->scolbg(255, 255, 255);
> pls->clear();
> plscol0(0, 0, 0, 0);
>
> but like this I have the default red on black again
>
>
> for now, the way I was able to have the black on white background was to
> replicate all the code
> of
> wxPLplotwindow
> wxPLplotwindow
>
> into new classes , giving them another name, commenting the init() call on
> them and then
> doing this code (note that the classes are renamed to wx_PLplotwindow and
> wx_PLplotstream)
>
>
>
>
> bool wxAppPlot::OnInit()
> {
> wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
> wxDefaultPosition,
> wxSize(900, 700));
> frame->Show();
>
> //set background color (0) to white RGB(255,255,255)
> //must be called before plinit()
> plscolbg(255, 255, 255);
>
> wx_PLplotstream* pls = frame->GetStream();
> pls->init();
>
> //change color (0) to black RGB(0, 0, 0)
> //must be called after plinit()
> plscol0(0, 0, 0, 0);
>
> Plot(frame);
> return true;
> }
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
> //Plot
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> template< class WXWINDOW >
> void Plot(wx_PLplotwindow<WXWINDOW> *plotwindow)
> {
> wx_PLplotstream* pls = plotwindow->GetStream();
>
> //render
> const int NSIZE = 101;
> PLFLT x[NSIZE], y[NSIZE];
> PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>
> for (int i = 0; i < NSIZE; i++)
> {
> x[i] = i;
> y[i] = 5;
> }
>
> plschr(0, 1.0);
> plcol0(0);
> plenv(xmin, xmax, ymin, ymax, 0, 0);
> pllab("x", "y", "Label");
> plpoin(NSIZE, x, y, 46);
>
> plotwindow->RenewPlot();
> }
>
>
>
>
> ----- Original Message ----- From: "Pedro Vicente"
> <ped...@sp...>
> To: "Phil Rosenberg" <p.d...@gm...>
> Cc: <plp...@li...>;
> <plp...@li...>
> Sent: Thursday, October 06, 2016 10:44 AM
>
> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
> thedefault blackbackground
>
>
>> Hi Phil, Alan
>>
>> This solution worked for me, thanks
>>
>>
>>> The easiest way to do this at the moment is something like
>>>
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>> pls->adv( 0 );
>>> pls->scolbg(255, 255, 255);
>>> pls->clear();
>>> //rest of your plotting code
>>
>>
>>
>>
>>> I'm very open to better ways
>>> to do this if you have suggestions.
>>
>>
>> The only suggestion I have is the one I sent on my previous mail, that
>> was *not* to have
>>
>> wxPLplotstream::Create
>>
>> call
>>
>> init()
>>
>> and let the user do that on his application.
>>
>>
>> By looking at the samples, I believe they all call plinit() at start,
>>
>>
>>
>> my complete test code is now
>>
>>
>> #include "wx/wxprec.h"
>> #include "wx/wx.h"
>> #include "wxPLplotwindow.h"
>>
>> template< class WXWINDOW >
>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow);
>>
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>> //wxAppPlot
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> class wxAppPlot : public wxApp
>> {
>> public:
>> virtual bool OnInit();
>> };
>>
>> IMPLEMENT_APP(wxAppPlot)
>>
>> bool wxAppPlot::OnInit()
>> {
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>> wxDefaultPosition,
>> wxSize(900, 700));
>> frame->Show();
>> Plot(frame);
>> return true;
>> }
>>
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>> //Plot
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> template< class WXWINDOW >
>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>> {
>> wxPLplotstream* pls = plotwindow->GetStream();
>> pls->adv(0);
>> pls->scolbg(255, 255, 255);
>> pls->clear();
>>
>> //render
>>
>> const int NSIZE = 101;
>> PLFLT x[NSIZE], y[NSIZE];
>> PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>>
>> for (int i = 0; i < NSIZE; i++)
>> {
>> x[i] = i;
>> y[i] = 5;
>> }
>>
>> plschr(0, 1.0);
>> plcol0(8);
>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>> pllab("x", "y", "Label");
>> plpoin(NSIZE, x, y, 46);
>>
>> plotwindow->RenewPlot();
>> }
>>
>>
>> -Pedro
>>
>> ----- Original Message ----- From: "Phil Rosenberg"
>> <p.d...@gm...>
>> To: "Pedro Vicente" <ped...@sp...>
>> Cc: <plp...@li...>;
>> <plp...@li...>
>> Sent: Thursday, October 06, 2016 5:55 AM
>> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
>> the
>> default blackbackground
>>
>>
>>> Hi Pedro
>>> The easiest way to do this at the moment is something like
>>>
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>> pls->adv( 0 );
>>> pls->scolbg(255, 255, 255);
>>> pls->clear();
>>> //rest of your plotting code
>>>
>>> If you have multiple subpages then you will need to do this on each
>>> page. Also if your subpages don't cover all the windows then you can
>>> call the SetBackgroundColour method of wxPLplotwindow and this will
>>> clear the whole window to the given colour initially.
>>>
>>> Hope that helps. If not then let me know. I'm very open to better ways
>>> to do this if you have suggestions.
>>>
>>> Phil
>>>
>>>
>>> On 6 October 2016 at 06:00, Pedro Vicente
>>> <ped...@sp...> wrote:
>>>>
>>>>
>>>> so, there are at least 2 solutions for this :
>>>> 1) the quick is just to modify the PLplot source code , in the call to
>>>>
>>>> void wxPLplotstream::Create
>>>>
>>>> comment the call to
>>>>
>>>> //init();
>>>>
>>>> then in our app code , do the init() call after Create() . as
>>>>
>>>> ~~~
>>>> bool wxAppPlot::OnInit()
>>>> {
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>>> wxDefaultPosition,
>>>> wxSize(900, 700));
>>>> frame->Show();
>>>>
>>>> //set background color (0) to white RGB(255,255,255)
>>>> //must be called before plinit()
>>>> plscolbg(255, 255, 255);
>>>>
>>>> wxPLplotstream* pls = frame->GetStream();
>>>> pls->init();
>>>>
>>>> //change color (0) to black RGB(0, 0, 0)
>>>> //must be called after plinit()
>>>> plscol0(0, 0, 0, 0);
>>>>
>>>> Plot(frame);
>>>> return true;
>>>> }
>>>> ~~~
>>>>
>>>>
>>>> since it seems the only way to modiy the background color is to do the
>>>> above
>>>> sequence
>>>> this is a change that I recommend to be included in the libray, since I
>>>> believe the other drivers require a call to init() too, but not the
>>>> wxWidgets driver.
>>>>
>>>> 2) not modifying the source code. In this case , I think it should be
>>>> possible to derive 2 classes ,
>>>> a) one from wxPLplotwindow
>>>> b) other from wxPLplotwindow
>>>>
>>>> then do everything in those classes as now except the call to init()
>>>>
>>>>
>>>> but if the developers could do option 1) that probably would be the best
>>>> thanks
>>>>
>>>>
>>>> -Pedro
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Pedro Vicente
>>>> To: plp...@li...
>>>> Sent: Wednesday, October 05, 2016 6:42 PM
>>>> Subject: [Plplot-general] wxWidgets driver -- change the default
>>>> blackbackground
>>>>
>>>> Hi
>>>>
>>>>
>>>> I am trying to change the default black background color using the
>>>> wxWidgets
>>>> driver
>>>>
>>>> If using the SVG driver this can be done as explained here
>>>>
>>>> https://sourceforge.net/p/plplot/mailman/message/2817799/
>>>>
>>>> the trick being calling
>>>>
>>>> plscolbg()
>>>>
>>>> before
>>>>
>>>> plinit();
>>>>
>>>> like the sample code below marked "SVG Driver" does
>>>>
>>>>
>>>> However for the wxWidegts driver , it seems we do not do a call to
>>>>
>>>> plinit();
>>>>
>>>> but rather this is done inside the C++ stream initialization
>>>>
>>>> From the wxWidgets PLplot sample below
>>>>
>>>> the
>>>>
>>>> plinit();
>>>>
>>>> is made inside
>>>>
>>>>
>>>>
>>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>>>>
>>>>
>>>> so I don't find a way to call the plscolbg() function before
>>>>
>>>>
>>>> How can this be accomplished ?
>>>>
>>>>
>>>>
>>>>
>>>> I also tried to modify the default colors of the default palette
>>>>
>>>> cmap0_default.pal
>>>>
>>>> 16
>>>> #000000
>>>>
>>>> so that the first is white
>>>>
>>>> this does work *but* only after the window is redrawn (it first shows
>>>> the
>>>> default red on black);
>>>> this seems like a bug to me
>>>>
>>>>
>>>> Also, what's the call to increase the font size?
>>>> On the wxWidgets driver the font looks tiny
>>>>
>>>> Thanks !
>>>>
>>>>
>>>> Sample code wxWidgets
>>>>
>>>>
>>>>
>>>> bool
>>>>
>>>> wxAppPlot::OnInit()
>>>>
>>>> {
>>>>
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>
>>>> frame->Create(
>>>>
>>>> NULL, wxID_ANY, wxT("wxPLplot"));
>>>>
>>>> frame->Show();
>>>>
>>>> Plot(frame);
>>>>
>>>> return true;
>>>>
>>>> }
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> //Plot
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> template
>>>>
>>>> < class WXWINDOW >
>>>>
>>>> void
>>>>
>>>> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>>>
>>>> {
>>>>
>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>>
>>>> //render
>>>>
>>>> plotwindow->RenewPlot();
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> Sample code SVG driver
>>>>
>>>> void
>>>>
>>>> atms_dwell_granu_t::plot()
>>>>
>>>> {
>>>>
>>>> //set SVG device and output file name
>>>>
>>>> plsdev("svg");
>>>>
>>>> plsfnam("atms_dwell_granu.svg");
>>>>
>>>> //set background color (0) to white RGB(255,255,255)
>>>>
>>>> //must be called before plinit()
>>>>
>>>> plscolbg(255, 255, 255);
>>>>
>>>> //initialize plplot
>>>>
>>>> plinit();
>>>>
>>>> //change color (0) to black RGB(0, 0, 0)
>>>>
>>>> //must be called after plinit()
>>>>
>>>> plscol0(0, 0, 0, 0);
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> //render
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> PLFLT xmin, xmax, ymin, ymax;
>>>>
>>>> PLFLT *x, *y;
>>>>
>>>> const int NSIZE = iOrbit_all;
>>>>
>>>> xmin = 0;
>>>>
>>>> xmax = NSIZE;
>>>>
>>>> ymin = -1.0;
>>>>
>>>> ymax = 6.0;
>>>>
>>>> x =
>>>>
>>>> new PLFLT[NSIZE];
>>>>
>>>> y =
>>>>
>>>> new PLFLT[NSIZE];
>>>>
>>>> plcol0(0);
>>>>
>>>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>>
>>>> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>>>>
>>>> //time axis
>>>>
>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>
>>>> {
>>>>
>>>> x[idx_orb] = idx_orb;
>>>>
>>>> }
>>>>
>>>> //mean
>>>>
>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>
>>>> {
>>>>
>>>> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT - 1][idx_orb];
>>>>
>>>> }
>>>>
>>>> plpoin(NSIZE, x, y, 46);
>>>>
>>>> plend();
>>>>
>>>> delete[] x;
>>>>
>>>> delete[] y;
>>>>
>>>> }
>>>>
>>>> ________________________________
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>
>>>> ________________________________
>>>>
>>>> _______________________________________________
>>>> Plplot-general mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Plplot-devel mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
|
|
From: Pedro V. <ped...@sp...> - 2016-10-06 15:41:46
|
Phil
I believe there is stiil an issue with this solution
my sample worked because I had
plcol0(8);
that does the plot in brown color
if I try to plot in black color (on white bacground now) by doing
plcol0(0);
then I have no plot, since color 0 is now white
is there a way with this solution to define color 0 as black for the plot?
I tried to call
plscol0(0, 0, 0, 0);
as
wxPLplotstream* pls = plotwindow->GetStream();
pls->adv(0);
pls->scolbg(255, 255, 255);
pls->clear();
plscol0(0, 0, 0, 0);
but like this I have the default red on black again
for now, the way I was able to have the black on white background was to
replicate all the code
of
wxPLplotwindow
wxPLplotwindow
into new classes , giving them another name, commenting the init() call on
them and then
doing this code (note that the classes are renamed to wx_PLplotwindow and
wx_PLplotstream)
bool wxAppPlot::OnInit()
{
wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
frame->Show();
//set background color (0) to white RGB(255,255,255)
//must be called before plinit()
plscolbg(255, 255, 255);
wx_PLplotstream* pls = frame->GetStream();
pls->init();
//change color (0) to black RGB(0, 0, 0)
//must be called after plinit()
plscol0(0, 0, 0, 0);
Plot(frame);
return true;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////
//Plot
/////////////////////////////////////////////////////////////////////////////////////////////////////
template< class WXWINDOW >
void Plot(wx_PLplotwindow<WXWINDOW> *plotwindow)
{
wx_PLplotstream* pls = plotwindow->GetStream();
//render
const int NSIZE = 101;
PLFLT x[NSIZE], y[NSIZE];
PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
for (int i = 0; i < NSIZE; i++)
{
x[i] = i;
y[i] = 5;
}
plschr(0, 1.0);
plcol0(0);
plenv(xmin, xmax, ymin, ymax, 0, 0);
pllab("x", "y", "Label");
plpoin(NSIZE, x, y, 46);
plotwindow->RenewPlot();
}
----- Original Message -----
From: "Pedro Vicente" <ped...@sp...>
To: "Phil Rosenberg" <p.d...@gm...>
Cc: <plp...@li...>;
<plp...@li...>
Sent: Thursday, October 06, 2016 10:44 AM
Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
thedefault blackbackground
> Hi Phil, Alan
>
> This solution worked for me, thanks
>
>
>> The easiest way to do this at the moment is something like
>>
>> wxPLplotstream* pls = plotwindow->GetStream();
>> pls->adv( 0 );
>> pls->scolbg(255, 255, 255);
>> pls->clear();
>> //rest of your plotting code
>
>
>
>> I'm very open to better ways
>> to do this if you have suggestions.
>
> The only suggestion I have is the one I sent on my previous mail, that
> was *not* to have
>
> wxPLplotstream::Create
>
> call
>
> init()
>
> and let the user do that on his application.
>
>
> By looking at the samples, I believe they all call plinit() at start,
>
>
>
> my complete test code is now
>
>
> #include "wx/wxprec.h"
> #include "wx/wx.h"
> #include "wxPLplotwindow.h"
>
> template< class WXWINDOW >
> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow);
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
> //wxAppPlot
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> class wxAppPlot : public wxApp
> {
> public:
> virtual bool OnInit();
> };
>
> IMPLEMENT_APP(wxAppPlot)
>
> bool wxAppPlot::OnInit()
> {
> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
> wxDefaultPosition,
> wxSize(900, 700));
> frame->Show();
> Plot(frame);
> return true;
> }
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
> //Plot
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> template< class WXWINDOW >
> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
> {
> wxPLplotstream* pls = plotwindow->GetStream();
> pls->adv(0);
> pls->scolbg(255, 255, 255);
> pls->clear();
>
> //render
>
> const int NSIZE = 101;
> PLFLT x[NSIZE], y[NSIZE];
> PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>
> for (int i = 0; i < NSIZE; i++)
> {
> x[i] = i;
> y[i] = 5;
> }
>
> plschr(0, 1.0);
> plcol0(8);
> plenv(xmin, xmax, ymin, ymax, 0, 0);
> pllab("x", "y", "Label");
> plpoin(NSIZE, x, y, 46);
>
> plotwindow->RenewPlot();
> }
>
>
> -Pedro
>
> ----- Original Message -----
> From: "Phil Rosenberg" <p.d...@gm...>
> To: "Pedro Vicente" <ped...@sp...>
> Cc: <plp...@li...>;
> <plp...@li...>
> Sent: Thursday, October 06, 2016 5:55 AM
> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
> the
> default blackbackground
>
>
>> Hi Pedro
>> The easiest way to do this at the moment is something like
>>
>> wxPLplotstream* pls = plotwindow->GetStream();
>> pls->adv( 0 );
>> pls->scolbg(255, 255, 255);
>> pls->clear();
>> //rest of your plotting code
>>
>> If you have multiple subpages then you will need to do this on each
>> page. Also if your subpages don't cover all the windows then you can
>> call the SetBackgroundColour method of wxPLplotwindow and this will
>> clear the whole window to the given colour initially.
>>
>> Hope that helps. If not then let me know. I'm very open to better ways
>> to do this if you have suggestions.
>>
>> Phil
>>
>>
>> On 6 October 2016 at 06:00, Pedro Vicente
>> <ped...@sp...> wrote:
>>>
>>> so, there are at least 2 solutions for this :
>>> 1) the quick is just to modify the PLplot source code , in the call to
>>>
>>> void wxPLplotstream::Create
>>>
>>> comment the call to
>>>
>>> //init();
>>>
>>> then in our app code , do the init() call after Create() . as
>>>
>>> ~~~
>>> bool wxAppPlot::OnInit()
>>> {
>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>> wxDefaultPosition,
>>> wxSize(900, 700));
>>> frame->Show();
>>>
>>> //set background color (0) to white RGB(255,255,255)
>>> //must be called before plinit()
>>> plscolbg(255, 255, 255);
>>>
>>> wxPLplotstream* pls = frame->GetStream();
>>> pls->init();
>>>
>>> //change color (0) to black RGB(0, 0, 0)
>>> //must be called after plinit()
>>> plscol0(0, 0, 0, 0);
>>>
>>> Plot(frame);
>>> return true;
>>> }
>>> ~~~
>>>
>>>
>>> since it seems the only way to modiy the background color is to do the
>>> above
>>> sequence
>>> this is a change that I recommend to be included in the libray, since I
>>> believe the other drivers require a call to init() too, but not the
>>> wxWidgets driver.
>>>
>>> 2) not modifying the source code. In this case , I think it should be
>>> possible to derive 2 classes ,
>>> a) one from wxPLplotwindow
>>> b) other from wxPLplotwindow
>>>
>>> then do everything in those classes as now except the call to init()
>>>
>>>
>>> but if the developers could do option 1) that probably would be the best
>>> thanks
>>>
>>>
>>> -Pedro
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Pedro Vicente
>>> To: plp...@li...
>>> Sent: Wednesday, October 05, 2016 6:42 PM
>>> Subject: [Plplot-general] wxWidgets driver -- change the default
>>> blackbackground
>>>
>>> Hi
>>>
>>>
>>> I am trying to change the default black background color using the
>>> wxWidgets
>>> driver
>>>
>>> If using the SVG driver this can be done as explained here
>>>
>>> https://sourceforge.net/p/plplot/mailman/message/2817799/
>>>
>>> the trick being calling
>>>
>>> plscolbg()
>>>
>>> before
>>>
>>> plinit();
>>>
>>> like the sample code below marked "SVG Driver" does
>>>
>>>
>>> However for the wxWidegts driver , it seems we do not do a call to
>>>
>>> plinit();
>>>
>>> but rather this is done inside the C++ stream initialization
>>>
>>> From the wxWidgets PLplot sample below
>>>
>>> the
>>>
>>> plinit();
>>>
>>> is made inside
>>>
>>>
>>>
>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>>>
>>>
>>> so I don't find a way to call the plscolbg() function before
>>>
>>>
>>> How can this be accomplished ?
>>>
>>>
>>>
>>>
>>> I also tried to modify the default colors of the default palette
>>>
>>> cmap0_default.pal
>>>
>>> 16
>>> #000000
>>>
>>> so that the first is white
>>>
>>> this does work *but* only after the window is redrawn (it first shows
>>> the
>>> default red on black);
>>> this seems like a bug to me
>>>
>>>
>>> Also, what's the call to increase the font size?
>>> On the wxWidgets driver the font looks tiny
>>>
>>> Thanks !
>>>
>>>
>>> Sample code wxWidgets
>>>
>>>
>>>
>>> bool
>>>
>>> wxAppPlot::OnInit()
>>>
>>> {
>>>
>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>
>>> frame->Create(
>>>
>>> NULL, wxID_ANY, wxT("wxPLplot"));
>>>
>>> frame->Show();
>>>
>>> Plot(frame);
>>>
>>> return true;
>>>
>>> }
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> //Plot
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> template
>>>
>>> < class WXWINDOW >
>>>
>>> void
>>>
>>> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>>
>>> {
>>>
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>> //render
>>>
>>> plotwindow->RenewPlot();
>>>
>>> }
>>>
>>>
>>>
>>>
>>> Sample code SVG driver
>>>
>>> void
>>>
>>> atms_dwell_granu_t::plot()
>>>
>>> {
>>>
>>> //set SVG device and output file name
>>>
>>> plsdev("svg");
>>>
>>> plsfnam("atms_dwell_granu.svg");
>>>
>>> //set background color (0) to white RGB(255,255,255)
>>>
>>> //must be called before plinit()
>>>
>>> plscolbg(255, 255, 255);
>>>
>>> //initialize plplot
>>>
>>> plinit();
>>>
>>> //change color (0) to black RGB(0, 0, 0)
>>>
>>> //must be called after plinit()
>>>
>>> plscol0(0, 0, 0, 0);
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> //render
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> PLFLT xmin, xmax, ymin, ymax;
>>>
>>> PLFLT *x, *y;
>>>
>>> const int NSIZE = iOrbit_all;
>>>
>>> xmin = 0;
>>>
>>> xmax = NSIZE;
>>>
>>> ymin = -1.0;
>>>
>>> ymax = 6.0;
>>>
>>> x =
>>>
>>> new PLFLT[NSIZE];
>>>
>>> y =
>>>
>>> new PLFLT[NSIZE];
>>>
>>> plcol0(0);
>>>
>>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>
>>> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>>>
>>> //time axis
>>>
>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>
>>> {
>>>
>>> x[idx_orb] = idx_orb;
>>>
>>> }
>>>
>>> //mean
>>>
>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>
>>> {
>>>
>>> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT - 1][idx_orb];
>>>
>>> }
>>>
>>> plpoin(NSIZE, x, y, 46);
>>>
>>> plend();
>>>
>>> delete[] x;
>>>
>>> delete[] y;
>>>
>>> }
>>>
>>> ________________________________
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>
>>> ________________________________
>>>
>>> _______________________________________________
>>> Plplot-general mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Pedro V. <ped...@sp...> - 2016-10-06 14:44:07
|
Hi Phil, Alan
This solution worked for me, thanks
> The easiest way to do this at the moment is something like
>
> wxPLplotstream* pls = plotwindow->GetStream();
> pls->adv( 0 );
> pls->scolbg(255, 255, 255);
> pls->clear();
> //rest of your plotting code
> I'm very open to better ways
> to do this if you have suggestions.
The only suggestion I have is the one I sent on my previous mail, that
was *not* to have
wxPLplotstream::Create
call
init()
and let the user do that on his application.
By looking at the samples, I believe they all call plinit() at start,
my complete test code is now
#include "wx/wxprec.h"
#include "wx/wx.h"
#include "wxPLplotwindow.h"
template< class WXWINDOW >
void Plot(wxPLplotwindow<WXWINDOW> *plotwindow);
/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxAppPlot
/////////////////////////////////////////////////////////////////////////////////////////////////////
class wxAppPlot : public wxApp
{
public:
virtual bool OnInit();
};
IMPLEMENT_APP(wxAppPlot)
bool wxAppPlot::OnInit()
{
wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
frame->Show();
Plot(frame);
return true;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////
//Plot
/////////////////////////////////////////////////////////////////////////////////////////////////////
template< class WXWINDOW >
void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
{
wxPLplotstream* pls = plotwindow->GetStream();
pls->adv(0);
pls->scolbg(255, 255, 255);
pls->clear();
//render
const int NSIZE = 101;
PLFLT x[NSIZE], y[NSIZE];
PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
for (int i = 0; i < NSIZE; i++)
{
x[i] = i;
y[i] = 5;
}
plschr(0, 1.0);
plcol0(8);
plenv(xmin, xmax, ymin, ymax, 0, 0);
pllab("x", "y", "Label");
plpoin(NSIZE, x, y, 46);
plotwindow->RenewPlot();
}
-Pedro
----- Original Message -----
From: "Phil Rosenberg" <p.d...@gm...>
To: "Pedro Vicente" <ped...@sp...>
Cc: <plp...@li...>;
<plp...@li...>
Sent: Thursday, October 06, 2016 5:55 AM
Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change the
default blackbackground
> Hi Pedro
> The easiest way to do this at the moment is something like
>
> wxPLplotstream* pls = plotwindow->GetStream();
> pls->adv( 0 );
> pls->scolbg(255, 255, 255);
> pls->clear();
> //rest of your plotting code
>
> If you have multiple subpages then you will need to do this on each
> page. Also if your subpages don't cover all the windows then you can
> call the SetBackgroundColour method of wxPLplotwindow and this will
> clear the whole window to the given colour initially.
>
> Hope that helps. If not then let me know. I'm very open to better ways
> to do this if you have suggestions.
>
> Phil
>
>
> On 6 October 2016 at 06:00, Pedro Vicente
> <ped...@sp...> wrote:
>>
>> so, there are at least 2 solutions for this :
>> 1) the quick is just to modify the PLplot source code , in the call to
>>
>> void wxPLplotstream::Create
>>
>> comment the call to
>>
>> //init();
>>
>> then in our app code , do the init() call after Create() . as
>>
>> ~~~
>> bool wxAppPlot::OnInit()
>> {
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>> wxDefaultPosition,
>> wxSize(900, 700));
>> frame->Show();
>>
>> //set background color (0) to white RGB(255,255,255)
>> //must be called before plinit()
>> plscolbg(255, 255, 255);
>>
>> wxPLplotstream* pls = frame->GetStream();
>> pls->init();
>>
>> //change color (0) to black RGB(0, 0, 0)
>> //must be called after plinit()
>> plscol0(0, 0, 0, 0);
>>
>> Plot(frame);
>> return true;
>> }
>> ~~~
>>
>>
>> since it seems the only way to modiy the background color is to do the
>> above
>> sequence
>> this is a change that I recommend to be included in the libray, since I
>> believe the other drivers require a call to init() too, but not the
>> wxWidgets driver.
>>
>> 2) not modifying the source code. In this case , I think it should be
>> possible to derive 2 classes ,
>> a) one from wxPLplotwindow
>> b) other from wxPLplotwindow
>>
>> then do everything in those classes as now except the call to init()
>>
>>
>> but if the developers could do option 1) that probably would be the best
>> thanks
>>
>>
>> -Pedro
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Pedro Vicente
>> To: plp...@li...
>> Sent: Wednesday, October 05, 2016 6:42 PM
>> Subject: [Plplot-general] wxWidgets driver -- change the default
>> blackbackground
>>
>> Hi
>>
>>
>> I am trying to change the default black background color using the
>> wxWidgets
>> driver
>>
>> If using the SVG driver this can be done as explained here
>>
>> https://sourceforge.net/p/plplot/mailman/message/2817799/
>>
>> the trick being calling
>>
>> plscolbg()
>>
>> before
>>
>> plinit();
>>
>> like the sample code below marked "SVG Driver" does
>>
>>
>> However for the wxWidegts driver , it seems we do not do a call to
>>
>> plinit();
>>
>> but rather this is done inside the C++ stream initialization
>>
>> From the wxWidgets PLplot sample below
>>
>> the
>>
>> plinit();
>>
>> is made inside
>>
>>
>>
>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>>
>>
>> so I don't find a way to call the plscolbg() function before
>>
>>
>> How can this be accomplished ?
>>
>>
>>
>>
>> I also tried to modify the default colors of the default palette
>>
>> cmap0_default.pal
>>
>> 16
>> #000000
>>
>> so that the first is white
>>
>> this does work *but* only after the window is redrawn (it first shows the
>> default red on black);
>> this seems like a bug to me
>>
>>
>> Also, what's the call to increase the font size?
>> On the wxWidgets driver the font looks tiny
>>
>> Thanks !
>>
>>
>> Sample code wxWidgets
>>
>>
>>
>> bool
>>
>> wxAppPlot::OnInit()
>>
>> {
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>
>> frame->Create(
>>
>> NULL, wxID_ANY, wxT("wxPLplot"));
>>
>> frame->Show();
>>
>> Plot(frame);
>>
>> return true;
>>
>> }
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> //Plot
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> template
>>
>> < class WXWINDOW >
>>
>> void
>>
>> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>
>> {
>>
>> wxPLplotstream* pls = plotwindow->GetStream();
>>
>> //render
>>
>> plotwindow->RenewPlot();
>>
>> }
>>
>>
>>
>>
>> Sample code SVG driver
>>
>> void
>>
>> atms_dwell_granu_t::plot()
>>
>> {
>>
>> //set SVG device and output file name
>>
>> plsdev("svg");
>>
>> plsfnam("atms_dwell_granu.svg");
>>
>> //set background color (0) to white RGB(255,255,255)
>>
>> //must be called before plinit()
>>
>> plscolbg(255, 255, 255);
>>
>> //initialize plplot
>>
>> plinit();
>>
>> //change color (0) to black RGB(0, 0, 0)
>>
>> //must be called after plinit()
>>
>> plscol0(0, 0, 0, 0);
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> //render
>>
>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>> PLFLT xmin, xmax, ymin, ymax;
>>
>> PLFLT *x, *y;
>>
>> const int NSIZE = iOrbit_all;
>>
>> xmin = 0;
>>
>> xmax = NSIZE;
>>
>> ymin = -1.0;
>>
>> ymax = 6.0;
>>
>> x =
>>
>> new PLFLT[NSIZE];
>>
>> y =
>>
>> new PLFLT[NSIZE];
>>
>> plcol0(0);
>>
>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>
>> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>>
>> //time axis
>>
>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>
>> {
>>
>> x[idx_orb] = idx_orb;
>>
>> }
>>
>> //mean
>>
>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>
>> {
>>
>> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT - 1][idx_orb];
>>
>> }
>>
>> plpoin(NSIZE, x, y, 46);
>>
>> plend();
>>
>> delete[] x;
>>
>> delete[] y;
>>
>> }
>>
>> ________________________________
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>> ________________________________
>>
>> _______________________________________________
>> Plplot-general mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
|
|
From: Phil R. <p.d...@gm...> - 2016-10-06 09:55:58
|
Hi Pedro
The easiest way to do this at the moment is something like
wxPLplotstream* pls = plotwindow->GetStream();
pls->adv( 0 );
pls->scolbg(255, 255, 255);
pls->clear();
//rest of your plotting code
If you have multiple subpages then you will need to do this on each
page. Also if your subpages don't cover all the windows then you can
call the SetBackgroundColour method of wxPLplotwindow and this will
clear the whole window to the given colour initially.
Hope that helps. If not then let me know. I'm very open to better ways
to do this if you have suggestions.
Phil
On 6 October 2016 at 06:00, Pedro Vicente
<ped...@sp...> wrote:
>
> so, there are at least 2 solutions for this :
> 1) the quick is just to modify the PLplot source code , in the call to
>
> void wxPLplotstream::Create
>
> comment the call to
>
> //init();
>
> then in our app code , do the init() call after Create() . as
>
> ~~~
> bool wxAppPlot::OnInit()
> {
> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
> wxDefaultPosition,
> wxSize(900, 700));
> frame->Show();
>
> //set background color (0) to white RGB(255,255,255)
> //must be called before plinit()
> plscolbg(255, 255, 255);
>
> wxPLplotstream* pls = frame->GetStream();
> pls->init();
>
> //change color (0) to black RGB(0, 0, 0)
> //must be called after plinit()
> plscol0(0, 0, 0, 0);
>
> Plot(frame);
> return true;
> }
> ~~~
>
>
> since it seems the only way to modiy the background color is to do the above
> sequence
> this is a change that I recommend to be included in the libray, since I
> believe the other drivers require a call to init() too, but not the
> wxWidgets driver.
>
> 2) not modifying the source code. In this case , I think it should be
> possible to derive 2 classes ,
> a) one from wxPLplotwindow
> b) other from wxPLplotwindow
>
> then do everything in those classes as now except the call to init()
>
>
> but if the developers could do option 1) that probably would be the best
> thanks
>
>
> -Pedro
>
>
>
>
> ----- Original Message -----
> From: Pedro Vicente
> To: plp...@li...
> Sent: Wednesday, October 05, 2016 6:42 PM
> Subject: [Plplot-general] wxWidgets driver -- change the default
> blackbackground
>
> Hi
>
>
> I am trying to change the default black background color using the wxWidgets
> driver
>
> If using the SVG driver this can be done as explained here
>
> https://sourceforge.net/p/plplot/mailman/message/2817799/
>
> the trick being calling
>
> plscolbg()
>
> before
>
> plinit();
>
> like the sample code below marked "SVG Driver" does
>
>
> However for the wxWidegts driver , it seems we do not do a call to
>
> plinit();
>
> but rather this is done inside the C++ stream initialization
>
> From the wxWidgets PLplot sample below
>
> the
>
> plinit();
>
> is made inside
>
>
>
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>
>
> so I don't find a way to call the plscolbg() function before
>
>
> How can this be accomplished ?
>
>
>
>
> I also tried to modify the default colors of the default palette
>
> cmap0_default.pal
>
> 16
> #000000
>
> so that the first is white
>
> this does work *but* only after the window is redrawn (it first shows the
> default red on black);
> this seems like a bug to me
>
>
> Also, what's the call to increase the font size?
> On the wxWidgets driver the font looks tiny
>
> Thanks !
>
>
> Sample code wxWidgets
>
>
>
> bool
>
> wxAppPlot::OnInit()
>
> {
>
> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>
> frame->Create(
>
> NULL, wxID_ANY, wxT("wxPLplot"));
>
> frame->Show();
>
> Plot(frame);
>
> return true;
>
> }
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> //Plot
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> template
>
> < class WXWINDOW >
>
> void
>
> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>
> {
>
> wxPLplotstream* pls = plotwindow->GetStream();
>
> //render
>
> plotwindow->RenewPlot();
>
> }
>
>
>
>
> Sample code SVG driver
>
> void
>
> atms_dwell_granu_t::plot()
>
> {
>
> //set SVG device and output file name
>
> plsdev("svg");
>
> plsfnam("atms_dwell_granu.svg");
>
> //set background color (0) to white RGB(255,255,255)
>
> //must be called before plinit()
>
> plscolbg(255, 255, 255);
>
> //initialize plplot
>
> plinit();
>
> //change color (0) to black RGB(0, 0, 0)
>
> //must be called after plinit()
>
> plscol0(0, 0, 0, 0);
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> //render
>
> /////////////////////////////////////////////////////////////////////////////////////////////////////
>
> PLFLT xmin, xmax, ymin, ymax;
>
> PLFLT *x, *y;
>
> const int NSIZE = iOrbit_all;
>
> xmin = 0;
>
> xmax = NSIZE;
>
> ymin = -1.0;
>
> ymax = 6.0;
>
> x =
>
> new PLFLT[NSIZE];
>
> y =
>
> new PLFLT[NSIZE];
>
> plcol0(0);
>
> plenv(xmin, xmax, ymin, ymax, 0, 0);
>
> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>
> //time axis
>
> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>
> {
>
> x[idx_orb] = idx_orb;
>
> }
>
> //mean
>
> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>
> {
>
> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT - 1][idx_orb];
>
> }
>
> plpoin(NSIZE, x, y, 46);
>
> plend();
>
> delete[] x;
>
> delete[] y;
>
> }
>
> ________________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> ________________________________
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Pedro V. <ped...@sp...> - 2016-10-06 05:00:15
|
so, there are at least 2 solutions for this :
1) the quick is just to modify the PLplot source code , in the call to
void wxPLplotstream::Create
comment the call to
//init();
then in our app code , do the init() call after Create() . as
~~~
bool wxAppPlot::OnInit()
{
wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
frame->Show();
//set background color (0) to white RGB(255,255,255)
//must be called before plinit()
plscolbg(255, 255, 255);
wxPLplotstream* pls = frame->GetStream();
pls->init();
//change color (0) to black RGB(0, 0, 0)
//must be called after plinit()
plscol0(0, 0, 0, 0);
Plot(frame);
return true;
}
~~~
since it seems the only way to modiy the background color is to do the above sequence
this is a change that I recommend to be included in the libray, since I believe the other drivers require a call to init() too, but not the wxWidgets driver.
2) not modifying the source code. In this case , I think it should be possible to derive 2 classes ,
a) one from wxPLplotwindow
b) other from wxPLplotwindow
then do everything in those classes as now except the call to init()
but if the developers could do option 1) that probably would be the best
thanks
-Pedro
----- Original Message -----
From: Pedro Vicente
To: plp...@li...
Sent: Wednesday, October 05, 2016 6:42 PM
Subject: [Plplot-general] wxWidgets driver -- change the default blackbackground
Hi
I am trying to change the default black background color using the wxWidgets driver
If using the SVG driver this can be done as explained here
https://sourceforge.net/p/plplot/mailman/message/2817799/
the trick being calling
plscolbg()
before
plinit();
like the sample code below marked "SVG Driver" does
However for the wxWidegts driver , it seems we do not do a call to
plinit();
but rather this is done inside the C++ stream initialization
From the wxWidgets PLplot sample below
the
plinit();
is made inside
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
so I don't find a way to call the plscolbg() function before
How can this be accomplished ?
I also tried to modify the default colors of the default palette
cmap0_default.pal
16
#000000
so that the first is white
this does work *but* only after the window is redrawn (it first shows the default red on black);
this seems like a bug to me
Also, what's the call to increase the font size?
On the wxWidgets driver the font looks tiny
Thanks !
Sample code wxWidgets
bool wxAppPlot::OnInit()
{
wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
frame->Show();
Plot(frame);
return true;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////
//Plot
/////////////////////////////////////////////////////////////////////////////////////////////////////
template< class WXWINDOW >
void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
{
wxPLplotstream* pls = plotwindow->GetStream();
//render
plotwindow->RenewPlot();
}
Sample code SVG driver
void atms_dwell_granu_t::plot()
{
//set SVG device and output file name
plsdev("svg");
plsfnam("atms_dwell_granu.svg");
//set background color (0) to white RGB(255,255,255)
//must be called before plinit()
plscolbg(255, 255, 255);
//initialize plplot
plinit();
//change color (0) to black RGB(0, 0, 0)
//must be called after plinit()
plscol0(0, 0, 0, 0);
/////////////////////////////////////////////////////////////////////////////////////////////////////
//render
/////////////////////////////////////////////////////////////////////////////////////////////////////
PLFLT xmin, xmax, ymin, ymax;
PLFLT *x, *y;
const int NSIZE = iOrbit_all;
xmin = 0;
xmax = NSIZE;
ymin = -1.0;
ymax = 6.0;
x = new PLFLT[NSIZE];
y = new PLFLT[NSIZE];
plcol0(0);
plenv(xmin, xmax, ymin, ymax, 0, 0);
pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
//time axis
for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
{
x[idx_orb] = idx_orb;
}
//mean
for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
{
y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT - 1][idx_orb];
}
plpoin(NSIZE, x, y, 46);
plend();
delete[] x;
delete[] y;
}
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
------------------------------------------------------------------------------
_______________________________________________
Plplot-general mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-general
|
|
From: Alan W. I. <ir...@be...> - 2016-10-02 09:19:36
|
For years we have been plagued by trailing space issues on quite a few lines in many of our text files. I have just made an extremely intrusive (651 files changed, 8548 insertions(+), 8534 deletions) commit (4e9797dc) to fix these issues. See the commit message for the regex pattern I used for the files I excluded from this change. This commit passed all my comprehensive testing (both noninteractive and interactive). So if this commit has introduced a bug, it is likely not going to be seen by many users. Nevertheless, it is possible your daily use may differ in some random way from our comprehensive testing and thus might find some issue that this commit introduces. Therefore, please keep an eye open for any strange results in your daily use of PLplot that is caused by this commit. 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 __________________________ |
|
From: Arjen M. <Arj...@de...> - 2016-09-19 06:54:42
|
Hi Phil, I had a quick look at the code to see what might be the cause, but the message comes from the "default" branch of a catch statement. So whatever the cause, it was not immediately clear to me ;). Regards, Arjen From: Phil Rosenberg [mailto:p.d...@gm...] Sent: Saturday, September 17, 2016 10:58 PM To: Arjen Markus Cc: Alan W. Irwin; plp...@li... Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Arjen I'm just emailing to say that I have now got plplot to compile with wxWidgets support on Cygwin and I also find that it doesn't function. I will look into it once I get time. On 16 September 2016 at 15:32, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote: Hi Phil, As a package, definitely. Regards, Arjen From: Phil Rosenberg [mailto:p.d...@gm...<mailto:p.d...@gm...>] Sent: Friday, September 16, 2016 4:25 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Arjen I'm just trying to reproduce your Cygwin problems, but I can't get plplot to build with wxWidgets on. Do you know if you installed wxWidgets as a package or from source? Sent from my Windows 10 phone From: Arjen Markus<mailto:Arj...@de...> Sent: 16 September 2016 08:08 To: Alan W. Irwin<mailto:ir...@be...>; Phil Rosenberg<mailto:p.d...@gm...> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Alan, Phil, I tried Phil's example on Cygwin - PLplot as built on my installation does have a wxWidgets driver - but unfortunately that fails to run: *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_init_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_bop_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_line_wxwidgets., aborting operation ... I then tried it with other drivers, but none demonstrated the sort of problem Phil mentions (I did not quite expect that to happen, but it never hurts to try). Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88335 8559 E arj...@de...<mailto:arj...@de...> [Logo]<http://www.deltares.com/> www.deltares.com<http://www.deltares.com/> Postbus 177 2600 MH Delft <http://www.twitter.com/deltares> Please consider the environment before printing this email > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, September 13, 2016 11:59 PM > To: Phil Rosenberg > Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c > > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > > > On 13 September 2016 at 03:27, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> > wrote: > >> There is a substantial testing requirement for fill changes. The > >> reason for that is we have had years of mostly good user experience > >> with the present fill algorithm so I feel it is important that > >> anybody that changes the fill algorithm in any further way needs to > >> demonstrate with substantial testing that their change does not > >> introduce fill regressions. > >> > >> I have alluded previously to automated fill regression testing (for > >> all our standard examples that directly or indirectly use fill and > >> all our file devices). The core of the idea is to compare old and > >> updated plot file results using imagemagick image differences. Do > >> you agree this general approach (supplemented by actually looking at the "fill" > >> subset of our examples for each of our interactive devices) is the > >> way forward to insure that our further fill changes do not introduce > >> more issues than they fix? > > > > I think this is a good idea in general to avoid all sorts of > > regressions. > > Good. > > > Would it be easier to use the svg output and diff as the svg examples > > can be built on all systems? > > Presumably you are aware of this already, but it should be mentioned that one > issue with diff results is you cannot reliably compare results from two different > floating-point (FP) platforms because FP errors propagate to rounded results on > two such platforms in different ways. So it is essential to calculate both the old and > revised fill result with exactly the same FP platform (i.e., you cannot store plot > results from one FP platform to compare with plot results from other FP platforms). > > Another issue with using diff even for the same FP platform is any significant > change in the fill code is likely to cause real differences, e.g., the effective > boundaries of the filled regions will be slightly different. In fact, this is a problem for > all fully automated methods I can think of to test for fill regressions; there are going > to be large local changes (as boundaries change slightly) in results, but so long as > the final result looks OK (i.e., no obvious holes in any fill region and no significantly > overfilled regions) then the change does not count as a significant fill regression. > > As a result of this concern, I am now thinking along the lines of an interactive script > (i.e., not completely automated so it will be tiring to use unless we are careful with > the selection of what images to compare). At the heart of the script, imagemagick > would calculate the normalized difference of the old and modified image results, and > then simultanously display old, modified, and difference image results to help > evaluate by visual means (as opposed to fully automated means) whether any > significant regression has occurred. (Of course, for those cases where the > normalized difference image is zero, the script could simply skip the visual > comparison to speed up the comparison). > > I have mentioned imagemagick here because I am reasonably familiar with it, and it > is one of the primary collections of software that is used on Unix to manipulate and > display images. However, you should also note that imagemagick is available as a > binary download on Windows (see <http://www.imagemagick.org/script/binary- <http://www.imagemagick.org/script/binary-%0b>> releases.php>). > Furthermore, even though it appears not to be specifically packaged for Cygwin > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the generic > windows binary download does not work, there is that other Windows platform > alternative to try as well. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>). > > Programming affiliations with the FreeEOS equation-of-state implementation for > stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); > PLplot scientific plotting software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project > (unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>); and the Linux > Brochure Project (lbproject.sf.net<http://lbproject.sf.net>). > __________________________ > > Linux-powered Science > __________________________ 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. 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. 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. |
|
From: Alan W. I. <ir...@be...> - 2016-09-18 14:36:44
|
Phil said: > I have modified my the example that exposes the bug so that it works for svg. Please find attached. Thanks, Phil, for this revised example which I confirm does trigger the "all-fill" bug for -dev svg here (Debian Jessie platform) as well. I have no further time to work on this before the release, but this example is what I will start with post-release. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-09-18 08:29:37
|
Hi All I have modified my the example that exposes the bug so that it works for svg. Please find attached. Phil On 17 September 2016 at 21:57, Phil Rosenberg <p.d...@gm...> wrote: > Hi Arjen > I'm just emailing to say that I have now got plplot to compile with > wxWidgets support on Cygwin and I also find that it doesn't function. I > will look into it once I get time. > > On 16 September 2016 at 15:32, Arjen Markus <Arj...@de...> > wrote: > >> Hi Phil, >> >> >> >> As a package, definitely. >> >> >> >> Regards, >> >> >> >> Arjen >> >> >> >> >> >> *From:* Phil Rosenberg [mailto:p.d...@gm...] >> *Sent:* Friday, September 16, 2016 4:25 PM >> *To:* Arjen Markus; Alan W. Irwin >> >> *Cc:* plp...@li... >> *Subject:* RE: [Plplot-devel] Bug in notcrossed() function of plfill.c >> >> >> >> Hi Arjen >> >> I'm just trying to reproduce your Cygwin problems, but I can't get plplot >> to build with wxWidgets on. Do you know if you installed wxWidgets as a >> package or from source? >> >> >> >> Sent from my Windows 10 phone >> >> >> >> *From: *Arjen Markus <Arj...@de...> >> *Sent: *16 September 2016 08:08 >> *To: *Alan W. Irwin <ir...@be...>; Phil Rosenberg >> <p.d...@gm...> >> *Cc: *plp...@li... >> *Subject: *RE: [Plplot-devel] Bug in notcrossed() function of plfill.c >> >> >> >> Hi Alan, Phil, >> >> >> >> I tried Phil’s example on Cygwin – PLplot as built on my installation >> does have a wxWidgets driver – but unfortunately that fails to run: >> >> >> >> *** PLPLOT ERROR, ABORTING OPERATION *** >> >> unknown error in plD_init_wxwidgets., aborting operation >> >> >> >> *** PLPLOT ERROR, ABORTING OPERATION *** >> >> unknown error in plD_bop_wxwidgets., aborting operation >> >> >> >> *** PLPLOT ERROR, ABORTING OPERATION *** >> >> unknown error in plD_line_wxwidgets., aborting operation >> >> … >> >> I then tried it with other drivers, but none demonstrated the sort of >> problem Phil mentions (I did not quite expect that to happen, but it never >> hurts to try). >> >> Regards, >> >> Arjen >> >> >> >> >> >> >> >> >> >> >> *Arjen Markus* >> Sr. Adviseur/Onderzoeker >> >> T >> >> +31(0)88335 8559 >> >> E >> >> arj...@de... >> >> >> >> >> >> [image: Logo] <http://www.deltares.com/> >> >> * www.deltares.com* <http://www.deltares.com/> >> >> Postbus 177 >> 2600 MH Delft >> >> >> <http://www.twitter.com/deltares> >> >> <http://www.linkedin.com/company/217430> >> >> <https://www.facebook.com/pages/Deltares/154189334634001> >> >> >> Please consider the environment before printing this email >> >> >> >> > -----Original Message----- >> > From: Alan W. Irwin [mailto:ir...@be... >> <ir...@be...>] >> > Sent: Tuesday, September 13, 2016 11:59 PM >> > To: Phil Rosenberg >> > Cc: Arjen Markus; plp...@li... >> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c >> > >> > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: >> > >> > > On 13 September 2016 at 03:27, Alan W. Irwin < >> ir...@be...> >> > wrote: >> > >> There is a substantial testing requirement for fill changes. The >> > >> reason for that is we have had years of mostly good user experience >> > >> with the present fill algorithm so I feel it is important that >> > >> anybody that changes the fill algorithm in any further way needs to >> > >> demonstrate with substantial testing that their change does not >> > >> introduce fill regressions. >> > >> >> > >> I have alluded previously to automated fill regression testing (for >> > >> all our standard examples that directly or indirectly use fill and >> > >> all our file devices). The core of the idea is to compare old and >> > >> updated plot file results using imagemagick image differences. Do >> > >> you agree this general approach (supplemented by actually looking at >> the "fill" >> > >> subset of our examples for each of our interactive devices) is the >> > >> way forward to insure that our further fill changes do not introduce >> > >> more issues than they fix? >> > > >> > > I think this is a good idea in general to avoid all sorts of >> > > regressions. >> > >> > Good. >> > >> > > Would it be easier to use the svg output and diff as the svg examples >> > > can be built on all systems? >> > >> > Presumably you are aware of this already, but it should be mentioned >> that one >> > issue with diff results is you cannot reliably compare results from two >> different >> > floating-point (FP) platforms because FP errors propagate to rounded >> results on >> > two such platforms in different ways. So it is essential to calculate >> both the old and >> > revised fill result with exactly the same FP platform (i.e., you cannot >> store plot >> > results from one FP platform to compare with plot results from other FP >> platforms). >> > >> > Another issue with using diff even for the same FP platform is any >> significant >> > change in the fill code is likely to cause real differences, e.g., the >> effective >> > boundaries of the filled regions will be slightly different. In fact, >> this is a problem for >> > all fully automated methods I can think of to test for fill >> regressions; there are going >> > to be large local changes (as boundaries change slightly) in results, >> but so long as >> > the final result looks OK (i.e., no obvious holes in any fill region >> and no significantly >> > overfilled regions) then the change does not count as a significant >> fill regression. >> > >> > As a result of this concern, I am now thinking along the lines of an >> interactive script >> > (i.e., not completely automated so it will be tiring to use unless we >> are careful with >> > the selection of what images to compare). At the heart of the script, >> imagemagick >> > would calculate the normalized difference of the old and modified image >> results, and >> > then simultanously display old, modified, and difference image results >> to help >> > evaluate by visual means (as opposed to fully automated means) whether >> any >> > significant regression has occurred. (Of course, for those cases where >> the >> > normalized difference image is zero, the script could simply skip the >> visual >> > comparison to speed up the comparison). >> > >> > I have mentioned imagemagick here because I am reasonably familiar with >> it, and it >> > is one of the primary collections of software that is used on Unix to >> manipulate and >> > display images. However, you should also note that imagemagick is >> available as a >> > binary download on Windows (see <http://www.imagemagick.org/sc >> ript/binary- >> <http://www.imagemagick.org/script/binary-%0b>> releases.php>). >> > Furthermore, even though it appears not to be specifically packaged for >> Cygwin >> > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the >> generic >> > windows binary download does not work, there is that other Windows >> platform >> > alternative to try as well. >> > >> > 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 >> > __________________________ >> >> 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. >> >> >> 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. >> > > |
|
From: Phil R. <p.d...@gm...> - 2016-09-17 20:57:55
|
Hi Arjen I'm just emailing to say that I have now got plplot to compile with wxWidgets support on Cygwin and I also find that it doesn't function. I will look into it once I get time. On 16 September 2016 at 15:32, Arjen Markus <Arj...@de...> wrote: > Hi Phil, > > > > As a package, definitely. > > > > Regards, > > > > Arjen > > > > > > *From:* Phil Rosenberg [mailto:p.d...@gm...] > *Sent:* Friday, September 16, 2016 4:25 PM > *To:* Arjen Markus; Alan W. Irwin > > *Cc:* plp...@li... > *Subject:* RE: [Plplot-devel] Bug in notcrossed() function of plfill.c > > > > Hi Arjen > > I'm just trying to reproduce your Cygwin problems, but I can't get plplot > to build with wxWidgets on. Do you know if you installed wxWidgets as a > package or from source? > > > > Sent from my Windows 10 phone > > > > *From: *Arjen Markus <Arj...@de...> > *Sent: *16 September 2016 08:08 > *To: *Alan W. Irwin <ir...@be...>; Phil Rosenberg > <p.d...@gm...> > *Cc: *plp...@li... > *Subject: *RE: [Plplot-devel] Bug in notcrossed() function of plfill.c > > > > Hi Alan, Phil, > > > > I tried Phil’s example on Cygwin – PLplot as built on my installation does > have a wxWidgets driver – but unfortunately that fails to run: > > > > *** PLPLOT ERROR, ABORTING OPERATION *** > > unknown error in plD_init_wxwidgets., aborting operation > > > > *** PLPLOT ERROR, ABORTING OPERATION *** > > unknown error in plD_bop_wxwidgets., aborting operation > > > > *** PLPLOT ERROR, ABORTING OPERATION *** > > unknown error in plD_line_wxwidgets., aborting operation > > … > > I then tried it with other drivers, but none demonstrated the sort of > problem Phil mentions (I did not quite expect that to happen, but it never > hurts to try). > > Regards, > > Arjen > > > > > > > > > > > *Arjen Markus* > Sr. Adviseur/Onderzoeker > > T > > +31(0)88335 8559 > > E > > arj...@de... > > > > > > [image: Logo] <http://www.deltares.com/> > > * www.deltares.com* <http://www.deltares.com/> > > Postbus 177 > 2600 MH Delft > > > <http://www.twitter.com/deltares> > > <http://www.linkedin.com/company/217430> > > <https://www.facebook.com/pages/Deltares/154189334634001> > > > Please consider the environment before printing this email > > > > > -----Original Message----- > > From: Alan W. Irwin [mailto:ir...@be... > <ir...@be...>] > > Sent: Tuesday, September 13, 2016 11:59 PM > > To: Phil Rosenberg > > Cc: Arjen Markus; plp...@li... > > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c > > > > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > > > > > On 13 September 2016 at 03:27, Alan W. Irwin < > ir...@be...> > > wrote: > > >> There is a substantial testing requirement for fill changes. The > > >> reason for that is we have had years of mostly good user experience > > >> with the present fill algorithm so I feel it is important that > > >> anybody that changes the fill algorithm in any further way needs to > > >> demonstrate with substantial testing that their change does not > > >> introduce fill regressions. > > >> > > >> I have alluded previously to automated fill regression testing (for > > >> all our standard examples that directly or indirectly use fill and > > >> all our file devices). The core of the idea is to compare old and > > >> updated plot file results using imagemagick image differences. Do > > >> you agree this general approach (supplemented by actually looking at > the "fill" > > >> subset of our examples for each of our interactive devices) is the > > >> way forward to insure that our further fill changes do not introduce > > >> more issues than they fix? > > > > > > I think this is a good idea in general to avoid all sorts of > > > regressions. > > > > Good. > > > > > Would it be easier to use the svg output and diff as the svg examples > > > can be built on all systems? > > > > Presumably you are aware of this already, but it should be mentioned > that one > > issue with diff results is you cannot reliably compare results from two > different > > floating-point (FP) platforms because FP errors propagate to rounded > results on > > two such platforms in different ways. So it is essential to calculate > both the old and > > revised fill result with exactly the same FP platform (i.e., you cannot > store plot > > results from one FP platform to compare with plot results from other FP > platforms). > > > > Another issue with using diff even for the same FP platform is any > significant > > change in the fill code is likely to cause real differences, e.g., the > effective > > boundaries of the filled regions will be slightly different. In fact, > this is a problem for > > all fully automated methods I can think of to test for fill regressions; > there are going > > to be large local changes (as boundaries change slightly) in results, > but so long as > > the final result looks OK (i.e., no obvious holes in any fill region and > no significantly > > overfilled regions) then the change does not count as a significant fill > regression. > > > > As a result of this concern, I am now thinking along the lines of an > interactive script > > (i.e., not completely automated so it will be tiring to use unless we > are careful with > > the selection of what images to compare). At the heart of the script, > imagemagick > > would calculate the normalized difference of the old and modified image > results, and > > then simultanously display old, modified, and difference image results > to help > > evaluate by visual means (as opposed to fully automated means) whether > any > > significant regression has occurred. (Of course, for those cases where > the > > normalized difference image is zero, the script could simply skip the > visual > > comparison to speed up the comparison). > > > > I have mentioned imagemagick here because I am reasonably familiar with > it, and it > > is one of the primary collections of software that is used on Unix to > manipulate and > > display images. However, you should also note that imagemagick is > available as a > > binary download on Windows (see <http://www.imagemagick.org/ > script/binary- > <http://www.imagemagick.org/script/binary-%0b>> releases.php>). > > Furthermore, even though it appears not to be specifically packaged for > Cygwin > > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the > generic > > windows binary download does not work, there is that other Windows > platform > > alternative to try as well. > > > > 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 > > __________________________ > > 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. > > > 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. > |
|
From: Alan W. I. <ir...@be...> - 2016-09-17 18:53:46
|
On 2016-09-17 09:12+0200 Laurent Berger wrote: > Hi Pedro, > > I am using vs2013 and plplot (from github) with wxwidgets and I haven't got > any problem. I think you should update findwxwidgets.cmake from > https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/modules/FindwxWidgets.cmake > (see > https://sourceforge.net/p/plplot/plplot/ci/5b9dd303b50061c8ed3a9f149aea4b2a6817eece/log/?path=/cmake/modules/FindwxWidgets.cmake) > > May be you should clone plplot version but it is a develloper version. > > I hope it will solve your problem. > > Laurent I have just looked at the latest official version of FindwxWidgets.cmake from the cmake git master branch and it is the same as or superior to the PLplot unofficial version in all respects (e.g., in supporting all the recently released versions of wxWidgets). Therefore, I have just changed the PLplot master branch so that our unofficial version follows the official version (see my recent commit 511a6ac). @Pedro, Laurent, and other wxwidgets users: Please test the latest PLplot git master branch to make sure that unofficial FindwxWidgets.cmake find module satisfies your needs. 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 __________________________ |
|
From: Pedro V. <ped...@sp...> - 2016-09-17 07:57:37
|
so, I found the issue, that was just a matter of not adding strings for the latest
wxwidgets-3.1.0
version
in the script named FindwxWidgets.cmake
add the line containing "31" in several places
foreach(LIB net odbc xml)
find_library(WX_${LIB}${_DBG}
NAMES
wxbase31${_UCD}${_DBG}_${LIB}
wxbase30${_UCD}${_DBG}_${LIB}
wxbase29${_UCD}${_DBG}_${LIB}
wxbase28${_UCD}${_DBG}_${LIB}
I am evaluating PLplot for a C++ project concerning 1D axis and 2D map plots and I have to say I am impressed so far:
1) easy to use, build a basic SVG output in a couple of hours
2) so far the SVG output looks good
3) WxWidgets and QT drivers
4) etc
-Pedro
----- Original Message -----
From: Laurent Berger
To: plp...@li...
Sent: Saturday, September 17, 2016 3:12 AM
Subject: Re: [Plplot-devel] build with wxWidgets, Visual Studio
Hi Pedro,
I am using vs2013 and plplot (from github) with wxwidgets and I haven't got any problem. I think you should update findwxwidgets.cmake from https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/modules/FindwxWidgets.cmake (see https://sourceforge.net/p/plplot/plplot/ci/5b9dd303b50061c8ed3a9f149aea4b2a6817eece/log/?path=/cmake/modules/FindwxWidgets.cmake)
May be you should clone plplot version but it is a develloper version.
I hope it will solve your problem.
Laurent
Le 17/09/2016 à 07:43, Pedro Vicente a écrit :
Hi
I am trying to build PLPlot with the wxWidgets driver , and I get some errors
https://sourceforge.net/p/plplot/wiki/WxWidgets/
This is for
wxwidgets-3.1.0
Visual Studio 2015
I used
cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR=%WXWIN% -DwxWidgets_LIB_DIR=%WXWIN%/lib/vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
The wxwidgets Cmake output is
-- wxWidgets_FOUND : FALSE
-- wxWidgets_INCLUDE_DIRS : M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include
-- wxWidgets_LIBRARY_DIRS :
-- wxWidgets_LIBRARIES : M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxpngd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxtiffd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxjp
egd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxzlibd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxregexud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxexpatd.lib;winmm;comct
l32;rpcrt4;wsock32
-- wxWidgets_CXX_FLAGS :
-- wxWidgets_USE_FILE : UsewxWidgets
-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
-- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.
-- WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.
It seems some libraries are found, and these 2 lines here
-- wxWidgets_INCLUDE_DIRS : M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include
-- wxWidgets_LIBRARY_DIRS :
seem to be mixed up.
How could I debug the PLPlot supplied Cmake script, "FindwxWidgets.cmake"?
thanks
-Pedro
----------------------
Pedro Vicente
ped...@sp...
http://www.space-research.org/
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel
|
|
From: Laurent B. <lau...@un...> - 2016-09-17 07:31:55
|
Hi Pedro, I am using vs2013 and plplot (from github) with wxwidgets and I haven't got any problem. I think you should update findwxwidgets.cmake from https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/modules/FindwxWidgets.cmake (see https://sourceforge.net/p/plplot/plplot/ci/5b9dd303b50061c8ed3a9f149aea4b2a6817eece/log/?path=/cmake/modules/FindwxWidgets.cmake) May be you should clone plplot version but it is a develloper version. I hope it will solve your problem. Laurent Le 17/09/2016 à 07:43, Pedro Vicente a écrit : > Hi > I am trying to build PLPlot with the wxWidgets driver , and I get some > errors > https://sourceforge.net/p/plplot/wiki/WxWidgets/ > This is for > wxwidgets-3.1.0 > Visual Studio 2015 > I used > cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON > -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" > -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF > -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON > -DwxWidgets_ROOT_DIR=%WXWIN% -DwxWidgets_LIB_DIR=%WXWIN%/lib/vc_lib > -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON > -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF > The wxwidgets Cmake output is > -- wxWidgets_FOUND : FALSE > -- wxWidgets_INCLUDE_DIRS : > M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include > -- wxWidgets_LIBRARY_DIRS : > -- wxWidgets_LIBRARIES : > M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxpngd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxtiffd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxjp > egd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxzlibd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxregexud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxexpatd.lib;winmm;comct > l32;rpcrt4;wsock32 > -- wxWidgets_CXX_FLAGS : > -- wxWidgets_USE_FILE : UsewxWidgets > -- WARNING: wxWidgets or its libraries not found so setting all > wxwidgets devices to OFF. > -- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF. > -- WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices > to OFF. > It seems some libraries are found, and these 2 lines here > -- wxWidgets_INCLUDE_DIRS : > M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include > -- wxWidgets_LIBRARY_DIRS : > seem to be mixed up. > How could I debug the PLPlot supplied Cmake script, > "FindwxWidgets.cmake"? > thanks > -Pedro > ---------------------- > Pedro Vicente > ped...@sp... > http://www.space-research.org/ > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Pedro V. <ped...@sp...> - 2016-09-17 06:10:03
|
Hi I am trying to build PLPlot with the wxWidgets driver , and I get some errors https://sourceforge.net/p/plplot/wiki/WxWidgets/ This is for wxwidgets-3.1.0 Visual Studio 2015 I used cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR=%WXWIN% -DwxWidgets_LIB_DIR=%WXWIN%/lib/vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF The wxwidgets Cmake output is -- wxWidgets_FOUND : FALSE -- wxWidgets_INCLUDE_DIRS : M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include -- wxWidgets_LIBRARY_DIRS : -- wxWidgets_LIBRARIES : M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxpngd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxtiffd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxjp egd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxzlibd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxregexud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxexpatd.lib;winmm;comct l32;rpcrt4;wsock32 -- wxWidgets_CXX_FLAGS : -- wxWidgets_USE_FILE : UsewxWidgets -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF. -- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF. -- WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF. It seems some libraries are found, and these 2 lines here -- wxWidgets_INCLUDE_DIRS : M:/wx/wxwidgets-3.1.0/lib/vc_lib/mswud;M:/wx/wxwidgets-3.1.0/include -- wxWidgets_LIBRARY_DIRS : seem to be mixed up. How could I debug the PLPlot supplied Cmake script, "FindwxWidgets.cmake"? thanks -Pedro ---------------------- Pedro Vicente ped...@sp... http://www.space-research.org/ |
|
From: Arjen M. <Arj...@de...> - 2016-09-16 14:32:36
|
Hi Phil, As a package, definitely. Regards, Arjen From: Phil Rosenberg [mailto:p.d...@gm...] Sent: Friday, September 16, 2016 4:25 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Arjen I'm just trying to reproduce your Cygwin problems, but I can't get plplot to build with wxWidgets on. Do you know if you installed wxWidgets as a package or from source? Sent from my Windows 10 phone From: Arjen Markus<mailto:Arj...@de...> Sent: 16 September 2016 08:08 To: Alan W. Irwin<mailto:ir...@be...>; Phil Rosenberg<mailto:p.d...@gm...> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Alan, Phil, I tried Phil's example on Cygwin - PLplot as built on my installation does have a wxWidgets driver - but unfortunately that fails to run: *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_init_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_bop_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_line_wxwidgets., aborting operation ... I then tried it with other drivers, but none demonstrated the sort of problem Phil mentions (I did not quite expect that to happen, but it never hurts to try). Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88335 8559 E arj...@de...<mailto:arj...@de...> [Logo]<http://www.deltares.com/> www.deltares.com<http://www.deltares.com/> Postbus 177 2600 MH Delft <http://www.twitter.com/deltares> <http://www.linkedin.com/company/217430> <https://www.facebook.com/pages/Deltares/154189334634001> Please consider the environment before printing this email > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, September 13, 2016 11:59 PM > To: Phil Rosenberg > Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c > > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > > > On 13 September 2016 at 03:27, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> > wrote: > >> There is a substantial testing requirement for fill changes. The > >> reason for that is we have had years of mostly good user experience > >> with the present fill algorithm so I feel it is important that > >> anybody that changes the fill algorithm in any further way needs to > >> demonstrate with substantial testing that their change does not > >> introduce fill regressions. > >> > >> I have alluded previously to automated fill regression testing (for > >> all our standard examples that directly or indirectly use fill and > >> all our file devices). The core of the idea is to compare old and > >> updated plot file results using imagemagick image differences. Do > >> you agree this general approach (supplemented by actually looking at the "fill" > >> subset of our examples for each of our interactive devices) is the > >> way forward to insure that our further fill changes do not introduce > >> more issues than they fix? > > > > I think this is a good idea in general to avoid all sorts of > > regressions. > > Good. > > > Would it be easier to use the svg output and diff as the svg examples > > can be built on all systems? > > Presumably you are aware of this already, but it should be mentioned that one > issue with diff results is you cannot reliably compare results from two different > floating-point (FP) platforms because FP errors propagate to rounded results on > two such platforms in different ways. So it is essential to calculate both the old and > revised fill result with exactly the same FP platform (i.e., you cannot store plot > results from one FP platform to compare with plot results from other FP platforms). > > Another issue with using diff even for the same FP platform is any significant > change in the fill code is likely to cause real differences, e.g., the effective > boundaries of the filled regions will be slightly different. In fact, this is a problem for > all fully automated methods I can think of to test for fill regressions; there are going > to be large local changes (as boundaries change slightly) in results, but so long as > the final result looks OK (i.e., no obvious holes in any fill region and no significantly > overfilled regions) then the change does not count as a significant fill regression. > > As a result of this concern, I am now thinking along the lines of an interactive script > (i.e., not completely automated so it will be tiring to use unless we are careful with > the selection of what images to compare). At the heart of the script, imagemagick > would calculate the normalized difference of the old and modified image results, and > then simultanously display old, modified, and difference image results to help > evaluate by visual means (as opposed to fully automated means) whether any > significant regression has occurred. (Of course, for those cases where the > normalized difference image is zero, the script could simply skip the visual > comparison to speed up the comparison). > > I have mentioned imagemagick here because I am reasonably familiar with it, and it > is one of the primary collections of software that is used on Unix to manipulate and > display images. However, you should also note that imagemagick is available as a > binary download on Windows (see <http://www.imagemagick.org/script/binary- <http://www.imagemagick.org/script/binary-%0b>> releases.php>). > Furthermore, even though it appears not to be specifically packaged for Cygwin > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the generic > windows binary download does not work, there is that other Windows platform > alternative to try as well. > > 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 > __________________________ 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. 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. |
|
From: Phil R. <p.d...@gm...> - 2016-09-16 14:25:20
|
Hi Arjen I'm just trying to reproduce your Cygwin problems, but I can't get plplot to build with wxWidgets on. Do you know if you installed wxWidgets as a package or from source? Sent from my Windows 10 phone From: Arjen Markus |
|
From: Arjen M. <Arj...@de...> - 2016-09-16 07:08:18
|
Hi Alan, Phil, I tried Phil's example on Cygwin - PLplot as built on my installation does have a wxWidgets driver - but unfortunately that fails to run: *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_init_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_bop_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_line_wxwidgets., aborting operation ... I then tried it with other drivers, but none demonstrated the sort of problem Phil mentions (I did not quite expect that to happen, but it never hurts to try). Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88335 8559 E arj...@de... [Logo]<http://www.deltares.com/> www.deltares.com<http://www.deltares.com/> Postbus 177 2600 MH Delft [Deltares Twitter] <http://www.twitter.com/deltares> [Deltares LinkedIn]<http://www.linkedin.com/company/217430> [Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001> [Think before printing]Please consider the environment before printing this email > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, September 13, 2016 11:59 PM > To: Phil Rosenberg > Cc: Arjen Markus; plp...@li... > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c > > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > > > On 13 September 2016 at 03:27, Alan W. Irwin <ir...@be...> > wrote: > >> There is a substantial testing requirement for fill changes. The > >> reason for that is we have had years of mostly good user experience > >> with the present fill algorithm so I feel it is important that > >> anybody that changes the fill algorithm in any further way needs to > >> demonstrate with substantial testing that their change does not > >> introduce fill regressions. > >> > >> I have alluded previously to automated fill regression testing (for > >> all our standard examples that directly or indirectly use fill and > >> all our file devices). The core of the idea is to compare old and > >> updated plot file results using imagemagick image differences. Do > >> you agree this general approach (supplemented by actually looking at the "fill" > >> subset of our examples for each of our interactive devices) is the > >> way forward to insure that our further fill changes do not introduce > >> more issues than they fix? > > > > I think this is a good idea in general to avoid all sorts of > > regressions. > > Good. > > > Would it be easier to use the svg output and diff as the svg examples > > can be built on all systems? > > Presumably you are aware of this already, but it should be mentioned that one > issue with diff results is you cannot reliably compare results from two different > floating-point (FP) platforms because FP errors propagate to rounded results on > two such platforms in different ways. So it is essential to calculate both the old and > revised fill result with exactly the same FP platform (i.e., you cannot store plot > results from one FP platform to compare with plot results from other FP platforms). > > Another issue with using diff even for the same FP platform is any significant > change in the fill code is likely to cause real differences, e.g., the effective > boundaries of the filled regions will be slightly different. In fact, this is a problem for > all fully automated methods I can think of to test for fill regressions; there are going > to be large local changes (as boundaries change slightly) in results, but so long as > the final result looks OK (i.e., no obvious holes in any fill region and no significantly > overfilled regions) then the change does not count as a significant fill regression. > > As a result of this concern, I am now thinking along the lines of an interactive script > (i.e., not completely automated so it will be tiring to use unless we are careful with > the selection of what images to compare). At the heart of the script, imagemagick > would calculate the normalized difference of the old and modified image results, and > then simultanously display old, modified, and difference image results to help > evaluate by visual means (as opposed to fully automated means) whether any > significant regression has occurred. (Of course, for those cases where the > normalized difference image is zero, the script could simply skip the visual > comparison to speed up the comparison). > > I have mentioned imagemagick here because I am reasonably familiar with it, and it > is one of the primary collections of software that is used on Unix to manipulate and > display images. However, you should also note that imagemagick is available as a > binary download on Windows (see <http://www.imagemagick.org/script/binary- > releases.php>). > Furthermore, even though it appears not to be specifically packaged for Cygwin > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the generic > windows binary download does not work, there is that other Windows platform > alternative to try as well. > > 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 > __________________________ 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. |
|
From: Alan W. I. <ir...@be...> - 2016-09-13 21:59:27
|
On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > On 13 September 2016 at 03:27, Alan W. Irwin <ir...@be...> wrote: >> There is a substantial testing requirement for fill changes. The >> reason for that is we have had years of mostly good user experience >> with the present fill algorithm so I feel it is important that anybody >> that changes the fill algorithm in any further way needs to >> demonstrate with substantial testing that their change does not >> introduce fill regressions. >> >> I have alluded previously to automated fill regression testing (for >> all our standard examples that directly or indirectly use fill and all >> our file devices). The core of the idea is to compare old and updated >> plot file results using imagemagick image differences. Do you agree >> this general approach (supplemented by actually looking at the "fill" >> subset of our examples for each of our interactive devices) is the way >> forward to insure that our further fill changes do not introduce more >> issues than they fix? > > I think this is a good idea in general to avoid all sorts of > regressions. Good. > Would it be easier to use the svg output and diff as the > svg examples can be built on all systems? Presumably you are aware of this already, but it should be mentioned that one issue with diff results is you cannot reliably compare results from two different floating-point (FP) platforms because FP errors propagate to rounded results on two such platforms in different ways. So it is essential to calculate both the old and revised fill result with exactly the same FP platform (i.e., you cannot store plot results from one FP platform to compare with plot results from other FP platforms). Another issue with using diff even for the same FP platform is any significant change in the fill code is likely to cause real differences, e.g., the effective boundaries of the filled regions will be slightly different. In fact, this is a problem for all fully automated methods I can think of to test for fill regressions; there are going to be large local changes (as boundaries change slightly) in results, but so long as the final result looks OK (i.e., no obvious holes in any fill region and no significantly overfilled regions) then the change does not count as a significant fill regression. As a result of this concern, I am now thinking along the lines of an interactive script (i.e., not completely automated so it will be tiring to use unless we are careful with the selection of what images to compare). At the heart of the script, imagemagick would calculate the normalized difference of the old and modified image results, and then simultanously display old, modified, and difference image results to help evaluate by visual means (as opposed to fully automated means) whether any significant regression has occurred. (Of course, for those cases where the normalized difference image is zero, the script could simply skip the visual comparison to speed up the comparison). I have mentioned imagemagick here because I am reasonably familiar with it, and it is one of the primary collections of software that is used on Unix to manipulate and display images. However, you should also note that imagemagick is available as a binary download on Windows (see <http://www.imagemagick.org/script/binary-releases.php>). Furthermore, even though it appears not to be specifically packaged for Cygwin such packaging has occurred for the MinGW-w64/MSYS2 platform so if the generic windows binary download does not work, there is that other Windows platform alternative to try as well. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-09-13 09:44:13
|
Hi Alan, Arjen On 13 September 2016 at 03:27, Alan W. Irwin <ir...@be...> wrote: > On 2016-09-12 21:39+0100 Phil Rosenberg wrote: > >>>>> I'm still of the opinion that the notcrossed function should not use >>>>> the 2 pixel fuzziness. At this point in the drawing we are dealing in >>>>> integer pixels and we need only an epsilon test I think. I think the >>>>> best fix is to change this. There are some sticking plaster solutions >>>>> that would hide the problem but not really fix it in my opinion. I >>>>> would really like to change the notcrossed function unless anyone has >>>>> some really strong objections? >>>> >>>> >>>> >>>> My opinion is this is an extraordinarily tricky topic where all the >>>> currently active fill code (i.e., the part of the code not currently >>>> removed by the C preprocessor) needs to be completely reviewed and >>>> potentially rewritten. Also, I think the fuzziness logic (with all >>>> bugs fixed in that code) should stay just in the interests of >>>> providing some tolerance for numerical rounding errors. For example, >>>> even the article <https://en.wikipedia.org/wiki/Point_in_polygon> >>>> talks of providing some numerical tolerance. Note also, such >>>> tolerance is certainly required for the integer case since minute >>>> rounding errors in the floating point calculations that decide, for >>>> example, whether a point is inside or outside a polygon can shift >>>> integer results around by +/- 1. >>>> >>>> I have a topic branch where I have already taken some substantial >>>> steps along the above ideas (including at least one bug fix in our >>>> current fuzzy logic in notcrossed). I temporarily halted work on that >>>> topic some time ago, but assuming you can provide a test example that >>>> triggers fill bugs regardless of compiler or optimization level, I >>>> plan to take up that topic again where the first order of business >>>> will be to compare (using imagemagick image differences) updated fill >>>> algorithm results versus 5.11.1 results for all our standard examples >>>> that use fill in some way. (That test should turn up any unusual fill >>>> artifacts in our examples that are generated by bugs in the original >>>> or revised fill algorithm, and once that test is implemented it should >>>> be done for any fill change from now on.) In addition, of course, I >>>> will look carefully at your example to make sure the revised fill >>>> algorithm produces the correct result for it. >>>> >>>> Assuming you are able to provide the requested example which triggers >>>> the fill bug regardless of rounding issues, and the above >>>> plan meets with your approval, I would plan to start working on this >>>> topic again just after the current release is out the door. >>>> >>>> Note also there are still a number of relatively small issues I would >>>> like to address for this release, but because of the break I mentioned >>>> above, I made little progress on those this summer so that release >>>> deadline is still indefinite and at least a month or two away. >>>> >> I agree that this is tricky, but feel this is something we can deal >> with without being too troublesome. Algorithms and code already exist >> to do this consistently - we're not the first to have to deal with it. >> In fact here is a 7 line C implementation that deals with the ray >> hitting a vertex correctly, but doesn't give any warning about if the >> point is close to or on a segment. >> >> I still don't understand why we need two whole plplot units of >> fuzziness. I understand that we round and that can give us up to two >> pixels of error. But surely we just accept that and work with the >> rounded polygons as if they were exact - in fact they are exact >> because they use integers. >> >> for example we wish to plot two rectangles which end up with internal >> coordinates of the opposite corners of (200,400.2),(600,600.4) and >> (200,600.4),(600,800.1). We round these to give (200,400),(600,600) >> and (200,600),(600,800). Now there is absolutely no count that the >> point (350,600.2) is in the second rectangle. Of course if we were >> using the original coordinates this point would have been in the first >> rectangle. But we are not plotting the original coordinates, we are >> plotting the rounded coordinates and that is what matters - the >> coordinates we are plotting. > > > We shouldn't care about 1-pixel rounding shifts in results. But we do > need to care about logic screwups caused by such shifts. Of course, > you are also demonstrating the current fuzzy logic sucks, i.e., the > cure is currently worse than the disease. But let's fix that fuzzy > logic rather than throwing it out completely. > I'm not sure what logic screw-ups can occur. We pass in all polygons in integer coordinates. Therefore when doing e.g. contoured fills we will get exact tessellation. The PNPOLY code I linked to before consistently processes so that for tessellating polygons every point, even one on a line or vertex ends up in exactly one polygon. Is this sufficient to avoid the logic screw ups you refer to? As it happens I have realised that even with non-fuzzy point-in-polygon tests this bug could still occur if the bottom left corner was exactly on a segment. Note that the test for filling the whole window is that no lines are drawable (i.e. all lines are outside the clip region) and the bottom left corner is inside the polygon. We should add a different check - that the centre of the clip region is in the polygon. I think this absolutely guarantees that the polygon encompasses the whole clip region. >> >> I would clearly like to get this fixed properly, but in the meantime >> would anyone object if I apply a sticking plaster fix for this as it >> is something I have hit about half a dozen times over the last six >> months - I presume this is because I've been plotting some really high >> resolution data. So I do really need to avoid the issue for now. > > > There is a substantial testing requirement for fill changes. The > reason for that is we have had years of mostly good user experience > with the present fill algorithm so I feel it is important that anybody > that changes the fill algorithm in any further way needs to > demonstrate with substantial testing that their change does not > introduce fill regressions. > > I have alluded previously to automated fill regression testing (for > all our standard examples that directly or indirectly use fill and all > our file devices). The core of the idea is to compare old and updated > plot file results using imagemagick image differences. Do you agree > this general approach (supplemented by actually looking at the "fill" > subset of our examples for each of our interactive devices) is the way > forward to insure that our further fill changes do not introduce more > issues than they fix? I think this is a good idea in general to avoid all sorts of regressions. Would it be easier to use the svg output and diff as the svg examples can be built on all systems? > > Assuming you like this idea, please implement it if you are in a hurry > or else wait for me to implement it post-release. Then once our fill > regression testing scheme is in place, you should test any proposed > fill change with that scheme before you merge that fill change to the > master branch. > > Of course, while waiting for one of us to implement such a fill > testing scheme, there is still the problem about what to do for the > fill problems that have recently been bugging you? I suggest you > should simply solve those issues locally in any convenient way that > you find that works for your particular needs, and circulate that > patch on this list to be referred to when we finally start working on > the definitive fix. > > |
|
From: Phil R. <p.d...@gm...> - 2016-09-13 09:33:36
|
Oh, I didn't realise you were working on Windows Arjen. I will have to spend some time sorting out a case for the SVG driver then. Unfortunately it was about 4 hours work finding a suitable test case before, but hopefully now I understand the bug better it should be faster - but it probably won't be today when I get time. Phil On 13 September 2016 at 10:29, Arjen Markus <Arj...@de...> wrote: > Hi Phil, > > > >> -----Original Message----- >> From: Phil Rosenberg [mailto:p.d...@gm...] >> >> … > >> I assume this has something to do with aspect ratios of the page on the >> different >> devices or something. But anyway, these inconsistent sizes means it isn't >> possible >> to generate a case that exposes the bug on all devices. I think all those >> involved >> have access to wxWidgets - please state if not - so I think this should be >> fine for us >> to work on. >> > wxWidgets is not available on bare Windows. It is on Cygwin, though I have > never done much with it. > > Regards, > > Arjen > > > > 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. |
76 messages has been excluded from this view by a project administrator.
