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

Reply via email to