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

Reply via email to