From: Alan W. I. <ir...@be...> - 2010-04-29 21:22:36
|
Here is the current status of our standard examples (from "make test_noninteractive") for all our languages. c++ Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : f77 Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : f95 Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : java Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : octave Missing examples : 19 Differing postscript output : 06 07 28 Missing stdout : Differing stdout : 14 python Missing examples : Differing postscript output : 06 07 15 19 21 Missing stdout : Differing stdout : tcl Missing examples : Differing postscript output : 06 07 15 16 19 21 28 Missing stdout : Differing stdout : 21 perl Missing examples : Differing postscript output : 03 06 07 16 19 25 28 29 30 Missing stdout : Differing stdout : 14 ada Missing examples : Differing postscript output : 06 07 19 28 29 Missing stdout : Differing stdout : adathick Missing examples : Differing postscript output : 06 07 19 28 29 Missing stdout : Differing stdout : ocaml Missing examples : Differing postscript output : 06 07 Missing stdout : Differing stdout : lua Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : d Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : I encourage everyone to help remove these differences before our imminent release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-04-29 21:46:48
|
On 2010-04-29 14:22-0700 Alan W. Irwin wrote: > python > Missing examples : > Differing postscript output : 06 07 15 19 21 > Missing stdout : > Differing stdout : > tcl > Missing examples : > Differing postscript output : 06 07 15 16 19 21 28 > Missing stdout : > Differing stdout : 21 I have looked further at the 15 and 16 issues. Interestingly, the errors for example 15 (empty first page, mostly empty second) are identical for python and tcl. For tcl example 16, the issue is a mostly empty first page. My guess is something got badly clobbered with python and tcl with the recent extensive API additions for either arbitrary organization of 2D data or arbitrary transformation of world coordinates. Dave and Hez, will either/both of you have a look at this? 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-01 16:58:48
|
On 2010-04-29 14:46-0700 Alan W. Irwin wrote: > On 2010-04-29 14:22-0700 Alan W. Irwin wrote: > >> python >> Missing examples : >> Differing postscript output : 06 07 15 19 21 >> Missing stdout : >> Differing stdout : >> tcl >> Missing examples : >> Differing postscript output : 06 07 15 16 19 21 28 >> Missing stdout : >> Differing stdout : 21 > > I have looked further at the 15 and 16 issues. Interestingly, the errors > for example 15 (empty first page, mostly empty second) are identical for > python and tcl. For tcl example 16, the issue is a mostly empty first page. > My guess is something got badly clobbered with python and tcl with the > recent extensive API additions for either arbitrary organization of 2D data > or arbitrary transformation of world coordinates. Dave and Hez, will > either/both of you have a look at this? My apologies to Dave and Hez who may have been looking in the wrong direction due to the above speculation. I should have used svn-bisect right away rather than speculating. That showed the problem was caused by Hez's revision 10895 which just changed 3 lines of plshade.c to remove tests on whether pltr_data was NULL. It turns out those tests are important for both our python and tcl bindings. I reinstated the tests for revision 10959 and the result was substantially improved python and tcl differences (results for examples 15 and 21 became consistent with C for python while results for examples 15 and 16 became consistent with C for tcl). Here are the current python and tcl results in full. python Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : tcl Missing examples : Differing postscript output : 06 07 19 21 28 Missing stdout : Differing stdout : 21 The differences for other bindings were unaffected by revision 10959. For platforms with Tcl 8.5, it is possible that example 21 for Tcl might be consistent with C for revision 10959 because of the good python result for that example. But I don't know for sure because I didn't actually test example 21 for Tcl on my platform; the stdout message for that example was "This example require Tcl 8.5 or later: use of NaNs". Hez, from your revision 10895 commit message you likely just wanted to make it a little easier to use your OCaml bindings. However, this change to ignore the pltr_data tests for NULL obviously affected the python and tcl example results (for reasons I haven't looked into), and our C users may also depend on these tests being made. So if you would like to pursue this idea further, you should try to figure out how to deal with the python and tcl issues and also consider the significance of this change for our C users. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-05-01 18:43:58
|
On Sat, May 1, 2010 at 12:58 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-04-29 14:46-0700 Alan W. Irwin wrote: > >> On 2010-04-29 14:22-0700 Alan W. Irwin wrote: >> >>> python >>> Missing examples : >>> Differing postscript output : 06 07 15 19 21 >>> Missing stdout : >>> Differing stdout : >>> tcl >>> Missing examples : >>> Differing postscript output : 06 07 15 16 19 21 28 >>> Missing stdout : >>> Differing stdout : 21 >> >> I have looked further at the 15 and 16 issues. Interestingly, the errors >> for example 15 (empty first page, mostly empty second) are identical for >> python and tcl. For tcl example 16, the issue is a mostly empty first page. >> My guess is something got badly clobbered with python and tcl with the >> recent extensive API additions for either arbitrary organization of 2D data >> or arbitrary transformation of world coordinates. Dave and Hez, will >> either/both of you have a look at this? > > My apologies to Dave and Hez who may have been looking in the wrong > direction due to the above speculation. I should have used svn-bisect right > away rather than speculating. That showed the problem was caused by Hez's > revision 10895 which just changed 3 lines of plshade.c to remove tests on > whether pltr_data was NULL. It turns out those tests are important for both > our python and tcl bindings. I reinstated the tests for revision 10959 and > the result was substantially improved python and tcl differences (results > for examples 15 and 21 became consistent with C for python while results for > examples 15 and 16 became consistent with C for tcl). Here are the current > python and tcl results in full. > > <cut> > > Hez, from your revision 10895 commit message you likely just wanted to make > it a little easier to use your OCaml bindings. However, this change to > ignore the pltr_data tests for NULL obviously affected the python and tcl > example results (for reasons I haven't looked into), and our C users may also > depend on these tests being made. So if you would like to pursue this idea > further, you should try to figure out how to deal with the python and tcl > issues and also consider the significance of this change for our C users. > Alan, Thank you for looking in to this. My reason for making that change was that it doesn't make sense to me in a general context to require that both arguments are non-NULL - if the pltr function does not require any extra data to be passed in then it seems strange to require a non-NULL pltr_data argument. This holds for any language. This check: if ( pltr == NULL && plsc->coordinate_transform == NULL ) rectangular = 1; had the pltr_data check removed because it causes rendering errors if pltr or plsc->coordinate_transform is defined and the transform is non-rectangular. I ran in to this when generating the example plot I sent to the list with my message about global transform support. If the pltr_data check == NULL check is included then cracks and gaps appear in the shaded contours. The other checks for both pltr and pltr_data lead to similar errors as they will disregard any pltr function which does not require extra data to be passed in. This can lead to some very confusing and difficult to track down bugs in users' plotting code. I don't know Python or Tcl well enough to see where this affects their code, but I think that it is a bug in either the bindings or the relevant Python and Tcl examples if they fail with these changes, particularly when other language bindings seem to handle the change gracefully. Unfortunately I haven't had any luck in the past when trying to build the Python or Tcl bindings on my system. In summary, I think that the changes reverted in revision 10959 are important bug fixes and should be re-applied to PLplot, even though it likely requires changes to the Python and Tcl bindings. Hez |
From: Alan W. I. <ir...@be...> - 2010-05-01 21:31:02
|
On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > Alan, > > Thank you for looking in to this. My reason for making that change > was that it doesn't make sense to me in a general context to require > that both arguments are non-NULL - if the pltr function does not > require any extra data to be passed in then it seems strange to > require a non-NULL pltr_data argument. This holds for any language. > > This check: > > if ( pltr == NULL && plsc->coordinate_transform == NULL ) > rectangular = 1; > > had the pltr_data check removed because it causes rendering errors if > pltr or plsc->coordinate_transform is defined and the transform is > non-rectangular. I ran in to this when generating the example plot I > sent to the list with my message about global transform support. If > the pltr_data check == NULL check is included then cracks and gaps > appear in the shaded contours. > > The other checks for both pltr and pltr_data lead to similar errors as > they will disregard any pltr function which does not require extra > data to be passed in. This can lead to some very confusing and > difficult to track down bugs in users' plotting code. > > I don't know Python or Tcl well enough to see where this affects their > code, but I think that it is a bug in either the bindings or the > relevant Python and Tcl examples if they fail with these changes, > particularly when other language bindings seem to handle the change > gracefully. Unfortunately I haven't had any luck in the past when > trying to build the Python or Tcl bindings on my system. > > In summary, I think that the changes reverted in revision 10959 are > important bug fixes and should be re-applied to PLplot, even though it > likely requires changes to the Python and Tcl bindings. Your arguments above sound like good ones to me, but the problem is that the Python and Tcl bindings are important and long-standing ones that a lot of people use so we don't want to clobber their ability to make shade plots. That regression would become especially critical just before a release. So I think we really do have to fix our Python and Tcl bindings so they are no longer sensitive to dropping the pltr_data checks before we actually did drop those checks. At the same time I realize those pltr_data checks are messing up some interesting uses of your new transformation work. So clearly this is an important issue that we hopefully will be able to solve before the release, and I encourage everyone here with Python and Tcl bindings expertise to help us do that. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-05-03 06:58:26
|
Hi Alan, Hez, I will have a look at the interface for Tcl - the coordinate transformation is a bit roundabout there, as I need a C function to call the actual Tcl procedure for the transformation. Possibly this is causing the empty page. My guess is the same holds for the Python bindings. Regards, Arjen On 2010-05-01 23:30, Alan W. Irwin wrote: > On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > >> Alan, >> >> Thank you for looking in to this. My reason for making that change >> was that it doesn't make sense to me in a general context to require >> that both arguments are non-NULL - if the pltr function does not >> require any extra data to be passed in then it seems strange to >> require a non-NULL pltr_data argument. This holds for any language. >> >> This check: >> >> if ( pltr == NULL && plsc->coordinate_transform == NULL ) >> rectangular = 1; >> >> had the pltr_data check removed because it causes rendering errors if >> pltr or plsc->coordinate_transform is defined and the transform is >> non-rectangular. I ran in to this when generating the example plot I >> sent to the list with my message about global transform support. If >> the pltr_data check == NULL check is included then cracks and gaps >> appear in the shaded contours. >> >> The other checks for both pltr and pltr_data lead to similar errors as >> they will disregard any pltr function which does not require extra >> data to be passed in. This can lead to some very confusing and >> difficult to track down bugs in users' plotting code. >> >> I don't know Python or Tcl well enough to see where this affects their >> code, but I think that it is a bug in either the bindings or the >> relevant Python and Tcl examples if they fail with these changes, >> particularly when other language bindings seem to handle the change >> gracefully. Unfortunately I haven't had any luck in the past when >> trying to build the Python or Tcl bindings on my system. >> >> In summary, I think that the changes reverted in revision 10959 are >> important bug fixes and should be re-applied to PLplot, even though it >> likely requires changes to the Python and Tcl bindings. > > Your arguments above sound like good ones to me, but the problem is that the > Python and Tcl bindings are important and long-standing ones that a lot of > people use so we don't want to clobber their ability to make shade plots. > That regression would become especially critical just before a release. So I > think we really do have to fix our Python and Tcl bindings so they are no > longer sensitive to dropping the pltr_data checks before we actually did > drop those checks. > > At the same time I realize those pltr_data checks are messing up some > interesting uses of your new transformation work. So clearly this is an > important issue that we hopefully will be able to solve before the release, > and I encourage everyone here with Python and Tcl bindings expertise to help > us do that. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@de...> - 2010-05-03 07:05:42
|
Hi Alan, Hez, I had to plough through a myriad of mails, so my response was a bit premature/late. Okay, I see it has been solved. My task will then be to propagate the recent changes to the Fortran 77/95 and Tcl examples, if not done yet. Regards, Arjen On 2010-05-03 08:58, Arjen Markus wrote: > Hi Alan, Hez, > > I will have a look at the interface for Tcl - the coordinate > transformation is a bit roundabout there, as I need a C function > to call the actual Tcl procedure for the transformation. Possibly > this is causing the empty page. My guess is the same holds for > the Python bindings. > > Regards, > > Arjen > > On 2010-05-01 23:30, Alan W. Irwin wrote: >> On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: >> >>> Alan, >>> >>> Thank you for looking in to this. My reason for making that change >>> was that it doesn't make sense to me in a general context to require >>> that both arguments are non-NULL - if the pltr function does not >>> require any extra data to be passed in then it seems strange to >>> require a non-NULL pltr_data argument. This holds for any language. >>> >>> This check: >>> >>> if ( pltr == NULL && plsc->coordinate_transform == NULL ) >>> rectangular = 1; >>> >>> had the pltr_data check removed because it causes rendering errors if >>> pltr or plsc->coordinate_transform is defined and the transform is >>> non-rectangular. I ran in to this when generating the example plot I >>> sent to the list with my message about global transform support. If >>> the pltr_data check == NULL check is included then cracks and gaps >>> appear in the shaded contours. >>> >>> The other checks for both pltr and pltr_data lead to similar errors as >>> they will disregard any pltr function which does not require extra >>> data to be passed in. This can lead to some very confusing and >>> difficult to track down bugs in users' plotting code. >>> >>> I don't know Python or Tcl well enough to see where this affects their >>> code, but I think that it is a bug in either the bindings or the >>> relevant Python and Tcl examples if they fail with these changes, >>> particularly when other language bindings seem to handle the change >>> gracefully. Unfortunately I haven't had any luck in the past when >>> trying to build the Python or Tcl bindings on my system. >>> >>> In summary, I think that the changes reverted in revision 10959 are >>> important bug fixes and should be re-applied to PLplot, even though it >>> likely requires changes to the Python and Tcl bindings. >> Your arguments above sound like good ones to me, but the problem is that the >> Python and Tcl bindings are important and long-standing ones that a lot of >> people use so we don't want to clobber their ability to make shade plots. >> That regression would become especially critical just before a release. So I >> think we really do have to fix our Python and Tcl bindings so they are no >> longer sensitive to dropping the pltr_data checks before we actually did >> drop those checks. >> >> At the same time I realize those pltr_data checks are messing up some >> interesting uses of your new transformation work. So clearly this is an >> important issue that we hopefully will be able to solve before the release, >> and I encourage everyone here with Python and Tcl bindings expertise to help >> us do that. >> >> 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 >> __________________________ >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2010-05-03 05:12:14
|
On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > Alan, > > Thank you for looking in to this. My reason for making that change > was that it doesn't make sense to me in a general context to require > that both arguments are non-NULL - if the pltr function does not > require any extra data to be passed in then it seems strange to > require a non-NULL pltr_data argument. This holds for any language. The Python and Tcl issues are now solved, and the pltr_data tests are now dropped as of revision 10965. Your clear argument for dropping the pltr_data tests was an excellent motivator to deal with these issues. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-05-03 13:46:16
|
On Mon, May 3, 2010 at 1:12 AM, Alan W. Irwin <ir...@be...> wrote: > On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > >> Alan, >> >> Thank you for looking in to this. My reason for making that change >> was that it doesn't make sense to me in a general context to require >> that both arguments are non-NULL - if the pltr function does not >> require any extra data to be passed in then it seems strange to >> require a non-NULL pltr_data argument. This holds for any language. > > The Python and Tcl issues are now solved, and the pltr_data tests are now > dropped as of revision 10965. Your clear argument for dropping the > pltr_data tests was an excellent motivator to deal with these issues. > Alan, Thank you very much for tracking down and fixing these issues! As per our off-list discussion, I just got the Python and Tcl bindings building on my system so I will hopefully be able to be more proactive about at least identifying issues like this in the future. Hez |
From: Andrew R. <and...@us...> - 2010-05-05 22:42:48
|
On Mon, May 03, 2010 at 09:45:50AM -0400, Hezekiah M. Carty wrote: > On Mon, May 3, 2010 at 1:12 AM, Alan W. Irwin <ir...@be...> wrote: > > On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > > > >> Alan, > >> > >> Thank you for looking in to this. ??My reason for making that change > >> was that it doesn't make sense to me in a general context to require > >> that both arguments are non-NULL - if the pltr function does not > >> require any extra data to be passed in then it seems strange to > >> require a non-NULL pltr_data argument. ??This holds for any language. > > > > The Python and Tcl issues are now solved, and the pltr_data tests are now > > dropped as of revision 10965. ??Your clear argument for dropping the > > pltr_data tests was an excellent motivator to deal with these issues. > > > > Alan, > > Thank you very much for tracking down and fixing these issues! As per > our off-list discussion, I just got the Python and Tcl bindings > building on my system so I will hopefully be able to be more proactive > about at least identifying issues like this in the future. One further fallout from this change was the C++ specific extensions to plshade which are exercised by the C++ specific example x01cc. The changes led to a segmentation fault in the example. I have now fixed this up in the C++ bindings. This is shown up by the c++ tests, but nobody had noticed it. So the moral is test early, test often, and be careful about unexpected consequences of seemingly trivial changes. All the fallout from these changes have so far been detected by our test suite which is good! Andrew |
From: Alan W. I. <ir...@be...> - 2010-05-05 23:29:31
|
On 2010-05-05 23:42+0100 Andrew Ross wrote: > On Mon, May 03, 2010 at 09:45:50AM -0400, Hezekiah M. Carty wrote: >> On Mon, May 3, 2010 at 1:12 AM, Alan W. Irwin <ir...@be...> wrote: >>> On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: >>> >>>> Alan, >>>> >>>> Thank you for looking in to this. ??My reason for making that change >>>> was that it doesn't make sense to me in a general context to require >>>> that both arguments are non-NULL - if the pltr function does not >>>> require any extra data to be passed in then it seems strange to >>>> require a non-NULL pltr_data argument. ??This holds for any language. >>> >>> The Python and Tcl issues are now solved, and the pltr_data tests are now >>> dropped as of revision 10965. ??Your clear argument for dropping the >>> pltr_data tests was an excellent motivator to deal with these issues. >>> >> >> Alan, >> >> Thank you very much for tracking down and fixing these issues! As per >> our off-list discussion, I just got the Python and Tcl bindings >> building on my system so I will hopefully be able to be more proactive >> about at least identifying issues like this in the future. > > One further fallout from this change was the C++ specific extensions to > plshade which are exercised by the C++ specific example x01cc. The > changes led to a segmentation fault in the example. I have now fixed > this up in the C++ bindings. This is shown up by the c++ tests, but > nobody had noticed it. > > So the moral is test early, test often, and be careful about unexpected > consequences of seemingly trivial changes. All the fallout from these > changes have so far been detected by our test suite which is good! It is interesting that I didn't see that x01cc segfault in my early tests that originally showed the Tcl and Python issues. Or in my tests after I fixed the Tcl and Python issues. I therefore think this is one of those cases where x01cc segfaults on your platform but not on mine. Anyhow, thanks for doing tests on a platform which triggered the segfault, and thanks for fixing the issue as well. Based on these results, I will expand your moral to this: test early and often and on as many different platforms as possible! 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-06 00:13:10
|
On 2010-05-05 16:29-0700 Alan W. Irwin wrote: > It is interesting that I didn't see that x01cc segfault in my early tests > that originally showed the Tcl and Python issues. Or in my tests after I > fixed the Tcl and Python issues. I therefore think this is one of those > cases where x01cc segfaults on your platform but not on mine. Hmm. I posted too soon. The segfault was there in my test output, but I didn't notice it because x01cc did not have proper error handling in test_cxx.sh(.in) so no make error was generated. I have now fixed that, proved the fix gave the proper make error when a segfault occurred for x01cc prior to your fix, and also confirmed that there is no segfault or associated make error from x01cc after updating to your recent changes. The multiple platform test moral is still correct, however; there are certain segfaults that show up on some platforms and not 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); 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-05-06 06:58:28
|
Hi Alan, On 2010-05-06 02:12, Alan W. Irwin wrote: > > The multiple platform test moral is still correct, however; there are > certain segfaults that show up on some platforms and not others. > I propagated the changes to examples 6 and 7 to F77, F95 and Tcl (the latter not tested yet, but the first two give perfect results - after some repairs to the first round of changes ;) I will commit them later today). But, in the process of testing I came across a rather strange problem: (I ran on Windows XP, with the MinGW GNU compilers) test-drv-info stops with an error of -10356462 (or something similar), thus terminating the build. Restarting the build makes it fail again, but now on the next device. So, by stepping through all configured devices, I was able to build the examples (and hence ferret out the glitches in my changes), but I do not understand the failure as such. Has anyone seen something similar happening? (A first glance at the code did not reveal anything strange - I did notice from running it via tclsh that the program fails on an unknown signal) I will try and investigate what is going on, but I fear it happens somewhere in libtool and that is very much terra incognita for me. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-05-06 14:22:40
|
On 2010-05-06 08:58+0200 Arjen Markus wrote: > [...]in the process of testing I came across a rather strange > problem: > > (I ran on Windows XP, with the MinGW GNU compilers) > test-drv-info stops with an error of -10356462 (or something similar), > thus terminating the build. Restarting the build makes it fail again, > but now on the next device. Hi Arjen: I presume you have done this exact test many times before on this platform. So the question on my mind is what is different about this test compared to your prior ones? For example, do you have the same issue for a PLplot release that you know you have tested before on this platform? This test replication issue is a substantial part of the value of reporting test results at http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot; once you report a working test there then in future if there is some regression you will have recorded in the table the exact revision number and the exact platform that worked before for you. One other extremely puzzling thing about your report is that test-drv-info just does a subset of what the PLplot library does with dynamic devices so if it fails, the PLplot library should also fail to dynamically load the device driver. So why is test-drv-info failing while the PLplot library is (apparently) succeeding? Do the actual PLplot results you get from say the psc device look fine in a PostScript viewer or are they blank or badly rendered? 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 __________________________ |
From: Jerry <lan...@qw...> - 2010-04-29 23:12:34
|
Alan, thanks for this info. Is it possible to briefly summarize the changes that have been made to the C examples and API? I know I can figure this out from slogging through SVN but it would be helpful to have a guide as to what has changed recently. Or has this progress already been recorded somewhere (besides the list)? Jerry On Apr 29, 2010, at 2:22 PM, Alan W. Irwin wrote: > Here is the current status of our standard examples (from "make > test_noninteractive") for all our languages. > > c++ > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > f77 > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > f95 > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > java > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > octave > Missing examples : 19 > Differing postscript output : 06 07 28 > Missing stdout : > Differing stdout : 14 > python > Missing examples : > Differing postscript output : 06 07 15 19 21 > Missing stdout : > Differing stdout : > tcl > Missing examples : > Differing postscript output : 06 07 15 16 19 21 28 > Missing stdout : > Differing stdout : 21 > perl > Missing examples : > Differing postscript output : 03 06 07 16 19 25 28 29 30 > Missing stdout : > Differing stdout : 14 > ada > Missing examples : > Differing postscript output : 06 07 19 28 29 > Missing stdout : > Differing stdout : > adathick > Missing examples : > Differing postscript output : 06 07 19 28 29 > Missing stdout : > Differing stdout : > ocaml > Missing examples : > Differing postscript output : 06 07 > Missing stdout : > Differing stdout : > lua > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > d > Missing examples : > Differing postscript output : 06 07 19 > Missing stdout : > Differing stdout : > > I encourage everyone to help remove these differences before our > imminent > release. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); 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 > __________________________ > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2010-04-30 04:02:13
|
On 2010-04-29 16:12-0700 Jerry wrote: > Alan, thanks for this info. Is it possible to briefly summarize the > changes that have been made to the C examples and API? I know I can > figure this out from slogging through SVN but it would be helpful to > have a guide as to what has changed recently. Or has this progress > already been recorded somewhere (besides the list)? Hi Jerry: The best source is svn. Let's take example 6 which is an easy one. "svn log examples/c/x06c.c" shows the key revision was 10908. So do an svn diff with the revision just before that: svn diff -x -w --revision 10907 examples/c/x06c.c (where -x -w are important options which mean whitespace changes will be ignored by svn diff). The following results are obtained by that command: Index: examples/c/x06c.c =================================================================== --- examples/c/x06c.c (revision 10907) +++ examples/c/x06c.c (working copy) @@ -15,7 +15,7 @@ main( int argc, const char *argv[] ) { char text[10]; - int i, j, k; + int i, j, k, kind_font, font, maxfont; PLFLT x, y; /* Parse and process command line arguments */ @@ -26,6 +26,18 @@ plinit(); + for ( kind_font = 0; kind_font < 2; kind_font++ ) + { + plfontld( kind_font ); + if ( kind_font == 0 ) + maxfont = 1; + else + maxfont = 4; + + for ( font = 0; font < maxfont; font++ ) + { + plfont( font + 1 ); + pladv( 0 ); /* Set up viewport and window */ @@ -68,7 +80,12 @@ } } - plmtex( "t", 1.5, 0.5, 0.5, "PLplot Example 6 - plpoin symbols" ); + if ( kind_font == 0 ) + plmtex( "t", 1.5, 0.5, 0.5, "PLplot Example 6 - plpoin symbols (compact)" ); + else + plmtex( "t", 1.5, 0.5, 0.5, "PLplot Example 6 - plpoin symbols (extended)" ); + } + } plend(); exit( 0 ); } So those two extra loops should be a straightforward change to implement for all instances of example 6 for all our non-C languages. Example 7 changes should be similarly straightforward. Once 6 and 7 are knocked off the remaining differences will look much more tractable. 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 __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-02 02:53:40
|
Alan W. Irwin writes: > On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > > > Alan, > > > > Thank you for looking in to this. My reason for making that change > > was that it doesn't make sense to me in a general context to require > > that both arguments are non-NULL - if the pltr function does not > > require any extra data to be passed in then it seems strange to > > require a non-NULL pltr_data argument. This holds for any language. > > > > This check: > > > > if ( pltr == NULL && plsc->coordinate_transform == NULL ) > > rectangular = 1; > > > > had the pltr_data check removed because it causes rendering errors if > > pltr or plsc->coordinate_transform is defined and the transform is > > non-rectangular. I ran in to this when generating the example plot I > > sent to the list with my message about global transform support. If > > the pltr_data check == NULL check is included then cracks and gaps > > appear in the shaded contours. > > > > The other checks for both pltr and pltr_data lead to similar errors as > > they will disregard any pltr function which does not require extra > > data to be passed in. This can lead to some very confusing and > > difficult to track down bugs in users' plotting code. > > > > I don't know Python or Tcl well enough to see where this affects their > > code, but I think that it is a bug in either the bindings or the > > relevant Python and Tcl examples if they fail with these changes, > > particularly when other language bindings seem to handle the change > > gracefully. Unfortunately I haven't had any luck in the past when > > trying to build the Python or Tcl bindings on my system. > > > > In summary, I think that the changes reverted in revision 10959 are > > important bug fixes and should be re-applied to PLplot, even though it > > likely requires changes to the Python and Tcl bindings. > > Your arguments above sound like good ones to me, but the problem is that the > Python and Tcl bindings are important and long-standing ones that a lot of > people use so we don't want to clobber their ability to make shade plots. > That regression would become especially critical just before a release. So I > think we really do have to fix our Python and Tcl bindings so they are no > longer sensitive to dropping the pltr_data checks before we actually did > drop those checks. > > At the same time I realize those pltr_data checks are messing up some > interesting uses of your new transformation work. So clearly this is an > important issue that we hopefully will be able to solve before the release, > and I encourage everyone here with Python and Tcl bindings expertise to help > us do that. What is the simplest statement of the commumdrum? |
From: Alan W. I. <ir...@be...> - 2010-05-02 03:58:13
|
On 2010-05-01 21:26-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote: > > > > > Alan, > > > > > > Thank you for looking in to this. My reason for making that change > > > was that it doesn't make sense to me in a general context to require > > > that both arguments are non-NULL - if the pltr function does not > > > require any extra data to be passed in then it seems strange to > > > require a non-NULL pltr_data argument. This holds for any language. > > > > > > This check: > > > > > > if ( pltr == NULL && plsc->coordinate_transform == NULL ) > > > rectangular = 1; > > > > > > had the pltr_data check removed because it causes rendering errors if > > > pltr or plsc->coordinate_transform is defined and the transform is > > > non-rectangular. I ran in to this when generating the example plot I > > > sent to the list with my message about global transform support. If > > > the pltr_data check == NULL check is included then cracks and gaps > > > appear in the shaded contours. > > > > > > The other checks for both pltr and pltr_data lead to similar errors as > > > they will disregard any pltr function which does not require extra > > > data to be passed in. This can lead to some very confusing and > > > difficult to track down bugs in users' plotting code. > > > > > > I don't know Python or Tcl well enough to see where this affects their > > > code, but I think that it is a bug in either the bindings or the > > > relevant Python and Tcl examples if they fail with these changes, > > > particularly when other language bindings seem to handle the change > > > gracefully. Unfortunately I haven't had any luck in the past when > > > trying to build the Python or Tcl bindings on my system. > > > > > > In summary, I think that the changes reverted in revision 10959 are > > > important bug fixes and should be re-applied to PLplot, even though it > > > likely requires changes to the Python and Tcl bindings. > > > > Your arguments above sound like good ones to me, but the problem is that the > > Python and Tcl bindings are important and long-standing ones that a lot of > > people use so we don't want to clobber their ability to make shade plots. > > That regression would become especially critical just before a release. So I > > think we really do have to fix our Python and Tcl bindings so they are no > > longer sensitive to dropping the pltr_data checks before we actually did > > drop those checks. > > > > At the same time I realize those pltr_data checks are messing up some > > interesting uses of your new transformation work. So clearly this is an > > important issue that we hopefully will be able to solve before the release, > > and I encourage everyone here with Python and Tcl bindings expertise to help > > us do that. > > What is the simplest statement of the commumdrum? If you apply the following patch Index: src/plshade.c =================================================================== --- src/plshade.c (revision 10959) +++ src/plshade.c (revision 10958) @@ -514,7 +514,7 @@ return; } - if ( (pltr == NULL && plsc->coordinate_transform == NULL) || pltr_data == NULL ) + if ( pltr == NULL && plsc->coordinate_transform == NULL ) rectangular = 1; int_val = shade_max - shade_min; @@ -609,7 +609,7 @@ y[0] = y[3] = iy; y[1] = y[2] = iy + j; - if ( pltr && pltr_data ) + if ( pltr ) { for ( i = 0; i < 4; i++ ) { @@ -668,7 +668,7 @@ } n += i; - if ( pltr && pltr_data ) + if ( pltr ) { for ( i = 0; i < n; i++ ) { in accordance with Hez's arguments above, then plshade and plshades quit working (blank results or one giant triangle result) under certain (but not all) circumstances for the Python and Tcl examples. What has us both puzzled is why does this minor (and probably well-justified) change matter for Tcl and Python but no other bindings? If we can figure out those special circumstance and eliminate them, then we can go ahead with the above cleanup which also benefits Hez's new transformation work. 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 __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-02 04:09:10
|
Alan W. Irwin writes: > On 2010-05-01 21:26-0500 Geoffrey Furnish wrote: > > What is the simplest statement of the commumdrum? > > If you apply the following patch > [...] > > in accordance with Hez's arguments above, then plshade and plshades quit > working (blank results or one giant triangle result) under certain (but not > all) circumstances for the Python and Tcl examples. What has us both > puzzled is why does this minor (and probably well-justified) change matter > for Tcl and Python but no other bindings? If we can figure out those > special circumstance and eliminate them, then we can go ahead with the above > cleanup which also benefits Hez's new transformation work. Okay. I'll try to peer into this and see if I can remember why we set it up that way when we wrote the Tcl binding eons ago. |
From: Alan W. I. <ir...@be...> - 2010-05-03 02:17:54
|
On 2010-05-01 23:08-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > On 2010-05-01 21:26-0500 Geoffrey Furnish wrote: > > > What is the simplest statement of the commumdrum? > > > > If you apply the following patch > > [...] > > > > in accordance with Hez's arguments above, then plshade and plshades quit > > working (blank results or one giant triangle result) under certain (but not > > all) circumstances for the Python and Tcl examples. What has us both > > puzzled is why does this minor (and probably well-justified) change matter > > for Tcl and Python but no other bindings? If we can figure out those > > special circumstance and eliminate them, then we can go ahead with the above > > cleanup which also benefits Hez's new transformation work. > > Okay. I'll try to peer into this and see if I can remember why we set it up > that way when we wrote the Tcl binding eons ago. I have just solved this for Python. See the revision 10962 commit message for details which involved the default pltr0 result for the human-friendly variations of the plshade and plshades argument lists. We don't actually want pltr0 for examples 15 and 21. Instead, we want NULL. (A complicating issue is the documentation says pltr0 and NULL are interpreted identically but they are not!) I didn't want to change that human-friendly python default so I changed the examples instead to be explicit about asking for a NULL pltr result, and the Postscript results are identical to the C versions even with pltr_data checks dropped at the C level. As I recall, those Python user-friendly argument list variation defaults were all copied from Tcl so I imagine the same issue exists there, and I hope to apply the same fix (specify NULL explicitly for pltr in the affected examples). I will look at that shortly unless you beat me to it. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-05-07 06:54:25
|
Hello all, I have done some tests wrt the strange error messages I got from test-drv-info yesterday. It turns out that the program is issuing an error code -1073741515 (completely nonsensical of course) when it can not find the driver - the PATH environment variable does not contain the directory containing the driver DLLs. From the source code for test-drv-info I would guess that a more proper error message should occur, but perhaps this does not work under Windows/MinGW. (Yesterday I probably made a mistake in updating the path before running make again, so that the error occurred multiple times. I will make a note on the Wiki about this.) Regards, Arjen On 2010-05-06 16:40, Arjen Markus wrote: > > On 2010-05-06 16:37, David MacMahon wrote: >> On May 6, 2010, at 7:27 , Arjen Markus wrote: >> >>> this is indeed very puzzling! I have never seen it before - and all >>> the stuff I used I have used countless times before. >>> >>> Also puzzling: why does a repeated invocation of test-drv-info via make >>> examine different drivers? It must be recording some information. >> Have you tried from a clean build tree? Sometimes after making Makefile >> changes, old build products from previous builds can cause weird >> problems because make no longer considers them but the tools make >> invokes might consider/use them. >> >> Just an idea, >> Dave >> > > Hi Dave, > > thanks, but that was not the cause: I always rebuild from scratch. > (Hm, but not just now ... I will have to re-examine this! And I need > to keep track of seemingly unimportant glitches, like the one with > the PATH I just mentioned) > > Regards, > > Arjen > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Werner S. <sm...@ia...> - 2010-05-09 07:36:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, On 5/7/10 6:21 PM, Alan W. Irwin wrote: > On 2010-05-07 08:54+0200 Arjen Markus wrote: > >> Hello all, >> >> I have done some tests wrt the strange error messages I got >> from test-drv-info yesterday. It turns out that the program >> is issuing an error code -1073741515 (completely nonsensical >> of course) when it can not find the driver - the PATH environment >> variable does not contain the directory containing the driver DLLs. > > It appears to me there is a good possibility you discovered a build-system > issue here. If your PATH did not contain the directory where the driver > DLL's are located, how come this was not an issue for running the examples > in the build tree? > > In other words, is the build system doing the right thing with regard to the > driver PATH for running build-tree examples for MinGW, but not for running > test-drv-info? > > Even if there is a mundane explanation for your puzzling results (such as > you had the wrong PATHs set for running test-drv-info, but you corrected > that afterward for running the examples in the build tree), it appears to me > we could make life substantially easier for those using the MinGW platform. > > Anyhow, there is a lot of power in CMake to make life easy for builders > on all platforms. Let's use that power rather than demanding workarounds > from our users such as adding extra paths when CMake might give us > a better solution automatically. The problem is, that in Windows dlls must either be in the same directory as the executable (so test-drv-info must be in this directory as well), or the PATH is set accordingly (this can't be set by cmake, since the changes of cmake to the environment variables only last as long cmake runs - so the changes are not anymore during compile time) or if the dlls are in on of the system directories (no option). > > Assuming you do come up with a build-system fix to make life easier for our > MinGW users, please think as generally as possible. For example, try to > make the fix so that MinGW/MSYS, Cygwin, and bare Windows users benefit as > well as MinGW users. The above considerations are valid generally, not only for MinGW. IMO the best idea is to move the test-drv-info executable in the place where the dlls are. So we get through the compiling stage without problems. The examples won't run, if the PATH wasn't set accordingly though. I think we had the same discussion before with exactly the same conclusion but nobody did the simple change :(. Regards, Werner > > 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 > __________________________ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL5mXuAAoJEG1QQcXtyvSnZn4H/RHJi0vVqdFpAKQJtH/17otY A2CGsMrzwjNyW4U1xdh3vLImW19C72vVZWkkE5oeyLG5MgiV+NN4qlu5t+PIgv4d iq1w13z6mIQkIDsYcHxkkx+juxXjvHVaCvcZJfjNDzmojrZHuqMfAYRXeb7NTe70 lDq9V9pfmKoaSKN92VoghnUfdiuwPOCw/WUwIb9iZ1moH6gE2j+8LtuwtSBN0rI4 hUiy26+rMhVsFy14uYH2e+4luV3bdPOe2tBaEuerNsG/qCjijTpC5QGDAB1ka2Ii DKrM2i3pCrSupmNULthfP8Yz3bdK1VGaUrL4yJ31RwX8aPPqnoENfolKYKvKtYg= =/ngz -----END PGP SIGNATURE----- |
From: Werner S. <sm...@ia...> - 2010-05-09 19:30:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, On 5/9/10 5:13 PM, Alan W. Irwin wrote: > On 2010-05-09 09:36+0200 Werner Smekal wrote: > >> The problem is, that in Windows dlls must either be in the same >> directory as the executable (so test-drv-info must be in this directory >> as well), or the PATH is set accordingly (this can't be set by cmake, >> since the changes of cmake to the environment variables only last as >> long cmake runs - so the changes are not anymore during compile time) or >> if the dlls are in on of the system directories (no option). > > But test-drv-info is located in the same build-tree drivers subdirectory as > the plug-in device drivers that it is testing. For example, here is > the story on Linux for xwin: Not for Windows: all dlls (whereever they come from) are in the dll directory, while test-drv-info is as you say in the drivers directory. I hope I have more time tomorrow to have a look at it. Regards, Werner > > software@raven> ls /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so > /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so* > > This is the relevant fragment of the the output from "make VERBOSE=1 > test_dyndrivers" > > cd /home/software/plplot_svn/HEAD/build_dir/drivers && ./test-drv-info xwin >> /home/software/plplot_svn/HEAD/build_dir/drivers/test_dyndrivers_dir/xwin.rc > > So according to your dll location criteria above, all should be well for > finding the device-driver plug-ins. > > I guess there is a possibility that on the Windows side of things > test-drv-info is not being executed in the build-tree drivers subdirectory > or the dynamic device plug-ins are not located there. Could you please check > that? > > I am now also wondering if there is some issue with ltdl_win32.c (the > special code you wrote to dynamically load devices on Windows) such that it > does not find the plug-in when it is in the same directory. Could you > check that as well? > > I will also check both those issues for MinGW/MSYS on Wine, but that > may be a special case so checking on a "real" windows platform would be > a good idea as well. > > N.B. Remember that for such checking the test_dyndrivers target is only > executed if you run it explicitly, or run the all or install targets. I plan > to improve dependencies so that if you build a device it will get > immediately checked by test-drv-info, but that hasn't happened yet. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL5w1VAAoJEG1QQcXtyvSnuBgIAJq9Lh5UKQJYakPGJXfSKM/t LhgWGsfwH0AGnGz6NUoGXBVbuScmhacCMak36h0QrBhvlkDGCEo4gQiflFb8yHyf 7TJBNcYKdYnYhvm2+61rGZFexLAMNoWyQTF5kqfhQekzN9tMHn4rlVYS8xlPxHvN SmCaixHXakWrimaEwxNYiQZ10xEuC/A7KCDpGs6yE814hfB+AFSIfy00bxn6Vnh+ wibuQEevwkTMjQQe3rxbtE2DBS0js7UqCEEnPmPX7Tcljfl8tFn5VUBR6aaAsC0f /IkuzXN0JdFCuxsQy0G6YRfchn3W+rmcsMOcNs2IJCMlbROTzIbcSxizTkfIPRo= =Jc86 -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2010-05-10 03:16:10
|
On 2010-05-09 21:30+0200 Werner Smekal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alan, > > On 5/9/10 5:13 PM, Alan W. Irwin wrote: >> On 2010-05-09 09:36+0200 Werner Smekal wrote: >> >>> The problem is, that in Windows dlls must either be in the same >>> directory as the executable (so test-drv-info must be in this directory >>> as well), or the PATH is set accordingly (this can't be set by cmake, >>> since the changes of cmake to the environment variables only last as >>> long cmake runs - so the changes are not anymore during compile time) or >>> if the dlls are in on of the system directories (no option). >> >> But test-drv-info is located in the same build-tree drivers subdirectory as >> the plug-in device drivers that it is testing. For example, here is >> the story on Linux for xwin: > > Not for Windows: all dlls (whereever they come from) are in the dll > directory, while test-drv-info is as you say in the drivers directory. Thanks for that key clarification. > > I hope I have more time tomorrow to have a look at it. > The current dll subdirectory location for the plug-in device drivers is essential for build-tree testing on Windows (since that dll location must be on your PATH for that case). So the location of the plug-in devices must not be changed. Therefore, I believe the only thing left to do (for those users who are building but not testing so they don't have their PATH set to dll) is to change the location of the test-drv-info executable to dll for the if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) case. If I can get that to work on Wine, I will commit the change (unless you beat me to it or unless you know of some reason why that wont work). 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 __________________________ |
From: Werner S. <sm...@ia...> - 2010-05-10 07:14:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, >> Not for Windows: all dlls (whereever they come from) are in the dll >> directory, while test-drv-info is as you say in the drivers directory. > > Thanks for that key clarification. > >> >> I hope I have more time tomorrow to have a look at it. >> > > The current dll subdirectory location for the plug-in device drivers is > essential for build-tree testing on Windows (since that dll location > must be > on your PATH for that case). So the location of the plug-in devices must > not > be changed. Therefore, I believe the only thing left to do (for those users > who are building but not testing so they don't have their PATH set to dll) > is to change the location of the test-drv-info executable to dll for the > if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) case. If I can get that to > work on Wine, I will commit the change (unless you beat me to it or unless > you know of some reason why that wont work). I just commited the change. This works for me on MinGW. Compilation should now be always successful, to make the examples work the PATH variable must be adjusted (add the dll directory). There is no automatic automatism for that, except that we could warn the user at the end of the cmake configuration stage, if the dll path is not in the PATH variable or similar. Regards, Werner > > 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 > __________________________ - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL57JOAAoJEG1QQcXtyvSn3DMH/32lekXWY5jyMQiwvieDKmyo yuFSuc6rewyYXqMRGvuCebc51AKX70Vm3kCqdiYiSPIDdlyultiOgceT4ZLMVC1M Blwecx8+pGyeU46N7+gvb2yE0cX2dTlbfip6FrsoTpzy98R6XXuWE037AHWXUZFa 2zaJh+u8XQJ99rDpI5yYZ0wg9Ijy+nbrn6+akPJ5sqgNnWo4HuYFYsscK5t81uvk 2CvbRwGQXOJiR073NbO3uVuxTCH5zS181GX0xpGu1dOPpNKAEKg14/bbtlySbhAL UU7eZVYxHyYZVw9CYKwllODx+99xImTvjO8RZ+6xzkgsYNng45tWgn+tZGtUVok= =85as -----END PGP SIGNATURE----- |