From: Alan W. I. <ir...@be...> - 2004-09-02 06:33:44
|
Full credit to Andrew Roach who just now coded up a gif device for the gd device driver. The gif device seems pretty mature right out of the box. I did a valgrind test with no problems for c/x01c. I also modified plplot-test.sh.in to include this device and ran ./plplot-test.sh --device=gif for the installed examples. The only obvious errors occurred for the "p" series of examples which exercise the high-level octave interface. Bad looking (blank page) results appeared as well as a segfault. The "x" octave series which exercises the low-level octave interface and all other examples for the various front-ends (including perl/pdl) worked fine and produced 546 (!) good-looking file results. Rafael, will you please try ./plplot-test.sh --front-end=octave --device=gif to verify the segfault? If you can narrow down the problem to one simple test case and give the cookbook to run that test, then I could probably run valgrind on that test case to quickly find what is causing the segfault. In fact because errors only seem to occur for the high-level octave interface, I am currently speculating that the whole problem is caused not by the gif device, but instead by some subtle memory management problem in the high-level octave interface that is triggered by the gif device. A valgrind run will tell the tale. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-02 11:19:55
|
* Rafael Laboissiere <rla...@us...> [2004-09-02 12:24]: > So, I suspect that the problems come from p16.m, but I am not sure. I do > not have time to test it extensively, but I think I narrowed done the > problem. I could not refrain myself the bug hunting during lunch time. I narrowed down completely the problem now. The following Octave script works: toggle_plplot_use figure (1, "psc", "foo.ps"); colormap (ones (10, 3)); While the following fails: toggle_plplot_use figure (1, "gif", "foo.gif"); colormap (ones (10, 3)); There is some strange interaction between the plscmap1 call, the Octave binding, and the GD driver. I will stop trying to debug this, since it seems to be much more complicated than I can handle at lunch time (and, besides, I am hungry!). -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-02 18:10:34
|
On 2004-09-02 13:19+0200 Rafael Laboissiere wrote: > * Rafael Laboissiere <rla...@us...> [2004-09-02 12:24]: > >> So, I suspect that the problems come from p16.m, but I am not sure. I do >> not have time to test it extensively, but I think I narrowed done the >> problem. > > I could not refrain myself the bug hunting during lunch time. I narrowed > down completely the problem now. The following Octave script works: > > toggle_plplot_use > figure (1, "psc", "foo.ps"); > colormap (ones (10, 3)); > > While the following fails: > > toggle_plplot_use > figure (1, "gif", "foo.gif"); > colormap (ones (10, 3)); > > There is some strange interaction between the plscmap1 call, the Octave > binding, and the GD driver. The above cookbook inspired me to try two valgrind runs as follows: export octavedir=/usr/local/plplot/share/plplot_octave//:/usr/local/plplot/share/octave/site/m//:/usr/local/plplot/share/plplot_octave//: valgrind --num-callers=10 octave -f -q -p $octavedir toggle_plplot_use figure (1, "psc", "foo.ps"); colormap (ones (10, 3)); closefig ctrl-d and the same again with figure (1, "psc", "foo.ps"); replaced by figure (1, "gif", "foo.gif"); The valgrind environment for octave is rather noisy because octave itself has many memory management issues. However, comparison of the two valgrind runs indicated extra memory management issues with the second version. In particular, we have the following severe error associated with the colomap call for the gif device: octave:3> colormap (ones (10, 3)); ==12390== ==12390== Invalid read of size 4 ==12390== at 0x1FE44FA7: plD_state_png (gd.c:949) ==12390== by 0x1FE0F806: plP_state (plcore.c:166) ==12390== by 0x1FE15422: plcmap1_calc (plctrl.c:506) ==12390== by 0x1FE157C4: c_plscmap1n (plctrl.c:602) ==12390== by 0x1FDBC4EF: _wrap_plscmap1n(octave_value_list const&, int) (in /home/software/plplot_cvs/install/share/plplot_octave/plplot_octave.oct) ==12390== by 0x1FDEE12E: Fplplot_octave(octave_value_list const&, int) (in /home/software/plplot_cvs/install/share/plplot_octave/plplot_octave.oct) ==12390== by 0x1BB2F564: octave_builtin::do_multi_index_op(int,octave_value_list const&) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) ==12390== by 0x1BB2E9CB: octave_builtin::subsref(std::string const&,std::list<octave_value_list, std::allocator<octave_value_list> > const&,int) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) ==12390== by 0x1BB237F6: octave_value::subsref(std::string const&,std::list<octave_value_list, std::allocator<octave_value_list> > const&,int) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) ==12390== by 0x1BBE1054: tree_index_expression::rvalue(int) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) ==12390== Address 0x1F75EB38 is 7224 bytes inside a block of size 7268 free'd ==12390== at 0x1B907460: free (vg_replace_malloc.c:153) ==12390== by 0x1FF4855E: gdFree (in /usr/lib/libgd.so.2.0.28) ==12390== by 0x1FF37432: gdImageDestroy (in /usr/lib/libgd.so.2.0.28) ==12390== by 0x1FE456BD: plD_eop_gif (gd.c:1399) ==12390== by 0x1FE0F65D: plP_eop (plcore.c:109) ==12390== by 0x1FE256FC: c_pleop (plpage.c:107) ==12390== by 0x1FDA1B24: _wrap_pleop(octave_value_list const&, int) (in /home/software/plplot_cvs/install/share/plplot_octave/plplot_octave.oct) ==12390== by 0x1FDEDAF8: Fplplot_octave(octave_value_list const&, int) (in /home/software/plplot_cvs/install/share/plplot_octave/plplot_octave.oct) ==12390== by 0x1BB2F564: octave_builtin::do_multi_index_op(int,octave_value_list const&) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) ==12390== by 0x1BB2E9CB: octave_builtin::subsref(std::string const&,std::list<octave_value_list, std::allocator<octave_value_list> > const&,int) (in /usr/lib/octave-2.1.57/liboctinterp.so.2.1.57) followed by many additional serious errors for that device. To Andrew (Roach): You will notice from the above error messages that the invalid read is associated with line 949 of gd.c which is the following: if (!gdImageTrueColor(dev->im_out)) but I recall you said that the gif device did not have TrueColor. So I am wondering if this is the cause of the invalid read. Should that line be executed for the gif device? (Andrew, in case you are wondering, the Debian testing version of the libgd2-xpm package I have installed is 2.0.28-2). Because of the severe memory management problems showing up in the above test of the high-level octave interface using the gif device, I ran valgrind tests on every c/x??c example with the gif device but found no serious problems. for test in x??c; do valgrind ./$test -dev gif -fam -fflen 2 -o test.gif; enddo; done ignoring x14c and x17c (since they are interactive), the only memory problems I could find were for examples 8, 11, and 20. 8 and 11 leave 42 bytes of unfreed memory. We should track those gif device memory leaks down, but 42 bytes won't receive the largest memory leak of the year award.... :-) Furthermore, these memory leaks do not interfere with functionality. The example 20 issue had a simple explanation; the problem appears for all non-interactive devices and disappears if I use the correct command-line -nointeractive option with those devices. Because the C examples test show no severe memory management problems, I think there can only be two explanations of the problems encountered for gif and the high-level octave interface where extensive testing shows no gif problems for any other interface (including the low-level octave interface). 1. The high-level octave interface is not initializing the gif device correctly. 2. The high-level octave interface is initializing and using the gif device correctly, but it is doing it in a different way or different order than the C interface (or any other interface including the low-level octave interface), and this different way exercises a bug in the gif device driver. To test both hypotheses, it would be interesting for Rafael to try essentially the same thing as the above high-level cookbook but using just the low-level octave interface to mimic exactly what the high-level interface does in the same order to initialize the device. If the low-level interface always works regardless of any way you tweak it (and associated valgrind runs show no extra memory management problems), then probably hypothesis 1 is the explanation of the problem. Good luck, Andrew and Rafael in sorting out the cause of this problem. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-02 18:28:08
|
* Alan W. Irwin <ir...@be...> [2004-09-02 11:04]: > Because the C examples test show no severe memory management problems, I > think there can only be two explanations of the problems encountered for > gif and the high-level octave interface where extensive testing shows no > gif problems for any other interface (including the low-level octave > interface). > > 1. The high-level octave interface is not initializing the gif device > correctly. > > 2. The high-level octave interface is initializing and using the gif device > correctly, but it is doing it in a different way or different order than the > C interface (or any other interface including the low-level octave > interface), and this different way exercises a bug in the gif device driver. > > To test both hypotheses, it would be interesting for Rafael to try > essentially the same thing as the above high-level cookbook but using just > the low-level octave interface to mimic exactly what the high-level > interface does in the same order to initialize the device. If the low-level > interface always works regardless of any way you tweak it (and associated > valgrind runs show no extra memory management problems), then probably > hypothesis 1 is the explanation of the problem. > > Good luck, Andrew and Rafael in sorting out the cause of this problem. Thanks for the extensive tests and the hypotheses formulation. I will have a hectic month before me and my involvement with PLplot will have to be reduced to the essential minimum during this period (for instance, the official 5.3.1 announcement, if I can get to that). Fixing the crazy interaction bug between Octave and GD is far beyond what I can afford in my current time budget. Joao would be the appropriate person for doing that, but he may be busy as well. I am sorry. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-03 05:34:39
|
Andrew, I hope you don't mind me taking the liberty of keeping this thread on plplot-devel. I am doing this because other developers may be interested as well, and we may need all the help we can get to solve this. More comments in context below. Alan On 2004-09-03 13:31+1000 Andrew Roach wrote: > Hello Alan and Rafael, > >> You will notice from the above error messages that the invalid read is >> associated with line 949 of gd.c which is the following: >> >> if (!gdImageTrueColor(dev->im_out)) >> >> but I recall you said that the gif device did not have TrueColor. So I am >> wondering if this is the cause of the invalid read. > > Yes, I am sure it is. > >> Should that line be executed for the gif device? > > Never. I can not actually belive that is has executed. Truecolour support for > the Gif driver is turned off not once, but twice ! (once implicitly, once > explicitly) There should be NO way for that command to execute for the gif > driver. > >> Because the C examples test show no severe memory management problems, I >> think there can only be two explanations of the problems encountered for >> gif and the high-level octave interface where extensive testing shows no >> gif problems for any other interface (including the low-level octave >> interface). >> >> 1. The high-level octave interface is not initializing the gif device >> correctly. >> >> 2. The high-level octave interface is initializing and using the gif >> device >> correctly, but it is doing it in a different way or different order than >> the >> C interface (or any other interface including the low-level octave >> interface), and this different way exercises a bug in the gif device >> driver. > > > I don't have octave on my system, so cant test, but I will tell you what I > think it might be. Remember a few months ago a problem popped up with octave, > GD, and freetype fonts ? Although I did not say anything at the time (I just > fixed it), what it turned out to be was octave was sending 256,256,256 to > represent white, when it should have sent 255,255,255. The 8 bit limit for > the colour index was being exceeded, and that mucked up freetype. I just > clamped freetype so anything greater than 255 (ie 256 in this case) was set > to 255. It fixed the problem, from freetype's side of things, but was just a > quick work around. Now if octave is doing a similar thing here, sending 256 > instead of 255 that would trick either libgd or the gd driver (or both!) into > truecolour mode since there was more than the 8 bit limit in an index > somewhere. It would probably be possible to patch the GD driver to clamp > values of 256 back to 255 in a couple of key places to stop this happening, > but I don't think, in this case, that is the real culprit. I think the > problem lies somewhere in octave. Your explanation sounded quite promising, but, alas, the input "ones" array used by the colormap (ones (10, 3)); command is multiplied by 255 in bindings/octave/PLplot/colormap.m so that should not produce a bad colour. I even tried colormap (ones (10, 3)-1); to make that an array of zeroes input, but the segfault is still produced for the gif device. So we have to think of some alternative explanation why the high-level octave interface (but not any other interface including the low-level octave interface) puts the gif device improperly into Truecolour mode. Andrew, can you think of any other way (no matter how strange) to do this except for a bad cmap1 colour? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2004-09-03 09:55:09
|
>Your explanation sounded quite promising, but, alas, the input "ones" array >used by the >[snip..] >to make that an array of zeroes input, but the segfault is still produced >for the gif device. So we have to think of some alternative explanation why >the high-level octave interface (but not any other interface including the >low-level octave interface) puts the gif device improperly into Truecolour >mode. Andrew, can you think of any other way (no matter how strange) to do >this except for a bad cmap1 colour? "Disappointing" springs to mind... no quick fix today I guess :-( . I was way off the mark in my initial estimate anyway and should have read some docs. If the problem is stemming from: if (!gdImageTrueColor(dev->im_out)) we could be in for a whole mess of confusion. The "function" gdImageTrueColor is a simple macro in GD, defined as: #define gdImageTrueColor(im) ((im)->trueColor) All it is doing is checking a GD flag to see if it is a truecolour file. If it's segfaulting on that line, I cant see how it has anything to do with either the gd driver OR libgd. That is a very, very simple macro, and is called *whenever* the gd device initialises to work out which pallette setting routine to use, truecolour or not. Octave must be somehow trashing the memory location dev->im_out resides in, which is then segfaulting when functions are trying to reference that memory area. The examples which are not working with octave are working ok with python etc... aren't they ? |
From: Rafael L. <rla...@us...> - 2004-09-03 11:01:09
|
* Andrew Roach <aro...@ya...> [2004-09-03 17:05]: > Octave must be somehow trashing the memory location dev->im_out resides in, > which is then segfaulting when functions are trying to reference that > memory area. This is also my feeling. > The examples which are not working with octave are working ok with python > etc... aren't they ? The problematic Octave scripts are the bindings/octave/demos/p*.m, which have no counterparts in the other bindings. We might try to closely mimic in other languages what the Octave demos are doing with the cmap to see if the problem persists. I do not know if Joao is lurking here but he would be the right person to investigate the problem. -- Rafael |
From: <jc...@fe...> - 2004-09-03 15:16:37
|
On Friday 03 September 2004 12:00, Rafael Laboissiere wrote: | * Andrew Roach <aro...@ya...> [2004-09-03 17:05]: | > Octave must be somehow trashing the memory location dev->im_out | > resides in, which is then segfaulting when functions are trying to | > reference that memory area. | | This is also my feeling. | | > The examples which are not working with octave are working ok with | > python etc... aren't they ? | | The problematic Octave scripts are the bindings/octave/demos/p*.m, | which have no counterparts in the other bindings. We might try to | closely mimic in other languages what the Octave demos are doing with | the cmap to see if the problem persists. | | I do not know if Joao is lurking here but he would be the right | person to investigate the problem. Hi, I will try to see what is happening, but as I don't build PLplot for=20 almost an year I'm having some difficulties. Jo=E3o |
From: <jc...@fe...> - 2004-09-06 17:58:50
Attachments:
figure.m.diff
Makefile.am.diff
|
On Friday 03 September 2004 16:14, Jo=E3o Cardoso wrote: | On Friday 03 September 2004 12:00, Rafael Laboissiere wrote: | | * Andrew Roach <aro...@ya...> [2004-09-03 17:05]: | | > Octave must be somehow trashing the memory location dev->im_out | | > resides in, which is then segfaulting when functions are trying | | > to reference that memory area. | | | | This is also my feeling. | | | | > The examples which are not working with octave are working ok | | > with python etc... aren't they ? | | | | The problematic Octave scripts are the bindings/octave/demos/p*.m, | | which have no counterparts in the other bindings. We might try to | | closely mimic in other languages what the Octave demos are doing | | with the cmap to see if the problem persists. | | | | I do not know if Joao is lurking here but he would be the right | | person to investigate the problem. | | Hi, | | I will try to see what is happening, but as I don't build PLplot for | almost an year I'm having some difficulties. Hi, I coulnd't reproduce (in the build tree) the reported problem. The GIF=20 device works fine for me with any of the x??c Octave demos. I had to download, compile and install gd-2.0.28 in order to have GIF=20 support. Perhaps the problem is the gd library version? With the p?? Octave demos there is also no problem, if we apply the=20 attached patch. I had however some other problems to compile plplot_octave --- strange=20 that nobody else reported it. I had to change the matwrap options in=20 order to have no errors, as the other attached patch shows. As for the colormap problem, I also found no problem at all, as the=20 following procedure illustrates: > cd plplot/bindings/octave > octave octave:1> fig(1,"gif","foo.gif"); plSetOpt("fam","1"); p7; closefig This generates two GIF files/images. The p7 demo changes the colormap,=20 so one should be able to see different colormap in each of the=20 generated files. However, this does not happens, both figures have the=20 same (last set) colormap, but that is is a problem of the GIF driver=20 and not of octave. ?? Joao | | Jo=E3o | | | ------------------------------------------------------- | This SF.Net email is sponsored by BEA Weblogic Workshop | FREE Java Enterprise J2EE developer tools! | Get your free copy of BEA WebLogic Workshop 8.1 today. | http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2004-09-06 20:48:08
|
On 2004-09-06 18:57+0100 Jo=E3o Cardoso wrote: > Hi, > > I coulnd't reproduce (in the build tree) the reported problem. The GIF > device works fine for me with any of the x??c Octave demos. Actually, that was everybody else's experience as well. Gif seems fine wit= h the low-level (x example) interface. > > I had to download, compile and install gd-2.0.28 in order to have GIF > support. Perhaps the problem is the gd library version? My tests have always been for that version (Debian testing version, 2.0.28-2). > > I had however some other problems to compile plplot_octave --- strange > that nobody else reported it. I had to change the matwrap options in > order to have no errors, as the other attached patch shows. I don't understand why this patch (just committed by Rafael) is now required. (It wasn't the last time I ran a complete check which I think was sometime in the last week or so.) The only change is you replace $(srcdir)/plplot_octave_rej.h by plplot_octave_rej.h. On my system, with a build in the source tree, $(srcdir) reduces to ".", but somehow that is now confusing the local bindings/octave/matwrap/matwrap perl script. Could we fix that script instead? If we do it that way, we don't break the separate build tree case. > cd plplot/bindings/octave > octave octave:1> fig(1,"gif","foo.gif"); plSetOpt("fam","1"); p7; closefig > This generates two GIF files/images. The p7 demo changes the colormap,=20 > so one should be able to see different colormap in each of the > generated files. However, this does not happens, both figures have the > same (last set) colormap, but that is is a problem of the GIF driver > and not of octave. I confirm that there appears to be a colour map problem with p7 both in the gif and png devices when compared to the psc device results. However, the octave logic for that plot is still problematic; if you look at the results of the first page (even in postscript) there seems to be two different sets of labels superimposed on each other. I would like to see those p7.m logic problems straightened out before we come to any conclusions about how gif and png handle colour maps. For example, those devices do just fine for the python/xw08.py example where the colour map is reset several times. > [out of order] > With the p?? Octave demos there is also no problem, if we apply the > attached patch. This figure.m patch (just committed to cvs by Rafael) works for me. plplot-test.sh now goes through without any problems with the gif device. The "p" example results (for all devices including postscript) are now much better. Also, valgrind results (within the noise created by memory management problems in octave itself) seem okay for this simple test that did not work before: valgrind --num-callers=3D10 octave -f -q -p $octavedir toggle_plplot_use figure (1, "psc", "foo.ps"); colormap (ones (10, 3)); closefig ctrl-d Thanks Joao, for finding the fix to this subtle problem! In sum, the principal problem seems to have been addressed by Joao's figure.m change, but there remain some other issues. * I believe to avoid breaking the separate build tree case for octave, Rafael's recent commit for Makefile.am should be reverted. Instead, I believe the fix should be made in the bindings/octave/matwrap/matwrap perl script to recognize forms like dirname/filename to access the plplot_octave_rej.h file. * the problems with the p7 logic need to be addressed. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-06 21:14:07
|
* Alan W. Irwin <ir...@be...> [2004-09-06 13:43]: > * I believe to avoid breaking the separate build tree case for octave, > Rafael's recent commit for Makefile.am should be reverted. Instead, I > believe the fix should be made in the bindings/octave/matwrap/matwrap perl > script to recognize forms like dirname/filename to access the > plplot_octave_rej.h file. I went ahead and committed the patch because Joao was completely right: the $(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago broke indeed the building of the Octave binding in the source tree. This is not acceptable because building in the source tree is by far the most current case (Debian packaging, casual users having CVS checked out, etc). We must find another solution for building PLplot in all possible situations, perhaps along the lines of your suggestion above. For now, please, do not revert my last change. -- Rafael |
From: Andrew R. <and...@us...> - 2004-09-06 21:34:05
|
On Mon, Sep 06, 2004 at 11:14:01PM +0200, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-09-06 13:43]: > > > * I believe to avoid breaking the separate build tree case for octave, > > Rafael's recent commit for Makefile.am should be reverted. Instead, I > > believe the fix should be made in the bindings/octave/matwrap/matwrap perl > > script to recognize forms like dirname/filename to access the > > plplot_octave_rej.h file. > > I went ahead and committed the patch because Joao was completely right: the > $(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago > broke indeed the building of the Octave binding in the source tree. This is > not acceptable because building in the source tree is by far the most > current case (Debian packaging, casual users having CVS checked out, etc). > We must find another solution for building PLplot in all possible > situations, perhaps along the lines of your suggestion above. For now, > please, do not revert my last change. OK. I didn't realise matwrap was broken in this way. Unfortunately this is partly outside out control, unless we force use of our own copy. I'll look into this further and make sure I thoroughly test building in source tree as well. Andrew |
From: Alan W. I. <ir...@be...> - 2004-09-06 23:33:45
|
On 2004-09-06 22:34+0100 Andrew Ross wrote: > On Mon, Sep 06, 2004 at 11:14:01PM +0200, Rafael Laboissiere wrote: >> * Alan W. Irwin <ir...@be...> [2004-09-06 13:43]: >> >>> * I believe to avoid breaking the separate build tree case for octave, >>> Rafael's recent commit for Makefile.am should be reverted. Instead, I >>> believe the fix should be made in the bindings/octave/matwrap/matwrap perl >>> script to recognize forms like dirname/filename to access the >>> plplot_octave_rej.h file. >> >> I went ahead and committed the patch because Joao was completely right: the >> $(srcdir)/plplot_octave_rej.h change made by Andrew Ross three days ago >> broke indeed the building of the Octave binding in the source tree. This is >> not acceptable because building in the source tree is by far the most >> current case (Debian packaging, casual users having CVS checked out, etc). >> We must find another solution for building PLplot in all possible >> situations, perhaps along the lines of your suggestion above. For now, >> please, do not revert my last change. Understood, Rafael. > > OK. I didn't realise matwrap was broken in this way. Unfortunately this > is partly outside out control, unless we force use of our own copy. I'll > look into this further and make sure I thoroughly test building in > source tree as well. Andrew, I suspect you have already discovered this for yourself, but just to be specific, the latest matwrap available on debian-testing (version 0.57-3) is only slightly different than bindings/octave/matwrap/matwrap. Also, I just tested that Debian version and it also doesn't recognize the dirname/filename version of plplot_octave_rej.h. Looking further into this we have the following quote from the man page: -cpp_ignore filename_or_directory Ignored unless used with the -cpp option. Causes functions defined in the given file name or in include files in the given directory or subdirectories of it not to be wrapped. By default, functions defined in "/usr/include", "/usr/local/include", or "*/gcc-lib" are not wrapped. So it looks like it is a matwrap design decision to have that option either a file or directory, and it may be difficult to recognize the dirname/filename version of the filename because of that design decision. I agree that with matwrap design decisions like this essentially out of our control, a different way (establishing a build tree symlink if the file or symlink doesn't already exist in the build tree?) should be found to make a separate build tree work. BTW, I asked a question some time ago about the nicest way to establish a symlink in the build tree to the corresponding source tree file (something I need to do to get python in a separate build tree to work properly). That question was never answered, but if you find a slick way to do it for the present case, it will also help the python case as well. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-09-07 06:35:09
|
On Mon, Sep 06, 2004 at 04:29:22PM -0700, Alan Irwin wrote: > On 2004-09-06 22:34+0100 Andrew Ross wrote: > > >OK. I didn't realise matwrap was broken in this way. Unfortunately this > >is partly outside out control, unless we force use of our own copy. I'll > >look into this further and make sure I thoroughly test building in > >source tree as well. > > Andrew, I suspect you have already discovered this for yourself, but just to > be specific, the latest matwrap available on debian-testing (version 0.57-3) > is only slightly different than bindings/octave/matwrap/matwrap. Also, I > just tested that Debian version and it also doesn't recognize the > dirname/filename version of plplot_octave_rej.h. > > Looking further into this we have the following quote from the man page: > > -cpp_ignore filename_or_directory > Ignored unless used with the -cpp option. Causes functions > defined > in the given file name or in include files in the given directory > or subdirectories of it not to be wrapped. By default, functions > defined in "/usr/include", "/usr/local/include", or "*/gcc-lib" > are > not wrapped. > > So it looks like it is a matwrap design decision to have that option either > a file or directory, and it may be difficult to recognize the > dirname/filename version of the filename because of that design decision. > > I agree that with matwrap design decisions like this essentially out of our > control, a different way (establishing a build tree symlink if the file or > symlink doesn't already exist in the build tree?) should be found to make a > separate build tree work. > > BTW, I asked a question some time ago about the nicest way to establish a > symlink in the build tree to the corresponding source tree file (something I > need to do to get python in a separate build tree to work properly). That > question was never answered, but if you find a slick way to do it for the > present case, it will also help the python case as well. Under unix the symlink option would be our neatest bet for a lot of these build tree / source tree problems. I've always shrunk away from this because it doesn't work on windows. I imagine you would have to revert the link to a copy there. Do any windows users have any comments on this? Andrew |
From: Alan W. I. <ir...@be...> - 2004-09-07 15:17:49
|
On 2004-09-07 07:34+0100 Andrew Ross wrote: > On Mon, Sep 06, 2004 at 04:29:22PM -0700, Alan Irwin wrote: >> BTW, I asked a question some time ago about the nicest way to establish a >> symlink in the build tree to the corresponding source tree file (something I >> need to do to get python in a separate build tree to work properly). That >> question was never answered, but if you find a slick way to do it for the >> present case, it will also help the python case as well. > > Under unix the symlink option would be our neatest bet for a lot of > these build tree / source tree problems. I've always shrunk away from > this because it doesn't work on windows. I imagine you would have to > revert the link to a copy there. Do any windows users have any comments > on this? The windows build system (in sys/win32/msdev) has always been independent of the Unix/Linux build system. The only cross-talk I am aware of between the two build systems is the windows side currently needs the swig-generated files that are in the tarball, and those wouldn't be necessary if something were done on the windows side with swig. Anyhow, symlinks generated at build time in our Unix/Linux build tree to the corresponding source tree counterparts are not an issue for the independent windows build system. Alan. __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-09-07 16:10:51
|
On Tue, Sep 07, 2004 at 07:55:52AM -0700, Alan Irwin wrote: > On 2004-09-07 07:34+0100 Andrew Ross wrote: > > The windows build system (in sys/win32/msdev) has always been independent of > the Unix/Linux build system. The only cross-talk I am aware of between the > two build systems is the windows side currently needs the swig-generated > files that are in the tarball, and those wouldn't be necessary if something > were done on the windows side with swig. Anyhow, symlinks generated at build > time in our Unix/Linux build tree to the corresponding source tree > counterparts are not an issue for the independent windows build system. You are in of course right. In fact according to the autobook (quoting the GNU coding standards) you can rely on the utility "ln" in you shell scripts, although you are recommended to use the autoconf macro AC_PROG_LN_S to set the variable LN_S since not all systems use the -s option for soft links. Oh well. Rafael's changes have fixed the problem in this instance anyway, though we could change some of the cp's to ln's I guess. I'll bear this in mind for next time. Andrew |
From: Arjen M. <arj...@wl...> - 2004-09-08 06:51:39
|
Andrew Ross wrote: > > Under unix the symlink option would be our neatest bet for a lot of > these build tree / source tree problems. I've always shrunk away from > this because it doesn't work on windows. I imagine you would have to > revert the link to a copy there. Do any windows users have any comments > on this? > It may be different with the most modern versions of Windows, and there is a kind of link mechanism available, but AIUI you would need a proper copy - this is how the building of the C library works on Windows anyway. Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-09-07 07:51:06
|
* Alan W. Irwin <ir...@be...> [2004-09-06 16:29]: > >OK. I didn't realise matwrap was broken in this way. Unfortunately this > >is partly outside out control, unless we force use of our own copy. I'll > >look into this further and make sure I thoroughly test building in > >source tree as well. > > Andrew, I suspect you have already discovered this for yourself, but just to > be specific, the latest matwrap available on debian-testing (version 0.57-3) > is only slightly different than bindings/octave/matwrap/matwrap. Also, I > just tested that Debian version and it also doesn't recognize the > dirname/filename version of plplot_octave_rej.h. I just committed a change to bindings/octave/Makefile.am that may work for a separate build tree. Please, try it. Matwrap is called now with: -cpp_ignore $(scrdir) -cpp_ignore plplot_octave_rej.h This is akin to calling gcc with "-L <dir> -l <file>", but matwrap has a single option (-cpp_ignore) to specify both directories and files. What matwrap does not accept (and that I only discovered after looking at the Perl code) are constructs like "-cpp_ignore <dir/file>". -- Rafael |
From: Andrew R. <and...@us...> - 2004-09-07 16:03:06
|
On Tue, Sep 07, 2004 at 09:50:56AM +0200, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-09-06 16:29]: > > > Andrew, I suspect you have already discovered this for yourself, but just to > > be specific, the latest matwrap available on debian-testing (version 0.57-3) > > is only slightly different than bindings/octave/matwrap/matwrap. Also, I > > just tested that Debian version and it also doesn't recognize the > > dirname/filename version of plplot_octave_rej.h. > > I just committed a change to bindings/octave/Makefile.am that may work for a > separate build tree. Please, try it. Matwrap is called now with: > > -cpp_ignore $(scrdir) -cpp_ignore plplot_octave_rej.h > > This is akin to calling gcc with "-L <dir> -l <file>", but matwrap has a > single option (-cpp_ignore) to specify both directories and files. What > matwrap does not accept (and that I only discovered after looking at the > Perl code) are constructs like "-cpp_ignore <dir/file>". Excellent - this appears to fix the problem building outside the source tree. I uncovered another problem with plplot.doc not being proper copied. I have hopefully now fixed that as well. This means reverting the changes to massage.c so is in fact neater anyway. Please check. Andrew |
From: Rafael L. <rla...@us...> - 2004-09-02 10:25:14
|
* Alan W. Irwin <ir...@be...> [2004-09-01 22:51]: > Rafael, will you please try > > ./plplot-test.sh --front-end=octave --device=gif > > to verify the segfault? If you can narrow down the problem to one simple > test case and give the cookbook to run that test, then I could probably run > valgrind on that test case to quickly find what is causing the segfault. It segfaults for all the GD devices (gif, jpeg, and png). The problem disappears with the following patch: Index: test_octave.sh.in =================================================================== RCS file: /cvsroot/plplot/plplot/test/test_octave.sh.in,v retrieving revision 1.1 diff -u -r1.1 test_octave.sh.in --- test_octave.sh.in 15 Jul 2004 13:08:49 -0000 1.1 +++ test_octave.sh.in 2 Sep 2004 10:22:53 -0000 @@ -44,7 +44,7 @@ # These require octave-2.1.50 so comment out since not everybody has # this. -for i=[1:7 8 9 13 15 16]; +for i=[1:7 8 9 13 15]; figure(i,"$device",sprintf("p%d.$dsuffix",i)); feval(sprintf("p%d",i)) closefig So, I suspect that the problems come from p16.m, but I am not sure. I do not have time to test it extensively, but I think I narrowed done the problem. Another strangeness is that all the p*.gif.01 files generated are blank. This needs further investigation. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-02 23:22:32
|
On 2004-09-02 20:27+0200 Rafael Laboissiere wrote: > Thanks for the extensive tests and the hypotheses formulation. I will have > a hectic month before me and my involvement with PLplot will have to be > reduced to the essential minimum during this period (for instance, the > official 5.3.1 announcement, if I can get to that). Fixing the crazy > interaction bug between Octave and GD is far beyond what I can afford in my > current time budget. Joao would be the appropriate person for doing that, > but he may be busy as well. I am sorry. I appreciate very much what you have done so far, and I am sorry myself that I also cannot help any more as well. My own time is limited and more fundamentally I am probably not qualified to debug the severe memory management issues that are showing up only for this combination of octave high-level interface and gif device. Everybody who read my previous post now knows how to generate this severe error and investigate it with valgrind so hopefully, one of the other developers here will take up the challenge and figure out this peculiar situation (as well as the other tiny but still annoying memory leaks that I found for the C examples 8 and 11 with the gif device.) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |