Oh there is the fill issue that I reported previously too. Once you have had a chance to consider if the change is okay let me know.
Phil On 20 June 2015 at 11:46, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > Hi Alan > > Regarding the tcl cmake bug it is still there. Just to reiterate the > problem does not seem to be that the file that is being looked for has > a space - the problem is that the file genuinely does not exist. So > the problem must be elsewhere in the CMake logic, which could be due > to speces still I guess. > > Here is the error I get from trying to build INSTALL > > 102> CMake Error at bindings/cmake_install.cmake:39 (file): > > 102> file INSTALL cannot find "D:/usr/local/src/plplot-plplot/build/Visual > > 102> Studio 11 64sd/bindings/pkgIndex.tcl". > > 102> Call Stack (most recent call first): > > 102> cmake_install.cmake:61 (include) > > 102> > > 102> > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: The command "setlocal > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" > -DBUILD_TYPE=Debug -P cmake_install.cmake > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: if %errorlevel% neq 0 goto :cmEnd > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: :cmEnd > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto > :cmDone > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: :cmErrorLevel > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: exit /b %1 > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: :cmDone > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: if %errorlevel% neq 0 goto :VCEnd > > 102>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): > error MSB3073: :VCEnd" exited with code 1. > > Perhaps if you try to build in a directory with a space you will be > able to see more easily what the problem is? > > Regarding the speed on Linux.I have a problem which I will describe > below with my Ubuntu machine, but I have just quickly tested example 3 > with ssh over the internet connecting to my work CentOS PC. I think > was the example you used to highlight the problem. On Windows it takes > about 3 seconds from selecting the wxWidgets driver and pressing enter > to running the wxViewer and displaying the plot. By comparison the ssh > over the internet test takes about 10 seconds. 6 of those seconds are > the time up to the window being initially displayed so they are > probably the time required to load the executable and for wxWidgets to > do its initial window setup. This leaves about 4 seconds to transfer > the data to wxViewer and render. While I agree that this isn't > brilliant, given all the extra overheads going on with that connection > I think that is acceptable. What sort of rendering times do you see > running on an actual Linux machine? > > Now for my Ubuntu machine. I have hit a snag that has come from the > checking text length. I think from the limited debugging I have done > that when I try to get the font metrics in the console part of the > device this causes a segfault within wxWidgets. This is therefore > going to have to be rewritten. For some reason there is no problem on > my CentOS machine, I think this is running wxWidgets 2.8 rather than > 3.0. If anyone else can confirm this behaviour then it would be > appreciated. > > Regarding other bugs. Please see my trello page where I am currently > tracking everything > https://trello.com/b/xBv7SJco/plplot-wxwidgets-plus-related-buffer-issues. > > One item I would appreciate confirmation on - it seems like fixing the > text size problem has fixed the bad transform of 3d text, at least to > my eyes. If you could take a quick look and confirm you are happy that > would be good. > > Phil > > On 19 June 2015 at 21:02, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >> As release manager for the forthcoming release of 5.11.1, I would >> appreciate those who have further bug fixing projects in mind for this >> release cycle leading up to 5.11.1 inform me of those projects. >> >> @ Phil: specifically what is on your agenda for wxwidgets bug fixing >> for the next several weeks? For example, I would dearly like to see >> the extreme slowness regression (introduced since 5.11.0) for >> wxwidgets on Linux fixed for this release, and the last I heard on >> that topic from you was you could not build PLplot on Linux to >> investigate the matter further. At which point I asked for a >> comprehensive test report on that situation (see below), but I have >> not received that yet from you. Also, with regard to the concatenated >> file bug you found in our build system for a "spaced" build tree, I >> committed a second version of that fix after you reported the first >> one did not completely work, and I am currently waiting for your >> report of whether that second fix works. >> >> My own agenda items for the remainder of this release cycle are as follows: >> >> * Keep up with on-going resolution of bugs in our C/C++ source code. >> Those currently include the wxwidgets extreme slowness regression on >> Linux mentioned above, Jim's series of patches fixing the eop >> problem for interactive devices, and the on-going discussion of the >> notcrossed functionality with Phil. Please let me know if I forgot >> anything here that should be on my agenda during the rest of this >> release cycle. >> >> * Fix build-system issues that are discovered via comprehensive >> testing by everyone that is lurking on this list that routinely >> builds PLplot from our git version. Arjen has been extremely >> helpful in this regard, and future builds of 5.11.1 on Cygwin should >> be much easier for our users as a result of his many tests, but I >> strongly encourage the rest of you to start running >> >> scripts/comprehensive_test.sh --do_test_interactive no >> >> on all platforms accessible to you on a routine basis. (That option >> is a convenience to make that script run without the babysitting >> required for the interactive comprehensive testing part of the >> script.) That script automatically collects a report tarball in >> ../comprehensive_test_disposeable/comprehensive_test.tar.gz that you >> should send to this list if you have any difficulties on a platform >> since that tarball generally gives all the information I need to >> analyze the issue and find a build-system fix for it. Also, please >> send that report tarball in the case when you have a (partial) >> success you want to see reported on our wiki since the report >> tarball generally includes all necessary information for that wiki >> entry. Such comprehensinve test results from a lot of you here will go a >> long way >> to insure that 5.11.1 will have good build behaviour on all >> platforms. >> >> * Remove everything to do with long-retired device drivers since the >> outdated information in those files simply confuses those who want >> to develop a modern PLplot device driver. >> >> * Extend the TEST_DEVICE concept, e.g., for the svg device from ctest >> to the test_noninteractive target for the build tree, install tree, >> and traditional install tree. >> >> * Improve exporting of PLplot targets following >> <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>. >> >> * Update epa_build to the latest versions of cmake and all libraries. >> >> * Investigate a report on plplot-general that "MinGW Makefiles" fails to >> build for 5.11.0 although it was fine for 5.10.0. >> >> * One more try at a MinGW-w64/MSYS2 install on Wine to see if the latest >> development version of Wine has fixed the bugs that did not allow that >> before. However, because Wine is incredibly slow, I am hoping I >> will never have to do this and someone else here will adopt that >> platform for comprehensive testing (see above agenda item concerning >> comprehensive testing on all accessible platforms). >> >> * Fix Ada language support for Cygwin. >> >> In the interests of getting 5.11.1 out roughly a month from now rather >> than considerably later, I will likely have to put off the last three >> items until later. But I am pretty sure I can get everything else on >> the above agenda into 5.11.1 especially with cooperation from everyone >> lurking on this list on doing comprehensive testing and sending the >> report tarballs that are automatically generated by that script to >> this list. >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel