From: Alan W. I. <ir...@be...> - 2004-02-06 07:18:52
Attachments:
test.c
|
c/x14c -dev tk segfaults now whenever you attempt to exit either the primary or secondary gui (with the file or Plot "exit" of either master or slave GUI or by hitting ">>" enough times in the master GUI). It didn't segfault before. If you run valgrind c/x14c -dev tk and ignore all the invalid packet messages you do get an invalid free when you attempt to immediately exit using the GUI file dialog. Here are the details: valgrind --num-callers=40 c/x14c -dev tk ==18647== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==18647== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==18647== Using valgrind-20030725, a program supervision framework for x86-linux. ==18647== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==18647== Estimated CPU clock rate is 604 MHz ==18647== For more details, rerun with: -v ==18647== Demo of multiple output streams via the tk driver. Running with the second window as slave. Badly formatted packet, numRead = 8 .... many repeats as secondary GUI is plotted with obvious rendering errors, but primary GUI is fine, and at the end.... ==18647== Invalid free() / delete / delete[] ==18647== at 0x40027C2A: free (vg_replace_malloc.c:220) ==18647== by 0x40249B5D: c_plend1 (plcore.c:1367) ==18647== by 0x402497C8: c_plend (plcore.c:1307) ==18647== by 0x4024D970: plexit (plctrl.c:1039) ==18647== by 0x413C4075: abort_session (tk.c:895) ==18647== by 0x413C4D90: Abort (tk.c:1614) ==18647== by 0x416F78C5: TclInvokeStringCommand (in /usr/lib/libtcl8.3.so.1) ==18647== by 0x4172F64C: (within /usr/lib/libtcl8.3.so.1) ==18647== by 0x4172FD53: Tcl_EvalEx (in /usr/lib/libtcl8.3.so.1) ==18647== by 0x4173C6CB: (within /usr/lib/libtcl8.3.so.1) ==18647== by 0x4173BE40: (within /usr/lib/libtcl8.3.so.1) ==18647== by 0x4172D489: Tcl_ServiceEvent (in /usr/lib/libtcl8.3.so.1) ==18647== by 0x4172D7AB: Tcl_DoOneEvent (in /usr/lib/libtcl8.3.so.1) ==18647== by 0x413C4C3C: WaitForPage (tk.c:1518) ==18647== by 0x413C3092: plD_eop_tk (tk.c:409) ==18647== by 0x40247030: plP_eop (plcore.c:108) ==18647== by 0x4025B591: c_pladv (plpage.c:45) ==18647== by 0x402617A5: c_plenvi (plvpor.c:126) ==18647== by 0x402616AA: c_plenv (plvpor.c:78) ==18647== by 0x80492BC: plot2 (in /tmp/examples/c/x14c) ==18647== by 0x8049016: main (in /tmp/examples/c/x14c) ==18647== by 0x403550BE: __libc_start_main (in /lib/libc-2.2.5.so) ==18647== by 0x8048CA0: (within /tmp/examples/c/x14c) ==18647== Address 0x413C5FB9 is not stack'd, malloc'd or free'd ==18647== discard syms in /home/software/plplot_cvs/install_location_alternative/lib/plplot5.3.0.cvs.20040205/driversd/tk.so due to munmap() Program aborted ==18647== ==18647== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==18647== malloc/free: in use at exit: 418965 bytes in 7533 blocks. ==18647== malloc/free: 38901 allocs, 31369 frees, 3184422 bytes allocated. ==18647== For a detailed leak analysis, rerun with: --leak-check=yes ==18647== For counts of detected errors, rerun with: -v Andrew, it is not possible to run this example without using -dev tk. However, it is an interesting example because it uses more than one stream, and the resulting segfault on exit may be due to a memory management error that only occurs under a multi-stream environment with -dev tk. The known problems of valgrind and -dev tk may be obfuscating the segfault problem, but nevertheless, this invalid free found by valgrind might be an indication of the source of the problem. I also tried a test.c (attached) that is a slightly simplified variation of x14c.c that uses two separate psc devices. For this case, the valgrind result is absolutely clean with no segfaults, and the resulting test1.ps and test2.ps look good under the gv postscript viewer. But the segfaults are introduced again if you simply do the following patch to test.c, i.e., replace -dev psc by -dev tk for the two now-independent devices and comment out the plsfam calls. --- test.c~ Thu Feb 5 23:00:04 2004 +++ test.c Thu Feb 5 23:05:39 2004 @@ -50,8 +50,8 @@ /* Set up first stream */ - plsdev("psc"); - plsfnam("test1.ps"); + plsdev("tk"); +// plsfnam("test1.ps"); plssub(2, 2); plinit(); @@ -63,8 +63,8 @@ plsetopt("geometry", geometry_slave); plspause(0); - plsdev("psc"); - plsfnam("test2.ps"); + plsdev("tk"); +// plsfnam("test2.ps"); plinit(); /* Set up the data & plot */ Furthermore, if the first device is tk and second psc, there are no segfaults, but if the first device is psc and second tk, there is a segfault. That's the combination that should probably be investigated further. 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: Alan W. I. <ir...@be...> - 2004-02-06 09:59:31
|
On 2004-02-05 23:18-0800 Alan W. Irwin wrote: > Furthermore, if the first device is tk and second psc, there are no > segfaults, but if the first device is psc and second tk, there is a > segfault. That's the combination that should probably be investigated > further. I just now did some more experiments with test.c with the first device always psc and with a variety of second devices. ntk is fine (no segfaults and valgrind runs show no problems except the usual unfreed memory at exit) and xwin is also fine. So it appears this test.c code segfaults only when the second device is tk, and never in any other circumstances. Furthermore, if you believe the valgrind results for this second device tk case, it appears the plend call is attempting to free memory that is not allocated only in that particular case. Andrew, I hope these extra tests help narrow down where the actual problem is occurring. 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-02-06 14:48:49
|
On Fri, Feb 06, 2004 at 01:59:17AM -0800, Alan Irwin wrote: > On 2004-02-05 23:18-0800 Alan W. Irwin wrote: > > > Furthermore, if the first device is tk and second psc, there are no > > segfaults, but if the first device is psc and second tk, there is a > > segfault. That's the combination that should probably be investigated > > further. > > I just now did some more experiments with test.c with the first device > always psc and with a variety of second devices. ntk is fine (no segfaults > and valgrind runs show no problems except the usual unfreed memory at exit) > and xwin is also fine. So it appears this test.c code segfaults only when > the second device is tk, and never in any other circumstances. Furthermore, > if you believe the valgrind results for this second device tk case, it > appears the plend call is attempting to free memory that is not allocated > only in that particular case. > > Andrew, I hope these extra tests help narrow down where the actual problem > is occurring. Cheers for the report Alan. I had actually already found and fixed this bug - but not got the patch submitted. The tk driver tries to set the PLStream variable program itself if the pointer is NULL only it was setting it to a static string. Fix is in CVS. Andrew |
From: Alan W. I. <ir...@be...> - 2004-02-06 18:50:40
|
On 2004-02-06 14:48-0000 Andrew Ross wrote: > Cheers for the report Alan. I had actually already found and fixed this > bug - but not got the patch submitted. The tk driver tries to set > the PLStream variable program itself if the pointer is NULL only it was > setting it to a static string. Fix is in CVS. Thanks, Andrew, for fixing this bug. I absolutely hate segfaults, and it is great to see them knocked off so quickly like this. 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: <jc...@fe...> - 2004-02-06 16:13:01
|
On Friday 06 February 2004 07:18, Alan W. Irwin wrote: | c/x14c -dev tk segfaults now whenever you attempt to exit either | the primary or secondary gui (with the file or Plot "exit" of either | master or slave GUI or by hitting ">>" enough times in the | master GUI). It didn't segfault before. ... | Andrew, it is not possible to run this example without using -dev tk. If you just comment the check for the tk device, and supply xwin (or whatever driver, including tk) in the cmd line, ./x14c -dev xwin, you are able to run the demo with the xwin device, using the right mouse button to advance the plot. If you don't specify the device on the cmd line, you can use any combination of drivers you want, because you are prompted for each one at plinit() time. As a matter of fact I don't know why the tk driver is needed and hard coded! The advance button in the tk driver is equivalent to the enter or right mouse buton. RCS file: /cvsroot/plplot/plplot/examples/c/x14c.c,v retrieving revision 1.23 diff -u -r1.23 x14c.c --- examples/c/x14c.c 19 Jan 2004 23:10:25 -0000 1.23 +++ examples/c/x14c.c 6 Feb 2004 15:48:14 -0000 @@ -49,9 +49,9 @@ (void) plParseOpts(&argc, argv, PL_PARSE_FULL); plgdev(driver); - if (strcmp(driver, "tk") != 0 ) +/* if (strcmp(driver, "tk") != 0 ) plexit("Demo for tk driver only."); - +*/ printf("Demo of multiple output streams via the %s driver.\n", driver); printf("Running with the second window as slave.\n"); printf("\n"); I can't reproduce your segfaults using the tk driver. I have run the demo in the build tree: [jcard@feup] pwd /home/jcard/plplot/examples/c/.libs LD_LIBRARY_PATH=../../../src/.libs/:../../../lib/nn/.libs/:../../../lib/csa/.libs/ valgrind --leak-check=yes --show-reachable=yes ./x14c -dev tk [jcard@feup] valgrind --version valgrind-1.9.5pre Joao |
From: <jc...@fe...> - 2004-02-06 16:41:34
|
On Friday 06 February 2004 16:11, Jo=E3o Cardoso wrote: | On Friday 06 February 2004 07:18, Alan W. Irwin wrote: | | c/x14c -dev tk segfaults now whenever you attempt to exit either | | the primary or secondary gui (with the file or Plot "exit" of | | either master or slave GUI or by hitting ">>" enough times in the | | master GUI). It didn't segfault before. =2E.. | I can't reproduce your segfaults using the tk driver. Obviously this happened after Andrew commit, but before his e-mail=20 arrived. Joao |
From: Alan W. I. <ir...@be...> - 2004-02-06 21:20:53
|
On 2004-02-06 16:11-0000 Jo=E3o Cardoso wrote: > On Friday 06 February 2004 07:18, Alan W. Irwin wrote: > | Andrew, it is not possible to run this example without using -dev tk. > > If you just comment the check for the tk device, and supply xwin (or > whatever driver, including tk) in the cmd line, ./x14c -dev xwin, you > are able to run the demo with the xwin device, using the right mouse > button to advance the plot. > > If you don't specify the device on the cmd line, you can use any > combination of drivers you want, because you are prompted for each one > at plinit() time. I think it is an excellent idea to allow this example to work with any device, and I have just made the commit after testing for no dev specified, -dev tk, -dev xwin, -dev psc, and -dev ntk. The only one that showed problems was -dev ntk that apparently was confusin= g the various streams. Joao, would you be willing to make the fix? Since example 14 is no longer device specific, and it exercises our stream API, I would like to encourage everyone to propagate it to your favorite language interface or update appropriately to be consistent with the new wa= y of doing things. The octave and c++ examples need updating to be consisten= t with the updated c example, the fortran, python, and tcl examples need to b= e done from scratch. I will do the python example 14 first then tcl. Joao would you please update the octave version, and Andrew would you please update the c++ version? Arjen, would you be willing to do the fortran example from scratch? 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: Alan W. I. <ir...@be...> - 2004-02-08 02:56:37
|
On 2004-02-06 13:20-0800 Alan W. Irwin wrote: > I think it is an excellent idea to allow this example to work with any > device, and I have just made the commit after testing for no dev specified, > -dev tk, -dev xwin, -dev psc, and -dev ntk. > > The only one that showed problems was -dev ntk that apparently was confusing > the various streams. Joao, would you be willing to make the fix? > > Since example 14 is no longer device specific, and it exercises our stream > API, I would like to encourage everyone to propagate it to your favorite > language interface or update appropriately to be consistent with the new way > of doing things. The octave and c++ examples need updating to be consistent > with the updated c example, the fortran, python, and tcl examples need to be > done from scratch. I will do the python example 14 first then tcl. Joao > would you please update the octave version, and Andrew would you please > update the c++ version? Arjen, would you be willing to do the fortran > example from scratch? Status: I have finished the python version of this, xw14.py, and also made further changes to x14c.c (polar plot label logic now identical to example 3) so now the python and C versions give identical file results. Further plans: Andrew, you are off the hook about the C++ changes since that is the next example I will do (since the C changes I just did are so similar). Afterward it will be the tcl version from "scratch" although it is pretty easy to copy the appropriate parts of examples 1, 3 and 9. 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: Alan W. I. <ir...@be...> - 2004-02-10 02:27:30
|
On 2004-02-07 18:56-0800 Alan W. Irwin wrote: > On 2004-02-06 13:20-0800 Alan W. Irwin wrote: > > > I think it is an excellent idea to allow this example to work with any > > device, and I have just made the commit after testing for no dev specified, > > -dev tk, -dev xwin, -dev psc, and -dev ntk. > > > > The only one that showed problems was -dev ntk that apparently was confusing > > the various streams. Joao, would you be willing to make the fix? > > > > Since example 14 is no longer device specific, and it exercises our stream > > API, I would like to encourage everyone to propagate it to your favorite > > language interface or update appropriately to be consistent with the new way > > of doing things. The octave and c++ examples need updating to be consistent > > with the updated c example, the fortran, python, and tcl examples need to be > > done from scratch. I will do the python example 14 first then tcl. Joao > > would you please update the octave version, and Andrew would you please > > update the c++ version? Arjen, would you be willing to do the fortran > > example from scratch? > Status: I have updated C++, and made new versions from scratch of the 14th example for python, tcl, and java (one language interface I forgot in the message above). Arjen has kindly volunteered to do the fortran example from scratch. The 14th examples for C++, python, and tcl agree exactly with the C example. The 14th java example does not. There are minor rendering problems (probably due to 16-bit rendering), and there are also API difficulties for exporting C strings to java that I don't know how to fix with swig and which mean you must currently use the menu to set the second device in the 14th java example. That just leaves the -dev ntk stream problems, and inconsistent octave examples. (In fact, the octave inconsistencies extend to about half the standard examples). I think it is important to maintain -dev ntk and the standard octave examples, but I have run out of time/inclination so somebody else will have to step forward. In sum, I am done with the work I want to contribute for the 14th example. 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: Arjen M. <arj...@wl...> - 2004-02-09 07:29:14
|
"Alan W. Irwin" wrote: > > > The only one that showed problems was -dev ntk that apparently was confusing > the various streams. Joao, would you be willing to make the fix? > > Since example 14 is no longer device specific, and it exercises our stream > API, I would like to encourage everyone to propagate it to your favorite > language interface or update appropriately to be consistent with the new way > of doing things. The octave and c++ examples need updating to be consistent > with the updated c example, the fortran, python, and tcl examples need to be > done from scratch. I will do the python example 14 first then tcl. Joao > would you please update the octave version, and Andrew would you please > update the c++ version? Arjen, would you be willing to do the fortran > example from scratch? > Yes, I will do that - catching up with all the discussion after a week of barely being at my desk is a bit stressful, but I caught your question :) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-02-10 02:45:28
|
On 2004-02-09 08:28+0100 Arjen Markus wrote: > "Alan W. Irwin" wrote: > > > > > > > The only one that showed problems was -dev ntk that apparently was confusing > > the various streams. Joao, would you be willing to make the fix? > > > > Since example 14 is no longer device specific, and it exercises our stream > > API, I would like to encourage everyone to propagate it to your favorite > > language interface or update appropriately to be consistent with the new way > > of doing things. The octave and c++ examples need updating to be consistent > > with the updated c example, the fortran, python, and tcl examples need to be > > done from scratch. I will do the python example 14 first then tcl. Joao > > would you please update the octave version, and Andrew would you please > > update the c++ version? Arjen, would you be willing to do the fortran > > example from scratch? > > > > Yes, I will do that. That will be most helpful, Arjen. To make things a lot easier for plot[1-3] you can simply copy what is done in x01f.fm4, for plot4 you can copy x03.f.fm4, and for plot5 you can copy the first example of x09f.fm4. There are a few colour and width adjustments you have to make to plot[1-5] and you also have to put plflush at the end of each, but it is pretty straightforward to get both identical file and interactive results to the other language interfaces. 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: Arjen M. <arj...@wl...> - 2004-02-11 10:02:28
|
Hello, I noticed while using the black/white Postscript driver to save my files, that all colour is translated into black. Should not this be converted into a grayscale? Note: this happens _only_ for colormap 0. For colormap 1 this is being converted into grayscale. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-02-11 10:49:49
|
Hello, here is yet another problem: setting the portrait mode. You can set the portrait mode via the command-line options for certain drivers, but there seems to be a problem/inconsistency setting it via plsdiori(). That is: using the win3 device, the portrait mode works fine, using the ps/psc device, the plot is rotated to landscape/seascape. I will experiment a bit to see if I can get it right in my application. Regards, Arjen |
From: <jc...@fe...> - 2004-02-11 15:24:22
|
On Tuesday 10 February 2004 02:27, Alan W. Irwin wrote: | On 2004-02-07 18:56-0800 Alan W. Irwin wrote: | > On 2004-02-06 13:20-0800 Alan W. Irwin wrote: | > > I think it is an excellent idea to allow this example to work | > > with any device, and I have just made the commit after testing | > > for no dev specified, -dev tk, -dev xwin, -dev psc, and -dev ntk. | > > | > > The only one that showed problems was -dev ntk that apparently | > > was confusing the various streams. Joao, would you be willing to | > > make the fix? | > > | > > Since example 14 is no longer device specific, and it exercises | > > our stream API, I would like to encourage everyone to propagate | > > it to your favorite language interface or update appropriately to | > > be consistent with the new way of doing things. The octave and | > > c++ examples need updating to be consistent with the updated c | > > example, the fortran, python, and tcl examples need to be done | > > from scratch. I will do the python example 14 first then tcl. | > > Joao would you please update the octave version, and Andrew would | > > you please update the c++ version? Arjen, would you be willing | > > to do the fortran example from scratch? | | Status: I have updated C++, and made new versions from scratch of the | 14th example for python, tcl, and java (one language interface I | forgot in the message above). Arjen has kindly volunteered to do the | fortran example from scratch. The 14th examples for C++, python, and | tcl agree exactly with the C example. The 14th java example does | not. There are minor rendering problems (probably due to 16-bit | rendering), and there are also API difficulties for exporting C | strings to java that I don't know how to fix with swig and which mean | you must currently use the menu to set the second device in the 14th | java example. | | That just leaves the -dev ntk stream problems, and inconsistent | octave examples. (In fact, the octave inconsistencies extend to about | half the standard examples). I think it is important to maintain | -dev ntk and the standard octave examples, but I have run out of | time/inclination so somebody else will have to step forward. I'm sorry but I don't have the time during the next couple of months. 1-The Octave x14c.m example uses the same convention of the other x??c.m examples, i.e., use the xwin driver if no driver is previously specified using plsetop(). I can of course change all x??c.m examples. The following patch just comment sout that section of the code. You can do a similar thing for the other x??c.m demos. To try it, just > cd bindings/octave > octave octave:1> plplot_stub octave:2> x14c RCS file: /cvsroot/plplot/plplot/bindings/octave/demos/x14c.m,v retrieving revision 1.9 diff -c -b -u -r1.9 x14c.m cvs diff: conflicting specifications of output style --- x14c.m 28 Jan 2004 17:39:29 -0000 1.9 +++ x14c.m 11 Feb 2004 15:11:19 -0000 @@ -30,10 +30,10 @@ endif device = sprintf("%s",plgdev'); - if(isempty(device)) - device = "xwin"; - plsdev(device); - endif +## if(isempty(device)) +## device = "xwin"; +## plsdev(device); +## endif xleng0 = 400; yleng0 = 300; xoff0 = 200; yoff0 = 200; xleng1 = 400; yleng1 = 300; xoff1 = 500; yoff1 = 500; 2-The ntk driver, as I already said, is incomplete. It lacks window resizing (but has zoom/pan) and precision is low (it should use tcl objects, instead of strings; for this same reason it is also slow). Joao | In sum, I am done with the work I want to contribute for the 14th | example. | | 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 | __________________________ | | | ------------------------------------------------------- | The SF.Net email is sponsored by EclipseCon 2004 | Premiere Conference on Open Tools Development and Integration | See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. | http://www.eclipsecon.org/osdn | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2004-02-11 20:34:58
|
On 2004-02-11 15:22-0000 Jo=E3o Cardoso wrote: > 2-The ntk driver, as I already said, is incomplete. It lacks window > resizing (but has zoom/pan) and precision is low (it should use tcl > objects, instead of strings; for this same reason it is also slow). Joao, as I recall, you made the ntk driver as a proof-of-concept that there= was a simpler way to do the tk driver without all the linking issues. You did prove that, but the general idea of replacing the tk driver with something simpler has not caught on. Although the tk driver has quite a complicated implementation (witness all the recent memory management cleanup issues), w= e have so far been able to maintain it fairly well, and it does provide a lot of functionality that ntk does not have at the present time. What are your preferences for the ntk driver? Turn on by default (the current status), don't configure it by default (i.e., designate it as experimental), or abandon it (delete the code from CVS which of course still preserves a copy in CVS attic.) The problem with the experimental designation, is by default nobody uses it and it gradually falls into worse disrepair. Thus, if there is some hope that you will at least fix the stream bug in the future, I would be happy t= o accept the limited functionality (simple is worth having) and continue with the turning on -dev ntk by default. But, Joao, if you don't think you will maintain the ntk driver ever again, perhaps you should consider the idea of abandoning it. This brings up a more general issue with some of our drivers that I suspect are absolutely never used any more. To be specific, is it time to abandon dg300.c, impress.c, and next.c, and the conex, mskermit, tek4107t, tek4107f= , tekt, tekf, versaterm, and vlt devices (i.e, all but the xterm device) in tek.c? A couple of years ago when this was discussed before, Geoffrey suggested there might be somebody who actually used some of these devices still, but hardware does die after a while, and nobody has ever mentioned t= o me that they use any of these devices so I am bringing up the issue again. 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: <jc...@fe...> - 2004-02-12 15:42:58
|
On Wednesday 11 February 2004 20:34, Alan W. Irwin wrote: | On 2004-02-11 15:22-0000 Jo=E3o Cardoso wrote: | > 2-The ntk driver, as I already said, is incomplete. It lacks window | > resizing (but has zoom/pan) and precision is low (it should use tcl | > objects, instead of strings; for this same reason it is also slow). | | Joao, as I recall, you made the ntk driver as a proof-of-concept that | there was a simpler way to do the tk driver without all the linking | issues. You did prove that, but the general idea of replacing the tk | driver with something simpler has not caught on. Although the tk | driver has quite a complicated implementation (witness all the recent | memory management cleanup issues), we have so far been able to | maintain it fairly well, and it does provide a lot of functionality | that ntk does not have at the present time. | | What are your preferences for the ntk driver? Turn on by default | (the current status), don't configure | it by default (i.e., designate it as experimental), or abandon it | (delete the code from CVS which of course still preserves a copy in | CVS attic.) It was disable by default, it was you that enabled it. I would like to=20 keep it under cvs, perhaps I (or others) get the time to finish it. But my intention was not to replace the tk driver, only to provide an=20 alternative. With its simple building, and the availability of tk in=20 almost all known plateforms, the ntk is an excelent inter-platform=20 driver. But, as you say, the job isn't finished. | The problem with the experimental designation, is by default nobody | uses it and it gradually falls into worse disrepair. Thus, if there | is some hope that you will at least fix the stream bug in the future, | I would be happy to accept the limited functionality (simple is worth | having) and continue with the turning on -dev ntk by default. But, | Joao, if you don't think you will maintain the ntk driver ever again, | perhaps you should consider the idea of abandoning it. Well, I'm alive and still here. | This brings up a more general issue with some of our drivers that I | suspect are absolutely never used any more. To be specific, is it | time to abandon dg300.c, impress.c, and next.c, and the conex, | mskermit, tek4107t, tek4107f, tekt, tekf, versaterm, and vlt devices | (i.e, all but the xterm device) in tek.c? A couple of years ago when | this was discussed before, Geoffrey suggested there might be somebody | who actually used some of these devices still, but hardware does die | after a while, and nobody has ever mentioned to me that they use any | of these devices so I am bringing up the issue again. Disable them by default. If such users exists they will eventually=20 complain. There are other candidates to removal, I'm sure that nobody=20 is using the HP-laserjet 2 nowadays. Where would they get the toner=20 cartdridge? (humm, google gave 402000 hits :( Joao | | 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 | __________________________ | | | ------------------------------------------------------- | SF.Net is sponsored by: Speed Start Your Linux Apps Now. | Build and deploy apps & Web services for Linux with | a free DVD software kit from IBM. Click Now! | http://ads.osdn.com/?ad_id56&alloc_id438&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Maurice L. <mj...@ga...> - 2004-02-13 17:43:18
|
Jo=E3o Cardoso writes: > On Wednesday 11 February 2004 20:34, Alan W. Irwin wrote: > | This brings up a more general issue with some of our drivers that = I > | suspect are absolutely never used any more. To be specific, is it > | time to abandon dg300.c, impress.c, and next.c, and the conex, > | mskermit, tek4107t, tek4107f, tekt, tekf, versaterm, and vlt devic= es > | (i.e, all but the xterm device) in tek.c? A couple of years ago wh= en > | this was discussed before, Geoffrey suggested there might be someb= ody > | who actually used some of these devices still, but hardware does d= ie > | after a while, and nobody has ever mentioned to me that they use a= ny > | of these devices so I am bringing up the issue again. >=20 > Disable them by default. If such users exists they will eventually=20= > complain. There are other candidates to removal, I'm sure that nobod= y=20 > is using the HP-laserjet 2 nowadays. Where would they get the toner=20= > cartdridge? (humm, google gave 402000 hits :( I agree, especially as regards the tek variants, just disable them by d= efault for now. Revisit the issue a couple years from now. :) --=20 Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2004-02-13 21:52:47
|
On 2004-02-13 11:41-0600 Maurice LeBrun wrote: > Jo=E3o Cardoso writes: > > On Wednesday 11 February 2004 20:34, Alan W. Irwin wrote: > > | This brings up a more general issue with some of our drivers that I > > | suspect are absolutely never used any more. To be specific, is it > > | time to abandon dg300.c, impress.c, and next.c, and the conex, > > | mskermit, tek4107t, tek4107f, tekt, tekf, versaterm, and vlt devices > > | (i.e, all but the xterm device) in tek.c? A couple of years ago when > > | this was discussed before, Geoffrey suggested there might be somebod= y > > | who actually used some of these devices still, but hardware does die > > | after a while, and nobody has ever mentioned to me that they use any > > | of these devices so I am bringing up the issue again. > > > > Disable them by default. If such users exists they will eventually > > complain. There are other candidates to removal, I'm sure that nobody > > is using the HP-laserjet 2 nowadays. Where would they get the toner > > cartdridge? (humm, google gave 402000 hits :( > > I agree, especially as regards the tek variants, just disable them by def= ault > for now. Revisit the issue a couple years from now. :) Done. I couldn't get rid of conex, et al. without also getting rid of xterm. AFAIK, we do have the infrastructure in place to delete individual devices for a particular driver, but I don't think tek.c makes use of that infrastructure, and I don't want to rewrite it just so xterm can be in the default list. Furthermore, xterm is pretty lame (monochrome, software fill= ) so you would probably only want to enable it if nothing else worked in any case. The default list of devices is now pared down to cgm png jpeg hp7470 hp7580 lj_hpgl mem null pbm plmeta ps psc pstex tk tkwin xfig xwin Default configured builds are going to be a lot faster now. Should I get rid of hp7470 hp7580 lj_hpgl devices from the hpgl driver as well or is that hardware still in active use? 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 __________________________ |