From: Alan W. I. <ir...@be...> - 2004-04-08 22:23:51
|
Hi Alan (Bleasby): I am forwarding your bug report to plplot-devel along with my own comments. Thanks for your report. Alan (Irwin) ******************* To PLplot developers (especially Andrew): I forward below a message from Alan Bleasby about memory management problems in PLplot. His first point I disagree with but my conclusion needs to be checked. There may well be something valid in his second point. (1) I have checked that malloc is used in pdf_fopen, and changing to calloc wouldn't hurt. But I notice pdfs->bp = 0 initialization there so I don't see why Alan says there is a problem with a later "+= [that] is done on the bp element." However, I don't trust my C coding skills that much so, Andrew, could you double-check me please? Also, if it turns out a malloc to calloc change is necessary in pdf_fopen, it would have to be done in pdf_finit as well since it is essentially used the same way as pdf_fopen (Note, there is a pdfs->bp = 0 in that routine as well.) Of course, to complement reading through the code to check for memory management troubles, it is a good idea to run valgrind as well. But we have done that. For example, plLibOpenPdfstr (used for fonts and maps) calls pdf_fopen indirectly so pdf_fopen is exercised a lot with no reported valgrind problems. pdf_finit is used by the plmeta device. I have just checked (for the x01c example) that there are no valgrind problems in that case. (2) I compared Alan's xwin.c (URL below) with our own. Clearly, Andrew has already made some of the suggested changes (probably post-5.3.0), but Alan has made additional changes beyond those. Andrew, will you have a look at Alan's xwin.c changes to see if there is anything there that we should incorporate? Alan (Irwin) __________________________ 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 __________________________ ---------- Forwarded message ---------- Date: Thu, 8 Apr 2004 21:19:33 +0100 (BST) From: Alan Bleasby <abl...@hg...> To: ir...@be... Subject: Plplot bug report Hello Alan, I've noticed several problems in PLPLOT 5.3 while updating EMBOSS from plplot 5.0. In fact some of the problems were in 5.0 too and I forgot to pass them on. a) In pdf_fopen: Changed the malloc to be a calloc to avoid a disastrous UMR when, later in the code, a += is done on the bp element. b) xwin.c: a couple of UMRs and a few leaks. If your xwin maintainer wants to pick up: ftp://ftp.hgmp.mrc.ac.uk/pub/ajb/xwin.c he/she can do a diff and check that the required memory frees are in the right place. Sorry not to use your bug system, never could get the hang of them. I suppose I'd better do so soon as we are in the middle of putting a copy of EMBOSS on sourceforge and may well use their system. HTH Alan Bleasby Rosalind Franklin Centre for Genomics Research |
From: Arjen M. <arj...@wl...> - 2004-04-14 07:41:13
|
Hello, I have a question about the possibility to display images with PLplot: - As far as I have seen, there is the routine plimage() which maps an array of z-values onto a colour map and then onto the screen. This routine appears undocumented, so I just detect this from its use in example x20.c. - What I am looking for is a way to display an image like a logo (stored in a GIF file or whatever, that format is not important to me). So, rather than a single value that gets mapped, all three colour components should be used directly ... Is there such a routine? (It seems fairly easy to write one, once you have the image data) Regards, Arjen |
From: Michel P. <Mic...@en...> - 2004-04-14 08:03:12
|
To complement this message, I would like to stress again a question I raised earlier: I would find very useful to have plimage in fortran too. This is the only thing that has, up to now, prevented me from switching completely from PGPLOT to PLplot. I use PLplot for most of my applications (in fortran) but still rely on PGPLOT to display images. plshades1 is not really a replacement. Michel Peyrard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Michel Peyrard, Professeur % Ph: +33 (0)4 7272 8374 % % Laboratoire de Physique % Fax: +33 (0)4 7272 8080 % % Ecole Normale Sup=E9rieure de Lyon % e-mail:Mic...@en... % % 46 all=E9e d'Italie % perso.ens-lyon.fr/michel.peyrard % % 69364 Lyon Cedex 07, France % (GPG key available on home page) % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% On Wed, 14 Apr 2004, Arjen Markus wrote: > Hello, > > I have a question about the possibility to display images with PLplot: > - As far as I have seen, there is the routine plimage() which maps > an array of z-values onto a colour map and then onto the screen. > This routine appears undocumented, so I just detect this from its > use in example x20.c. > - What I am looking for is a way to display an image like a logo > (stored in a GIF file or whatever, that format is not important > to me). So, rather than a single value that gets mapped, all > three colour components should be used directly ... > > Is there such a routine? (It seems fairly easy to write one, once > you have the image data) > > Regards, > > Arjen > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@wl...> - 2004-04-14 08:08:52
|
Michel Peyrard wrote: > > To complement this message, I would like to stress again a question I > raised earlier: I would find very useful to have plimage in fortran too. > This is the only thing that has, up to now, prevented me from switching > completely from PGPLOT to PLplot. I use PLplot for most of my applications > (in fortran) but still rely on PGPLOT to display images. > plshades1 is not really a replacement. > It does not seem too tough - and I have some interest in the Fortran API too. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-04-14 14:43:43
|
On 2004-04-14 10:08+0200 Arjen Markus wrote: > Michel Peyrard wrote: > > > > To complement this message, I would like to stress again a question I > > raised earlier: I would find very useful to have plimage in fortran too. > > This is the only thing that has, up to now, prevented me from switching > > completely from PGPLOT to PLplot. I use PLplot for most of my applications > > (in fortran) but still rely on PGPLOT to display images. > > plshades1 is not really a replacement. > > > > It does not seem too tough - and I have some interest in the Fortran > API too. I looked into this once, and it would take a fair amount of effort to do colour images. The problem is the current plimage is based on colour map 1 which is indexed by a floating point number between 0 and 1 that is used to interpolate smoothly between various colour values. That is great for false-colour plots, and gray scale (as evidenced already by the 20th demo), but awkward for colour images where you would have to order the colour palette in a way where you can interpolate the 3 R,G,B colours or H,L,S values with one index. (That is possible, I think, but the interpolated results probably would not look so hot if one part of the colour palette of the colour image was "distant" from the rest.) I believe the proper solution to this colour image problem is to switch plimage and friends over to use colour map 0 which just simply has an uninterpolated integer index corresponding to each RGB colour in the colour palette. I would encourage making that conversion effort since I agree with Arjen and Michel that colour images are important, but I don't have time to do the required programming and documentation (!) myself. Also note this effort will require an API change for plimage, but I doubt many of our users depend on that undocumented routine at this time, and I think they would be grateful for an API change that would allow colour images. 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-04-15 10:27:17
|
* Alan W. Irwin <ir...@be...> [2004-04-14 07:36]: > On 2004-04-14 10:08+0200 Arjen Markus wrote: > > > Michel Peyrard wrote: > > > > > > To complement this message, I would like to stress again a question I > > > raised earlier: I would find very useful to have plimage in fortran too. > > > This is the only thing that has, up to now, prevented me from switching > > > completely from PGPLOT to PLplot. I use PLplot for most of my applications > > > (in fortran) but still rely on PGPLOT to display images. > > > plshades1 is not really a replacement. > > > > > > > It does not seem too tough - and I have some interest in the Fortran > > API too. > > I looked into this once, and it would take a fair amount of effort to do > colour images. The problem is the current plimage is based on colour map 1 > which is indexed by a floating point number between 0 and 1 that is used to > interpolate smoothly between various colour values. That is great for > false-colour plots, and gray scale (as evidenced already by the 20th demo), > but awkward for colour images where you would have to order the colour > palette in a way where you can interpolate the 3 R,G,B colours or H,L,S > values with one index. (That is possible, I think, but the interpolated > results probably would not look so hot if one part of the colour palette of > the colour image was "distant" from the rest.) > > I believe the proper solution to this colour image problem is to switch > plimage and friends over to use colour map 0 which just simply has an > uninterpolated integer index corresponding to each RGB colour in the colour > palette. I am not sure that switching to color map 0 would be enough. Actually, image storage/manipulation/rendering is a quite complicated problem. Unless you are working with true color (24 bits per pixel), color map management is a real nightmare. Besides that, each image that would be displayed by the PLplot library would have to have its own color map. A reasonable approach would be to use an external library that can do all the work of representing and manipulating images in memory, as well as reading files in different formats (jpeg, png, bmp, etc). Nowadays, the ubiquitous library that can do that is gdk-pixbuf, which is part of GTK/GDK: http://developer.gnome.org/arch/imaging/gdkpixbuf.html This library has a function for rendering a pixbuf to an X drawable, so that it should be possible to get it working with the xwin driver. > I would encourage making that conversion effort since I agree with Arjen > and Michel that colour images are important, but I don't have time to do > the required programming and documentation (!) myself. Also note this > effort will require an API change for plimage, but I doubt many of our > users depend on that undocumented routine at this time, and I think they > would be grateful for an API change that would allow colour images. What is wrong with adding a new function to the API, capable of plotting RGB images, instead of changing the API? Backward-incompatible changes to the API are a real PITA and should be hardly avoided (I guess I already made this point in the past). -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-04-15 13:04:42
|
Rafael Laboissiere wrote: > > * Alan W. Irwin <ir...@be...> [2004-04-14 07:36]: > > > On 2004-04-14 10:08+0200 Arjen Markus wrote: > > > > > Michel Peyrard wrote: > > > > > > > > To complement this message, I would like to stress again a question I > > > > raised earlier: I would find very useful to have plimage in fortran too. > > > > This is the only thing that has, up to now, prevented me from switching > > > > completely from PGPLOT to PLplot. I use PLplot for most of my applications > > > > (in fortran) but still rely on PGPLOT to display images. > > > > plshades1 is not really a replacement. > > > > > > > > > > It does not seem too tough - and I have some interest in the Fortran > > > API too. > > > > I looked into this once, and it would take a fair amount of effort to do > > colour images. The problem is the current plimage is based on colour map 1 > > which is indexed by a floating point number between 0 and 1 that is used to > > interpolate smoothly between various colour values. That is great for > > false-colour plots, and gray scale (as evidenced already by the 20th demo), > > but awkward for colour images where you would have to order the colour > > palette in a way where you can interpolate the 3 R,G,B colours or H,L,S > > values with one index. (That is possible, I think, but the interpolated > > results probably would not look so hot if one part of the colour palette of > > the colour image was "distant" from the rest.) > > > > I believe the proper solution to this colour image problem is to switch > > plimage and friends over to use colour map 0 which just simply has an > > uninterpolated integer index corresponding to each RGB colour in the colour > > palette. > > I am not sure that switching to color map 0 would be enough. Actually, > image storage/manipulation/rendering is a quite complicated problem. Unless > you are working with true color (24 bits per pixel), color map management is > a real nightmare. Besides that, each image that would be displayed by the > PLplot library would have to have its own color map. > > A reasonable approach would be to use an external library that can do all > the work of representing and manipulating images in memory, as well as > reading files in different formats (jpeg, png, bmp, etc). Nowadays, the > ubiquitous library that can do that is gdk-pixbuf, which is part of GTK/GDK: > > http://developer.gnome.org/arch/imaging/gdkpixbuf.html > > This library has a function for rendering a pixbuf to an X drawable, so that > it should be possible to get it working with the xwin driver. > > > I would encourage making that conversion effort since I agree with Arjen > > and Michel that colour images are important, but I don't have time to do > > the required programming and documentation (!) myself. Also note this > > effort will require an API change for plimage, but I doubt many of our > > users depend on that undocumented routine at this time, and I think they > > would be grateful for an API change that would allow colour images. > > What is wrong with adding a new function to the API, capable of plotting RGB > images, instead of changing the API? Backward-incompatible changes to the > API are a real PITA and should be hardly avoided (I guess I already made > this point in the past). > I was thinking along the lines of a new public function too. But is gdk-pixbuf also useable with the other screen drivers, notably win3? Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-04-15 17:42:55
|
* Arjen Markus <arj...@wl...> [2004-04-15 15:04]: > I was thinking along the lines of a new public function too. Yes, this is the way to go. > But is gdk-pixbuf also useable with the other screen drivers, notably > win3? GTK has been ported to Win32: http://www.gimp.org/~tml/gimp/win32/ -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-04-15 15:30:51
|
On 2004-04-15 12:26+0200 Rafael Laboissiere wrote: > What is wrong with adding a new function to the API, capable of plotting RGB > images, instead of changing the API? Backward-incompatible changes to the > API are a real PITA and should be hardly avoided (I guess I already made > this point in the past). It is not a black and white issue, but instead shades of gray. It is a judgement call balancing the one-time PITA of changing the API against the on-going PITA of a bloated API. We have strongly differing viewpoints about which PITA is worse so we'll simply have to agree to disagree on this issue. 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-04-15 17:48:47
|
* Alan W. Irwin <ir...@be...> [2004-04-15 08:30]: > It is not a black and white issue, but instead shades of gray. It is a > judgement call balancing the one-time PITA of changing the API against the > on-going PITA of a bloated API. We have strongly differing viewpoints about > which PITA is worse so we'll simply have to agree to disagree on this issue. The change libplplot5 -> libplplot9 in the Debian packaging caused me a *_HUGE_* headache and the Debian build daemons are still trying to catch up with that. Please, consider the users of the Linux distributions, for whom backward-incompatible changes in the API are a real PITA. That said, why is a bloated API a PITA? It is so harmless... -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-04-16 00:18:42
|
On 2004-04-15 19:48+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-04-15 08:30]: > > > It is not a black and white issue, but instead shades of gray. It is a > > judgement call balancing the one-time PITA of changing the API against the > > on-going PITA of a bloated API. We have strongly differing viewpoints about > > which PITA is worse so we'll simply have to agree to disagree on this issue. > > The change libplplot5 -> libplplot9 in the Debian packaging caused me a > *_HUGE_* headache and the Debian build daemons are still trying to catch up > with that. Please, consider the users of the Linux distributions, for whom > backward-incompatible changes in the API are a real PITA. I recognize your concern, yet all viable software projects do have backwards incompatible API changes from time to time. I do feel we should manage change as best we can to minimize the pain, but a blanket prohibition on backwards incompatible changes for all time is not the correct approach in my view. > > That said, why is a bloated API a PITA? It is so harmless... Not really. Let's take the current case. The new user is reading through the commands and sees plimage. Ah Hah, that is what they want, well-no, maybe plimage_colour or whatever the new one will be called. All the good names get taken by the old API and confuse the new user into avoiding the new more powerful API. Also, there is the effort of maintaining documentation and code for both the old and new commands which do similar but not quite identical things. I do agree each little choice of adding more API doesn't seem like much, but I also assert the long-term cumulative effect is bad as our API gradually gets more and more bloated, our function names get more and more complicated, and our new users consequently have a more and more difficult time of it. Assuming that you see my point, what do you suggest is the best way to get rid of the old cruft while still minimizing the pain of the changes? Surely this is a standard problem that the better software projects deal with in a standard way (other than prohibiting all backwards incompatible changes). I notice, for example, that KDE has allowed backwards incompatible API changes every couple of years as they moved from KDE1 to KDE2 to KDE3, but in between those changes there have been periods of stability where everybody could rely on no backwards incompatible changes in the API. Is that how we should proceed? 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-04-16 07:19:33
|
* Alan W. Irwin <ir...@be...> [2004-04-15 15:51]: > I recognize your concern, yet all viable software projects do have backwards > incompatible API changes from time to time. I do feel we should manage > change as best we can to minimize the pain, but a blanket prohibition on > backwards incompatible changes for all time is not the correct approach in > my view. I never meant a blanket prohibition, please. This is what I wrote: * Rafael Laboissiere <rla...@us...> [2004-04-15 12:26]: > Backward-incompatible changes to the API are a real PITA and should be > hardly avoided. There are cases where backwards incompatible changes are really needed, but in the case of plimage, I think that the change is too gratuitous and is not worth doing. What do the other developers think? (Arjen already expressed agreement with me.) -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-04-16 07:33:59
|
Rafael Laboissiere wrote: > > * Alan W. Irwin <ir...@be...> [2004-04-15 15:51]: > > > I recognize your concern, yet all viable software projects do have backwards > > incompatible API changes from time to time. I do feel we should manage > > change as best we can to minimize the pain, but a blanket prohibition on > > backwards incompatible changes for all time is not the correct approach in > > my view. > > I never meant a blanket prohibition, please. This is what I wrote: > > * Rafael Laboissiere <rla...@us...> [2004-04-15 12:26]: > > > Backward-incompatible changes to the API are a real PITA and should be > > hardly avoided. > > There are cases where backwards incompatible changes are really needed, but > in the case of plimage, I think that the change is too gratuitous and is not > worth doing. What do the other developers think? (Arjen already expressed > agreement with me.) > Yes, as it is, even undocumented, plimage() is quite useable for monochromatic images. It is a bit unfortunate that this is not apparent from the name, but that is a different matter. I would not want to throw it away. The first step that I have in mind is make it accessible in its current form from Fortran. The second is to look at the gdk-pixbuf library. Regards, Arjen |
From: <jc...@fe...> - 2004-04-16 13:38:23
|
On Friday 16 April 2004 08:18, Rafael Laboissiere wrote: | * Alan W. Irwin <ir...@be...> [2004-04-15 15:51]: | > I recognize your concern, yet all viable software projects do have | > backwards incompatible API changes from time to time. I do feel we | > should manage change as best we can to minimize the pain, but a | > blanket prohibition on backwards incompatible changes for all time | > is not the correct approach in my view. | | I never meant a blanket prohibition, please. This is what I wrote: | | * Rafael Laboissiere <rla...@us...> [2004-04-15 12:26]: | > Backward-incompatible changes to the API are a real PITA and should | > be hardly avoided. | | There are cases where backwards incompatible changes are really | needed, but in the case of plimage, I think that the change is too | gratuitous and is not worth doing. What do the other developers | think? (Arjen already expressed agreement with me.) Do we have a color plimage()? When we have one we could restart this thread. Joao |
From: Alan W. I. <ir...@be...> - 2004-04-16 16:04:25
|
On 2004-04-16 09:18+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-04-15 15:51]: > > > I recognize your concern, yet all viable software projects do have backwards > > incompatible API changes from time to time. I do feel we should manage > > change as best we can to minimize the pain, but a blanket prohibition on > > backwards incompatible changes for all time is not the correct approach in > > my view. > > I never meant a blanket prohibition, please. This is what I wrote: > > * Rafael Laboissiere <rla...@us...> [2004-04-15 12:26]: > > > Backward-incompatible changes to the API are a real PITA and should be > > hardly avoided. > > There are cases where backwards incompatible changes are really needed... I am glad we agree on this. But what is the best way to handle such API emergencies so you don't have to go through some apparently horrendous contortions as the Debian packager? > but > in the case of plimage, I think that the change is too gratuitous and is not > worth doing. What do the other developers think? (Arjen already expressed > agreement with me.) Actually, I don't care that strongly in each individual case like this. As I stated there is very little pain in adding new API that does everything the old did with added features (such a colour images). However, the cumulative effect of a series of such changes, API bloat, is something I am quite concerned with, and which I feel we should have a long-term strategy to deal with just like all major software projects do. So I really am interested in your view about the best way to get rid of all the API bloat we have accumulated, and will continue to accumulate as old functions are superseded by new with added capabilities (such as colour images). A year or so from now do we plan a plplot6 where we eliminate the old superseded functions and possibly rename the new ones to more reasonable names? (I assume this is what goes on when say KDE2 is transitioned to KDE3.) If we did have some long-term strategy in place to deal with API bloat, then I would be willing (except for API emergencies like name clashes where there is no other choice then to make a backwards incompatible change) to go along with a temporary blanket prohibition on backwards incompatible API changes between major planned API transitions. 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-04-16 18:25:32
|
* Alan W. Irwin <ir...@be...> [2004-04-16 08:53]: > If we did have some long-term strategy in place to deal with API bloat, then > I would be willing (except for API emergencies like name clashes where there > is no other choice then to make a backwards incompatible change) to go along > with a temporary blanket prohibition on backwards incompatible API changes > between major planned API transitions. This plan sounds reasonable. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-04-16 21:04:49
|
I have changed the subject line because we are on a quite different topic now. More comment below....Alan On 2004-04-16 20:24+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-04-16 08:53]: > > > If we did have some long-term strategy in place to deal with API bloat, then > > I would be willing (except for API emergencies like name clashes where there > > is no other choice then to make a backwards incompatible change) to go along > > with a temporary blanket prohibition on backwards incompatible API changes > > between major planned API transitions. > > This plan sounds reasonable. OK. To further discussion of this plan, I would be willing to summarize a list of possible plplot6 API changes to reduce our API bloat. Everybody here, please send suggestions to me off list. The following is the relatively narrow questions that I will address: * What parts of the PLplot API can safely be discarded when we make the major transition to plplot6? (I will start that list with everything we officially deprecate now.) * What function name changes (if any) will be done? I will specifically avoid dealing with the following related questions, but I think they should be discussed further on list: * Would the advent of plplot6 also be a good time to make our API more consistent? It has grown like topsy so right now we have no API standards. For one example we sometimes have the array dimensions first and sometimes last, and this has greatly complicated our use of automated interface generators like SWIG, but I am sure there are other API inconsistencies as well that we may want to deal with. Do we want to tackle this problem for plplot6 or are the PLplot developers as a group content to continue indefinitely with the present inconsistent API? * Are there other general API changes we should be doing with the advent of plplot6? For an previous important thread on this issue use the search engine at http://sourceforge.net/mailarchive/forum.php?forum_id=2199 to look for "black box handles". That idea petered out because nobody was interested in doing all the effort involved, but our development team is bigger now, and such a project might appeal to somebody here. * Are there some specific API changes that you would like to see with the advent of plplot6? 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-04-17 00:39:43
|
* Alan W. Irwin <ir...@be...> [2004-04-16 12:56]: > To further discussion of this plan, I would be willing to summarize a list > of possible plplot6 API changes to reduce our API bloat. Everybody here, > please send suggestions to me off list. The following is the relatively > narrow questions that I will address: > > [...] What about an approach that is both radical and non-harmful? The radical aspect consists in changing completely the names of the functions (and also some prototypes, aiming at consistency). I would lean to have informative names like in modern libraries. Take the example of the gdk-pixbuf libray, recently discussed in this mailing list. Here are some function of its API: gdk_pixbuf_new gdk_pixbuf_get_colorspace gdk_pixbuf_get_has_alpha gdk_pixbuf_get_bits_per_sample gdk_pixbuf_get_pixels gdk_pixbuf_copy gdk_pixbuf_new_from_file gdk_pixbuf_new_from_data gdk_pixbuf_save gdk_pixbuf_saturate_and_pixelate gdk_pixbuf_scale gdk_pixbuf_animation_iter_on_currently_loading_frame Even if you are a newbie to the gdk-pixbuf library, you can almost immediately tell what each function above is expected to do. For the PLplot library, we could do something like this (the names below are a quick example, just to make my point): plbop -> plplot_begin_new_page plcol0 -> plplot_set_color_map0 plcont -> plplot_plot_contour plfill -> plplot_area_fill plgdev -> plplot_get_current_device_name plgver -> plplot_get_version pllab -> plplot_write_label plline -> plplot_draw_line plot3d -> plplot_plot_3d_surface plptex -> plplot_write_text_in_viewport plsdiori -> plplot_set_orientation plstyl -> plplot_set_line_style plwid -> plplot_set_pen_width etc. The names of the functions in the current PLplot API are way too cryptic and confusing. Besides that, they are too short, what increases the chance of interference with the user's namespace. The non-harmful aspect of this approach is that we can keep both APIs for a certain amount of time. The functions with short, cryptic names would be wrappers to the new functions (or vice-versa). At some point in the not so near future, we could deprecate the old API (or even remove it), but users will have time to switch to the new one. The advantage of this approach is that it does not introduce backwards incompatible changes, so that we keep the library soname. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-04-23 07:56:34
|
Hello, I have a question about deploying a program that uses PLplot: 1. On Linux, the program uses dynamically loadable drivers 2. It should be installed on other machines at clients' site I have tried, but the problem is that unless I have my original directory with the libraries and drivers available, loading, say, the xwin driver will fail. I have done the following: - Set PLPLOT_DRV_DIR to a directory that I can be sure of will exist on the clients' site. - Put the .so and .la files there - Adjusted the .la file (manually for the moment) so that they point to that directory. But via the debugger I have seen that ultimately dlopen() fails. It will not fail if the original directory is available, but that is an unacceptable situation. What can I do about this? Should I use some link flag to get the LD_LIBRARY_PATH mechanism to work properly? Or what other solution is there? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-04-23 09:43:16
|
Arjen Markus wrote: > > Hello, > > I have a question about deploying a program that uses PLplot: > > 1. On Linux, the program uses dynamically loadable drivers > 2. It should be installed on other machines at clients' site > > I have tried, but the problem is that unless I have my original > directory with the libraries and drivers available, loading, > say, the xwin driver will fail. > > I have done the following: > - Set PLPLOT_DRV_DIR to a directory that I can be sure of will > exist on the clients' site. > - Put the .so and .la files there > - Adjusted the .la file (manually for the moment) so that > they point to that directory. > > But via the debugger I have seen that ultimately dlopen() > fails. It will not fail if the original directory is > available, but that is an unacceptable situation. > > What can I do about this? Should I use some link flag to > get the LD_LIBRARY_PATH mechanism to work properly? Or > what other solution is there? > Okay, it seems solved: I have used the shared library instead of the static library and now things are working correctly. I still feel a bit uneasy about it, but at least there seems to be a way forward. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-04-23 12:53:17
|
Hello all, I have extended the set of Fortran bindings and examples by one: example x20f works (well, the sombrero surface) and the plimage seems to work too (possible problems: transfer of the data from Fortran to C). Well, at least the first step is taken now. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-04-17 02:52:48
|
On 2004-04-17 02:38+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-04-16 12:56]: > > > To further discussion of this plan, I would be willing to summarize a list > > of possible plplot6 API changes to reduce our API bloat. Everybody here, > > please send suggestions to me off list. The following is the relatively > > narrow questions that I will address: > > > > [...] > > What about an approach that is both radical and non-harmful? The radical > aspect consists in changing completely the names of the functions (and also > some prototypes, aiming at consistency). I would lean to have informative > names like in modern libraries. Take the example of the gdk-pixbuf libray, > recently discussed in this mailing list. Here are some function of its API: > > gdk_pixbuf_new > gdk_pixbuf_get_colorspace > gdk_pixbuf_get_has_alpha > gdk_pixbuf_get_bits_per_sample > gdk_pixbuf_get_pixels > gdk_pixbuf_copy > gdk_pixbuf_new_from_file > gdk_pixbuf_new_from_data > gdk_pixbuf_save > gdk_pixbuf_saturate_and_pixelate > gdk_pixbuf_scale > gdk_pixbuf_animation_iter_on_currently_loading_frame > > Even if you are a newbie to the gdk-pixbuf library, you can almost > immediately tell what each function above is expected to do. For the PLplot > library, we could do something like this (the names below are a quick > example, just to make my point): > > plbop -> plplot_begin_new_page > plcol0 -> plplot_set_color_map0 > plcont -> plplot_plot_contour > plfill -> plplot_area_fill > plgdev -> plplot_get_current_device_name > plgver -> plplot_get_version > pllab -> plplot_write_label > plline -> plplot_draw_line > plot3d -> plplot_plot_3d_surface > plptex -> plplot_write_text_in_viewport > plsdiori -> plplot_set_orientation > plstyl -> plplot_set_line_style > plwid -> plplot_set_pen_width > etc. > > The names of the functions in the current PLplot API are way too cryptic and > confusing. Besides that, they are too short, what increases the chance of > interference with the user's namespace. > > The non-harmful aspect of this approach is that we can keep both APIs for a > certain amount of time. The functions with short, cryptic names would be > wrappers to the new functions (or vice-versa). At some point in the not so > near future, we could deprecate the old API (or even remove it), but users > will have time to switch to the new one. The advantage of this approach is > that it does not introduce backwards incompatible changes, so that we keep > the library soname. Seems fine to me IF we have a solid commitment to get rid of the old names for plplot6. That is all the documentation of old names should say something like (Deprecated. To be removed for plplot6. Use newname instead), and all our examples should use the newnames instead. Sounds like a good chance to use a script to do all the name conversions that will be necessary, and of course we can provide that to our users as well for their convenience. With documentation revised as above, such a script, and revised examples, and waiting for at least a year (or maybe two) before plplot6, the pain of the plplot6 transition for PLplot users should be minimized. Of course this is a big change so before we go any further with this we need the other developers to comment here. Especially Maurice and Geoffrey, the originators of PLplot. I would also like general comments on the other important plplot6 API questions that I listed in my revious post. 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 __________________________ |