Re: [Plplot-devel] Intermittent Ada example build failures are now back again
> On Jul 16, 2018, at 10:10 AM, Alan W. Irwin > wrote: > > On 2018-06-09 13:30-0700 Alan W. Irwin wrote: > >> On 2018-04-15 11:15-0700 Alan W. Irwin wrote: >> >>> Hi Jerry: >> [...] >>> So once this Ada build issue appeared again for me yesterday after all >>> those previous successful hardware checks, I did a google search for >>> the terms (without the quotes) "gnatmake intermittent build error" and >>> found >>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple=65451> >>> which was a bug report in 2015 about intermittent Ada build issues >>> which was immediately fixed back then. However, my gnat version (= >>> 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure >>> at this stage that bug 65451 is the issue that is causing the >>> intermittent Ada build issues for me. Therefore, I plan to use the >>> -DENABLE_ada=OFF option for my further testing until I can get access >>> to a later version of the Ada build tools myself, and I suggest others >>> who currently don't have access to Ada build tools with bug 65451 >>> fixed should do the same. >> >> Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I >> was using for Debian Jessie) the first test of Ada has been a complete >> success. >> See commit 994723471 for the details of the tests I ran. > > Hi Jerry: > > I just ran into this issue for the first time for my new hardware and > latest Ada/gnat (version 7.3.0) from Debian Buster (sigh). I was > doing a parallel build (with -j10 for my new system with 8 real > cores), when the following error was encountered: > > ./plplot_standard.o: file not recognized: File truncated > collect2: error: ld returned 1 exit status > gnatlink-7: error when calling /usr/bin/gcc-7 > gnatmake: *** link failed. > examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target > 'examples/ada/xstandard30a' failed > make[3]: *** [examples/ada/xstandard30a] Error 4 > > A google search found > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which > appears to be a similar (or the same bug) for 7.1. At the time, the > Debian packagers thought they had a fix, but it seems from my > experience either that was not true or else the fix has not been > propagated to 7.3. I have just now privately reported the situation to > Matthias Klose (the author of the bug 857831 report, and they guy who > decided that bug was fixed), and we will see what he says. But to > work around this problem until it is fixed for Debian Buster, I plan > to use -DENABLE_ada=OFF for my testing. > > Alan Thanks for the update, Alan. Keep me posted. Jerry -- 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Redacted dimension arguments
On Jan 19, 2016, at 5:32 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > I'm perhaps less keen on the idea of using the minimum dimension. > Passing unequal sized arrays is clearly and error and so I think we > should flag it is such is the loudest way possible so the user can fix > it. I agree with Phil. Jerry -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git (again)
On Feb 5, 2014, at 8:25 AM, Hazen Babcock hbabc...@mac.com wrote: On 2/5/2014 12:25 AM, Alan W. Irwin wrote: How big will the local copy be? And yes, the learning curve is kinda big. I fiddled around some time back with git w.r.t. LyX, the document processor. As I recall, the local storage requirements can be large. @Jerry: Good question on local size which I hope Hazen is in a position to answer. @Hazen: Here is a related question. My understanding from superficial reading is that git users normally have a local repository (unlike the svn case where there is normally just one repository). But if someone is worried about the disk space that is required by that local git repository, is there also a detached repository mode for git (i.e., so the user could simply use the SourceForge repository without copying all of the repository to his own computer)? This is no longer true? I checked out PLplot using git (master branch) and svn (trunk), which I believe to be roughly equivalent and the sizes are: (svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot) SVN: 36.2MB (43.8MB on disk) (git clone https://github.com/HazenBabcock/PLplot.git) GIT: 40.1MB (44.0MB on disk) That's interesting. My superficial understanding of git (also) is that the user stores the entire history of a project locally (with the advantage that checking stuff in and out is very fast). That means that apparently the PLplot history is stored very efficiently since the git size is only a little larger than the svn size. Also, I didn't spend enough time learning git to figure out what advantage there is when updating the master with a local repo--there still must be issues with conflicts. And is there any mechanism to lock a file while it is being edited, since it is checked out from the local repo and the master has no clue of the file's status. I recall we had a discussion of this recently w.r.t. svn where most agreed that conflicts like this are a rare event but there is indeed a locking mechanism of some sort if one chooses to use it. Jerry I'm pretty sure that there is nothing like a detached repository mode. Everything is local as they say. -Hazen -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git (again)
On Feb 4, 2014, at 3:05 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: So Hazen, assuming no other core PLplot developer have questions about the conversion of the official PLplot repo to git How big will the local copy be? And yes, the learning curve is kinda big. I fiddled around some time back with git w.r.t. LyX, the document processor. As I recall, the local storage requirements can be large. Jerry -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Tests are not being run on my OS X machine
I am running my usual build script on OS X but it is finishing early, before doing any tests. It worked OK about a day or two ago. Here are the last few lines of output: UpdateCTestConfiguration from :/usr/local/plplot_build_dir/DartConfiguration.tcl Parse Config file:/usr/local/plplot_build_dir/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/plplot_build_dir/DartConfiguration.tcl Parse Config file:/usr/local/plplot_build_dir/DartConfiguration.tcl Test project /usr/local/plplot_build_dir Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end No tests were found!!! I use this line to do Ada-only tests: ctest --verbose --tests-regex ada but nada. All of the Ada examples are created as usual so I don't know why this is now failing to run the tests. Jerry -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tests are not being run on my OS X machine
On Dec 13, 2013, at 11:29 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-12-13 03:33-0700 Jerry wrote: I am running my usual build script on OS X but it is finishing early, before doing any tests. It worked OK about a day or two ago. Here are the last few lines of output: UpdateCTestConfiguration from :/usr/local/plplot_build_dir/DartConfiguration.tcl Parse Config file:/usr/local/plplot_build_dir/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/plplot_build_dir/DartConfiguration.tcl Parse Config file:/usr/local/plplot_build_dir/DartConfiguration.tcl Test project /usr/local/plplot_build_dir Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end No tests were found!!! I use this line to do Ada-only tests: ctest --verbose --tests-regex ada but nada. All of the Ada examples are created as usual so I don't know why this is now failing to run the tests. Hi Jerry: I am glad you caught that. Should be fixed in revision 12863. Alan Working again. Thanks. Jerry -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Does SVN have a locked or checked-out feature?
Does SVN have a locked or a checked-out feature so that several people aren't editing the same file the same time? Jerry -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Still on track for the 5.9.11 release on December 14th
On Nov 29, 2013, at 8:36 AM, Andrew Ross andrewr...@users.sourceforge.net wrote: Alan, Thanks for this. Once my example 22 changes are finished I intend doing some testing too on my Ubuntu system (and hopefully on Debian unstable). I agree we're still on track for 14th December release. See comments below about example 22 progress. Andrew On Thu, Nov 28, 2013 at 10:56:10PM -0800, Alan W. Irwin wrote: Earlier today, I finished up the last of my planned test improvements (extending the interactive testing done for the traditional build of the installed examples to be comparable to the Tcl/Tk CMake-based testing that is done for the core build tree and the installed examples tree). To establish a testing benchmark for the runup to the 5.9.11 release on December 14th (two weeks from this Saturday) I ran scripts/comprehensive_test.sh with no options (i.e., everything default so a full suite of tests was done, i.e., ctest, make test_noninteractive, and make test_interactive in the build tree, and the latter two for the two build systems for the installed examples tree for each of our three major configurations (shared libs/dynamic devices, shared libs/non-dynamic devices, and static libs/non-dynamic devices). There were no obvious build or run-time issues with any of these large number of tests. So that is a great benchmark test result on Debian stable, and I hope others here will also do comprehensive testing in the next few days for the platforms they have access to in order to establish test benchmarks for those platforms. Such benchmarks for all platforms are important a couple of weeks before release to help guard against any regressions that may occur between now and release due to further changes. Note that thanks to Arjen's recent nopause work for Tcl and friends, the test_interactive targets are much easier to run now with relatively little clicking required by the user. So comprehensive testing is getting to be quiet convenient, and there are no excuses not to do it. :-) With regard to actual results I obtained with the set of comprehensive tests today, the diff issues have been reduced to the following thanks to all of Andrew's recent example 22 propagation efforts, f95 Missing examples: Differing postscript output : 22 Missing stdout : Differing stdout: The example has been updated. The difference is because f95 version of plshades does not support the rect argument. Once that is done (Arjen?) it is a one line fix. tcl Missing examples: Differing postscript output : 22 Missing stdout : Differing stdout: ada Missing examples: Differing postscript output : 22 Missing stdout : Differing stdout: adathick Missing examples: Differing postscript output : 22 Missing stdout : Differing stdout: ocaml Missing examples: Differing postscript output : 16 22 33 Missing stdout : Differing stdout: I expect those differences will be substantially reduced or even eliminated in the next few days if everyone cooperates for their favorite language(s) that still have remaining propagation issues. The remaining languages need updating. I will look at tcl next. I am assuming Hez will take on the ocaml changes along with the changes to examples 16 and 33. If someone is able to look at ada that would be great, otherwise I'll try and get round to it, but my ada knowledge is pretty hazy. I plan to get to this (Ada). Jerry Andrew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Question from comp.lang.ada user about thread safety
On Nov 14, 2013, at 5:28 AM, Andrew Ross andrewr...@users.sourceforge.net wrote: On Wednesday 13 Nov 2013 09:28:02 Hezekiah M. Carty wrote: On Tue, Nov 12, 2013 at 6:32 PM, Jerry lancebo...@qwest.net wrote: I posted an announcement some time back on comp.lang.ada. about the latest PLplot release. (FWIW, it currently has 182 views, and I got some useful feedback from the Ada gurus.) Today this post (below) appeared. I don't know how to answer his question about thread safety. Any thoughts? Jerry Hi Jerry, That looks really interesting. I'm looking for a plotter routine that could be used safely inside the AWS [= Ada Web Server] web server, so I can implement a 'callback' chart server (currently I have one written in Java). Could this be used for that? Some simple tests suggest to me that it isn't thread safe. The Initialize_PLplot [aka plinit] and associated procedures to set filenames, etc, seem to set global variables somewhere. Is there some trick I'm missing? It does make lovely looking charts. thanks very much for this. Graham PLplot is not thread safe. While you can use PLplot in a threaded program, only one thread per process may interact with PLplot at a given time. This limitation holds even if you are working with multiple plot streams in a single process. Regarding Alan's follow-up - while it is possible to make PLplot thread-safe, the changes required are invasive and pervasive. They are all good changes to make! But there is a lot to be done and the result is a completely backwards-incompatible API. The three big pieces required are: a) All PLplot functions will need to explicitly operate on a given plstream value representing the affected plot stream. This requires adding an additional stream argument to all PLplot functions and removing any global state from plot streams. b) Remove all of the globals used through the PLplot code base in the actual plotting logic. One example is the contour/shading routines which use several global variables to track their state. c) Confirm/ensure that each of our output devices can be and are used in a thread-safe manner. Each of these big pieces is made up of several smaller chunks. (a) is where the API breakage would come in. It is also likely the simplest (simple being relative here!) to complete. (b) could be pretty hairy as the logic in the contouring routines in particular is tricky to translate to something which doesn't use globals. (c) should be attainable for at least the Cairo, Qt and built-in output drivers (SVG, PS, null). I would be happy to help in putting together a plan for this work. Unfortunately my PLplot time is very limited these days so it's unlikely I'll be able to provide much development assistance. I'd concur with what Hez said, however there is one further source of thread problems - namely a number of the language bindings use globals to work round passing things like function pointers between languages. This would also need checking. This would be a useful, but substantive job. In terms of security we try to follow best practice in terms of checking buffer lengths, avoiding insecure library calls etc to avoid the obvious problems. Newer versions of gcc / gnu ld are getting better at flagging some of these. There is certainly no systematic attempt to harden plplot or fully check it for potential security issues. Andrew Thanks, Andrew. Jerry -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Question from comp.lang.ada user about thread safety
On Nov 12, 2013, at 4:32 PM, Jerry lancebo...@qwest.net wrote: I posted an announcement some time back on comp.lang.ada. about the latest PLplot release. (FWIW, it currently has 182 views, and I got some useful feedback from the Ada gurus.) Today this post (below) appeared. I don't know how to answer his question about thread safety. Any thoughts? Jerry Hi Jerry, That looks really interesting. I'm looking for a plotter routine that could be used safely inside the AWS [= Ada Web Server] web server, so I can implement a 'callback' chart server (currently I have one written in Java). Could this be used for that? Some simple tests suggest to me that it isn't thread safe. The Initialize_PLplot [aka plinit] and associated procedures to set filenames, etc, seem to set global variables somewhere. Is there some trick I'm missing? It does make lovely looking charts. thanks very much for this. Graham Thanks Alan and Hezekiah. I've transferred your responses to comp.lang.ada. Jerry -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Question from comp.lang.ada user about thread safety
I posted an announcement some time back on comp.lang.ada. about the latest PLplot release. (FWIW, it currently has 182 views, and I got some useful feedback from the Ada gurus.) Today this post (below) appeared. I don't know how to answer his question about thread safety. Any thoughts? Jerry Hi Jerry, That looks really interesting. I'm looking for a plotter routine that could be used safely inside the AWS [= Ada Web Server] web server, so I can implement a 'callback' chart server (currently I have one written in Java). Could this be used for that? Some simple tests suggest to me that it isn't thread safe. The Initialize_PLplot [aka plinit] and associated procedures to set filenames, etc, seem to set global variables somewhere. Is there some trick I'm missing? It does make lovely looking charts. thanks very much for this. Graham -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] How to treat calling plend in Ada
A few weeks ago, at the time of the most recent PLplot release, I posted a short announcement on comp.lang.ada, and I gave a very simple example of usage in an Ada program. Someone asked why plinit couldn't be done in the (Ada) elaboration of PLplot and why couldn't plend be done in the (Ada) finalization when the program terminates. These are Ada concepts meaning roughly that plinit could be worked into Ada's own initialization (aka elaboration, sort of) and finalization and thus executed automatically. I replied that in some usage situations PLplot needs to do some work before plinit is called. So that left the question of whether it made sense to put plend into an Ada finalization stage. I remarked that the manual method currently used would be better if the user wanted to free resources before the program was done running, but that it might be a good idea to have the automatic method (in the Ada finalization stage) in case the user forgot to do it manually. Then someone pointed o ut that if the program raises an exception, the manual method would be bypassed. We could ask the user to write an exception handler but s/he might forget to do that too. One might consider removing the manual method (and keeping backward compatibility by making the Ada-level call do nothing) but I don't like removing the manual option for reasons stated above. So before trying to put in an automatic call to plend at the Ada finalization, I need to know: (1) Does it hurt to call plend twice without an intervening plinit? I.e., the user puts in a manual plend and Ada does another automatic plend. (2) If so, is there a way to find out if PLplot is active, that is, has there been a call to plinit but no matching call to plend? Jerry -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the 5.9.10 release
On Oct 1, 2013, at 3:21 PM, Andrew Ross andrewr...@users.sourceforge.net wrote: On Monday 30 Sep 2013 23:40:25 Alan W. Irwin wrote: I still need to create a news item and do other publicity, and I also need to refine my notes on this release process in README.Release_Manager_Cookbook. But otherwise, the 5.9.10 release process is completed and the commit freeze is lifted. Let the 5.9.11 release cycle begin! Alan, Thank you (as ever) for all your work and rigorous testing of the release. Ditto here. Jerry Let's hope we can make them a little more regular again. I've already started working on the Debian packages and hope to get them uploaded to unstable shortly. This should fix a number of outstanding bugs and bring them back up to date. Regards Andrew -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the forthcoming 5.9.10 release
On Sep 20, 2013, at 8:56 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: We still seem on course for a release of 5.9.10 on September 28th (8 days from today). Here is the status of the language bindings and examples. All is well except for the following languages: ada Missing examples: Differing postscript output : 16 33 Missing stdout : Differing stdout: adathick Missing examples: Differing postscript output : 16 33 Missing stdout : Differing stdout: I have Ada example 16 generating correct Postscript so the remaining work now is mostly slogging through Example 33. Jerry ocaml Missing examples: Differing postscript output : 16 33 Missing stdout : Differing stdout: d Missing examples: Differing postscript output : 33 Missing stdout : Differing stdout: My understanding is that Jerry is working on the Ada issues, Hez is working on the OCaml issues, and Andrew is working on the D issues so there appears to be a good chance that we will have completely clean test_noninteractive (and test_interactive) results for this release. Here is what I hope to get accomplished before this release. 1. Implement sanity checks on NULL arrays for pllegend and plcolorbar. This change means that any input array that is used internally (rather than being ignored because of the specified input options) will be checked to make sure the array pointer is not NULL. Normally C users of these functions use NULL for the pointers to all arrays they think are ignored for a particular call because of the combination of options they have specified for that call. But if they make a mistake in the arrays they think will be ignored, these planned sanity checks should catch that mistake. 2. Add paragraphs to advanced.xml describing what pllegend and plcolorbar do. 3. Disable the production of the dvi form of documentation and make the corresponding change to our website (as discussed previously). 4. Update README.release to reflect the current status of pllegend and plcolorbar. 5. Update README.release to reflect the current status of the Cygwin platform. (This depends on Arjen's planned updates to our Wiki describing his recent Cygwin platform breakthroughs.) 6. Fix other Website issues such as the new locations for our Allura-based resources and additional pages for example 33. 7. Tests for this release during the last few days before the release. At minimum I plan to run scripts/comprehensive_test.sh, but I also hope to do some Wine testing as well with build_projects if I have time. 8. Do everything in README.Release_Manager_Cookbook (and edit that file if I change anything in that procedure) to get out the release itself. 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 __ -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] API documentation updates
On Sep 18, 2013, at 2:22 AM, Andrew Ross andrewr...@users.sourceforge.net wrote: On Wednesday 18 Sep 2013 00:36:14 Alan W. Irwin wrote: Hi Jerry: I have just completed (as of revision 12507) updates for the API documentation for both pllegend and plcolorbar. This effort took a while because as I got into it, I kept finding more and more language that needed to be tweaked. But I am reasonably satisfied with this documentation of the pllegend and plcolorbar API at the present time, and I hope it is useful to you in figuring out what you need to do to propagate plcolorbar to the Ada bindings and Ada examples 16 and 13. Jerry, Examples 16 and 33 now demonstrate most of the capabilities of pllegend / plcolorbar which will also be useful in understanding the interfaces. Note you might also have to add support for plscmap1_range which is used in example 33, but not yet propagated to all languages. You should also include plgcmap1_range, although we don't actually use this in an examples yet (a small project - but probably post release. I've done the leg work adding it to the bindings for most langauges as I did the plcolorbar changes). Andrew I went ahead and started the Ada bindings and examples update several days ago, using the documentation in the comments of pllegend.c. As of last night, I think the bindings were pretty much working but I'm having a weird problem with example 16 where the colorbars are too close to the main plot and extra numeric text is appearing near one of the colorbar tics. I don't know why this iteration is causing me more problems than past ones. I haven't started on example 33 yet. Has the API for pllegend changed recently? I believe not. As for my ability to build and test, I am using an old Ada compiler to get the job done so that this not going to hold me up. (It is the new compiler which is troublesome.) Jerry -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Time for a release? pen width issues
On Aug 23, 2013, at 3:54 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-08-23 15:08-0600 Orion Poplawski wrote: So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This contains the change of wid - width for pen width. This is breaking my gdl build because it is still trying to use wid() which is all of a sudden gone. And now I have nothing like a version number change to key this on. So: - Is it intentional for plstream-wid() to be removed completely already? At the C level plwid is still available if the builder specifies -DPL_DEPRECATED=ON, but I suspect nobody has bothered to propagate that deprecated version to other languages. So IIRC we have a gradual change possible from plwid to plwidth for C, but an abrupt change for the bindings. That was not intentional, but it is also not a bad outcome since integer line widths are pretty old-fashioned and the fix is easy (see below). - Time for a release? My opinion is this is long overdue. We still need to propagate the plcolorbar changes to the OCaml and Ada bindings and examples and I'm going to be seriously unavailable to work on the Ada stuff starting now for one week. I'm not sure what state plcolorbar is in off the top of my head but I'll look into this and the plwidth issue that we discussed a couple weeks ago. document plcolorbar in doc/docbook/src/api.xml, but I think those relatively minor issues are all that is currently blocking us from a release. - other suggestions? You are probably aware of this already, but the gdl breakage should be trivial to fix. Replace all instances of plstream-wid( integer width) with plstream-plwidth(floating width). One could test plplot to see if plwid or plwidth was available and key the change on that. However, I agree it would make life much easier for you and others to have a PLplot version number to key such a change. Thus, getting out a PLplot release out soon is important not only for this reason but many others. 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 __ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plwid - plwidth broke Ada bindings
On Aug 7, 2013, at 8:10 PM, Orion Poplawski or...@cora.nwra.com wrote: On 08/07/2013 08:56 PM, Alan W. Irwin wrote: @Orion: just to confirm that, could you double-check you are testing the latest revision of PLplot trunk that includes Andrew's revision 12337 fixes for my widespread revision 12288 change? Whoops! That was my problem! I was stuck on the old SF svn checkout. I'm now building revision 12474. Apologies for that. No problem. I'll make that function addition real soon now. Curious to know if you use the Ada bindings in your work or if you mainly test for us. Jerry -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plwid - plwidth broke Ada bindings
On Aug 7, 2013, at 3:00 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-08-07 15:45-0600 Orion Poplawski wrote: So, svn commit 12288: r12288 | airwin | 2013-01-29 21:40:35 -0700 (Tue, 29 Jan 2013) | 13 lines Replace plwid everywhere by plwidth, and store pen width arguments as PLFLT's everywhere (that I can find them). These changes allow width parameters 1. to work for cairo devices, e.g., examples/c/x03c.c -dev xcairo -width 0.3 gives extremely thin line results. Further discussion on list of what else there is to do. --- bindings/ada/plplot.adb (revision 12287) +++ bindings/ada/plplot.adb (working copy) @@ -3311,10 +3311,10 @@ -- Set pen width. --- plwid +-- plwidth procedure Set_Pen_Width(Pen_Width : Integer) is begin -plwid(Pen_Width); +plwidth(Pen_Width); end Set_Pen_Width; appears to have broken the ada bindings. I get: [ 13%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o cd /export/home/orion/fedora/plplot/plplot-5.9.9/fedora/bindings/ada /usr/bin/gnatgcc -fPIC -c /export/home/orion/fedora/plplot/plplot-5.9.9/bindings/ada/plplot.adb -o CMakeFiles/plplotadad.dir/plplot.o plplot.adb:3317:17: expected type Standard.Long_Float plplot.adb:3317:17: found type Standard.Integer Now, I was about to simply change the argument to Set_Pen_Width to be a Long_Float, but this changes the API/ABI. So, should the ada bindings grow a new interface (Set_Pen_Width_Float?) that takes a Long_Float and calls plwidth? That seems the most appropriate to me. Comments? Hi Orion: Thanks for your report. I cannot reproduce this for irwin@raven gnatgcc --version gnatgcc (Debian 4.6.3-14) 4.6.3 So I suspect you have a newer version of gnatgcc which is being more careful about types than 4.6.3. @Jerry: is there a simple fix for what Orion has found? Alan I've only glanced at these e-mails but want to make a quick response anyway. I would be stunned if the GNAT version difference was causing this because of being more careful about types. Ada has always been rigorous about types. I noted the API change at the time but assumed that this had been discussed. Were no other languages affected? Do all the other PLplot languages automatically convert types so that this did not appear as an API change? To answer to if there is a simple fix I need to know what we want to present to the user as an API. Do we want to break backward compatibility? If we want to keep backward compatibility then indeed a new function is in order. It could be an overloaded function, however, so that the same function name works depending on if the argument is Integer or Long_Float; however, it would need to call a different C routine. As I said, I haven't yet dug into this today so some of my comments may have obvious answers. More later. Jerry -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plwid - plwidth broke Ada bindings
On Aug 7, 2013, at 7:56 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-08-07 18:40-0700 Jerry wrote: I've only glanced at these e-mails but want to make a quick response anyway. I would be stunned if the GNAT version difference was causing this because of being more careful about types. Ada has always been rigorous about types. I noted the API change at the time but assumed that this had been discussed. Were no other languages affected? Do all the other PLplot languages automatically convert types so that this did not appear as an API change? To answer to if there is a simple fix I need to know what we want to present to the user as an API. Do we want to break backward compatibility? If we want to keep backward compatibility then indeed a new function is in order. It could be an overloaded function, however, so that the same function name works depending on if the argument is Integer or Long_Float; however, it would need to call a different C routine. As I said, I haven't yet dug into this today so some of my comments may have obvious answers. More later. Hi Jerry: To remind you of the background, the Replace plwid everywhere by plwidth commit (revision 12288 that Orion referred to) was an extremely broad change that created and used floating-point line widths (for a changed function name (plwidth rather than plwid) rather than the integer linewidths we had before with plwid that severely limited line-width possibilities that were available for certain of our devices. This widespread change was discussed on list at the time and does consist of a backwards-incompatible API change as noted at README.release. As a result of that discussion, plwid was moved to src/pldeprecated.c which is completely ignored unless users specifically ask for it using the -DPL_DEPRECATED=ON option. With regard to your last question, I think it would make the change a little bit easier for your users if you provided an overloaded version of the line width function that had integer arguments, but we haven't done that for any other language (C++, Python, etc.) that has overloading. My own feeling on this is that the integer line widths are going to become more and more restrictive compared to what can actually be done with floating line widths these days with modern graphics libraries such as pango/cairo and Qt4. Therefore, tough love may be the better approach for you to take with Ada users so you break them of the habit of using integer line widths. But that is up to you and the alternative of giving them a soft landing with overloading is a reasonable choice as well in my opinion. I think I will put in the overload as long as you concur (and I guess you have). I assume that the change (to floats) is documented so users can know of the improvement and can opt for it if they want, and if the deprecated version goes away eventually then that should bother fewer people. Although your decision to give Ada users tough love or soft landing is an important issue, it is a side issue compared to the issue of possible Ada breakage which I want to turn to now. My widespread change mostly gave good test results, but there were some exceptions such as Ada which broke. However, as far as I know Andrew cleared up that Ada breakage (commit 12337, Update Ada bindings to change line width arguments from Integer to Long_Float in pllegend and plshade.) Yes. And I also made a change at 12299 to fix a type in the actual plwidth functionality. pllegend is a new addition as I recall so tough love shouldn't be necessary. I don't think plshade is new. Among other things, that fixed bindings/ada/plplot.adb so that the incorrect integer type was changed to the correct floating type for the new plwidth-related function. After revision 12337 all worked well here with gnatgcc-4.6.3-14, but now Orion apparently has found an additional issue with his (much) later gnatgcc version. @Orion: just to confirm that, could you double-check you are testing the latest revision of PLplot trunk that includes Andrew's revision 12337 fixes for my widespread revision 12288 change? @Jerry: what gnatgcc version do you have access to and what happens when you test latest PLplot trunk? I have three GNATs installed. I'm not sure what the difference is between these version requests (on gnat versus gcc), but here are the results. (1) The 2011 GPL from AdaCore: $ ./gnat --version GNAT GPL 2011 (20110419) $ ./gcc --version gcc (GCC) 4.5.3 20110419 for GNAT GPL 2011 (20110419) (2) The 2013 GPL from AdaCore: $ ./gnat --version GNAT GPL 2013 (20130314) $ ./gcc --version gcc (GCC) 4.7.4 20130416 for GNAT GPL 2013 (20130314) (3) FSF version $ ./gnat --version GNAT 4.8.0 $ ./gcc --version gcc (GCC) 4.8.0 You (Alan) might recall that a couple months ago I updated my compiler from the 2011 GPL to the 2013 GPL and was not able to build PLplot. Everyone said that I probably had
Re: [Plplot-devel] Trouble building plplot with new Ada compiler
Hi Alan, On Jun 24, 2013, at 1:52 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Blanks in paths generally cause build trouble so I am wondering if (3) has a blank in one of the paths as one of the minor path adjustments compared to case (2). I didn't find any stray blanks. I'd be happy to send you the script(s) for GNAT 2013 which doesn't work and 2011 which does. In case this guess for the cause of the issue is not correct, then I suggest you take the usual next debugging step which is to attempt to replicate the issue for the simplest test case possible. Fortunately, such a Hello World test case for Ada is already implemented. You should be able to download it using svn checkout \ http://svn.code.sf.net/p/plplot/code/branches/test_cmake/test_ada \ test_ada This step fails. I've attached my script and the output made when running with both GNAT 2013 and 2011. As you can see, they both fail at the same place. There should be three attached text files. Jerry test.sh Description: Binary data MBPro:~ jerrybauck$ /Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/Problems_building_PLplot_with_GNAT_GPL_2013/test_from_readme.sh -- The C compiler identification is GNU 4.7.4 -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler: /usr/local/adacore-gnat-2013/bin/gcc -- Check for working C compiler: /usr/local/adacore-gnat-2013/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_PLATFORM_INFO_DIR = /Users/jerrybauck/temp_plplot/CMakeFiles -- Check for working Ada builder: /usr/local/adacore-gnat-2013/bin/gnatmake -- Check for working Ada builder: /usr/local/adacore-gnat-2013/bin/gnatmake -- works -- gnat version = 4.7 CMake Error at ada.cmake:14 (message): Required gnat library not found. Call Stack (most recent call first): CMakeLists.txt:30 (include) -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. /Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/Problems_building_PLplot_with_GNAT_GPL_2013/test_from_readme.sh: line 8: src_executable/hello: No such file or directory MBPro:~ jerrybauck$ MBPro:~ jerrybauck$ /Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/Problems_building_PLplot_with_GNAT_GPL_2013/test.sh -- The C compiler identification is GNU 4.5.3 -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler: /usr/local/adacore-gnat-2011/bin/gcc -- Check for working C compiler: /usr/local/adacore-gnat-2011/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_PLATFORM_INFO_DIR = /Users/jerrybauck/temp_plplot/CMakeFiles -- Check for working Ada builder: /usr/local/adacore-gnat-2011/bin/gnatmake -- Check for working Ada builder: /usr/local/adacore-gnat-2011/bin/gnatmake -- works -- gnat version = 4.5 CMake Error at ada.cmake:14 (message): Required gnat library not found. Call Stack (most recent call first): CMakeLists.txt:30 (include) -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. /Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/Problems_building_PLplot_with_GNAT_GPL_2013/test.sh: line 8: src_executable/hello: No such file or directory MBPro:~ jerrybauck$ If that extremely simple test case replicates the issue, you should communicate (as attachments) your build tree results (including cmake output and make VERBOSE=1 output) as a compressed tarball and also your script for building the simple test case for both GNAT 2011 and 2013. That e-mail can be posted too this list if the total size is less than a MB or so, but otherwise send it to me off list. Of course, if that simple test case gives good results for both GNAT 2011 and 2013, that is an encouraging result, but that means you need to replicate the issue for the simplest PLplot case (no device drivers other than ps, no bindings other than Ada), and communicate the PLplot build tree result and your build script and build script output for that simplest PLplot case for both GNAT 2011 and 2013. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble building plplot with new Ada compiler
On Jun 12, 2013, at 4:22 AM, Jerry lancebo...@qwest.net wrote: I'm a little bleary-eyed right now but I can't figure this problem out. I just replaced my GPL GNAT (Ada) compiler with the new 2013 edition and am now getting a link error. I made a few trivial changes to my build script to account for some directory changes and I think it should be doing the same thing as it did with the old (2011 edition) compiler. But I'm getting this. install_name seems to be getting embedded in some funny places including several occurrences that appeared in the output before this, specifically as -headerpad_max_install_names, as well as those shown below. Linking Ada shared library libplplotadad.dylib cd /usr/local/plplot_build_dir/bindings/ada /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplotadad.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2013/bin/gcc -fPIC -single_module -dynamiclib -Wl,-headerpad_max_install_names -install_namelibplplotadad.0.dylib -o libplplotadad.0.0.0.dylib CMakeFiles/plplotadad.dir/plplot.o CMakeFiles/plplotadad.dir/plplot_thin.o CMakeFiles/plplotadad.dir/plplot_traditional.o CMakeFiles/plplotadad.dir/plplot_auxiliary.o ../../src/libplplotd.11.0.0.dylib /usr/local/adacore-gnat-2013/lib/gcc/x86_64-apple-darwin12.2.0/4.7.4/adalib/libgnat.dylib -lgcc_s.1 gcc: error: unrecognized command line option '-install_namelibplplotadad.0.dylib' make[2]: *** [bindings/ada/libplplotadad.0.0.0.dylib] Error 1 make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 make: *** [all] Error 2 Jerry I've finally gotten a chance to revisit this. I should mention that right before I updated GNAT from the 2011 edition to the 2013 edition I also updated my OS from Lion to Mountain Lion, or 10.7.5 to 10.8.4. I know this is dumb to make two changes more or less at once but I was under the impression that the 2011 GNAT might not work under 10.8.4, but this is wrong as noted below. Here's a subset of what I've learned. (1) If I disable Ada and build with GNAT 2013, there are no problems (other than not having the Ada library built). (2) If I enable Ada and build with GNAT 2013, the above problem exists. (3) If I enable Ada and build with GNAT 2011, there are no problems. In the case of (1), I can still have a main program that works with PLplot because the GNAT make facility, gnatmake, notices that it can see some source files (the various PLplot Ada things) that that it needs but which have not been compiled and compiles them on its own, sort of on the side, if you will, and then links to them. (I don't know if other make facilities do this sort of thing.) My build scripts for 2011 and 2013 are identical except for minor path adjustments since AdaCore likes to make some edition-specific paths in their annual releases. Jerry -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble building plplot with new Ada compiler
Thanks, Arjen. I looked into this a bit and played a little bit but I really don't understand the cmake code so I didn't get far. There are four files that contain the string install_name by itself, not part of a longer string. On my system, when MacPorts is visible in /opt/local/, it is these four files: /opt/local/share/cmake-2.8/Modules/Platform/Darwin-icc.cmake /opt/local/share/cmake-2.8/Modules/Platform/Darwin-XL-C.cmake /opt/local/share/cmake-2.8/Modules/Platform/Darwin-XL-CXX.cmake /opt/local/share/cmake-2.8/Modules/Platform/Darwin.cmake and the cmake version is 2.8.9_1. I don't know whether this problem (not being able to build PLplot with GNAT GPL 2013) is a cmake problem or a GNAT problem but as of now I've tried everything that I can think of short of putting this problem to another audience. Jerry On Jun 12, 2013, at 4:33 AM, Arjen Markus arjen.mar...@deltares.nl wrote: Hi Jerry, could it be as simple as a missing space between -install_name and libplplotadad.0.dylib ? Perhaps fiddling a bit with the CMake module files in the CMake installation (I found these options in Platform/Darwin.cmake and two similar ones) might help. Regards, Arjen On Wed, 12 Jun 2013 04:22:01 -0700 Jerry lancebo...@qwest.net wrote: I'm a little bleary-eyed right now but I can't figure this problem out. I just replaced my GPL GNAT (Ada) compiler with the new 2013 edition and am now getting a link error. I made a few trivial changes to my build script to account for some directory changes and I think it should be doing the same thing as it did with the old (2011 edition) compiler. But I'm getting this. install_name seems to be getting embedded in some funny places including several occurrences that appeared in the output before this, specifically as -headerpad_max_install_names, as well as those shown below. Linking Ada shared library libplplotadad.dylib cd /usr/local/plplot_build_dir/bindings/ada /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplotadad.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2013/bin/gcc -fPIC -single_module -dynamiclib -Wl,-headerpad_max_install_names -install_namelibplplotadad.0.dylib -o libplplotadad.0.0.0.dylib CMakeFiles/plplotadad.dir/plplot.o CMakeFiles/plplotadad.dir/plplot_thin.o CMakeFiles/plplotadad.dir/plplot_traditional.o CMakeFiles/plplotadad.dir/plplot_auxiliary.o ../../src/libplplotd.11.0.0.dylib /usr/local/adacore-gnat-2013/lib/gcc/x86_64-apple-darwin12.2.0/4.7.4/adalib/libgnat.dylib -lgcc_s.1 gcc: error: unrecognized command line option '-install_namelibplplotadad.0.dylib' make[2]: *** [bindings/ada/libplplotadad.0.0.0.dylib] Error 1 make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 make: *** [all] Error 2 Jerry -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel 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. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Trouble building plplot with new Ada compiler
I'm a little bleary-eyed right now but I can't figure this problem out. I just replaced my GPL GNAT (Ada) compiler with the new 2013 edition and am now getting a link error. I made a few trivial changes to my build script to account for some directory changes and I think it should be doing the same thing as it did with the old (2011 edition) compiler. But I'm getting this. install_name seems to be getting embedded in some funny places including several occurrences that appeared in the output before this, specifically as -headerpad_max_install_names, as well as those shown below. Linking Ada shared library libplplotadad.dylib cd /usr/local/plplot_build_dir/bindings/ada /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplotadad.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2013/bin/gcc -fPIC -single_module -dynamiclib -Wl,-headerpad_max_install_names -install_namelibplplotadad.0.dylib -o libplplotadad.0.0.0.dylib CMakeFiles/plplotadad.dir/plplot.o CMakeFiles/plplotadad.dir/plplot_thin.o CMakeFiles/plplotadad.dir/plplot_traditional.o CMakeFiles/plplotadad.dir/plplot_auxiliary.o ../../src/libplplotd.11.0.0.dylib /usr/local/adacore-gnat-2013/lib/gcc/x86_64-apple-darwin12.2.0/4.7.4/adalib/libgnat.dylib -lgcc_s.1 gcc: error: unrecognized command line option '-install_namelibplplotadad.0.dylib' make[2]: *** [bindings/ada/libplplotadad.0.0.0.dylib] Error 1 make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 make: *** [all] Error 2 Jerry -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] patch to plbox re placement of exponential labels
On May 24, 2013, at 7:53 AM, Schwartz, Steven J wrote: I attach a patch to svn 12298 which addresses the following issues: 1 Exponential labels, e.g. (x10^nn), along vertical axes were absent when driven by plslabelfunc(). This was due to the fact that the call to plmtex was unreachable in the case if(plsc-label_data) being true. 2 Default height, pos, and just values correspond to the bottom of the left but top of the right vertical axes. I think both should be at the top (but accept this is my humble opinion. These are easy to change.) 3 Default height, pos, and just values are inappropriate for both l and lv label orientations. To be honest, finding a decent default for this in v orientation is pretty difficult. 4 There were other bugs, e.g., in using a t option rather than l or lv to plmtex. The attached test code illustrates the initial state and the result after my changes to plbox. I made parallel changes to the code in label_box_custom as it is virtually identical here, but don't have source code to test it. Best wishes Steve Professor Steven J SchwartzPhone: +44 (0)207 594 7660 Head, Space Atmospheric Physics Fax:+44 (0)207 594 7772 The Blackett LaboratoryEmail: s.schwa...@imperial.ac.uk Imperial College LondonOffice: Huxley 6M67A London SW7 2AZ, UK Web:www.sp.ph.ic.ac.uk/~sjs Thanks, Steve. Just a casual observation and a question (not only to Steve): Why does test overlay 500 or 0.5 in all of these plots? Is this collision normal? Jerry -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should line width thinner than 1.0 be supported?
Hi Atri, I was in a bit of a hurry when I did the commit and failed to include all of the changed files. 12300 should be OK. Alan is already reporting good results. Jerry On Mar 19, 2013, at 5:46 PM, Jerry wrote: Atri, I'll give you an answer later this evening. I have an urgent thing to do right now. Jerry On Mar 19, 2013, at 5:44 PM, Atri wrote: Thanks Jerry! However, I am a little confused as I do not see the examples having being patched with revision 12299 yet; isn't that supposed to be done as I did in the patch (attached with previous email) as well? Otherwise building the examples would lead to issues as Alan pointed out earlier. -- Atri -Original Message- From: Jerry lancebo...@qwest.net To: Atri badshah...@aim.com Cc: Alan Irwin ir...@beluga.phys.uvic.ca; Plplot-devel mailing list plplot-devel@lists.sourceforge.net Sent: Tue, Mar 19, 2013 7:37 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? I just committed probably the same changes just minutes ago. I'm building fine on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of this sooner. Jerry On Mar 19, 2013, at 5:31 PM, Atri wrote: Hello Alan! This is the updated patch that should take care of the problems with the examples in ada as well (I only had to correct four of the examples). After applying the patch, I built plplot with ada binding turned on, with DBUILD_TEST=ON and did a make VERBOSE=1 test_ada_psc just as you asked. The package, along with all the examples now builds fine. The examples that needed correcting are: x01a.adb x02a.adb xthick01a.adb xthick02a.adb Please let me know if this is okay. -- Atri -Original Message- From: Alan W. Irwin ir...@beluga.phys.uvic.ca To: Atri badshah...@aim.com Cc: Jerry lancebo...@qwest.net; hezekiahcarty hezekiahca...@users.sourceforge.net; PLplot development list plplot-devel@lists.sourceforge.net; Andrew Ross andrewr...@users.sourceforge.net; hwang.dev hwang@gmail.com Sent: Mon, Mar 18, 2013 10:59 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? On 2013-03-18 15:49-0400 Atri wrote: Hi! To get the ada binding build successfully with the latest svn trunk (12298) (at least on openSUSE 12.2 and higher), I used the attached patch. Please have a look and let me know what you think. Hi Atri: I think that your patch does the job in the Ada bindings, but it appears you need to make similar changes in some/all of the Ada examples. The error message I get here is x01a.adb:101:17: expected type Standard.Long_Float x01a.adb:101:17: found type universal integer x01a.adb:103:17: expected type Standard.Long_Float x01a.adb:103:17: found type universal integer To verify this for yourself, try the following: Configure with the CMake option -DBUILD_TEST=ON Then after cmake is run, run the following target in the build tree: make VERBOSE=1 test_ada_psc test_ada_psc.out Thanks for your patch, and I look forward to seeing the complete version that gets rid of all errors in the test_ada_psc target. :-) 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-fix-plwidth-ada-binding.patch -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should line width thinner than 1.0 be supported?
Atri, I'll give you an answer later this evening. I have an urgent thing to do right now. Jerry On Mar 19, 2013, at 5:44 PM, Atri wrote: Thanks Jerry! However, I am a little confused as I do not see the examples having being patched with revision 12299 yet; isn't that supposed to be done as I did in the patch (attached with previous email) as well? Otherwise building the examples would lead to issues as Alan pointed out earlier. -- Atri -Original Message- From: Jerry lancebo...@qwest.net To: Atri badshah...@aim.com Cc: Alan Irwin ir...@beluga.phys.uvic.ca; Plplot-devel mailing list plplot-devel@lists.sourceforge.net Sent: Tue, Mar 19, 2013 7:37 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? I just committed probably the same changes just minutes ago. I'm building fine on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of this sooner. Jerry On Mar 19, 2013, at 5:31 PM, Atri wrote: Hello Alan! This is the updated patch that should take care of the problems with the examples in ada as well (I only had to correct four of the examples). After applying the patch, I built plplot with ada binding turned on, with DBUILD_TEST=ON and did a make VERBOSE=1 test_ada_psc just as you asked. The package, along with all the examples now builds fine. The examples that needed correcting are: x01a.adb x02a.adb xthick01a.adb xthick02a.adb Please let me know if this is okay. -- Atri -Original Message- From: Alan W. Irwin ir...@beluga.phys.uvic.ca To: Atri badshah...@aim.com Cc: Jerry lancebo...@qwest.net; hezekiahcarty hezekiahca...@users.sourceforge.net; PLplot development list plplot-devel@lists.sourceforge.net; Andrew Ross andrewr...@users.sourceforge.net; hwang.dev hwang@gmail.com Sent: Mon, Mar 18, 2013 10:59 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? On 2013-03-18 15:49-0400 Atri wrote: Hi! To get the ada binding build successfully with the latest svn trunk (12298) (at least on openSUSE 12.2 and higher), I used the attached patch. Please have a look and let me know what you think. Hi Atri: I think that your patch does the job in the Ada bindings, but it appears you need to make similar changes in some/all of the Ada examples. The error message I get here is x01a.adb:101:17: expected type Standard.Long_Float x01a.adb:101:17: found type universal integer x01a.adb:103:17: expected type Standard.Long_Float x01a.adb:103:17: found type universal integer To verify this for yourself, try the following: Configure with the CMake option -DBUILD_TEST=ON Then after cmake is run, run the following target in the build tree: make VERBOSE=1 test_ada_psc test_ada_psc.out Thanks for your patch, and I look forward to seeing the complete version that gets rid of all errors in the test_ada_psc target. :-) 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-fix-plwidth-ada-binding.patch -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should line width thinner than 1.0 be supported?
On Jan 30, 2013, at 1:59 AM, Alan W. Irwin wrote: However, there are some known leftover issues that need to be polished up such as the qt issue with -width above, the Ada and OCaml issues I pointed out before I started on the Ada issues tonight but got distracted with a problem with the Aquaterm driver caused by a change I made on my computer. The Ada issues with plwidth look pretty trivial and I'll get to them soon. Jerry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On Jan 29, 2013, at 8:52 PM, Jerry wrote: On Jan 29, 2013, at 5:02 PM, Orion Poplawski wrote: On 01/29/2013 03:21 AM, Jerry wrote: Hi Orion, This is puzzling. I can't see what could possibly be causing this. (By this I mean the x02.adb example, as I haven't looked any of the others.) I have not set ranges for any of the entities involved. (In Ada, you can specify an allowed range for a variable. For instance, one could specify that r1 is constrained between 0.0 and 1.0 and any attempt to assign a value outside that range would raise an overflow (I think) exception.) So I don't see where there is an opportunity to overflow either r1, a 64-bit float or r( ), a 32-bit integer. FWIW, GNAT does something a little controversial--it defaults to disabling overflow checking. The controversy is that this compiler is then, by default, not an Ada compiler. But I don't see how that is apropos to this situation. Can you try running this program and report the results? with Ada.Text_IO; use Ada.Text_IO; procedure Test_Overflow is r : Integer; r1 : Long_Float := 0.3; begin Put_Line(Running); r := Integer((r1 * 255.001) - 0.499); end Test_Overflow; Compile and run: $ gnatmake Test_Overflow.adb $./test_overflow I also tried it with overflow checking turned on: $ gnatmake -gnato Test_Overflow.adb $./test_overflow It works either way on my system. [orion@vmrawhide ~]$ gnatmake Test_Overflow.adb gcc -c Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed [[orion@vmrawhide ~]$ rm Test_Overflow Test_Overflow.o Test_Overflow.ali [orion@vmrawhide ~]$ gnatmake -gnato Test_Overflow.adb gcc -c -gnato Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com Orion: I've queried the oracle (comp.lang.ada). Jerry The oracle had two responses. (Note that wrt the second response, I in fact did mention that you are on Fedora Rawhide.) (1) Well, GCC 4.8 hasn't been released yet! but a quick check through the bugs/regressions doesn't show anything like this. Let's hope it doesn't make it to the release .. Neither GCC 4.7.0 nor GNAT GPL 2012 shows the problem. (2) I wonder if his hardware (you didn't say what processor/OS the person with the problem is running on) is either setting some bit incorrectly, or the bit is being interpreted wrong. I saw something like this when we implemented hardware conversions in Janus/Ada, as some weird bits were getting set that we misinterpreted as an error. It's possible to set up the Intel hardware to trap, and that could happen for underflow and other loss-of-precision cases, and such a trap would probably get reported as an overflow error. It even possible that his OS has left some goofy setup in the floating point unit which causes bogus traps (bad device driver?). Did he try rebooting and/or running a clean system? Orion: I checked the 18 places that you reported an error and in every line, there is a conversion of Long_Float to Integer using the Integer( ) function with a Long_Float as an argument. It appears extremely likely that in each case the exception is being raised at the first attempt to make the conversion in a given example. I don't think there is anything that I can do for this situation. If you are sure that you don't have a hardware problem re (2) above then someone should file a bug report, but, as far as I'm concerned, my note to comp.lang.ada suffices since there are a number of gurus on the list and I assume the GNAT folks monitor the list although if so they are surely quiet or anonymous. Jerry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On Jan 28, 2013, at 8:47 PM, Orion Poplawski wrote: On 01/28/2013 07:54 PM, Alan W. Irwin wrote: On 2013-01-28 17:01-0700 Orion Poplawski wrote: Fedora rawhide has moved to gcc 3.8 and I'm seeing: $ ./x02a -dev psc -o x02a.psc raised CONSTRAINT_ERROR : x02a.adb:138 overflow check failed I'm taking that this is due to some increased checking with ada in 3.8. Thoughts? Hi Orion: I am virtually positive you meant the gcc-4.8 development effort which (as far as I can tell) has not had a single release yet. So I am changing the subject line accordingly. But please confirm that is what you meant. If you meant gcc-4.8, there is always the chance that the symptom you are seeing is a general problem caused by some recently introduced version incompatibilty between gcc and Ada that still needs to be worked out, i.e., a compiler inconsistency issue that has nothing to do with PLplot development. On the other hand, it might be a PLplot Ada issue that has been detected by (presumably) better error checking for the latest versions of gcc/Ada as you have suggested. To help decide between those two possibilities, could you give more details? For example, if you use the make -k option (to keep going despite errors) are you able to compile all the Ada examples other than the second one? If the issue is confined to just one of our examples, then it is much more likely a PLplot Ada issue with that example (or the API tested with that example) as you have suggested. Sorry, yes it is 4.8. Fedora is very tight with gcc development so we get things early - fun! The example compiles fine, it just doesn't run. Some others don't run either (see below). It looks very much like a floating point overflow condition is being triggered. With a debug statement it aborts at the start of the loop: i = 0 r1 = 3.00E-01 I suspect that: 138 r(i+16) := Integer((r1 * 255.001) - 0.499); Has too many digits to be properly expressed. The comments indicate that it is dealing with some rounding/truncating differences. I suspect that gcc in 4.8 traps these conditions by default. Others: raised CONSTRAINT_ERROR : x02a.adb:141 overflow check failed raised CONSTRAINT_ERROR : x03a.adb:92 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:179 overflow check failed raised CONSTRAINT_ERROR : x12a.adb:105 overflow check failed raised CONSTRAINT_ERROR : x13a.adb:73 overflow check failed raised CONSTRAINT_ERROR : x14a.adb:218 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:179 overflow check failed raised CONSTRAINT_ERROR : x18a.adb:156 overflow check failed raised CONSTRAINT_ERROR : x19a.adb:192 overflow check failed raised CONSTRAINT_ERROR : plplot_thin.adb:241 overflow check failed raised CONSTRAINT_ERROR : plplot_auxiliary.adb:40 overflow check failed raised CONSTRAINT_ERROR : xthick02a.adb:136 overflow check failed raised CONSTRAINT_ERROR : xthick03a.adb:92 overflow check failed raised CONSTRAINT_ERROR : xthick12a.adb:104 overflow check failed raised CONSTRAINT_ERROR : xthick13a.adb:73 overflow check failed raised CONSTRAINT_ERROR : xthick14a.adb:218 overflow check failed raised CONSTRAINT_ERROR : xthick18a.adb:155 overflow check failed raised CONSTRAINT_ERROR : xthick19a.adb:192 overflow check failed Hi Orion, This is puzzling. I can't see what could possibly be causing this. (By this I mean the x02.adb example, as I haven't looked any of the others.) I have not set ranges for any of the entities involved. (In Ada, you can specify an allowed range for a variable. For instance, one could specify that r1 is constrained between 0.0 and 1.0 and any attempt to assign a value outside that range would raise an overflow (I think) exception.) So I don't see where there is an opportunity to overflow either r1, a 64-bit float or r( ), a 32-bit integer. FWIW, GNAT does something a little controversial--it defaults to disabling overflow checking. The controversy is that this compiler is then, by default, not an Ada compiler. But I don't see how that is apropos to this situation. Can you try running this program and report the results? with Ada.Text_IO; use Ada.Text_IO; procedure Test_Overflow is r : Integer; r1 : Long_Float := 0.3; begin Put_Line(Running); r := Integer((r1 * 255.001) - 0.499); end Test_Overflow; Compile and run: $ gnatmake Test_Overflow.adb $./test_overflow I also tried it with overflow checking turned on: $ gnatmake -gnato Test_Overflow.adb $./test_overflow It works either way on my system. Jerry -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only
Re: [Plplot-devel] Probably gcc 4.8 ada issue
On Jan 29, 2013, at 5:02 PM, Orion Poplawski wrote: On 01/29/2013 03:21 AM, Jerry wrote: Hi Orion, This is puzzling. I can't see what could possibly be causing this. (By this I mean the x02.adb example, as I haven't looked any of the others.) I have not set ranges for any of the entities involved. (In Ada, you can specify an allowed range for a variable. For instance, one could specify that r1 is constrained between 0.0 and 1.0 and any attempt to assign a value outside that range would raise an overflow (I think) exception.) So I don't see where there is an opportunity to overflow either r1, a 64-bit float or r( ), a 32-bit integer. FWIW, GNAT does something a little controversial--it defaults to disabling overflow checking. The controversy is that this compiler is then, by default, not an Ada compiler. But I don't see how that is apropos to this situation. Can you try running this program and report the results? with Ada.Text_IO; use Ada.Text_IO; procedure Test_Overflow is r : Integer; r1 : Long_Float := 0.3; begin Put_Line(Running); r := Integer((r1 * 255.001) - 0.499); end Test_Overflow; Compile and run: $ gnatmake Test_Overflow.adb $./test_overflow I also tried it with overflow checking turned on: $ gnatmake -gnato Test_Overflow.adb $./test_overflow It works either way on my system. [orion@vmrawhide ~]$ gnatmake Test_Overflow.adb gcc -c Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed [[orion@vmrawhide ~]$ rm Test_Overflow Test_Overflow.o Test_Overflow.ali [orion@vmrawhide ~]$ gnatmake -gnato Test_Overflow.adb gcc -c -gnato Test_Overflow.adb Test_Overflow.adb:2:11: warning: file name does not match unit name, should be test_overflow.adb gnatbind -x Test_Overflow.ali gnatlink Test_Overflow.ali [orion@vmrawhide ~]$ ./Test_Overflow Running raised CONSTRAINT_ERROR : Test_Overflow.adb:7 overflow check failed -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com Orion: I've queried the oracle (comp.lang.ada). Jerry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Release schedule?
On Sep 26, 2012, at 5:47 AM, Andrew Ross wrote: It is coming up to a year since the last official release of plplot (5.9.9). Although it has been a relatively quiet time in terms of developments, there are some important bug fixes for newer software versions in there. We should think about a timetable for the next release and whether there are any outstanding issues that need fixing / new features to include for such a release to happen. Does anyone have any thoughts on this? Before a release we also need to find a new release manager to coordinate the process and do the actual release, announcements etc. Regards Andrew I am considering taking at stab at getting wxwidgets working on OS X. The wiki has stated for years that this is a problem and recommends not doing it. IIRC it also mentions that it might just be a version problem, and given the age of that wiki entry, maybe it's time to give it a try. I can try building and see what happens but as usual if there is a problem I'll be dependent on others to help figure things out. Jerry -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15
On Aug 31, 2012, at 8:14 AM, Alan W. Irwin wrote: Hi Phil: On 2012-08-31 04:35-0700 phil rosenberg wrote: When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it Yes. or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? That could be done as well. I would reverse the sort of implied preference that Alan states here, if I understand correctly. I would say the primary zoom style would be to redraw the plot with new (zoomed) axes. If the zooming only enlarges everything in the window, it will normally cause the axes to disappear off-screen--not good. Also, an Undo stack should be kept so that one can back up one zoom operation at a time (without loosing numerical precision in the event that an extreme zoom has been reached). And a home feature to return to the originally (un)scaled view. This is probably stating the obvious but I have seen a surprising number of plotters where one is simply left to get home by manually entering the inverse of accumulated zoom factors or manually entering the axis limits. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15
On Aug 31, 2012, at 8:55 AM, phil rosenberg wrote: I find similar results to you on windows, however there seems to be something that is making things unstable and after a few clicks or button presses the cursor lines disapear and then the program quits. Not really sure what's going on. Phil [Sorry--just read Alan's post about clicking outside the plot areas. Jerry] [Sorry for the double post, Alan. Maybe I need a CLI mailer. 8^)] I found on OS X that on xwin, qtwidget, and xcairo (all that I can currently test), playing with example 1, (x01c) that if I click outside the plotting area of the plots, for example, in the area between the four plots, that the cursor disappears and interactivity stops. I have seen at least xwin also quit at that point but not always. It might depend on exactly where I click. qtwidget and xcairo report their textual results twice--two identical lines of text. qtwidget also behaves differently depending on the presence of -locate. If no -locate, the widget app launches and draws its contents immediately while also making itself the front (or active) application. This I believe is desirable because one normally expects to see a plot once the controlling program makes it. However, with -locate, the Qt widget runs and presents a blank (black) window which is not the front application. Upon clicking on this window, it comes to the front and the plots are drawn. Jerry From: Alan W. Irwin ir...@beluga.phys.uvic.ca To: phil rosenberg philip_rosenb...@yahoo.com Cc: plplot-devel@lists.sourceforge.net plplot-devel@lists.sourceforge.net Sent: Friday, 31 August 2012, 16:14 Subject: Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15 Hi Phil: On 2012-08-31 04:35-0700 phil rosenberg wrote: When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it Yes. or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? That could be done as well. I'd be interested in helping with the wxWidgets driver. That would be much appreciated. In fact, when I tried (after running make x01c and make wxwidgets) examples/c/x01c -dev wxwidgets -locate -drvopt backend=0 examples/c/x01c -dev wxwidgets -locate -drvopt backend=1 examples/c/x01c -dev wxwidgets -locate -drvopt backend=2 that device it turns out that the fundamental interactivity features are available (although the agg backend does not identify the key strokes for some reason, and the other backends that identify the keystrokes fail to identify which mouse button was pushed). Of course, this result is on Linux with X serving as the fundamental graphical software library supporting wxwidgets, and I am not sure whether you will get the same result on the Windows version of wxwidgets. If you can get it to mostly work like I described, it would be a help if you refined it so all three backends produced good identification results including mouse button identification and distinguishing between press and release (see below). If you ever install GTK+, then using the xcairo device on the above example produces (at least on Linux) the ideal result; _every_ keystroke and mouse button is identified both on press and release. That latter feature is important since it allows the CLI to identify drag and release events with any key where the user holds down the key and only releases it when the cursor has been moved to a new position. Other interactive devices on Linux are not that good with no release identification (all of them other than xcairo), missing identifications altogether (qtwidget), missing mouse button identifications (xwin), etc. So there is some work to do to bring them all up to the level of xcairo, and your help with the part of that work needed for wxwidgets would be much appreciated if Windows already gives you access to the partial interactivity that shows up on Linux for the 3 different versions of that device. 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 __ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
Hi Alan, Thanks for the patient explanation of the test dependencies. On Aug 29, 2012, at 9:33 AM, Alan W. Irwin wrote: In any case because of the good noninteractive Tcl results you are getting with -dev psc as demonstrated by the test_tcl_psc and test_diff_psc targets results you show above, I expect you will also get good interactive results using the test_tcl_standard_examples target (for -dev xwin). But please confirm that. Confirmed. The test ran in the X system, with the pictures flying by really fast. The only thing that I found odd was that beginning with the cropped Lena image, I had to move focus to the X window and hit Return four times, each time advancing to another modified Lena image, and at that point the plots updated once again without input by me. I don't have a dog in this (Tcl/Tk) race so I don't want to be a drag by pursuing this if nobody else is having a problem. I do think that my problems might also be shared by other OS X users and maybe we haven't had bug reports because OS X is a minority OS wrt PLplot and usage is light, or actual Tcl users are doing something that I don't know how to do. Does the Tk interactive method allow the user to use a mouse to interactively select a rectangular portion of the plot for zooming? This would certainly be useful and then I would have an actual personal interest in this work. Do any of the interactive devices allow this? X, Aquaterm and Qt do not--those are the only ones that I have tried. Jerry Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
On Aug 22, 2012, at 11:46 PM, Alan W. Irwin wrote: Hi Jerry: Do you have success with any other X application? The reason I ask is the above error message may simply mean that X is badly installed on your platform. Of course, if X were badly installed on Linux it would be catastrophic since X is so important on that platform, but my understanding is that X is not very important on Mac OS X. Therefore, on that platform you might have a bad X installation and not know about it (except by running some classical X applications such as xterm, xeyes, oclock, etc.) Alan Hi Alan, My X system as far as I know has always worked OK, both with plplot and other programs. On Plplot, X-Window (Xlib) is always the first choice and it has always worked--X launches and a graphics window appears with the plplot stuff in it. I can also run the programs you mention, and I have in the past run Grace and a version of OpenOffice among others. This is the X systems that Apple ships as part of the developer tools. Here is what I think I know about Tcl/Tk on OS X. tclsh is available at the command line. wish is also available and runs with a native (Aqua) look and feel. These are installed either out of the box or as part of the developer tools. wish can be built for X if desired (Wikipedia) but an X version is apparently not available out of the box. When I type wish in any OS X terminal or Xterm, the native wish shell launches and can run the widget demos, all of which work and are rendered in native Aqua. So the point here is--wish on OS X runs natively, not as an X app. Typing /usr/local/plplot/bin/plserver causes a native program to run that looks exactly like wish except the background on the window which displays the list of demos is gray instead of white, and the program name that is displayed is plserver instead of Wish. When I run x01c and choose device Tcl/TK Window, a native program is started called plserver but looks different--in its own window near the top is a drop-down menu with items About... and Exit. (Remember that on OS X, the standard menus are in a menu bar that is fixed at the top of the screen, not attached to each window.) When About... is chosen, a description of PLplot appears in a new window. There is another drop-down menu Help with items On Tcl/Tk, On GUI, and On Keys-- each of these opens a new window with help information. No plot appears, and as I have described before, when Quitting the program using the standard menu bar menu, it hangs and has to be force-quit. No plot ever appears. If I select Exit from the first menu in the window, the menu turns gray for a few seconds but the program continues to run. Typing exit in the terminal causes the program to stop running. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
On Aug 23, 2012, at 12:08 AM, Arjen Markus wrote:
Hi Jerry,
On 2012-08-23 08:46, Alan W. Irwin wrote:
Hi Jerry:
Do you have success with any other X application? The reason I ask is
the above error message may simply mean that X is badly installed on
your platform. Of course, if X were badly installed on Linux it would
be catastrophic since X is so important on that platform, but my
understanding is that X is not very important on Mac OS X. Therefore,
on that platform you might have a bad X installation and not know
about it (except by running some classical X applications such as
xterm, xeyes, oclock, etc.)
In addition to Alan's suggestions, you could try the following:
1. Start Tcl/Tk's wish
2. Type the command:
pack [button .b -command {puts Hello} -text Hi]
This should bring up a simple pushbutton with the label Hi and
when you press it, the text Hello is printed in the console window.
(Type exit to stop wish)
If the traditional X programs and this wish example work, then
we can conclude that something is wrong with the way you start
the PLplot examples, though I can not see what is wrong. Unfortunately
I have no OS X machine at my disposal, so I can only make guesses
as to what is going on/wrong.
Regards,
Arjen
Hi Arjen,
This works exactly as you describe except it runs as a native Aqua application,
not as an X application. See my more extensive comments to Alan.
Jerry
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
On Aug 23, 2012, at 2:02 PM, Alan W. Irwin wrote:
To Jerry and Arjen:
On 2012-08-23 02:22-0700 Jerry wrote:
Hi Arjen,
This [the simple wish test above] works exactly as you describe except it
runs as a native Aqua application, not as an X application. See my more
extensive comments to Alan.
@Jerry:
Just out of curiosity does Arjen's test also work with plserver? That works
fine here with me, e.g.,
software@raven plserver
% pack [button .b -command {puts Hello} -text Hi]
Yes.
If that works for you, is plserver a native app (depending on aqua
rather than X)?
Yes. It appears identical to Wish when launched from the command line, except
the program's name that is displayed in the (main) menu bar is plserver rather
than Wish.
When running x01c and selecting Tcl/TK Window for output, a program called
plserver appears and is similar to the plserver when launched from command
line, but with extra in-window menus as described earlier. In this case, a
_second_ Wish-like program is launched called x01c. (Both programs have a blue
feather icon in my dock which I gather is a Tcl/Tk logo.) The appearance of
x01c in the dock (sans feather) is also what happens when a program is run
using qtwidget so that's not that odd in itself. In this cases the x01c program
looks like a Wish program with the default Aqua menus but when I select e.g.
Run Widget Demo nothing happens except all of the menu bar items File, Edit,
Window, Help (all default items with an Aqua program) disappear, leaving only
the x01c menu and its standard items (About, Hide, Hide others, Services, Quit)
which are also standard default items for an Aqua program. (This will make
more sense if you've seen a Mac screen.)
I'd like to add this behavior and hope that it doesn't confuse things (more):
When I build plplot for tcl/tk (still 12221), the X server always launches. I
believe I saw, very briefly (1/10 second) a spurious window appear which might
be due to X. This _might_ be the mysterious window that I described earlier
when following the Tk readme that seems to have the words One ... Four
across the top. Also as part of the build output (as I have mentioned before),
this appears, possibly at the time the vanishing X windows flash on-off:
Scanning dependencies of target test_tk_01
make -f examples/CMakeFiles/test_tk_01.dir/build.make
examples/CMakeFiles/test_tk_01.dir/build
cd /usr/local/plplot_build_dir/examples tk/xtk01 -f
/usr/local/plplot_build_dir/examples/tk/tk01
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x6c275890
Serial number of failed request: 30
Current serial number in output stream: 33
make[3]: *** [examples/CMakeFiles/test_tk_01] Error 1
make[2]: *** [examples/CMakeFiles/test_tk_01.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_tk_01.dir/rule] Error 2
make: *** [test_tk_01] Error 2
make: *** No rule to make target `test_tk_02'. Stop.
and a little later,
Scanning dependencies of target test_tk_03
make -f examples/CMakeFiles/test_tk_03.dir/build.make
examples/CMakeFiles/test_tk_03.dir/build
cd /usr/local/plplot_build_dir/examples tk/tk03
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0xa98df290
Serial number of failed request: 30
Current serial number in output stream: 33
make[3]: *** [examples/CMakeFiles/test_tk_03] Error 1
make[2]: *** [examples/CMakeFiles/test_tk_03.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_tk_03.dir/rule] Error 2
make: *** [test_tk_03] Error 2
make: *** No rule to make target `test_tk_04'. Stop.
Also, recall that when running x01c and selecting for output New tk driver this
error appears:
*** PLPLOT ERROR, IMMEDIATE EXIT ***
No tk plframe widget to connect to
Program aborted
Jerry
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
On Aug 21, 2012, at 4:45 AM, Andrew Ross wrote: Jerry, We're getting there! I've now added X11_LIBRARIES to the tkwin driver link flags. Cheers Andrew 12221 builds Tk/Tcl without errors. Which gets to the place that I have always been with these demos--they don't run. Here's the synopsis--I hope it's not too confusing. As I understand it, my computer has three ways to run wish: an X11 version, a native (Aqua) version called plserver which appears to be a specialized version of the factory-installed wish which is the third way. Following the instructions in README.tkdemos: Only xtk01 is built--xtk02 etc. are not built. Typing ./xtk01 -f tk01 results in the X11 server launching and a window displaying for about 1/10 second before disappearing. The window seems to have some buttons across the top with the words One, ... , Four, Exit and additional text something like TK Control of x01c from TK but there is no plot--the rest of the window is blank. The following text appears in the terminal: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Resource id in failed request: 0xb8c0c90 Serial number of failed request: 30 Current serial number in output stream: 33 Starting plserver at /usr/local/plplot/bin/plserver starts a native app called plserver which displays a small blank window from which I can Run Widget Demo OK. Typing source tkdemos.tcl causes a blank window to appear for about 1/10 second. The following appears in the terminal: % source tkdemos.tcl % X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Resource id in failed request: 0x10b47e90 Serial number of failed request: 30 Current serial number in output stream: 33 Running /usr/local/plplot/bin/plserver -h causes Segmentation fault: 11. Running $ wish launches X11 and the X11 wish program. Following the instructions in the readme, % package require Pltk dlsym(0x7fd3b14d5e00, Pltk_Init): symbol not founddlsym(0x7fd3b14d5e00, Pltk_SafeInit): symbol not founddlsym(0x7fd3b14d5e00, Pltk_Unload): symbol not founddlsym(0x7fd3b14d5e00, Pltk_SafeUnload): symbol not foundcouldn't find procedure Pltk_Init % source tkdemos.tcl invalid command name plstdwin and then nothing interesting, no window drawn. If instead I run the factory-installed wish and follow the instructions, I get: %lappend auto_path /usr/local/plplot/share/plplot5.9.9 ...whole lotta paths... % package require Pltk dlsym(0x7fd171822450, Pltk_Init): symbol not founddlsym(0x7fd171822450, Pltk_SafeInit): symbol not founddlsym(0x7fd171822450, Pltk_Unload): symbol not founddlsym(0x7fd171822450, Pltk_SafeUnload): symbol not foundcouldn't find procedure Pltk_Init % source tkdemos.tcl invalid command name plstdwin and again and then nothing interesting, no window drawn. With respect to the tcl demos as described in README.tcldemos-- $ ./x01 ./x01: line 13: exec: pltcl: not found After adding /usr/local/plplot/bin/ to my PATH and repeating ./x01, the Plotting Options text menu is repeated several times in the terminal window. Choosing e.g. Cairo PDF Driver causes this output to appear many times: (process:89116): Pango-WARNING **: pango_layout_set_markup_with_accel: Value of 'size' attribute on span tag on line 1 could not be parsed; should be an integer, or a string such as 'small', not '-2147483648' and a valid PDF is created but which is an all-black page. Running e.g. $ ./x01c and selecting Tcl/TK Window causes a native program plserver to run. It has drop-down menus File and Help. File has an About... which opens a text window describing Plplot. The normal File menu has a functioning Run Widgets Demo. The window is otherwise blank, with no plot. There is a second program which runs at the same time called x01c and appears to be a standard native wish with some default-looking menu commands (Source, Run Widget Demo) but no window of its own. When I Quit either of these programs using the available menu item, they both hang and have to be force-quit. Running x01c and selecting New tk driver results in this: *** PLPLOT ERROR, IMMEDIATE EXIT *** No tk plframe widget to connect to Program aborted Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Can't build Tcl/Tk on OS X
Now I wonder if we could start working towards rehabilitating Tcl/Tk on OS X. I say rehabilitate because I had been building this without problems for years. With NON_TRANSITIVE=ON or NON_TRANSITIVE=OFF, ENABLE_tcl=ON, and ENABLE_tk=ON, the build fails as below. FWIW, my OS X has two Tcl and Tk installations, and it looks like cmake is using the factory versions of the headers and libraries (the so-called framework builds) but tclsh from Macports (in /opt). (All of the tcl stuff is also in /usr/bin or /usr/lib but they are links to the framework.) Cmake stuff: Found Tclsh: /opt/local/bin/tclsh (found version 8.5) -- Found TCL: /System/Library/Frameworks/tcl.framework -- Found TCLTK: /System/Library/Frameworks/tcl.framework -- Found TK: /System/Library/Frameworks/tk.framework -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /opt/local/bin/tclsh -- TCL_INCLUDE_PATH = /System/Library/Frameworks/Tcl.framework/Headers -- TCL_LIBRARY = /System/Library/Frameworks/tcl.framework -- TK_INCLUDE_PATH = /System/Library/Frameworks/Tk.framework/Headers;/usr/include -- TK_LIBRARY = /System/Library/Frameworks/tk.framework Here is the error report for NON_TRANSITIVE=ON: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 With NON_TRANSITIVE=OFF, the error is the same but with some extra libraries being linked: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib /usr/lib/libm.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 IIRC there was at the beginning of this thread the suggestion that there might be something wrong with the X11 libraries. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build Tcl/Tk on OS X
Also, the undefined symbols are the same if I use the factory or MacPorts X11 libraries. Jerry There were comments about this (Tcl/Tk X11) at the beginning of the thread, Can't build on OS X Lion. Maybe I shouldn't have started a new thread. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On Aug 18, 2012, at 1:37 PM, Andrew Ross wrote: On Fri, Aug 17, 2012 at 05:46:47PM -0700, Alan Irwin wrote: On 2012-08-17 09:59-0700 Alan W. Irwin wrote: On 2012-08-16 20:37-0700 Jerry wrote: Thanks for looking into this, Andrew. The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /opt/local/bin/cmake -E cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -bundle -Wl,-headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o ../src/libplplotd.11.0.0.dylib /usr/lib/libm.dylib ../bindings/qt_gui/libplplotqtd.0.0.1.dylib ../src/libplplotd.11.0.0.dylib -lQtCore ld: library not found for -lQtCore collect2: ld returned 1 exit status make[2]: *** [drivers/qt.so] Error 1 make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2 make: *** [all] Error 2 Andrew, just to interject here, I believe the source of the error is the lack of -L option in the above line to tell the linker where to find QtCore. QT_LIBRARIES should have that information along with a bunch of -l options that you do not want for the -DNON_TRANSITIVE=ON case. So probably the thing to do here is to parse the QT_LIBRARIES variable to remove the unwanted -l options. Since you are working through a 3rd party (Jerry) for a platform you are not familiar with (OS X), I suggest you use the CMake message command to always print out both QT_LIBRARIES, and its parsed form just in case Jerry finds any further difficulty with the parsed version. P.S. That comment wasn't quite right. To further clarify, all lists of linking flags like QT_LIBRARIES are further processed by our build system when they are first encountered (in cmake/modules) to transform -L and -l options to construct the equivalent full path name of libraries without disturbing other linking flags. (The absolute pathname form is the preferred one for variables that are used in target_link_libraries even though CMake internally changes that back to the -L and -l form when linking Linux libraries. But the actual resulting linking command may be different on other platforms which is why the absolute pathname form for library locations is preferred for input to target_link_libraries.) In sum, that clarification means for the case where you need to drop some but not all of those libraries, you should parse lists of linking flags such as QT_LIBRARIES to drop all absolute pathames other than the libraries you want. That parsing should leave hyphenated options alone. I've now done this, parsing QT_LIBRARIES to extract just the QtCore library. Jerry, can you try this version? Out of interest, if it doesn't work can you report the values of QT_LIBRARIES and QT_LINK_LIBS returned by cmake, and also the actual command used to link the Qt driver? Thanks Andrew Andrew, Sorry. With -DNON_TRANSITIVE=ON, the build failed on SVN 12217. The variables you wanted to see are: QT_LIBRARIES = /opt/local/lib/libQtSvg.dylib;/opt/local/lib/libQtGui.dylib;/opt/local/lib/libQtXml.dylib;/opt/local/lib/libQtCore.dylib QT_LINK_LIBS = /opt/local/lib/libQtCore.dylib Here is the error output and the few lines before it. Does this contain the link command you need to see? Scanning dependencies of target qt make -f drivers/CMakeFiles/qt.dir/build.make drivers/CMakeFiles/qt.dir/build /opt/local/bin/cmake -E cmake_progress_report /usr/local/plplot_build_dir/CMakeFiles 42 [ 31%] Building CXX object drivers/CMakeFiles/qt.dir/qt.cpp.o cd /usr/local/plplot_build_dir/drivers /usr/local/adacore-gnat-2011/bin/c++ -Dqt_EXPORTS -DHAVE_CONFIG_H -fPIC -I/Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include -I/Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime -I/Users/jerrybauck/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/nistcd -I/usr/local/plplot_build_dir -I/usr/local/plplot_build_dir/include -I/opt/local/include/QtDesigner -I/opt/local/include/QtDeclarative -I/opt/local/include/QtScriptTools -I/opt/local/include/QtDBus -I/opt/local/include/QtDesigner -I/opt/local/include/QtXml -I/opt/local/include/QtSql -I/opt/local/include/QtOpenGL -I/opt/local/include/QtMultimedia -I/opt/local/include/QtNetwork -I/opt/local/include/QtXmlPatterns -I/opt/local/include/QtWebKit -I/opt/local/include/QtHelp -I/opt/local/include/QtUiTools -I/opt/local/include/QtTest -I/opt/local/include/QtScript -I/opt/local/include/QtSvg -I/opt/local/include/Qt3Support -I/opt/local/include/QtGui -I/opt/local/include/QtCore -I/opt/local/share/qt4/mkspecs/default -I/opt/local/include -I/opt/local/include/QtCore -DUSINGDLL -o CMakeFiles/qt.dir/qt.cpp.o
Re: [Plplot-devel] Can't build on OS X Lion
On Aug 16, 2012, at 4:10 AM, Andrew Ross wrote: I've revisited this and taken a closer look at the code. There are no explicit references to QWidget in the qt driver other than pointers (which are fine). The QtPLWidget class does however inherit from QWidget and so some of its functions are used. It looks like although this code is all in libplplotqtd it results in QWidget functions being called from the qt driver implicitly. Now this seems to work ok on Linux, but not on OS-X. To do this properly the qt driver would need to link against QtCore, but not QtSvg or QtGui. I've included the changes to do this. Jerry, can you test the svn head to see if this works for you? Thanks Andrew Thanks for looking into this, Andrew. The results that I reported in my previous e-mail (reviving the thread) were with -DNON_TRANSITIVE=OFF. With your fix to 12216, I can now build 12216 for Qt. Problem fixed. When I switch to -DNON_TRANSITIVE=ON, however, the build fails like this: Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /opt/local/bin/cmake -E cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -bundle -Wl,-headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o ../src/libplplotd.11.0.0.dylib /usr/lib/libm.dylib ../bindings/qt_gui/libplplotqtd.0.0.1.dylib ../src/libplplotd.11.0.0.dylib -lQtCore ld: library not found for -lQtCore collect2: ld returned 1 exit status make[2]: *** [drivers/qt.so] Error 1 make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2 make: *** [all] Error 2 I gather that with -DNON_TRANSITIVE=OFF the linking happens with possible redundancies. FWIW, the above line looks like it is using the AdaCore c++ which comes with the Ada (GNAT) compiler. (Apple does not ship Ada so we have to get it from other places.) The build process is apparently finding it rather the Apple compiler which is probably /usr/bin/gcc. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On Aug 16, 2012, at 4:30 AM, Andrew Ross wrote: P.S. I've also checked the wxwidgets code. The wxwidgets driver does not link against libplplotwxwidgetsd and so there should not be a problem there. The example using this class explicitly links against the wxwidgets libraries as it uses some of the function directly so again should be fine. Jerry - if you have wxwidgets, please let me know if you encounter any problems. Regards Andrew I have wxwidgets 2.8.12_0 installed as part of MacPorts. (All of the MacPorts stuff is in /opt/local.) With DNON_TRANSITIVE=OFF, DENABLE_wxwidgets=ON, and DPLD_wxwidgets=ON the build of 12216 fails like this: Linking CXX shared library libplplotwxwidgetsd.dylib cd /usr/local/plplot_build_dir/bindings/wxwidgets /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplotwxwidgetsd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -single_module -o libplplotwxwidgetsd.0.0.0.dylib -install_name /usr/local/plplot_build_dir/bindings/wxwidgets/libplplotwxwidgetsd.0.dylib CMakeFiles/plplotwxwidgetsd.dir/wxPLplotstream.cpp.o CMakeFiles/plplotwxwidgetsd.dir/wxPLplotwindow.cpp.o -lplplotcxxd -arch i386 -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL /opt/local/lib/libwx_base_carbonu-2.8.dylib /opt/local/lib/libwx_macu_core-2.8.dylib ld: library not found for -lplplotcxxd collect2: ld returned 1 exit status make[2]: *** [bindings/wxwidgets/libplplotwxwidgetsd.0.0.0.dylib] Error 1 make[1]: *** [bindings/wxwidgets/CMakeFiles/plplotwxwidgetsd.dir/all] Error 2 make: *** [all] Error 2 To my unpracticed eye the part -arch i386 sticks out. I'm using x86_64 and as far as I know everything associated with building plplot on my machine is 64-bit. The wiki for OS X has long had the recommendation to not build for wxwidgets, possibly for an issue unrelated to what we are working on now; it would be great if we could get wxwidgets working on this OS. Jerry On Thu, Aug 16, 2012 at 12:10:24PM +0100, Andrew Ross wrote: I've revisited this and taken a closer look at the code. There are no explicit references to QWidget in the qt driver other than pointers (which are fine). The QtPLWidget class does however inherit from QWidget and so some of its functions are used. It looks like although this code is all in libplplotqtd it results in QWidget functions being called from the qt driver implicitly. Now this seems to work ok on Linux, but not on OS-X. To do this properly the qt driver would need to link against QtCore, but not QtSvg or QtGui. I've included the changes to do this. Jerry, can you test the svn head to see if this works for you? Thanks Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On Aug 16, 2012, at 4:30 AM, Andrew Ross wrote: P.S. I've also checked the wxwidgets code. The wxwidgets driver does not link against libplplotwxwidgetsd and so there should not be a problem there. The example using this class explicitly links against the wxwidgets libraries as it uses some of the function directly so again should be fine. Jerry - if you have wxwidgets, please let me know if you encounter any problems. Regards Andrew I also tried to build 12216 for tcl/tk. DNON_TRANSITIVE=OFF, DENABLE_tcl=ON, DENABLE_tk=ON, with the result below. This is the same condition which prompted the thread in the beginning, on May 9, 2012. The result is exactly the same whether I use the built-in tcl/tk by doing this: CMAKE_LIBRARY_PATH=/usr/local/adacore-gnat-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib:\ /usr/lib/libtcl.dylib:\ /usr/lib/libtk.dylib or (I think) using the MacPorts version by doing only this: CMAKE_LIBRARY_PATH=/usr/local/adacore-gnat-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib (The MacPorts paths are at the front of my PATH variable.) Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /opt/local/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib /usr/lib/libm.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
I would like to revive this thread from mid-May 2012 as I believe there are
still unresolved issues.
The short version is that on OS X 10.7.4 (now more than a year old) I can't
build for the Qt driver after SVN version 12053.
To clarify my remark below from my posting on 2012-05-13 21:15-0700,
12053 builds with -DDEFAULT_NO_QT_DEVICES=OFF
12054 fails with -DDEFAULT_NO_QT_DEVICES=OFF builds with
-DDEFAULT_NO_QT_DEVICES=ON
I tried building against both 4.7.0 and, since there was a warning when
building plpot that OS X 10.7 wasn't supported by 4.7.0, I also tried building
against Qt 4.8.2--no warning but _nearly_ the same error.
Here's the long version, from building against Qt 4.8.2:
Linking CXX shared module qt.so
cd /usr/local/plplot_build_dir/drivers /opt/local/bin/cmake -E
cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1
/usr/local/adacore-gnat-2011/bin/c++ -bundle -Wl,-headerpad_max_install_names
-o qt.so CMakeFiles/qt.dir/qt.cpp.o ../src/libplplotd.11.0.0.dylib
/usr/lib/libm.dylib ../bindings/qt_gui/libplplotqtd.0.0.1.dylib
../src/libplplotd.11.0.0.dylib
Undefined symbols for architecture x86_64:
QString::fromAscii_helper(char const*, int), referenced from:
QString::QString(char const*) in qt.cpp.o
QString::free(QString::Data*), referenced from:
QString::~QString() in qt.cpp.o
QCoreApplication::self, referenced from:
QCoreApplication::instance() in qt.cpp.o
QWidget::move(QPoint const), referenced from:
QWidget::move(int, int) in qt.cpp.o
QWidget::resize(QSize const), referenced from:
QWidget::resize(int, int) in qt.cpp.o
qt_assert_x(char const*, char const*, char const*, int), referenced from:
QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o
QMutex::unlock(), referenced from:
QMutex::unlockInline() in qt.cpp.o
QMutex::lock(), referenced from:
QMutex::lockInline() in qt.cpp.o
QApplication::QApplication(int, char**, bool, int), referenced from:
initQtApp(bool) in qt.cpp.o
QSvgGenerator::size() const, referenced from:
plD_eop_svgqt(PLStream*) in qt.cpp.o
QPicture::QPicture(int), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
plD_init_extqt(PLStream*) in qt.cpp.o
QPainter::QPainter(QPaintDevice*), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
plD_init_extqt(PLStream*) in qt.cpp.o
QWidget::setWindowTitle(QString const), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
qFlagLocation(char const*), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
QObject::connect(QObject const*, char const*, QObject const*, char const*,
Qt::ConnectionType), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
QPainter::~QPainter(), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
plD_init_extqt(PLStream*) in qt.cpp.o
QPicture::~QPicture(), referenced from:
plD_init_qtwidget(PLStream*) in qt.cpp.o
plD_init_extqt(PLStream*) in qt.cpp.o
QWidget::raise(), referenced from:
plD_eop_qtwidget(PLStream*) in qt.cpp.o
QCoreApplication::processEvents(QFlagsQEventLoop::ProcessEventsFlag),
referenced from:
plD_eop_qtwidget(PLStream*) in qt.cpp.o
QImage::scanLine(int), referenced from:
plD_init_memqt(PLStream*) in qt.cpp.o
plD_eop_memqt(PLStream*) in qt.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [drivers/qt.so] Error 1
make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2
make: *** [all] Error 2
Jerry
On May 14, 2012, at 10:54 AM, Alan W. Irwin wrote:
Hi Jerry and Andrew:
On 2012-05-13 21:15-0700 Jerry wrote:
with -DNON_TRANSITIVE=ON \ (and tcl/tk still disabled), both 12121 and 12165
failed to build. I then bisected between 12121 and 11957 and found:
12053 builds
12054 fails
Thanks very much, Jerry, for that essential information!
Andrew, the rest of this e-mail is addressed largely to you.
If you look at
svn diff -x -w --revision=12053:12054 |less
everything seems fine on the surface. The cmake logic
target_link_libraries(plplotqt${LIB_TAG} LINK_INTERFACE_LIBRARIES)
# This configures the pkg-config method to use non-transitive linking.
set(PC_REQUIRES_TAG Requires.private)
simply tells both CMake and pkg-config (when we use the latter) when
some application or shared object links to libplplotqtd not to link to
the libplplotqtd Qt4 dependencies to avoid overlinking. Of course, this
only works if we can assume that all of the applications/shared
objects that are linking to libplplotqtd actually have no direct
references to Qt4.
But it appears this assumption is violated for at least
qt.so (one important shared object that depends on libplplotqtd).
software@raven nm --demangle --undefined-only qt.so |grep QWidget
U QtPLWidget::QtPLWidget(int, int
Re: [Plplot-devel] cmap1 colourscale direction
On Aug 13, 2012, at 4:53 PM, Alan W. Irwin wrote: On 2012-08-13 14:20-0700 Alan W. Irwin wrote: So far so good, but there is a lot more rev ==alt_hue_path source code changes to come since plscmap1l (or cmap1l) is mentioned in quite a large number of different files in src, bindings, and examples. Revision 12212 finished off this change to our core C library, and the language bindings. These changes only build tested so far. @Jerry: The rev misnomer and bad documentation of that flag had propagated (through no fault of your own) to an extraordinary degree to the Ada bindings. So there were some fairly intrusive changes there. Those, in fact, constituted a minor API change so revision 12212 also includes the necessary changes to examples/ada, and Ada users will also have to make corresponding changes to their source code. But I think addressing this misunderstanding is well worth this minor pain. Thanks, Alan. I believe that Ada weirdness was a result of my finding a workaround to the C API calling for a null pointer in some cases. Ada-folk hardly know what a null pointer is. 8^) I'll make a note to make sure this is in the Ada docs. Jerry @Andrew: when you get around to updating the DocBook alt_hue_path documentation, you should look at my updated doxygen documentation in plctrl.c where I made a first attempt at that. Of course, if you can think of better wording, don't hesitate to change the doxygen documentation some more. @Everybody: there will be more to come (probably within a day or so as a break from my other work) with the remaining examples to finish off _all_ the rev ==alt_hue_path code changes. 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 __ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 10, 2012, at 11:02 AM, Alan W. Irwin wrote: What is going on here is you bypassed one problem/inconsistency with your system installation only to find a further completely unrelated problem. To bypass each such problem, do what you did with the Tcl issue, that is disable the relevant part of the PLplot build (in order to find the next problem or else finally exhaust the list of such problems that you have to bypass to get a valid PLplot build). In this case it is some issue with Qt4 which is a rather complicated part of our PLplot build. I think you bypass all of that part of the PLplot build with -DDEFAULT_NO_QT_DEVICES=ON, but you will have to experiment. (Note, I am getting the name of this variable and some idea what to do with it from the short annotations in CMakeCache.txt that is generated for any given build in the top of the build directory. So when you are disabling various parts of PLplot, that file is a good place to start looking for the names of the appropriate variables to set ON or OFF.) I have no idea why you are suddenly having all these problems, but obviously it is some system or PLplot change that was made since the last time you ran the test_noninteractive target with success. Note svn allows you to easily access any particular revision number that you like. Once you find some revision that worked in the past for your current system (if your current system installation is not the culprit), then use a binary search on revision numbers to find the last good one/first bad one. For example, from plplot.sf.net the last release occurred on 2011-10-13, and the svn log command shows revision 11957 is about the closest you get to that release date on svn trunk. The current revision is 12194 So to change to revision 11957 simply cd to the top of your source tree and svn update --revision 11957 Then do your normal build and test with make test_noninteractive in the top of the core build tree to see if that revision works. If it does, then try a revision half way between 11957 and 12194 to see if that works, etc. That is do a binary search for the last revision that worked, and the next revision after that is the one that first introduced a PLplot change that is not right for your current Mac OS X/macports platform. The binary search method is actually amazingly fast. In this case a maximum 8 builds should find the problem since there are less than 256 revisions between 11957 and 12194. There is a procedure to automate such binary searches, but in this case it is probably easier to do it by hand. 12121 Builds 12122 Doesn't build http://plplot.svn.sourceforge.net/viewvc/plplot?view=revisionsortby=logrevision=12122 tcl-related.cmake looks interesting. Here's the error output again: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib /usr/lib/libm.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 Jerry Note if the problems are caused by some issues with your new Mac OS X/macports system not even revision 11957 (or whatever revision you last tested successfully with the test_noninteractive target) would work well for you now. Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot
Re: [Plplot-devel] Can't build on OS X Lion
On May 11, 2012, at 12:54 AM, Arjen Markus wrote: On Fri, 11 May 2012 00:43:22 -0700 Jerry lancebo...@qwest.net wrote: 12121 Builds 12122 Doesn't build http://plplot.svn.sourceforge.net/viewvc/plplot?view=revisionsortby=logrevision=12122 tcl-related.cmake looks interesting. Hi Jerry, it would seem that reverting the change to tcl-related.cmake should solve the Tcl/Tk issue. What surprises me a bit is that there are only two unresolved symbols - plframe uses several other X11 functions as well. Regards, Arjen /usr/X11/bin is on my PATH. Could PLplot be getting into that? Jerry 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. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 11, 2012, at 12:16 PM, Alan W. Irwin wrote: Jerry, would you be willing to do a similar binary search for the revision that caused the Qt4 issues for you? If so, I would disable Tcl with the appropriate cmake option (so the above commit issues don't matter for your test) and repeat the binary search from revision 12121 onward. Sure, no problem. I might not be able to get to it today or tomorrow, though. Should I disable tk as well? Jerry Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 11, 2012, at 12:16 PM, Alan W. Irwin wrote: Jerry, would you be willing to do a similar binary search for the revision that caused the Qt4 issues for you? If so, I would disable Tcl with the appropriate cmake option (so the above commit issues don't matter for your test) and repeat the binary search from revision 12121 onward. Alan 12164 builds 12165 fails Jerry Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -bundle -Wl,-headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o ../src/libplplotd.11.0.0.dylib /usr/lib/libm.dylib ../bindings/qt_gui/libplplotqtd.0.0.1.dylib ../src/libplplotd.11.0.0.dylib ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: QString::fromAscii_helper(char const*, int), referenced from: QString::QString(char const*) in qt.cpp.o QString::free(QString::Data*), referenced from: QString::~QString() in qt.cpp.o QCoreApplication::self, referenced from: QCoreApplication::instance() in qt.cpp.o QWidget::move(QPoint const), referenced from: QWidget::move(int, int) in qt.cpp.o QWidget::resize(QSize const), referenced from: QWidget::resize(int, int) in qt.cpp.o qt_assert_x(char const*, char const*, char const*, int), referenced from: QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o QMutex::lock(), referenced from: QMutexLocker::QMutexLocker(QMutex*) in qt.cpp.o QMutex::unlock(), referenced from: QMutexLocker::unlock() in qt.cpp.o QApplication::QApplication(int, char**, bool, int), referenced from: initQtApp(bool) in qt.cpp.o QSvgGenerator::size() const, referenced from: plD_eop_svgqt(PLStream*) in qt.cpp.o QPicture::QPicture(int), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o QPainter::QPainter(QPaintDevice*), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o QWidget::setWindowTitle(QString const), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o qFlagLocation(char const*), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o QPainter::~QPainter(), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o QPicture::~QPicture(), referenced from: plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o QWidget::raise(), referenced from: plD_eop_qtwidget(PLStream*) in qt.cpp.o QCoreApplication::processEvents(QFlagsQEventLoop::ProcessEventsFlag), referenced from: plD_eop_qtwidget(PLStream*) in qt.cpp.o QImage::scanLine(int), referenced from: plD_init_memqt(PLStream*) in qt.cpp.o plD_eop_memqt(PLStream*) in qt.cpp.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [drivers/qt.so] Error 1 make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2 make: *** [all] Error 2 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 9, 2012, at 1:42 PM, Andrew Ross wrote: Jerry, It looks like this could be related to the recent changes to clean up redundant library linkages. As a quick check, you could try setting the NON_TRANSITIVE option to OFF to disable this. Does this help? If so we can start delving into what is happening. Looks like the linkage with the X11 library is missing, we just need to figure out why. Andrew I actually tried this before I first posted, and with -DNON_TRANSITIVE=OFF I got exactly the same results (except with a couple more libraries listed)--everything from Undefined symbols for architecture x86_64: onward is exactly the same. Jerry On Wed, May 09, 2012 at 03:21:07AM -0700, Jerry wrote: I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. Here's the problem: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink /Library/Tcl/macports1.0 which points to /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib /opt/local/share/macports/Tcl/macports1.0/macports.tcl /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 9, 2012, at 2:54 PM, Alan W. Irwin wrote: On 2012-05-09 03:21-0700 Jerry wrote: I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. Here's the problem: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink /Library/Tcl/macports1.0 which points to /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib /opt/local/share/macports/Tcl/macports1.0/macports.tcl /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl Hi Jerry: My guess is the the issue is some conflict between what -framework tcl means in the above command line (for example, that probably refers to the system version of Tcl) versus your macport install of Tcl. However, I don't have any Mac OS X/macports experience so one of the others here with such experience might be able to help you further. However, unless and until you can get such detailed help with the above Tcl linking issue, I suggest for now you simply work around the issue by disabling the Tcl part of the PLplot build using the -DENABLE_tcl=OFF cmake option. Alan I thought of that earlier too but didn't report it in my first post. With -DENABLE_tcl=OFF \ -DENABLE_tk=OFF \ (FWIW, my build script includes in CMAKE_LIBRARY_PATH the paths /usr/lib/libtcl.dylib:\ /usr/lib/libtk.dylib which are the standard-issue OS X libraries as far as I know, and which have worked in the past.) I get this (!) which appears to be Qt problems: Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/qt.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/c++ -bundle -Wl,-headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o ../src/libplplotd.11.0.0.dylib /usr/lib/libm.dylib ../bindings/qt_gui/libplplotqtd.0.0.1.dylib ../src/libplplotd.11.0.0.dylib ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: QString::fromAscii_helper(char const*, int), referenced from: QString::QString(char const*) in qt.cpp.o QString::free(QString::Data*), referenced from: QString::~QString() in qt.cpp.o QCoreApplication::self, referenced from: QCoreApplication::instance() in qt.cpp.o QWidget::move(QPoint const), referenced from: QWidget::move(int, int) in qt.cpp.o QWidget::resize(QSize const), referenced from: QWidget::resize(int, int) in qt.cpp.o qt_assert_x(char const*, char const*, char const*, int), referenced
Re: [Plplot-devel] Need small change to the way Ada bindings are built
On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote:
On 2012-05-10 00:59-0700 Jerry wrote:
Hi Jerry:
I think the above change will screw up our installed Ada examples
build which exclusively uses the gnatmake approach. So please test
the installed examples build with and without the above change to see
whether that hypothesis is correct.
To remind you how to do such testing do your normal procedure
for building and installing PLplot. Then
run cmake in an empty directory
with no options and with just a reference to the installed examples
tree like this:
# insures initially empty build tree.
rm -rf test_install_build
mkdir test_install_build
cd test_install_build
cmake /usr/local/plplot/share/plplot5.9.9/examples
then
make test_ada_psc
That make command should work fine for an unmolested install, but if
Hmm I did this
cd /usr/local/dumpme
rm -rf test_install_build
mkdir test_install_build
cd test_install_build
cmake /usr/local/plplot/share/plplot5.9.9/examples
make test_ada_psc
and got this...
Generate ada results for psc device
Testing front-end ada
x01
/usr/local/plplot/share/plplot5.9.9/examples/test_ada.sh: line 32: 34044
Trace/BPT trap: 5 $adadir/x${index}${lang} -dev $device -o
${OUTPUT_DIR}/x${index}${lang}%n.$dsuffix $options 2 test.error
|${OUTPUT_DIR}/x${index}${lang}_${dsuffix}.txt
dyld: Library not loaded: @rpath/libgnat-2010.dylib
Referenced from: /usr/local/dumpme/test_install_build/./ada/x01a
Reason: image not found
make[3]: *** [x01a.psc] Error 1
make[2]: *** [CMakeFiles/test_ada_psc.dir/all] Error 2
make[1]: *** [CMakeFiles/test_ada_psc.dir/rule] Error 2
make: *** [test_ada_psc] Error 2
I tried to supply the path to what I think it is asking for but I'm not sure
how to do that.
Hi Jerry:
I am not familiar with the Mac OS X platform, but from the message above
it looks to me like
the run-time loader that executes x01a is having trouble locating
libgnat-2010.dylib in your new installation.
I've puzzled over @rpath before--can't remember what I learned but I don't
think it was much.
Isn't there a standard
environment variable you can set (LD_LIBRARY_PATH works for Linux) to
help address such issues?
I assume you would get the same error for the core build system as
well, but to check that do a clean _core_ build of PLplot using
the cmake option, -DBUILD_TEST=ON
I always do.
then run
make test_ada_psc
What do I cd to before running this?
BTW the results that I reported before were with the 2010 compiler but the 2011
compiler makes the exact same output but with
dyld: Library not loaded: @rpath/libgnat-2011.dylib
^
All for tonight (U.S. west)
Jerry
as above. But this will be in the build tree of the core build rather
than the build tree of the installed examples. Of course, if the
core build version works while the above installed example version
does not, then compare exact commands that are run in each case using
make VERBOSE=1 test_ada_psc
But I am virtually positive you will get the same result for core
build and installed examples build since virtually the same CMake code
is used in both cases.
By the way, the test_ada_psc target runs the Ada subset of what is
done for all language bindings and examples with the
test_noninteractive target. And if I recall correctly you have run
that test_noninteractive target in the past with no issues. Once this
current run time loader cannot find Ada system library issue is
addressed for your current Ada installation, I strongly encourage you
to run the test_noninteractive target (or at least the Ada subset of
that test with the target name test_ada_psc) more often so that
_every_ system and PLplot change is tested right after the change
occurs (rather than days or months later when you have forgotten the
details of the change).
Alan
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't build on OS X Lion
On May 10, 2012, at 6:55 AM, Arjen Markus wrote: Hi Jerry, could it be the installation of X11? (I was told that such problems as unresolved symbols often result from architectures as x86_64.) A simple remedy might be to install the latest version of XQuartz - the open source version of X11 for OS X at http://xquartz.macosforge.org/landing/ Regards, Arjen I'll keep this in mind. As the page says, XQuartz has shipped with OS X for several years. However, the version listed on that page is 2.7.1 while the one included with the latest version of OS X is 2.6.3 with a Build Date: 20120112. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Need small change to the way Ada bindings are built
OK--I got some great help from comp.lang.ada (as usual) and have learned how to make a .gpr file that references the .ali files and the corresponding .dylib when they are in separate directories. My original problem is solved in that I can now build PLplot using the 2011 GNAT (from an old version of source--not to confuse this thread with my other pending thread on the list) and subsequently bind and link my personal project. I was pointed to a very nice document called Debian policy for Ada at http://people.debian.org/~lbrenta/debian-ada-policy.html which provided a clearer description of what needed to be done than the GPRbuild User's Guide. It's still a mystery why my defective .gpr file worked with the 2010 GNAT tools. Unless Alan thinks we have uncovered some testing issues, I'm ready to put this to rest. Sorry for the fuss. Jerry On May 10, 2012, at 11:12 AM, Alan W. Irwin wrote: On 2012-05-10 03:18-0700 Jerry wrote: On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote: Hi Jerry: I am not familiar with the Mac OS X platform, but from the message above it looks to me like the run-time loader that executes x01a is having trouble locating libgnat-2010.dylib in your new installation. I've puzzled over @rpath before--can't remember what I learned but I don't think it was much. Isn't there a standard environment variable you can set (LD_LIBRARY_PATH works for Linux) to help address such issues? I assume you would get the same error for the core build system as well, but to check that do a clean _core_ build of PLplot using the cmake option, -DBUILD_TEST=ON I always do. then run make test_ada_psc What do I cd to before running this? You run that target exactly the way your run the test_noninteractive target, i.e., you cd to the top of the (empty) build tree for the core build (or equivalent installed examples build), run cmake there, then run make test_ada_psc there. But if test_ada_psc does not work, neither will test_noninteractive since the latter executes the test_ada_psc target (and a whole lot more). The advantage of test_ada_psc, of course, is it just concentrates on testing the Ada build and Ada examples so it is much quicker than the far more comprehensive test_noninteractive target. 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 __ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Can't build on OS X Lion
I can no longer build from the current SVN version. I _can_ build from a rather old (months--not sure how many months) SVN that I have saved. As far as I know the only two things that have changed are PLplot version and OS version--I updated OS X from 10.6.8 Snow Leopard to 10.7.x Lion recently. The only variable I have easy control of is PLplot version. I assume that reverting to Snow Leopard would be painful and of questionable use. Here's the problem: Linking C shared library libplplottcltkd.dylib cd /usr/local/plplot_build_dir/bindings/tcl /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/plplottcltkd.dir/link.txt --verbose=1 /usr/local/adacore-gnat-2011/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -single_module -compatibility_version 9.0.0 -current_version 9.2.0 -o libplplottcltkd.9.2.0.dylib -install_name /usr/local/plplot_build_dir/bindings/tcl/libplplottcltkd.9.dylib CMakeFiles/plplottcltkd.dir/tclAPI.c.o CMakeFiles/plplottcltkd.dir/tclMain.c.o CMakeFiles/plplottcltkd.dir/__/tk/Pltk_Init.c.o CMakeFiles/plplottcltkd.dir/__/tk/plframe.c.o CMakeFiles/plplottcltkd.dir/__/tk/plr.c.o CMakeFiles/plplottcltkd.dir/__/tk/tcpip.c.o CMakeFiles/plplottcltkd.dir/__/tk/tkMain.c.o libtclmatrixd.9.2.0.dylib ../../src/libplplotd.11.0.0.dylib -framework tcl -framework tk ../../lib/csa/libcsirocsa.0.0.1.dylib ../../lib/qsastime/libqsastime.0.0.1.dylib Undefined symbols for architecture x86_64: _XLookupString, referenced from: _PlFrameKeyEH in plframe.c.o _XFlush, referenced from: _DisplayPlFrame in plframe.c.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [bindings/tcl/libplplottcltkd.9.2.0.dylib] Error 1 make[1]: *** [bindings/tcl/CMakeFiles/plplottcltkd.dir/all] Error 2 make: *** [all] Error 2 I should add that there has been one other change but I don't think it's relevant--I have (once again!) installed MacPorts which is a shadow quasi-OS-and-more which purports to be completely independent of OS X, and installs in /opt/local. However, and I mention this only because I don't understand what is happening above but see some possible tcl issues, MacPorts does place this symlink /Library/Tcl/macports1.0 which points to /opt/local/share/macports/Tcl/macports1.0/macports_autoconf.tcl /opt/local/share/macports/Tcl/macports1.0/macports_dlist.tcl /opt/local/share/macports/Tcl/macports1.0/macports_fastload.tcl /opt/local/share/macports/Tcl/macports1.0/macports_index.tcl /opt/local/share/macports/Tcl/macports1.0/macports_util.tcl /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib /opt/local/share/macports/Tcl/macports1.0/macports.tcl /opt/local/share/macports/Tcl/macports1.0/pkgIndex.tcl Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Building PLplot on OS X with AquaTerm
I have never been able to build PLplot on OS X with AquaTerm. (AquaTerm is nice because it scales everything, including lines, on screen when you resize the window, plus you can copy from it and get PDFs to paste, and other reasons.) I wonder if this is because Apple does not ship gcc with Ada and I get Ada from another place which does not include Objective-C. Here is the problem: Scanning dependencies of target aqt make -f drivers/CMakeFiles/aqt.dir/build.make drivers/CMakeFiles/aqt.dir/build /Applications/CMake 2.8-6.app/Contents/bin/cmake -E cmake_progress_report /usr/local/plplot_build_dir/CMakeFiles [ 23%] Building C object drivers/CMakeFiles/aqt.dir/aqt.c.o cd /usr/local/plplot_build_dir/drivers /usr/local/adacore-gnat-2010/bin/gcc -Daqt_EXPORTS -DHAVE_CONFIG_H -fPIC -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/nistcd -I/usr/local/plplot_build_dir -I/usr/local/plplot_build_dir/include-ObjC -DUSINGDLL -o CMakeFiles/aqt.dir/aqt.c.o -c /Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/drivers/aqt.c cc1: error: invalid option argument '-ObjC' make[2]: *** [drivers/CMakeFiles/aqt.dir/aqt.c.o] Error 1 make[1]: *** [drivers/CMakeFiles/aqt.dir/all] Error 2 make: *** [all] Error 2 FWIW, Aquaterm is written in Objective-C. Also, my build script has the line, CMAKE_C_COMPILER=/usr/bin/gcc as well as CMAKE_Ada_compiler=/usr/local/adacore-gnat-2010/bin/gcc Has anyone else built PLplot on OS X with both Ada and AquaTerm enabled? Jerry -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Odd ticks
When the last argument to plenv is 2, the tick marks at the left and bottom of the plot box extend outside the box, (as well as inside), sometimes colliding with numerical labels. The ticks at the right and top do not extend outside the box. Is this by design or is it a mistake? Try it on x00c.c or see the attached PS. Jerry inline: x00c odd ticks.ps-- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Output devices in ABOUT
No mention yet of output devices in the ABOUT file? Jerry -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] ada documentation does not build
On Sep 16, 2010, at 8:20 AM, Hazen Babcock wrote: It chokes on the following: type Real_Vector is array (Integer range ) of Long_Float; In particular it does not seem to like the . Does anyone know how to tell it that this is not a command that it should try to interpret? -Hazen Ada and I apologize. Jerry -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Sep 7, 2010, at 9:44 PM, Alan W. Irwin wrote: Hi Jerry: On 2010-09-07 19:49-0700 Jerry wrote: User programs that previously relied on the built-in declarations of Vector and Matrix _might_ now have a problem. From my tests, I don't think the standard Ada (both thin and thick) examples are affected by this. Do those examples do something special to avoid the problem? If so, perhaps the documentation should advertise what that is (if it doesn't do that now). Alan __ No, they don't do anything special. All they do is reference the Vector and Matrix declarations which are in PLplot_auxiliary.ads and look like this: type Real_Vector is array (Integer range ) of Long_Float; type Real_Matrix is array (Integer range , Integer range ) of Long_Float; These are open arrays or in Ada, unconstrained arrays, indicated by instead of actual index ranges such as 3..7. The examples and any user program need only to reference the package which contains these. In Ada, this looks like with PLplot_Auxiliary; (and optionally,) use PLplot_Auxiliary; The examples or user program then needs to declare variables of these types with actual bounds specified. For example, in x01a.adb, there is this: xs, ys : Real_Vector (0 .. 5); but this is SOP for Ada. If, when the user begins writing his/her program and (1) knows that there will no use of the Ada 2005 numerical BLAS-LAPACK vector-matrix stuff (eigenthings, solvers, etc.) and (2) plans on using PLplot, then the Ada bindings will just work. This is how the Ada examples are written. However, if the user either (a) needs to use the numerical stuff in Ada or (b) begins writing the program using the official Ada declarations and realizes later that PLplot is needed, then he/she will need to either (*) comment two lines in PLplot_Auxiliary.adb and uncomment three lines, then recompile the Ada part and make sure the link to BLAS and LAPACK happens, or (+) insert an explicit type conversion when those official vectors and matrices are passed to PLplot. I have explained this in the documentation pretty much like this. By the way, this easy switching of declaration styles is the only remaining reason for keeping PLplot_Auxiliary.ad[bs] (some PLplot- specific utilities notwithstanding). I could eliminate it for all of Ada in PLplot but then it obscures how to do the switch. It's a little ugly. I suppose other languages would do this with compiler pragmas but Ada does not have them--apparently someone thought they are unsafe. Jerry -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 22, 2010, at 4:09 AM, Jerry wrote: On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: On 2010-07-13 09:47-0600 Orion Poplawski wrote: On 07/13/2010 01:21 AM, Alan W. Irwin wrote: I think very little effort would be required to remove HAVE_ADA_2007 from the build system. However, let's wait to do anything about this until we understand the linking issue that Orion reported a lot more. I still think the linking issue may be completely orthogonal to HAVE_ADA_2007. You imply above, that lapack/blas are not used by HAVE_ADA_2007 so it appears to me that Orion's discovery of a lapack/blas linking issue must be completely independent of HAVE_ADA_2007. Nope, if I turn HAVE_ADA_2007 off, it compiles fine. Thanks, Orion, for that clarification. The rest of this is principally directed to Jerry. Jerry, given that clarification does that firm up your idea of removing HAVE_ADA_2007 because the benefit is rather small for the cost of the the extra lapack/blas dependencies? The rest of this assumes you want to make that change. As far as the build system is concerned, all you have to do to completely disable HAVE_ADA_2007 is to replace option(HAVE_ADA_2007 Ada 2007? OFF) with set(HAVE_ADA_2007 OFF CACHE BOOL Ada 2007? FORCE) in cmake/modules/ada.cmake. The effect of that last command is to force the OFF value regardless of what the user attempts to set. After that, at your leisure, you can remove any HAVE_ADA_2007 configuration dependencies in the bindings and examples and also in the build system. To help you with that effort, here are the current places where HAVE_ADA_2007 shows up in our source tree. softw...@raven find -type f |grep -v .svn| \ grep -v '~$' |xargs grep -l HAVE_ADA_2007 ./doc/docbook/src/ada.xml ./bindings/ada/README.rtf ./bindings/ada/README ./cmake/modules/ada.cmake All of those except ada.cmake are documentation. Looking at that file further, it sets Ada_Is_2007_With_and_Use_Numerics if HAVE_ADA_2007 is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. Those variables show up in the following places in our source tree : softw...@raven find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort ./bindings/ada/plplot.adb.cmake ./bindings/ada/plplot.ads.cmake ./bindings/ada/plplot_auxiliary.ads.cmake ./bindings/ada/plplot_thin.ads.cmake ./bindings/ada/plplot_traditional.adb.cmake ./bindings/ada/plplot_traditional.ads.cmake ./cmake/modules/ada.cmake ./examples/ada/x01a.adb.cmake ./examples/ada/x31a.adb.cmake ./examples/ada/xthick01a.adb.cmake ./examples/ada/xthick31a.adb.cmake softw...@raven find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort ./bindings/ada/plplot_auxiliary.ads.cmake ./cmake/modules/ada.cmake I would advise editing all the above *.cmake files to get rid of the references to the variables Ada_Is_2007_With_and_Use_Numerics Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is completed and you have tested it works then you should commit those changes. After that commit I can take over and do the necessary further changes to make those files non-configurable (from the CMake point of view), rename them without the *.cmake index in such a way that we do not lose svn history of those files, and commit all those further changes in such a way that we don't temporarily break PLplot. (That last issue has recently become important since we are using bisect methods to find regressions more and more, and commits that break PLplot interfere with that process unless you laboriously identify all such commits to the svn-bisect software.) Alan __ Alan W. Irwin Alan, I have just committed the changes that you describe--all affected Ada files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a (normal) build here but I have succeeded in doing my own private build in my own development system (which bypasses all of the PLplot build stuff) so I know the Ada code is OK. I hope you can make the changes at your end because I suspect that otherwise the build will fail (unless the ada.cmake edit overrides all new evil). Jerry I suppose I should update this slightly old thread. I have made changes to the documentation and added suitable comments to the Ada code but I suppose I shouldn't assume that anyone has read it yet. The problem, in part, arose from some difficulty with at least some Linux distros having trouble linking to BLAS and LAPACK. (There has recently been someone else commenting on comp.lang.ada in a non-PLplot context of similar problems.) I then decided that it probably wasn't worth the hassle to link to those Ada 2005 specific libraries anyway since only two type declarations were being used. I then inserted my own versions of those declarations so that all Ada builds now should
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 22, 2010, at 11:16 PM, Alan W. Irwin wrote: On 2010-07-22 14:29-0700 Jerry wrote: On Jul 22, 2010, at 10:07 AM, Alan W. Irwin wrote: I will now strip out all this configuration machinery so that the template files are treated directly as source files with no need to copy them. A beneficial side benefit of that change is I will be able to rename all of them without the .cmake suffix. This strip out will take some time and care, but I hope to finish it (with similar good test results as above) by late today. DONE as of revision 11101. Good to hear. I'll check out the problem with adathick but possibly not for 2-3 weeks as I'm planning to be away for a while. Actually, there is no problem with adathick (except that something in our mailpath wrapped the text summarizing the perfect test results in a funny way that lead you to believe there was an adathick error). So that leaves two remaining issues from this mini-project which I hope you will deal with after your break. (1) The documentation needs updating consistent with these changes. From my previous post on this issue: quote softw...@raven find -type f |grep -v .svn| \ grep -v '~$' |xargs grep -l HAVE_ADA_2007 ./doc/docbook/src/ada.xml ./bindings/ada/README.rtf ./bindings/ada/README ./cmake/modules/ada.cmake Indeed it needs updating. And I'll remove some of the docs in / bindings/ada/ because everything that is there is also now (and for quite a while) in the main docs where it is updated better. All of those except ada.cmake are documentation. /quote (2) Please try the PLplot build and test system with Ada to make sure it works for you on Mac OS X. You mentioned you were currently using some specialized build system instead, but that doesn't help us find PLplot build-system issues for the combination of Ada and Mac OS X (if those exist) and also doesn't allow you to run our usual Ada-related tests on Mac OS X. Thus, I hope you are willing to keep trying the PLplot build and test system with Ada on Mac OS X and reporting back any issues you encounter. My impression is we don't have that many testers of the Ada bindings and examples for PLplot on Mac OS X, and that platform has a large number of configuration possibilities in any case considering all the fink and macport possibilities as well as the various possibilities for official Mac APIs (cocoa, carbon, etc.) so we need every tester we can get for that platform especially for less popular languages like Ada. I do normal PLplot builds fairly often and always before I commit changes. I just now did a sucessful build so everything looks good here. Jerry For the same reasons I would appreciate others here with access to Mac OS X to always include Ada in their tests (especially after such a comprehensive change as the current one which touched virtually all Ada files). 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 22, 2010, at 10:07 AM, Alan W. Irwin wrote: On 2010-07-22 04:09-0700 Jerry wrote: On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: After that commit I can take over and do the necessary further changes to make those files non-configurable (from the CMake point of view), rename them without the *.cmake index in such a way that we do not lose svn history of those files, and commit all those further changes in such a way that we don't temporarily break PLplot. (That last issue has recently become important since we are using bisect methods to find regressions more and more, and commits that break PLplot interfere with that process unless you laboriously identify all such commits to the svn-bisect software.) Alan, I have just committed the changes that you describe--all affected Ada files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a (normal) build here but I have succeeded in doing my own private build in my own development system (which bypasses all of the PLplot build stuff) so I know the Ada code is OK. I hope you can make the changes at your end because I suspect that otherwise the build will fail (unless the ada.cmake edit overrides all new evil). Thanks, Jerry. Despite your concern, the build and test continue to work fine after your changes. For example, on Linux make test_diff_psc produces this result: ada Missing examples: Differing postscript output : Missing stdout : Differing stdout: adathick Missing examples: Differing postscript output : Missing stdout : Differing stdout: The reason why it works is you have simply removed all configurable @whatever@ strings from the Ada files, but CMake configures those files anyway as a pure copy of the template file. And then the build and test proceeds as normal using those copied files as source. I will now strip out all this configuration machinery so that the template files are treated directly as source files with no need to copy them. A beneficial side benefit of that change is I will be able to rename all of them without the .cmake suffix. This strip out will take some time and care, but I hope to finish it (with similar good test results as above) by late today. Alan __ Alan W. Irwin Good to hear. I'll check out the problem with adathick but possibly not for 2-3 weeks as I'm planning to be away for a while. Jerry 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 12, 2010, at 11:06 AM, Alan W. Irwin wrote: On 2010-07-12 10:56-0600 Orion Poplawski wrote: On 07/08/2010 06:43 PM, Jerry wrote: On Jul 8, 2010, at 9:37 AM, Orion Poplawski wrote: gcc 4.5 just landed in Fedora rawhide. Now getting the following error building Ada examples. Looks like we may need to add -llapack to the link, but not sure where this should be done. GNAT (GNU Ada Translator) 2005 and 2012 require LAPACK and BLAS libraries to implement certain numeric functionality. I'm not sure where in the gcc series this entered but I think it was 4.3. In the Ada Reference Manual this functionality is described in Annex G.3. You might have both C and Fortran versions of these libraries--OS X does. Ada can handle either (in principle) and I don't think it matters which one is used. I don't know which is currently being linked on OS X without looking into it. (Actually, I think OS X puts them both into the same framework which could mean in the same library.) There is a build flag in PLplot to indicate the presence or absence of Ada 2005 (versus Ada 95) but we should probably move towards using it when possible as this compiler becomes more widespread. In PLplot, there is minimal usage of this functionality--only some type declarations for arrays of floating point numbers. If the flag for Ada 2005 is not set, cmake causes these declarations to be made in the bindings themselves. So if you don't want to link the libraries, you should be able to proceed with PLplot by adjusting the flag. It seems to me then that if I specify Ada 2005(7), the plplot build system should add lapack and blas to the appropriate link command. The current situation is more primitive than that (see ada.cmake). If you specify HAVE_ADA_2007, then our Ada interface takes advantage of certain limited Ada 2005 capabilities, but there is no check that the Ada compiler has such capabilities, and that option certainly has nothing directly to do with whether the Ada compiler requires lapack/blas or not. Ideally, what we would like to do is an Ada version check to see whether the current version is greater than or equal to the first version (4.5?) where lapack/blas need to be linked in and the first version (4.0?) which has the limited Ada 2005 capabilities required by HAVE_ADA_2007. I guess it's irrelevant now, but for what it's worth, the answers from the oracle are, respectively, 4.3 and 4.2. Jerry Once we have those version checks implemented, no intervention by the user will be required, and we can simply do the right thing (link in lapack/blas when needed, and set HAVE_ADA_2007 when possible). I am willing to add those version checks with 4.5 and 4.0 tentatively used for the two separate version limits, but, Jerry, can you get me more refined numbers for those limits (especially the last one which is just a crude guess on my part at this time)? 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 13, 2010, at 12:21 AM, Alan W. Irwin wrote: On 2010-07-12 19:44-0700 Jerry wrote: I'm beginning to have second thoughts about whether this HAVE_ADA_2007 business is worth the trouble. If the flag is not set, the Ada bindings still work fine if the compiler is Ada 95 or Ada 2005. None of the lapack and blas stuff is actually used--only two lines of declarations are used from the Ada modules and these are already inserted into the bindings if the flag is not set. I think maybe requiring the linking of these large libraries is a bad idea and that I over-engineered the bindings just to get the two declarations in the case of 2005. How much work would it be to just remove this flag? I think very little effort would be required to remove HAVE_ADA_2007 from the build system. However, let's wait to do anything about this until we understand the linking issue that Orion reported a lot more. I still think the linking issue may be completely orthogonal to HAVE_ADA_2007. You imply above, that lapack/blas are not used by HAVE_ADA_2007 so it appears to me that Orion's discovery of a lapack/blas linking issue must be completely independent of HAVE_ADA_2007. Alan __ Alan W. Irwin No. Orion's result which he reports in the next e-mail is correct and expected. If the HAVE_ADA_2007 flag is set then something in the build process, probably cmake, modifies some Ada files by inserting this declaration: with Ada.Numerics.Long_Real_Arrays; This is somewhat analogous to an include statement in C. Once Ada.Numerics.Long_Real_Arrays is with-ed, the compiler knows that it is supposed to link blas and lapack because a primary function of that package is to provide some quasi-advanced numerics such as finding eigenvectors/eigenvalues and solving Ax=b, etc. (Yes, this is really an official part of Ada now.) PLplot of course needs none of this numeric capability; the only thing that I used from the Ada.Numerics.Long_Real_Arrays package are a couple of convenient (and now standardized) declarations for vectors and matrices which of course are just one- and two-dimensional arrays of double floats of indeterminate sizes. (It occurs to me that this type of discussion might require a knowledge of Ada namespaces which might be different from C namespaces, if C actually has such a concept--that's beyond my C knowledge.) If the flag is not set, then cmake mucks with some of the Ada files to insert equivalent vector and matrix declarations but does not insert the reference to Ada.Numerics.Long_Real_Arrays; thus the compiler has no need to link lapack and blas. Hope that makes sense. Jerry 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote: On 2010-07-13 09:47-0600 Orion Poplawski wrote: On 07/13/2010 01:21 AM, Alan W. Irwin wrote: I think very little effort would be required to remove HAVE_ADA_2007 from the build system. However, let's wait to do anything about this until we understand the linking issue that Orion reported a lot more. I still think the linking issue may be completely orthogonal to HAVE_ADA_2007. You imply above, that lapack/blas are not used by HAVE_ADA_2007 so it appears to me that Orion's discovery of a lapack/blas linking issue must be completely independent of HAVE_ADA_2007. Nope, if I turn HAVE_ADA_2007 off, it compiles fine. Thanks, Orion, for that clarification. The rest of this is principally directed to Jerry. Jerry, given that clarification does that firm up your idea of removing HAVE_ADA_2007 because the benefit is rather small for the cost of the the extra lapack/blas dependencies? Yes. The rest of this assumes you want to make that change. As far as the build system is concerned, all you have to do to completely disable HAVE_ADA_2007 is to replace option(HAVE_ADA_2007 Ada 2007? OFF) with set(HAVE_ADA_2007 OFF CACHE BOOL Ada 2007? FORCE) in cmake/modules/ada.cmake. The effect of that last command is to force the OFF value regardless of what the user attempts to set. After that, at your leisure, you can remove any HAVE_ADA_2007 configuration dependencies in the bindings and examples and also in the build system. To help you with that effort, here are the current places where HAVE_ADA_2007 shows up in our source tree. softw...@raven find -type f |grep -v .svn| \ grep -v '~$' |xargs grep -l HAVE_ADA_2007 ./doc/docbook/src/ada.xml ./bindings/ada/README.rtf ./bindings/ada/README ./cmake/modules/ada.cmake All of those except ada.cmake are documentation. Looking at that file further, it sets Ada_Is_2007_With_and_Use_Numerics if HAVE_ADA_2007 is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise. Those variables show up in the following places in our source tree : softw...@raven find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort ./bindings/ada/plplot.adb.cmake ./bindings/ada/plplot.ads.cmake ./bindings/ada/plplot_auxiliary.ads.cmake ./bindings/ada/plplot_thin.ads.cmake ./bindings/ada/plplot_traditional.adb.cmake ./bindings/ada/plplot_traditional.ads.cmake ./cmake/modules/ada.cmake ./examples/ada/x01a.adb.cmake ./examples/ada/x31a.adb.cmake ./examples/ada/xthick01a.adb.cmake ./examples/ada/xthick31a.adb.cmake softw...@raven find -type f | grep -v .svn | grep -v '~$' | \ xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort ./bindings/ada/plplot_auxiliary.ads.cmake ./cmake/modules/ada.cmake I would advise editing all the above *.cmake files to get rid of the references to the variables Ada_Is_2007_With_and_Use_Numerics Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is completed and you have tested it works then you should commit those changes. OK. I think I can handle the edit to ada.cmake and to the Ada sources. And it will be nice to have the Ada source in SVN actually be Ada again. Jerry After that commit I can take over and do the necessary further changes to make those files non-configurable (from the CMake point of view), rename them without the *.cmake index in such a way that we do not lose svn history of those files, and commit all those further changes in such a way that we don't temporarily break PLplot. (That last issue has recently become important since we are using bisect methods to find regressions more and more, and commits that break PLplot interfere with that process unless you laboriously identify all such commits to the svn-bisect software.) 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 12, 2010, at 11:06 AM, Alan W. Irwin wrote: On 2010-07-12 10:56-0600 Orion Poplawski wrote: On 07/08/2010 06:43 PM, Jerry wrote: On Jul 8, 2010, at 9:37 AM, Orion Poplawski wrote: gcc 4.5 just landed in Fedora rawhide. Now getting the following error building Ada examples. Looks like we may need to add -llapack to the link, but not sure where this should be done. GNAT (GNU Ada Translator) 2005 and 2012 require LAPACK and BLAS libraries to implement certain numeric functionality. I'm not sure where in the gcc series this entered but I think it was 4.3. In the Ada Reference Manual this functionality is described in Annex G.3. You might have both C and Fortran versions of these libraries--OS X does. Ada can handle either (in principle) and I don't think it matters which one is used. I don't know which is currently being linked on OS X without looking into it. (Actually, I think OS X puts them both into the same framework which could mean in the same library.) There is a build flag in PLplot to indicate the presence or absence of Ada 2005 (versus Ada 95) but we should probably move towards using it when possible as this compiler becomes more widespread. In PLplot, there is minimal usage of this functionality--only some type declarations for arrays of floating point numbers. If the flag for Ada 2005 is not set, cmake causes these declarations to be made in the bindings themselves. So if you don't want to link the libraries, you should be able to proceed with PLplot by adjusting the flag. It seems to me then that if I specify Ada 2005(7), the plplot build system should add lapack and blas to the appropriate link command. The current situation is more primitive than that (see ada.cmake). If you specify HAVE_ADA_2007, then our Ada interface takes advantage of certain limited Ada 2005 capabilities, but there is no check that the Ada compiler has such capabilities, and that option certainly has nothing directly to do with whether the Ada compiler requires lapack/blas or not. Ideally, what we would like to do is an Ada version check to see whether the current version is greater than or equal to the first version (4.5?) where lapack/blas need to be linked in and the first version (4.0?) which has the limited Ada 2005 capabilities required by HAVE_ADA_2007. Once we have those version checks implemented, no intervention by the user will be required, and we can simply do the right thing (link in lapack/blas when needed, and set HAVE_ADA_2007 when possible). I am willing to add those version checks with 4.5 and 4.0 tentatively used for the two separate version limits, but, Jerry, can you get me more refined numbers for those limits (especially the last one which is just a crude guess on my part at this time)? I've put this to the gurus at comp.lang.ada. I'm beginning to have second thoughts about whether this HAVE_ADA_2007 business is worth the trouble. If the flag is not set, the Ada bindings still work fine if the compiler is Ada 95 or Ada 2005. None of the lapack and blas stuff is actually used--only two lines of declarations are used from the Ada modules and these are already inserted into the bindings if the flag is not set. I think maybe requiring the linking of these large libraries is a bad idea and that I over-engineered the bindings just to get the two declarations in the case of 2005. How much work would it be to just remove this flag? I can fix the binding files (which currently end in .cmake because they are not actually legal Ada files with the @stuff@ in them) which would make people browsing the source code before building it less confused. Jerry 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 8, 2010, at 5:43 PM, Jerry wrote: On Jul 8, 2010, at 9:37 AM, Orion Poplawski wrote: gcc 4.5 just landed in Fedora rawhide. Now getting the following error building Ada examples. Looks like we may need to add -llapack to the link, but not sure where this should be done. GNAT (GNU Ada Translator) 2005 and 2012 require LAPACK and BLAS libraries to implement certain numeric functionality. I'm not sure where in the gcc series this entered but I think it was 4.3. In the Ada Reference Manual this functionality is described in Annex G.3. You might have both C and Fortran versions of these libraries--OS X does. Ada can handle either (in principle) and I don't think it matters which one is used. I don't know which is currently being linked on OS X without looking into it. (Actually, I think OS X puts them both into the same framework which could mean in the same library.) There is a build flag in PLplot to indicate the presence or absence of Ada 2005 (versus Ada 95) but we should probably move towards using it when possible as this compiler becomes more widespread. In PLplot, there is minimal usage of this functionality--only some type declarations for arrays of floating point numbers. If the flag for Ada 2005 is not set, cmake causes these declarations to be made in the bindings themselves. So if you don't want to link the libraries, you should be able to proceed with PLplot by adjusting the flag. To be more clear, even if you have Ada 2005 (which you do, now), you can tell PLplot that you don't and the build process should still work--it's just cmake making slight tweaks to the Ada bindings to insert the array declarations if you say you don't have Ada 2005. Note that pretty much everywhere in PLplot including bindings and docs, Ada 2007 is used instead of Ada 2005 which is my fault. (The Ada 2005 spec was not finalized until early 2007.) I wonder if a global change is possible without wrecking something. Jerry [ 23%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada /usr/ bin/gnatgcc -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -c /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada/x01a.adb -o CMakeFiles/x01a.dir/x01a.o Linking Ada executable x01a cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada /usr/ bin/cmake -E cmake_link_script CMakeFiles/x01a.dir/link.txt --verbose=1 /usr/bin/gnatmake -aI/builddir/build/BUILD/plplot-5.9.6/fedora/ examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aL/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ plplotadad.dir x01a.adb -cargs -largs -rdynamic ../../bindings/ada/ libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/ libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime gcc -c -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada x01a.adb gnatbind -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aO/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ plplotadad.dir -x x01a.ali gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/ libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrfXnn': (.text+0x3585): undefined reference to `dgetrf_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getriXnn': (.text+0x35ed): undefined reference to `dgetri_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrsXnn': (.text+0x3751): undefined reference to `dgetrs_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib
Re: [Plplot-devel] Trouble with Ada and gcc 4.5.0
On Jul 8, 2010, at 9:37 AM, Orion Poplawski wrote: gcc 4.5 just landed in Fedora rawhide. Now getting the following error building Ada examples. Looks like we may need to add -llapack to the link, but not sure where this should be done. GNAT (GNU Ada Translator) 2005 and 2012 require LAPACK and BLAS libraries to implement certain numeric functionality. I'm not sure where in the gcc series this entered but I think it was 4.3. In the Ada Reference Manual this functionality is described in Annex G.3. You might have both C and Fortran versions of these libraries--OS X does. Ada can handle either (in principle) and I don't think it matters which one is used. I don't know which is currently being linked on OS X without looking into it. (Actually, I think OS X puts them both into the same framework which could mean in the same library.) There is a build flag in PLplot to indicate the presence or absence of Ada 2005 (versus Ada 95) but we should probably move towards using it when possible as this compiler becomes more widespread. In PLplot, there is minimal usage of this functionality--only some type declarations for arrays of floating point numbers. If the flag for Ada 2005 is not set, cmake causes these declarations to be made in the bindings themselves. So if you don't want to link the libraries, you should be able to proceed with PLplot by adjusting the flag. Note that pretty much everywhere in PLplot including bindings and docs, Ada 2007 is used instead of Ada 2005 which is my fault. (The Ada 2005 spec was not finalized until early 2007.) I wonder if a global change is possible without wrecking something. Jerry [ 23%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada /usr/ bin/gnatgcc -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -c /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada/x01a.adb -o CMakeFiles/x01a.dir/x01a.o Linking Ada executable x01a cd /builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada /usr/ bin/cmake -E cmake_link_script CMakeFiles/x01a.dir/link.txt --verbose=1 /usr/bin/gnatmake -aI/builddir/build/BUILD/plplot-5.9.6/fedora/ examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aL/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ plplotadad.dir x01a.adb -cargs -largs -rdynamic ../../bindings/ada/ libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime gcc -c -I/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada x01a.adb gnatbind -aI/builddir/build/BUILD/plplot-5.9.6/fedora/examples/ada -aI/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada -aO/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada/CMakeFiles/ plplotadad.dir -x x01a.ali gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 ../../src/libplplotd.so.9.8.0 /usr/lib64/libltdl.so /usr/lib64/ libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so /usr/lib64/libgnat-4.5.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.6/fedora/bindings/ada:/ builddir/build/BUILD/plplot-5.9.6/fedora/src:/builddir/build/BUILD/ plplot-5.9.6/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.6/ fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.6/fedora/lib/qsastime /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrfXnn': (.text+0x3585): undefined reference to `dgetrf_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getriXnn': (.text+0x35ed): undefined reference to `dgetri_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__getrsXnn': (.text+0x3751): undefined reference to `dgetrs_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__orgtrXnn': (.text+0x3881): undefined reference to `dorgtr_' /usr/lib/gcc/x86_64-redhat-linux/4.5.0/adalib//libgnala.a(a- nlrear.o): In function `ada__numerics__long_real_arrays__lapack__steqrXnn': (.text
[Plplot-devel] Link to nowhere on PLplot home page
The link from the PLplot home page http://plplot.sourceforge.net/ from PLplot Release 5.9.6 doesn't go anywhere. The link is http://sourceforge.net/forum/forum.php?forum_id=0 and the page loaded says ERROR No Forum Chosen. Jerry -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Incompatible architectures in building on OS X with 64-bit Ada compiler
This was the thread [Plplot-devel] Linking problem with 64-bit Ada compiler on OS X 10.5.8 Leopard but I've started a new one because the problem actually seems to be a compiler problem Problem summary: I'm trying to build PLplot on OS X Leopard (10.5.8) with a 64-bit Ada compiler. The linker is encountering libraries of non-compatible architectures. I've done a bit of sleuthing on this problem and have discovered a potential explanation, or at least a place to look for problems. In my original post, below, there are three libraries which the linker reports as file is not of required architecture. These libraries are: libplplotd.9.7.0.dylib libcsirocsa.0.0.1.dylib libqsastime.0.0.1.dylib Running lipo -info filename on results in Non-fat file: filename is architecture: x86_64 Non-fat means that it is a single-architecture file, e.g., no 32-bit code in this case. My earlier suspicion of possible problems in the Qt library were wrong. Now, here is a paragraph from lipo. (I'm guessing that lipo is an OS X thing and not Linux.) The linker accepts universal (multiple-architecture) input files, but always creates a thin (single-architecture), standard Mach-O output file. The architecture for the output file is specified using the -arch option. If this option is not used, ld attempts to determine the output architecture by examining the object files in command line order. The first thin architecture determines that of the output file. If no input object file is a thin file, the native 32-bit architecture for the host is used. Here is a SUMMARY of running lipo on the files listed sent to the linker: * All Apple-supplied files are both 32- and 64-bits for both PPC and Intel processors EXCEPT THE CARBON FRAMEWORK WHICH IS 32 BITS AND SHOULD NOT BE LINKED WHEN DOING A 64-BIT BUILD. * All Qt libraries are 32- and 64-bits (Intel). * Two PLplot-built libraries are 32-bit and ONE OF THESE IS FIRST IN THE FILE LIST. The very first file in the file list is reported as 32-bit: Non-fat file: ./qt.cpp.o is architecture: i386 Architectures for the other files in the link list in order but not including the three reported above, are (sorry for mixing path styles): Non-fat file: /usr/local/plplot_build_dir/drivers/CMakeFiles/qt.dir/__/ bindings/qt_gui/plqt.cpp.o is architecture: i386 Architectures in the fat file: /usr/lib/libm.dylib are: ppc7400 ppc64 i386 x86_64 Architectures in the fat file: /Library/Frameworks/QtSvg.framework/ Versions/4/QtSvg are: x86_64 i386 [I'm assuming that all of the other Qt frameworks are the same.] Architectures in the fat file: /System/Library/Frameworks/ Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/ A/CarbonSound are: i386 ppc7400 (There are several frameworks embedded within the main carbon.framework and I believe them to all be 32-bit but I have not checked all of them.) Architectures in the fat file: /usr/lib/libz.dylib are: ppc7400 ppc64 i386 x86_64 Architectures in the fat file: /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/ApplicationServices are: ppc7400 ppc64 i386 x86_64 Architectures in the fat file: /usr/lib/libltdl.dylib are: ppc7400 ppc64 i386 x86_64 Architectures in the fat file: /usr/lib/libdl.dylib are: ppc7400 ppc64 i386 x86_64 The last library in the list is /usr/lib/libm.dylib which appears earlier. I believe that the second occurrence in the list can be removed. On Apr 14, 2010, at 12:53 AM, Jerry wrote: I have just upgraded my Ada compiler (GNAT GPL 2009) because the one I have been using has a small bug. The old version was 32 bits and the new version is 64 bits. I'm on OS X 10.5.8 (Leopard). Bad idea. I've changed the paths in my build script (below) to accommodate the new compiler. cmake sees it. The build goes OK until it hits a linking problem. Here is the problem encountered when linking to a qt library. FWIW, my Qt installation is the OS binary from http://qt.nokia.com/downloads/mac-os-cpp/ . Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /Applications/Programming/ CMake 2.6-2.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/ qt.dir/link.txt --verbose=1 /usr/bin/c++ -bundle -headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o CMakeFiles/qt.dir/__/bindings/qt_gui/ plqt.cpp.o ../src/libplplotd.9.7.0.dylib /usr/lib/libm.dylib - framework QtSvg -framework QtGui -framework Carbon -framework AppKit - framework QtXml -framework QtCore /usr/lib/libz.dylib -framework ApplicationServices /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../ lib/ csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.dylib / usr/lib/libm.dylib ld: warning in ../src/libplplotd.9.7.0.dylib, file is not of required architecture ld: warning in ../lib/csa/libcsirocsa.0.0.1.dylib, file is not of required architecture ld: warning in ../lib/qsastime/libqsastime.0.0.1.dylib, file is not of required
Re: [Plplot-devel] Incompatible architectures in building on OS X with 64-bit Ada compiler
On Apr 16, 2010, at 11:37 AM, David MacMahon wrote: Hi, Jerry, On Apr 16, 2010, at 3:16 , Jerry wrote: * Two PLplot-built libraries are 32-bit and ONE OF THESE IS FIRST IN THE FILE LIST. The very first file in the file list is reported as 32-bit: Non-fat file: ./qt.cpp.o is architecture: i386 How did this file managed to get built as 32-bit only? That's what I don't understand. Is it maybe left over from an old build? I suggest you delete this library The entire build directory is deleted before each build. The files qt.cpp.o and plqt.cpp.o are being re-build each time, as evidenced by their creation dates. and rebuild it with make VERBOSE=1 to capture the commands used to build it. That will probably provide some more clues. Dave Let me know how to create more verbosity if necessary. Here is the part that is causing the problem. I'll attach a text file of the same thing in case the lines get clobbered. I've also attached my build script. Jerry Scanning dependencies of target qt make -f drivers/CMakeFiles/qt.dir/build.make drivers/CMakeFiles/qt.dir/build /Applications/Programming/CMake 2.6-2.app/Contents/bin/cmake -E cmake_progress_report /usr/local/plplot_build_dir/CMakeFiles [ 31%] Building CXX object drivers/CMakeFiles/qt.dir/qt.cpp.o cd /usr/local/plplot_build_dir/drivers /usr/bin/c++ -DHAVE_CONFIG_H -DQT_DLL -DQT_SVG_LIB -DQT_GUI_LIB -DQT_CORE_LIB -Dqt_EXPORTS -fPIC -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/nistcd -I/usr/local/plplot_build_dir -I/usr/local/plplot_build_dir/include -I/Library/Frameworks/QtSvg.framework/Headers -I/Library/Frameworks/QtGui.framework/Headers -I/Library/Frameworks/QtCore.framework/Headers -F/Library/Frameworks -I/Library/Frameworks/phonon.framework/Headers -I/Library/Frameworks/QtXmlPatterns.framework/Headers -I/Library/Frameworks/QtWebKit.framework/Headers -I/Library/Frameworks/QtHelp.framework/Headers -I/Library/Frameworks/QtAssistant.framework/Headers -I/Library/Frameworks/QtDBus.framework/Headers -I/Library/Frameworks/QtTest.framework/Headers -I/usr/include/QtUiTools -I/Library/Frameworks/QtScript.framework/Headers -I/Library/Frameworks/QtSvg.framework/Headers -I/Library/Frameworks/QtXml.framework/Headers -I/Library/Frameworks/QtSql.framework/Headers -I/Library/Frameworks/QtOpenGL.framework/Headers -I/Library/Frameworks/QtNetwork.framework/Headers -I/Library/Frameworks/QtDesigner.framework/Headers -I/Library/Frameworks/QtDesigner.framework/Headers -I/Library/Frameworks/QtAssistant.framework/Headers -I/Library/Frameworks/Qt3Support.framework/Headers -I/Library/Frameworks/QtGui.framework/Headers -I/Library/Frameworks/QtCore.framework/Headers -I/Library/Frameworks/QtCore.framework/Headers -I/usr/local/Qt4.6/mkspecs/default -I/usr/include -DUSINGDLL -o CMakeFiles/qt.dir/qt.cpp.o -c /Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/drivers/qt.cpp /Applications/Programming/CMake 2.6-2.app/Contents/bin/cmake -E cmake_progress_report /usr/local/plplot_build_dir/CMakeFiles 24 [ 33%] Building CXX object drivers/CMakeFiles/qt.dir/__/bindings/qt_gui/plqt.cpp.o cd /usr/local/plplot_build_dir/drivers /usr/bin/c++ -DHAVE_CONFIG_H -DQT_DLL -DQT_SVG_LIB -DQT_GUI_LIB -DQT_CORE_LIB -Dqt_EXPORTS -fPIC -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime -I/Users/jb/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/nistcd -I/usr/local/plplot_build_dir -I/usr/local/plplot_build_dir/include -I/Library/Frameworks/QtSvg.framework/Headers -I/Library/Frameworks/QtGui.framework/Headers -I/Library/Frameworks/QtCore.framework/Headers -F/Library/Frameworks -I/Library/Frameworks/phonon.framework/Headers -I/Library/Frameworks/QtXmlPatterns.framework/Headers -I/Library/Frameworks/QtWebKit.framework/Headers -I/Library/Frameworks/QtHelp.framework/Headers -I/Library/Frameworks/QtAssistant.framework/Headers -I/Library/Frameworks/QtDBus.framework/Headers -I/Library/Frameworks/QtTest.framework/Headers -I/usr/include/QtUiTools -I/Library/Frameworks/QtScript.framework/Headers -I/Library/Frameworks/QtSvg.framework/Headers -I/Library/Frameworks/QtXml.framework/Headers -I/Library/Frameworks/QtSql.framework/Headers -I/Library/Frameworks/QtOpenGL.framework/Headers -I/Library/Frameworks/QtNetwork.framework/Headers -I/Library/Frameworks/QtDesigner.framework/Headers -I/Library/Frameworks/QtDesigner.framework/Headers -I/Library/Frameworks/QtAssistant.framework/Headers -I/Library/Frameworks/Qt3Support.framework/Headers -I/Library/Frameworks/QtGui.framework/Headers -I/Library/Frameworks/QtCore.framework/Headers -I/Library/Frameworks/QtCore.framework
Re: [Plplot-devel] Incompatible architectures in building on OS X with 64-bit Ada compiler
On Apr 16, 2010, at 5:06 PM, David MacMahon wrote: On Apr 16, 2010, at 15:56 , Jerry wrote: /usr/bin/c++ -bundle -headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o CMakeFiles/qt.dir/__/bindings/qt_gui/ plqt.cpp.o ../src/libplplotd.9.7.0.dylib /usr/lib/libm.dylib - framework QtSvg -framework QtGui -framework Carbon -framework AppKit -framework QtXml -framework QtCore /usr/lib/libz.dylib - framework ApplicationServices /usr/lib/libltdl.dylib /usr/lib/ libdl.dylib ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/ libqsastime.0.0.1.dylib /usr/lib/libm.dylib Maybe the -framework Carbon is confusing things? I thought you were using the Cocoa version of Qt, so where does that come from? Dave I am using the Cocoa version of Qt and I have no idea why the Carbon framework is being linked. From my earlier post: * All Apple-supplied files are both 32- and 64-bits for both PPC and Intel processors EXCEPT THE CARBON FRAMEWORK WHICH IS 32 BITS AND SHOULD NOT BE LINKED WHEN DOING A 64-BIT BUILD. I suppose that Carbon is also linked when using Cocoa version of Qt when doing 32-bit builds but it doesn't create a problem then. Is there ever a reason to use the Carbon version of Qt and if not, then maybe PLplot should _never_ link the Carbon Qt. This still doesn't explain why the two PLplot libraries are being built as 32 bit. Jerry -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Linking problem with 64-bit Ada compiler on OS X 10.5.8 Leopard
On Apr 14, 2010, at 12:11 PM, Jerry wrote: Yes, thanks Werner. I re-downloaded the binary yesterday (before I posted to the list) just in case I had accidentally downloaded the wrong thing earlier or there had been an update, but there was no change in my build results. From the page you linked, I downloaded http://get.qt.nokia.com/qt/source/qt-mac-cocoa-opensource-4.6.2.dmg On the page, the line of text right above that says Mac binary package using Cocoa for Mac OS X 10.5 - 10.6 (32-bit and 64-bit) So, I still don't know how to proceed. Is there a tool (otool?) that will tell me the target architecture of these libraries? I'm not even sure it's a Qt thing because the link warnings (cut from my original post) look like this: ld: warning in ../src/libplplotd.9.7.0.dylib, file is not of required architecture ld: warning in ../lib/csa/libcsirocsa.0.0.1.dylib, file is not of required architecture ld: warning in ../lib/qsastime/libqsastime.0.0.1.dylib, file is not of required architecture and the undefined symbols are all plplot things. Jerry On Apr 14, 2010, at 1:45 AM, Werner Smekal wrote: Hi Jerry, I've changed the paths in my build script (below) to accommodate the new compiler. cmake sees it. The build goes OK until it hits a linking problem. Here is the problem encountered when linking to a qt library. FWIW, my Qt installation is the OS binary from http://qt.nokia.com/downloads/mac-os-cpp/ . I'm not 100% sure, but if you have the Carbon version of qt, this might not work with a 64bit compiler (since Carbon is 32bit). You need the Cocoa version of Qt which can be used with 64 bit compilers (as well with 32 bit). This can be downloaded on the same page http://qt.nokia.com/downloads/mac-os-cpp/ but you need to select the cocoa version below. HTH, Werner -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sme...@iap.tuwien.ac.at (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 I have reverted to a 32-bit Ada compiler from sourceforge for OS X Leopard. (This is different than the 32-bit compiler from MacAda.org which I have been using without problems on PLplot but which has the small bug which I mentioned in my original post.) The ld problem is gone and the build completes but testing of the Ada examples fails -- I'll make a separate post for that problem. So the question remains--why does the build process fail with a 64-bit Ada compiler? Jerry with dyld: Library not loaded: @rpath/libgnat-2009.dylib Referenced from: /usr/local/plplot_build_dir/examples/ada/x01a Reason: image not found I get the same missing library complaint when I try to run the Ada examples myself unless I first run export DYLD_LIBRARY_PATH=/usr/local/ada-4.3/lib/gcc/i386-apple- darwin9.7.0/4.3.4/adalib:/usr/local/plplot/lib/ which is normal (I've always done that extra -- or similar-- step to run the Ada examples). However, adding this to my build script has no effect. Neither does adding this: GNAT_LIB=/usr/local/ada-4.3/lib/gcc/i386-apple-darwin9.7.0/4.3.4/adalib/ export GNAT_LIB The strange thing is, the directory containing libgnat-2009.dylib has a symlink named libgnat.dylib which points to it and is found when each of the examples is linked. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Missing Ada (GNAT) library when testing
I have changed my Ada compiler. (As described in a previous note, the
one that I have been using successfully has a small bug which is fixed
in later versions.) For the record, the old compiler was obtained from
MacAda.org, is 32 bits, and runs on OS X 10.5 (Leopard). The new
compiler is from sourceforge, also 32 bits and also running on Leopard.
The PLplot build completes but testing of the Ada examples fails with
this:
Test project /usr/local/plplot_build_dir
Constructing a list of tests
Done constructing a list of tests
Changing directory into /usr/local/plplot_build_dir/plplot_test
2/ 15 Testing examples_ada
Test command: /bin/bash -c EXAMPLES_DIR=/usr/local/plplot_build_dir/
examples\ SRC_EXAMPLES_DIR=/Users/jerrybauck/Documents/Programs/Ada/
Code/Bindings/PLplot/plplot_svn/plplot/examples\ ./plplot-test.sh\ --
verbose\ --device=psc\ --front-end=ada
Test timeout computed to be: 1500
Testing front-end ada
x01
./test_ada.sh: line 32: 5252 Trace/BPT trap $adadir/x$
{index}${lang} -dev $device -o ${OUTPUT_DIR}/x${index}${lang}%n.
$dsuffix $options 2 test.error |${OUTPUT_DIR}/x${index}${lang}_$
{dsuffix}.txt
dyld: Library not loaded: @rpath/libgnat-2009.dylib
Referenced from: /usr/local/plplot_build_dir/examples/ada/x01a
Reason: image not found
-- Process completed
***Failed
0% tests passed, 1 tests failed out of 1
The following tests FAILED:
2 - examples_ada (Failed)
Errors while running CTest
I get the same missing library complaint when I try to run the Ada
examples myself unless I first run
export DYLD_LIBRARY_PATH=/usr/local/ada-4.3/lib/gcc/i386-apple-
darwin9.7.0/4.3.4/adalib:/usr/local/plplot/lib/
which is normal (I've always done that extra -- or similar-- step to
run the Ada examples). However, adding this to my build script has no
effect. Neither does adding this:
GNAT_LIB=/usr/local/ada-4.3/lib/gcc/i386-apple-darwin9.7.0/4.3.4/adalib/
export GNAT_LIB
The strange thing is, the directory containing libgnat-2009.dylib has
a symlink named libgnat.dylib in the same directory which points to it
and is found when each of the examples is linked.
Jerry
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Linking problem with 64-bit Ada compiler on OS X 10.5.8 Leopard
I have just upgraded my Ada compiler (GNAT GPL 2009) because the one I have been using has a small bug. The old version was 32 bits and the new version is 64 bits. I'm on OS X 10.5.8 (Leopard). Bad idea. I've changed the paths in my build script (below) to accommodate the new compiler. cmake sees it. The build goes OK until it hits a linking problem. Here is the problem encountered when linking to a qt library. FWIW, my Qt installation is the OS binary from http://qt.nokia.com/downloads/mac-os-cpp/ . Linking CXX shared module qt.so cd /usr/local/plplot_build_dir/drivers /Applications/Programming/ CMake 2.6-2.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/ qt.dir/link.txt --verbose=1 /usr/bin/c++ -bundle -headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o CMakeFiles/qt.dir/__/bindings/qt_gui/ plqt.cpp.o ../src/libplplotd.9.7.0.dylib /usr/lib/libm.dylib - framework QtSvg -framework QtGui -framework Carbon -framework AppKit - framework QtXml -framework QtCore /usr/lib/libz.dylib -framework ApplicationServices /usr/lib/libltdl.dylib /usr/lib/libdl.dylib ../lib/ csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/libqsastime.0.0.1.dylib / usr/lib/libm.dylib ld: warning in ../src/libplplotd.9.7.0.dylib, file is not of required architecture ld: warning in ../lib/csa/libcsirocsa.0.0.1.dylib, file is not of required architecture ld: warning in ../lib/qsastime/libqsastime.0.0.1.dylib, file is not of required architecture Undefined symbols: _plgesc, referenced from: QtPLDriver::getTextPicture(unsigned int, unsigned int*, int, double)in plqt.cpp.o _plOpenFile, referenced from: plD_init_rasterqt(PLStream*) in qt.cpp.o plD_init_svgqt(PLStream*) in qt.cpp.o plD_init_epspdfqt(PLStream*) in qt.cpp.o _plP_setphy, referenced from: plD_init_rasterqt(PLStream*) in qt.cpp.o plD_init_svgqt(PLStream*) in qt.cpp.o plD_init_epspdfqt(PLStream*) in qt.cpp.o plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o _plGetFam, referenced from: plD_bop_bmpqt(PLStream*) in qt.cpp.o plD_bop_jpgqt(PLStream*) in qt.cpp.o plD_bop_pngqt(PLStream*) in qt.cpp.o plD_bop_ppmqt(PLStream*) in qt.cpp.o plD_bop_tiffqt(PLStream*) in qt.cpp.o plD_bop_svgqt(PLStream*) in qt.cpp.o plD_bop_epspdfqt_helper(PLStream*, int) in qt.cpp.o _plP_setpxl, referenced from: plD_init_rasterqt(PLStream*) in qt.cpp.o plD_init_svgqt(PLStream*) in qt.cpp.o plD_init_epspdfqt(PLStream*) in qt.cpp.o plD_init_qtwidget(PLStream*) in qt.cpp.o plD_init_extqt(PLStream*) in qt.cpp.o _plP_fci2hex, referenced from: QtPLDriver::getFont(unsigned int)in plqt.cpp.o QtPLDriver::getFont(unsigned int)in plqt.cpp.o QtPLDriver::getFont(unsigned int)in plqt.cpp.o _plwarn, referenced from: qt_family_check(PLStream*) in qt.cpp.o _c_plparseopts, referenced from: plsetqtdev(QtExtWidget*, int, char**)in plqt.cpp.o _c_plcalc_world, referenced from: QtExtWidget::mouseMoveEvent(QMouseEvent*)in plqt.cpp.o QtExtWidget::mouseReleaseEvent(QMouseEvent*)in plqt.cpp.o _plFamInit, referenced from: plD_init_rasterqt(PLStream*) in qt.cpp.o plD_init_svgqt(PLStream*) in qt.cpp.o plD_init_epspdfqt(PLStream*) in qt.cpp.o _plParseDrvOpts, referenced from: plD_init_rasterqt(PLStream*) in qt.cpp.o plD_init_svgqt(PLStream*) in qt.cpp.o plD_init_epspdfqt(PLStream*) in qt.cpp.o plD_init_qtwidget(PLStream*) in qt.cpp.o _c_plgfci, referenced from: QtPLDriver::drawText(PLStream*, EscText*) in plqt.cpp.o QtPLWidget::drawText(PLStream*, EscText*) in plqt.cpp.o _plsc, referenced from: _plsc$non_lazy_ptr in qt.cpp.o _plsc$non_lazy_ptr in plqt.cpp.o _plRotationShear, referenced from: QtPLDriver::drawText(PLStream*, EscText*) in plqt.cpp.o QtPLWidget::drawText(PLStream*, EscText*) in plqt.cpp.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [drivers/qt.so] Error 1 make[1]: *** [drivers/CMakeFiles/qt.dir/all] Error 2 make: *** [all] Error 2 Here is the build script: #!/bin/bash # Set environment so that cmake can find the Ada compiler, BLAS, and LAPACK. # Following used for OS X 10.5 with MacAda 32-bit compiler. #CMAKE_LIBRARY_PATH=/usr/local/ada-4.3/lib/gcc/i686-apple- darwin9/4.3.0/adalib:\ #/usr/lib/libblas.dylib:\ #/usr/lib/liblapack.dylib:\ #/usr/lib/libtcl.dylib:\ #/usr/lib/libtk.dylib # Following used for OS X 10.5 with GNAT GPL 2009 64-bit installed April 13, 2010. CMAKE_LIBRARY_PATH=/usr/local/ada-4.3/lib/gcc/x86_64-apple- darwin9.6.0/4.3.4/adalib:\ /usr/lib/libblas.dylib:\ /usr/lib/liblapack.dylib:\ /usr/lib/libtcl.dylib:\
Re: [Plplot-devel] Linking problem with 64-bit Ada compiler on OS X 10.5.8 Leopard
Yes, thanks Werner. I re-downloaded the binary yesterday (before I posted to the list) just in case I had accidentally downloaded the wrong thing earlier or there had been an update, but there was no change in my build results. From the page you linked, I downloaded http://get.qt.nokia.com/qt/source/qt-mac-cocoa-opensource-4.6.2.dmg On the page, the line of text right above that says Mac binary package using Cocoa for Mac OS X 10.5 - 10.6 (32-bit and 64-bit) So, I still don't know how to proceed. Is there a tool (otool?) that will tell me the target architecture of these libraries? I'm not even sure it's a Qt thing because the link warnings (cut from my original post) look like this: ld: warning in ../src/libplplotd.9.7.0.dylib, file is not of required architecture ld: warning in ../lib/csa/libcsirocsa.0.0.1.dylib, file is not of required architecture ld: warning in ../lib/qsastime/libqsastime.0.0.1.dylib, file is not of required architecture and the undefined symbols are all plplot things. Jerry On Apr 14, 2010, at 1:45 AM, Werner Smekal wrote: Hi Jerry, I've changed the paths in my build script (below) to accommodate the new compiler. cmake sees it. The build goes OK until it hits a linking problem. Here is the problem encountered when linking to a qt library. FWIW, my Qt installation is the OS binary from http://qt.nokia.com/downloads/mac-os-cpp/ . I'm not 100% sure, but if you have the Carbon version of qt, this might not work with a 64bit compiler (since Carbon is 32bit). You need the Cocoa version of Qt which can be used with 64 bit compilers (as well with 32 bit). This can be downloaded on the same page http://qt.nokia.com/downloads/mac-os-cpp/ but you need to select the cocoa version below. HTH, Werner -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sme...@iap.tuwien.ac.at (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Cairo and Hershey
On Mar 22, 2010, at 12:28 AM, Alan W. Irwin wrote: On 2010-03-21 23:22-0700 David MacMahon wrote: FWIW, I get a square bullet on the xcairo device for symbol 850 on Mac OS X. This is the same glyph that gucharmap shows for unicode symbol 0x2219 in the symbol font. Some other fonts have round bullets for this symbol. Can one specify a font for use with plsym? For our modern unicode font handling we only specify the most generic information (sans font, serif font, etc.) and let other libraries (e.g., fontconfig) do their work which is to find the best font glyph that represents that unicode symbol from the selection of system fonts in the generic class (sans or whatever) that we specify. So the proper thing to do here is to use gucharmap to find a glyph that you like. If you search for bullet operator there you will find 0x2219. If you then look at the generic sans font, fontconfig will pick something that has a high weight in the fontconfig configuration. In my case, that is DejaVu Sans (right click on the symbol to see the actual font being selected for the gucharmap display). That renders a square glyph here. However, if you choose generic serif instead, the font actually chosen (here) is DejaVu Serif, and that renders a circular glyph here. Were your above results for generic sans, generic serif, or something more specific? For best match with what our cairo and qt device drivers do, always use the generic gucharmap font choices. I suspect the simple answer to Jerry's original question is he was using sans when he should have being specifying serif. Another possibility is that U+2219 BULLET OPERATOR is not really what he wants. In that case he should try some of the other cross-references given by guchapmap in the character details for bullet operator e.g., • U+00B7 MIDDLE DOT • U+2022 BULLET • U+2024 ONE DOT LEADER Or he might just want to use the gucharmap search function for bullet or dot or circle. For example, if he just wanted a black circle, then the find function in gucharmap should quickly find U+25CF BLACK CIRCLE. Let's say, he likes the look of that with generic sans and/or serif. Then he could follow example 23 (or the documentation) about how to specify 0x25CF with a PLplot escape sequence. It could also cut and paste any glyph from gucharmap directly into his code (which actually copies the UTF-8 string for that glyph into his code). The PLplot library knows exactly what to do with UTF-8 input strings (examples 24 and 26 use this method), and the result should be exactly the same as what can be seen with gucharmap. Bottom line here, I think the gucharmap application is a wonderful application in general and also a wonderful adjunct to PLplot. It makes sense of what is going on with the system font choices for each glyph and it also makes it easy to choose PLplot symbols by using a PLplot escape sequence (the example 23 method) or UTF-8 directly (by cutting and pasting, the method used in examples 24 and 26). I hope these remarks help Jerry and anyone else who is looking for special glyphs they want to put into their PLplot strings. 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); PLplot scientific plotting software package (plplot.org); 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 __ Thanks, Alan. Jerry -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Cairo and Hershey
I was just trying to use the Hershey symbol 850 which is a solid dot and noticed with the cairo drivers that the wrong symbol is used. Instead of a dot it is a weird character. The same result occurs for all of the cairo devices. Does anybody else have this problem? I'm on OS X. Jerry -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plshade question
On Feb 18, 2010, at 10:14 AM, Alan W. Irwin wrote: On 2010-02-17 21:06-0800 David MacMahon wrote: Hi Dave: I left out your other questions because I am confused on those issues as well. However, assuming you get them figured out, I would appreciate it if you took some additional time to update the relevant docbook documentation to help relieve everybody's confusion on these matters. Since defined does not have a corresponding user data pointer, it seems that whether a point is defined or not must be determinable solely from the x,y coordinates themselves and not from the 2D data values (or accompanying data valid flags array). Is the primary intent of this to limit the region that is shaded (kind if like kx,lx,ky,ly for plcont, but in world coordinates rather than 2D data indices)? I can help you out a bit with this one. There is an example of how defined is used in the C version of example 16. And, FWIW, I think we should have adopted a more general API for defined. However, I guess nobody cares too much about it because of its limitations. For example, the defined part of example 16 looks pretty good at normal resolution, but you get a real mess at lower resolutions. Thus, I don't think there is any language interface that currently propagates what C does with defined, and I suggest you skip it for Ruby as well. FWIW, the Ada bindings handle this and it is now working in Ada examples 16 after I repaired some errors in what was formerly commented-out code. But the Ada examples don't bother to parse the - exclude option so it is turned on and off by setting a boolean in the code. Jerry Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
On Feb 11, 2010, at 12:59 AM, Alan W. Irwin wrote: Leo mentioned in an earlier plplot-general thread that it was too time consuming to compile Qt on Mac OS X. However, I don't believe compilation is required in this case. According to http://qt.nokia.com/ downloads, there is an SDK version available for Mac OS X. When I tried the corresponding Linux 64-bit SDK, it was a binary with no need to build so I presume that is also true of the Mac OS X SDK. If Leo or anybody else here will confirm that, I will go back and respond to that earlier thread on plplot- general so our Mac OS X users don't get unnecessarily intimidated about installing Qt. Yes--my installation of Qt on OS X was from a binary. Jerry -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Clipped plots using epsqt and pdfqt on OS X
Output from any example using epsqt and pdfqt on OS X clip the right 20% or so of the figure. The black background is rotated 90 degrees from what it should be. It's as if the figure is in landscape mode and the black background is in portrait mode and the figure is being clipped by the background where it spills over. Jerry -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Example 30, page 2, using psc is messed up on OS X
The second page of example 30 using the psc driver on OS X is a giant red near-rectangle with a bit of black border. The red rectangle is actually made up of a whole lot of small overlapping red rectangles. Jerry -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Clipped plots using epsqt and pdfqt on OS X
On Jan 5, 2010, at 1:03 AM, Jerry wrote: Output from any example using epsqt and pdfqt on OS X clip the right 20% or so of the figure. The black background is rotated 90 degrees from what it should be. It's as if the figure is in landscape mode and the black background is in portrait mode and the figure is being clipped by the background where it spills over. Jerry It looks like this for Example 1. (This is a screen capture of the reduced image.) pastedGraphic.pdf Description: Adobe PDF document Jerry-- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Gradient status report
On Dec 2, 2009, at 12:04 AM, Alan W. Irwin wrote: On 2009-12-01 17:58-0800 Alan W. Irwin wrote: There have been no comments about the plgradient API, and I certainly do not forsee that changing in the future. Therefore, it is time to propagate plgradient to all our languages and adjust examples 25 and 30 accordingly. I have just (revision 10662) completed that process for C++, D, and python, and I plan to follow up with most of the other languages excluding Ada and OCaml where I would appreciate some help with those languages. I'll take care of the Ada part, of course. Jerry Alan __ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Missing documentation for plenv
On Sep 2, 2009, at 11:20 AM, Alan W. Irwin wrote: On 2009-09-02 12:00-0500 Hezekiah M. Carty wrote: I'm still not entirely familiar with how Docbook markup works, but the PDF output looks good here and I think it gets the information across appropriately. Suggestions for improvement in the Docbook code as well as the actual documentation are welcome as always. Hi Hez: Thanks very much for your documentation update. The principal issue to be careful of is make validate finds no errors. (Your latest commit passes this test.) That is a fast and easy method (which requires the onsgmls application be installed but which does not require special configuration of the build) of checking that you haven't introduced some DocBook XML syntax error that will kill everybody's documentation build including the one that Hazen does for releases. It's that potential to kill the build that leads me to give make validate results the highest priority when evaluating patches to or commits of files in doc/docbook/src. The actual content of documentation upgrades is a second priority after that primary one. Basically, I believe we should be happy to take anything that we can get as the first try for documenting some aspect of PLplot; if necessary we can always refine the wording/organization/consistency of form later. Of course, as you have found, DocBook XML is not that hard to learn since you can do a lot simply by analogy with other aspects of the files in doc/docbook/src. Thus, I strongly encourage everybody on this list to send patches or make commits to those files to improve our DocBook documentation. And if some of you don't have onsgmls installed on your system, I am happy to try make validate here and correct any syntax errors it finds in your updates to the documentation. Alan Alan, I found some open-source (and commercial) docbook editors (OS X) that are pretty WYSIWYG--apparently they use some form of rules (schema?) to interpret the code as you edit, so that what you see is similar to what you get when you apply your own rules at rendering time. (Actually, I think OpenOffice.org is supposed to handle Docbook but my version doesn't render anything to the screen; I think I'm missing a plug-in or something.) But I was afraid to try any of them on the PLplot stuff for the very reason you mention--I was afraid it would trash something. Maybe I'll play with them more later. Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Missing documentation for plenv
x19c.c uses 70 as the last argument in plenv, axis, but the documentation does not mention such a value. This was detected by the Ada compiler at compile time. I have made the Ada code accept arguments up to 70 by creating a constant called Undocumented_Feature but I don't know if 70 is high enough or what is the meaning of arguments above 63. I suppose it is in the C code somewhere but I much prefer writing to the documentation rather than reading C which I seem genetically unable to do well. Genetics notwithstanding, the docs should probably be updated. Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Question about the callback in plslabelfunc
In example x19c.c, the callback geolocation_labeler for plslabelfunc has an argument named length which is used only in a call to snprintf. The purpose appears to be to be an input to fix the length of the string formed by snprintf. I can't find where this argument receives a value. Trying to trace the calling chain through the code seems to run in to a dead end pretty quickly. Alternately, how many elements is allocated to the output string, label? Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
On Aug 29, 2009, at 10:30 AM, Alan W. Irwin wrote: To Werner, Hazen, and Jerry: Without decent colour maps, PLplot is pretty useless so colour issues are release critical by definition. Therefore, I hope all three of you with access to OS X will give the current plspal1 issues on Mac OS X that were discovered by Werner your immediate attention. My working copy is in a state where it won't build because I'm working on getting example 19 fixed. I could swap my copy out and look at these color issues but I'd rather get 19 fixed first. Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible Qt issues on OS X
On Aug 24, 2009, at 8:41 PM, Alan W. Irwin wrote: On 2009-08-24 16:13-0700 Jerry wrote: The renderings of Example 1 using pdfqt and epsqt on OS X are attached. Theseare screen shots with a bit of the gray background of the PDF program (aPDFkit application) showing around the edges. pdfqt seems to have orientedthe plots relative to the background 90 degrees, clipping part of the plots.epsqt has a part-black and part- white background. Adobe Reader showed thesame result on the pdfqt file but did not open the epsqt file. (Is EPS notsupported by Adobe Reader?!?). Running ./x09c -dev qtwidget or ./x09c -fam -dev qtwidget causes the firstpage to be drawn only after the Qt program is made the front application(gets focus); subsequent pages are drawn only after hitting RETURN and theneither the window is resized or another application is made the frontapplication. Sorry for being so slow in finding these. What version of Qt4? Here is the summary of the discussion in README.release on Qt4 version issues. In sum, Qt-4.4.3 is worth trying if it is already installed on your machine, but if you run into any difficulty with it please switch to Qt-4.5.x (once Qt-4.5.x is installed all you have to do is to put the 4.5.x version of qmake in your path, and cmake does the rest). If the problem persists for Qt-4.5, then it is worth reporting a qt bug. Follow up on the context of the above quote to see how you can install Qt4.5.x. I get good-looking results with it. Alan I'm using 4.5.2. FWIW, x17c (stripchart) using qtwidget shows only a blank (gray) screen until the stripchart animation has stopped (it seems), then the complete plot is shown as a fixed image. Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ada examples now all give just a red rectangle with no plot
On Aug 22, 2009, at 2:05 PM, Alan W. Irwin wrote: Once plscmap0n(0) gives default colours like before, I suspect all the Ada red issues will go away. Jerry has remarked before that our Ada bindings do their own colour initialization, and my guess is that boils down in the cmap0 case to a call to plscmap0n(0). I didn't absorb all of what Alan wrote on my first and second quick readings, but here is what happens in the Ada initialization. The Ada binding, when initializing package plplot.adb or plplot_traditional.adb, makes several calls to plgcol0 as part of the color map 0 snapshot function--an initial snapshot is taken so that the user can later restore the initial colors if desired. No other calls are made. These calls to plgcol0 take place before plinit (which is normally called from the user program, after Ada package initialization). I did not put plinit into the Ada package initialization because I understood that there are other, optional, pre-initialization set-up calls that the user can make, and these must come before plinit. Except for those, the Ada package initialization could have been made to call plinit, relieving the user of doing that. Jerry -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ada examples now all give just a red rectangle with no plot
My working copy is 10303 and it is OK. The last change to plplot.h was in 10302. Not sure what is happening here. Jerry On Aug 20, 2009, at 12:52 PM, Alan W. Irwin wrote: I presume this has something to do with the recent core cmap[01] changes. Hopefully, the fix can be found in a hurry because I think otherwise this would be a showstopper for the release Alan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ada examples now all give just a red rectangle with no plot
I have just committed the changes to the Ada bindings that implement plspal0 and plspal1; the odd results that Alan and Andrew reported were without those functions implemented. Prior to this commit, there were no calls to either plspal0 or plspal1 in any of the Ada examples. Now, Ada examples 16 call both. I don't see how this can fix the problem, however. Jerry On Aug 21, 2009, at 5:34 AM, Andrew Ross wrote: As a second report, I can confirm that I also see this. Using -cmap0 on the command line to set the default palette cures the problem, so it looks like it is somewhere in the initialisation. This just seems to be an Ada issue, and happens for all the drivers I've tried. This is odd since with the thin bindings Ada should just be making the same plplot calls as all the other languages. Andrew On Fri, Aug 21, 2009 at 02:13:40AM -0700, Jerry wrote: My working copy is 10303 and it is OK. The last change to plplot.h was in 10302. Not sure what is happening here. Jerry On Aug 20, 2009, at 12:52 PM, Alan W. Irwin wrote: I presume this has something to do with the recent core cmap[01] changes. Hopefully, the fix can be found in a hurry because I think otherwise this would be a showstopper for the release Alan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ada examples now all give just a red rectangle with no plot
I now am seeing red also, at version 10314. Comparing SVG files for C and Ada on Example 1: The file sizes are the same; There are 535 differences; Every difference (date excepted) is due to either stroke=#FF or fill=#FF in the Ada-generated file. That's a lot of red. The same experiment on PostScript files: File sizes same 13 differences Every difference is exactly due to 1. 0. 0. C in the Ada-generated file where in the C-generated file there was x y z C where x, y, z are floats of various values. I'm going to take a wild guess that r g b C sets the color in PostScript. Using the -cmap0 option, these files work correctly cmap0_black_on_white.pal cmap0_default.pal cmap0_white_bg.pal whereas this one makes red cmap0_alternate.pal Disassembling the red SVG file for Ada example 1 with a graphics program shows a red rectangle for (I suppose) the background and correctly-drawn plots but all in red. There is no text--no numbers on the axes and no labels--but this is likely due to the graphics program as is complains of missing fonts when I open the file with it. Incidentally, the curve on the lower left-hand plot appears to be too thick--about twice the thickness of the others--but this is also true of the SVG result made with e.g. x01c using either the svg or svgqt drivers. Also, those SVG files displace the data points on the upper two graphs--svgqt upwards and svt downwards, but this is perhaps for another thread. Something happened between I think versions 10303 and 10312 to cause all this red. Jerry On Aug 21, 2009, at 1:19 PM, Jerry wrote: I have just committed the changes to the Ada bindings that implement plspal0 and plspal1; the odd results that Alan and Andrew reported were without those functions implemented. Prior to this commit, there were no calls to either plspal0 or plspal1 in any of the Ada examples. Now, Ada examples 16 call both. I don't see how this can fix the problem, however. Jerry On Aug 21, 2009, at 5:34 AM, Andrew Ross wrote: As a second report, I can confirm that I also see this. Using -cmap0 on the command line to set the default palette cures the problem, so it looks like it is somewhere in the initialisation. This just seems to be an Ada issue, and happens for all the drivers I've tried. This is odd since with the thin bindings Ada should just be making the same plplot calls as all the other languages. Andrew On Fri, Aug 21, 2009 at 02:13:40AM -0700, Jerry wrote: My working copy is 10303 and it is OK. The last change to plplot.h was in 10302. Not sure what is happening here. Jerry On Aug 20, 2009, at 12:52 PM, Alan W. Irwin wrote: I presume this has something to do with the recent core cmap[01] changes. Hopefully, the fix can be found in a hurry because I think otherwise this would be a showstopper for the release Alan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] D bindings (nearly finished) and tests on Mac OS X
I'm working on the Ada. Had a weird cmake problem until I installed Qt--seemed to me like even though I told it not to build for Qt it was trying anyway. Don't know if it was a cmake problem or a Jerry problem but I can once again get a build. (Not all of the Qt devices are working but I'll save that for another day.) Jerry On Aug 18, 2009, at 8:51 AM, Andrew Ross wrote: tcl clearly still needs work, as do ada and ocaml. Otherwise, we're beginning to get all the languages and examples back into shape again ready for the release. Andrew -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ada warnings
I saw these too. Weird thing is, I attributed it to the fact that I recently changed from a PPC box to Intel, both on OS X. Must be a coincidence that they turned up at the same time that I switched boxes. Actually, I'm getting them on 5.9.2 building on Intel where I did not get them with 5.9.2 on PPC. I'll look into this. Jerry On May 6, 2009, at 2:40 AM, Andrew Ross wrote: I'm getting the following ada warnings with gnat 4.3.3. Any chance of an easy fix from the ada gurus? plplot_thin.ads:565:13: warning: subprogram pointer Plfcont.f2eval should have foreign convention plplot_thin.ads:565:13: warning: add Convention pragma to declaration of Plplot_Thin.Function_Evaluator_Pointer_Type at line 153 plplot_thin.ads:1363:67: warning: subprogram pointer Plshade.defined should have foreign convention plplot_thin.ads:1363:67: warning: add Convention pragma to declaration of Plplot_Thin.Mask_Function_Pointer_Type at line 126 plplot_thin.ads:1375:61: warning: subprogram pointer Plshade1.defined should have foreign convention plplot_thin.ads:1375:61: warning: add Convention pragma to declaration of Plplot_Thin.Mask_Function_Pointer_Type at line 126 plplot_thin.ads:1387:68: warning: subprogram pointer Plshades.defined should have foreign convention plplot_thin.ads:1387:68: warning: add Convention pragma to declaration of Plplot_Thin.Mask_Function_Pointer_Type at line 126 Cheers Andrew -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Minor note about Ada status in Ubuntu and possibly elsewhere
On May 5, 2009, at 2:08 AM, Andrew Ross wrote: On Mon, May 04, 2009 at 08:14:31PM -0700, Jerry wrote: I was just poking around on the Ubuntu site and I notice that this statement appears: The ada bindings are currently under development and should be considered experimental. I think the experimental status was lifted some time back, so I wonder after the dust settles from the new release if someone could update (i.e., remove) this notice wherever it appears. Jerry, The reason for this is that Ubuntu pulls the source packages directly from Debian. On Debian we had a lot of trouble with some platforms where Gnu ada was not working / not available and so we marked the packages experimental. It was not just that the plplot ada code was experimental. I will go back and review the situation anyway. Things may have improved. Andrew OK. Thanks, Andrew. Jerry -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] time
On Feb 5, 2009, at 1:50 PM, Alan W. Irwin wrote: Terrence's report of success on his particular Windows platform for what was effectively revision 9458 is most encouraging. Hopefully, the requested further testing on all the different Windows and Mac OS X platforms accessible to our users and developers here will show no further platform issues for revision 9458. Alan Built 9474 OK today on OS X 10.4.11. Jerry -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't run examples in X11 on OS X
On Jan 26, 2009, at 1:57 PM, Hazen Babcock wrote: Jerry wrote: Yesterday I started looking at fixing the Ada stripchart example (17). This has to be run in X11 on the Mac. I discovered that neither it nor a few randomly selected other C and Ada examples now run in X11 on OS X 10.4.11 (Tiger). They used to. I'm not aware of making any changes on my machine or in my build options since they last ran. I get only a black window with nothing drawn in it, and no amount of clicking around or pressing keys has any effect. I seem to recall a discussion about X11 on OS X not long ago but I can't find it in the list archives. (Is there no search function for the archives?) I think this is due to having PTHREAD=ON. However it should be off by default now on OS-X, so I'm not sure why you are seeing this behavior. The relevant thread is xwin / pthread / OS-X started on 1/11/09. -Hazen Thanks, Hazen. It looks like I had not done a build since that was changed, and when I did, I ran into a problem where cmake and the Mac Ada compiler didn't like each other. That problem is now fixed thanks to Alan and the cmake team, and now my X11 runs normally. Jerry -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
