From: <jc...@fe...> - 2003-02-27 19:05:45
|
Hi, I have a certain amount of improvements in my sources that I'm reserving to commit for a future (not the April) release. The reasoning is that the April release will be to fix bugs. But now I'm starting to think that a newer release will only happen in within a year, as we usually only release once a year, given our limited human resources. I thus think that's a pity that my improvements will only reach users in 2004. Also, the "bug fix" turned out to be a major configuration redesign. My question is if we should not abandon the bug fix release, and take the April opportunity to make a new real release instead. Most of my changes are only small improvements, but I have a new API entry to submit. It's an utility function to grid data, removing the limitation that our 3D data plots have of using regularly sampled data. The new function, plgriddata(), does no plotting at all and implies no changes to any other plplot function, and so it will not break anything. plgriddata() takes non-uniformly sampled data and will resample it using several techniques, returning gridded data ready for use with our 3D data APIs. The new function requires access to an well know external library, Qhull (that Rafael knows well), http://www.thesa.com/software/qhull/, and to other simple libraries, libnn and libcsa, http://www.marine.csiro.au/~sakov/ libnn and libcsa are small libraries not widely know and its configuration does not supports shared libraries. libnn also needs a patch to work with Qhull, because by default it works with "triangle", http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free program. I think that the most effective way of using libnn and libcsa is to incorporate them into our source tree. I have already asked to libcsa and libnn author's permission, and he agreed. Comments? Joao |
From: Thomas J. D. <to...@fi...> - 2005-01-25 12:42:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I see that there is some talk of a new release. I am just about ready to commit changes that would add the new gcw/plplotcanvas driver. Please let me know when a good time to do this will be. There are changes to the build process (obviously), and so it would need a bit of testing first. Has a date been set for the release? I have done a ton of work over the last month or so on the new gcw/plplotcanvas driver. I think that you are going to like it! It even uses the postscript fonts. No unicode yet, though. Cheers, Tom - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB Tier I CRC Chair in Atmospheric Science: http://www.atm.dal.ca/jobs/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9j4VndxDHhfZZdsRAuiDAJ41FrKl8K/sUNt68/l8rBk4I/5U8gCgzDZ8 IC+neruBvQpWxXygOYg4o6E= =dpRc -----END PGP SIGNATURE----- |
From: Rafael L. <rla...@us...> - 2005-01-25 21:32:48
|
* Thomas J. Duck <to...@fi...> [2005-01-25 08:39]: > I see that there is some talk of a new release. I am just about ready to > commit changes that would add the new gcw/plplotcanvas driver. Please let > me know when a good time to do this will be. There are changes to the > build process (obviously), and so it would need a bit of testing first. > Has a date been set for the release? No release date has be set yet. We just agreed that it would be nice to release this year. You see, we are not in a hurry... We did talk though about producing a cvs release tarball. This is a low-commitment release in the sense that we do not guarantee it is breakage-free. Also, we do not advertise these releases very widely. In sum, go ahead with your commits. It is indeed a good time to introduce potential instabilities in cvs, since we are all working on non-trivial changes in HEAD. > I have done a ton of work over the last month or so on the new > gcw/plplotcanvas driver. I think that you are going to like it! It even > uses the postscript fonts. No unicode yet, though. This is indeed very interesting. One of my old plans regarding the gnome driver was to use the freetype library to draw the outline of characters as bpath objects, such that they become naturally scalable with the canvas resolution, besides being directly translatable into Postscript. I am curious to see how you implemented the Postscript fonts in the gcw/plplotcanvas driver. -- Rafael |
From: Alan W. I. <ir...@be...> - 2005-01-26 00:14:31
|
On 2005-01-25 08:39-0400 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I see that there is some talk of a new release. I am just about > ready to commit changes that would add the new gcw/plplotcanvas driver. > Please let me know when a good time to do this will be. Now. See below. > There are changes > to the build process (obviously), and so it would need a bit of testing > first. Has a date been set for the release? No. I think it is at least 3 months away. So I think this would be an ideal time to commit if you are willing to work until the release to make sure your new code is well integrated with the rest of PLplot. The only informal rule we have is please don't knowingly break CVS head for more than the time it takes to make all your commits. If you do break it for some combination of circumstances you haven't tested (like I just did, :-)), move fast to fix the problem when it is brought to your attention. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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. <lab...@ps...> - 2003-02-27 21:02:58
|
* João Cardoso <jc...@fe...> [2003-02-27 19:07]: > But now I'm starting to think that a newer release will only happen in > within a year, as we usually only release once a year, given our > limited human resources. > I thus think that's a pity that my improvements will only reach users in > 2004. Also, the "bug fix" turned out to be a major configuration > redesign. > > My question is if we should not abandon the bug fix release, and take > the April opportunity to make a new real release instead. I think that Alan will agree with me on this: what determines the release number is the improvement in CVS, not the reverse. So, if your changes are integrated and if they build and work correctly until April, I do not see any problem in committing it. We should just be careful to not put HEAD in a severe bad state. > plgriddata() takes non-uniformly sampled data and will resample it using > several techniques, returning gridded data ready for use with our 3D > data APIs. > > The new function requires access to an well know external library, Qhull > (that Rafael knows well), http://www.thesa.com/software/qhull/, > and to other simple libraries, libnn and libcsa, > http://www.marine.csiro.au/~sakov/ Sounds great. > libnn and libcsa are small libraries not widely know and its > configuration does not supports shared libraries. libnn also needs a > patch to work with Qhull, because by default it works with "triangle", > http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free > program. > > I think that the most effective way of using libnn and libcsa is to > incorporate them into our source tree. I have already asked to libcsa and > libnn author's permission, and he agreed. I would avoid this if possible. I took a look at libnn. It compiles fine, but generates only a static lib. I agree with you that integrating it in our source tree is probably the best thing to do. -- Rafael |
From: Joao C. <jc...@fe...> - 2003-02-28 01:00:48
|
On Thursday 27 February 2003 20:49, Rafael Laboissiere wrote: > * Jo=E3o Cardoso <jc...@fe...> [2003-02-27 19:07]: > > But now I'm starting to think that a newer release will only happen i= n > > within a year, as we usually only release once a year, given our > > limited human resources. > > I thus think that's a pity that my improvements will only reach users= in > > 2004. Also, the "bug fix" turned out to be a major configuration > > redesign. > > > > My question is if we should not abandon the bug fix release, and take > > the April opportunity to make a new real release instead. > > I think that Alan will agree with me on this: what determines the relea= se > number is the improvement in CVS, not the reverse. So, if your changes= are > integrated and if they build and work correctly until April, I do not s= ee > any problem in committing it. We should just be careful to not put HEA= D in > a severe bad state. Well, they were working after 5.2.0 but before your configuration changes= =2E As=20 a matter of fact I'm expecting your help with the configuration issue. > > plgriddata() takes non-uniformly sampled data and will resample it us= ing > > several techniques, returning gridded data ready for use with our 3D > > data APIs. > > > > The new function requires access to an well know external library, Qh= ull > > (that Rafael knows well), http://www.thesa.com/software/qhull/, > > and to other simple libraries, libnn and libcsa, > > http://www.marine.csiro.au/~sakov/ > > Sounds great. > > > libnn and libcsa are small libraries not widely know and its > > configuration does not supports shared libraries. libnn also needs a > > patch to work with Qhull, because by default it works with "triangle"= , > > http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free > > program. > > > > I think that the most effective way of using libnn and libcsa is to > > incorporate them into our source tree. I have already asked to libcsa= and > > libnn author's permission, and he agreed. > > I would avoid this if possible. Me too, but we would have to distribute nn and csa ourself, which would p= ut an=20 extra configuration/maintenance burden on ourself. Also, libnn needs a patch, and it is not reasonable in the auto-everythin= g=20 world to ask users to do it for us ;-) > I took a look at libnn. It compiles fine, > but generates only a static lib. I agree with you that integrating it = in > our source tree is probably the best thing to do. The way how I setup them in my sources was to create two subdirectories i= n=20 src, one to hold a striped version of nn and another subdir to hold a str= iped=20 csa. csa can always be built, as it depends on nothing, while nn should o= nly=20 be built if Qhull is available. In the src directory there is a new file,= =20 plgriddata.c, which is always built. As I said in another mail, I don't have much time now, but I can try to u= se=20 the Carnival holiday to update my setup to your configuration changes (th= at=20 you will latter hopefully fix :) and commit them. I will commit my other changes latter. Joao |
From: Alan W. I. <ir...@be...> - 2003-02-27 23:13:11
|
On Thu, 27 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > My question is if we should not abandon the bug fix release, and take > the April opportunity to make a new real release instead. I agree 100 per cent with Rafael's response on this question. What is in CVS at release time defines whether the release is bug-fix or not. > [...]I have a new API > entry to submit. It's an utility function to grid data, removing the > limitation that our 3D data plots have of using regularly sampled data. How does this compare with the pltr1 and pltr2 interpolation that already exists for the plcont and plshade(s) part of our 3D API? I don't mind adding an additional interpolation scheme possibility so long as it can be used in the same way pltr1 and pltr2 are used now. A related issue is this may be a good opportunity to generalize our argumen= t lists for all our 3D functions. For now plcont and plshades allow PLcGrid o= r PLcGrid2 style arguments to pass the x,y information and interpolate with pltr1, pltr2, or any other interpolation function specified by the user. Those arguments have enough generality so that the x,y surface can be irregular in shape (something I need for my research for all the 3D API). Thus, I would like to see the plcont and plshade(s) scheme for passing the x,y information adopted for plsurf3d and the rest of our 3D API. This additional facility should, of course, be implemented as added API rather than changed API. There is certainly a place for simple 3D API call= s where x and y appear as separate arrays rather than as part of a PLcGrid or PLcGrid2 structure. But I (and presumably many other users) need the other more general alternative as well. To be blunt about this, gnuplot has allowed irregular shaped x,y domains for all their 3D API since 1996, and I think it is long past time that PLplot caught up. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-02-28 01:01:38
|
On Thursday 27 February 2003 23:11, Alan W. Irwin wrote: > On Thu, 27 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > My question is if we should not abandon the bug fix release, and take > > the April opportunity to make a new real release instead. > > I agree 100 per cent with Rafael's response on this question. What is = in > CVS at release time defines whether the release is bug-fix or not. > > > [...]I have a new API > > entry to submit. It's an utility function to grid data, removing the > > limitation that our 3D data plots have of using regularly sampled dat= a. > > How does this compare with the pltr1 and pltr2 interpolation that alrea= dy > exists for the plcont and plshade(s) part of our 3D API? I don't mind > adding an additional interpolation scheme possibility so long as it > can be used in the same way pltr1 and pltr2 are used now. I didn't take the approach of provinding another pltr*(). Instead, if the user has irregularly sampled data he must call plgriddata= () to=20 obtain gridded data; after that he can use the usual 3D data APIs, whatev= er=20 they are, from plshade() to plot3d(), plsurf3d() or whatsoever. That's why I call plgriddata() an utility function, as the user can use i= ts=20 own gridding algorithm instead. This is the relevant plplot.h section: /* grid irregularly sampled data */ void plgriddata(PLFLT *x, PLFLT *y, PLFLT *z, int npts, =09 PLFLT *xg, int nptsx, PLFLT *yg, int nptsy, =09 PLFLT **zg, int type, PLFLT data); /* type of gridding algorithm for plgriddata() */ #define GRID_CSA 1 /* Bivariate Cubic Spline approximation */ #define GRID_DTLI 2 /* Delaunay Triangulation Linear Interpolation */ #define GRID_NNI 3 /* Natural Neighbors Interpolation */ #define GRID_NNIDW 4 /* Nearest Neighbors Inverse Distance Weighted */ #define GRID_NNLI 5 /* Nearest Neighbors Linear Interpolation */ #define GRID_NNAIDW 6 /* Nearest Neighbors Around Inverse Distance Weight= ed =20 */ GRID_CSA uses libcsa, GRID_DTLI and GRID_NNI uses nn (that uses Qhull), = while=20 GRID_NNIDW, GRID_NNLI and GRID_NNAIDW are implemented in plgriddata.c. x, y and z are ntps sized input arrays; xg[ntpsx] and yg[ntpsy] define th= e=20 desired grid size and spacing, while zg[nptsx][nptsy] is the output gridd= ed=20 data. > A related issue is this may be a good opportunity to generalize our > argument lists for all our 3D functions. For now plcont and plshades al= low > PLcGrid or PLcGrid2 style arguments to pass the x,y information and > interpolate with pltr1, pltr2, or any other interpolation function > specified by the user. Those arguments have enough generality so that t= he > x,y surface can be irregular in shape (something I need for my research= for > all the 3D API). Thus, I would like to see the plcont and plshade(s) sc= heme > for passing the x,y information adopted for plsurf3d and the rest of ou= r 3D > API. I really don't want to mess with some plot functions internals. Often the= y=20 were designed with a certain objective in mind, and changing them with=20 another objective can turns the code confusing. This does not means that it can't be done, perhaps in an elegant way, I d= on't=20 know, as I never looked at them from that perspective. > This additional facility should, of course, be implemented as added API > rather than changed API. There is certainly a place for simple 3D API > calls where x and y appear as separate arrays rather than as part of a > PLcGrid or PLcGrid2 structure. But I (and presumably many other users) > need the other more general alternative as well. To be blunt about thi= s, > gnuplot has allowed irregular shaped x,y domains for all their 3D API s= ince > 1996, and I think it is long past time that PLplot caught up. I don't know how gnuplot does it internally, I only know that irregular=20 gridded data is allowed. Joao > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astron= omy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the Canadian Centre for Climate Modelling= and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2003-02-28 02:58:01
|
On Fri, 28 Feb 2003, Joao Cardoso wrote: > On Thursday 27 February 2003 23:11, Alan W. Irwin wrote: > > A related issue is this may be a good opportunity to generalize our > > argument lists.... > > I really don't want to mess with some plot functions internals. [...] > This does not means that it can't be done, perhaps in an elegant way, I don't > know, as I never looked at them from that perspective. OK. After the next release (which will presumably contain your current set of changes) I will look into the additional issue I have brought up. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Christophe T. <deb...@ti...> - 2003-02-28 12:49:26
|
On Fri, 28 Feb 2003, Joao Cardoso <jc...@fe...> wrote: > > On Thursday 27 February 2003 20:49, Rafael Laboissiere wrote: > > * João Cardoso <jc...@fe...> [2003-02-27 19:07]: > > > I think that the most effective way of using libnn and libcsa is > > > to incorporate them into our source tree. I have already asked > > > to libcsa and libnn author's permission, and he agreed. > > > > I would avoid this if possible. > > Me too, but we would have to distribute nn and csa ourself, which > would put an extra configuration/maintenance burden on ourself. > Also, libnn needs a patch, and it is not reasonable in the > auto-everything world to ask users to do it for us ;-) Wouldn't the better solution be that the author of libnn agrees to merge the patch in his sources? Has this been asked? ChriS |
From: Rafael L. <lab...@ps...> - 2003-02-28 14:04:59
|
* Christophe TROESTLER <deb...@ti...> [2003-02-28 13:49]: > Wouldn't the better solution be that the author of libnn agrees to > merge the patch in his sources? Has this been asked? Probably, but there will be still the problem of asking the users to build and install libnn in their system. I think that this is the most important concern. If we integrate libnn in our source tree, I can quickly generate a Makefile.am with Libtool support for it. Actually, it is already done. Here is the Makefile.am: lib_LTLIBRARIES = libnn.la libnn_la_SOURCES = delaunay.c hash.c istack.c linear.c minell.c \ nnai.c nnpi.c nncommon.c triangle.c libnn_la_LDFLAGS = -version 0:0:0 -lm AM_CPPFLAGS = -I. -DME_UTIL -DTRILIBRARY And here is the configure.ac: AC_INIT(nn.h) AC_CONFIG_HEADERS(nnconfig.h) AM_INIT_AUTOMAKE(nn, 1.23) AM_PROG_CC_STDC AM_PROG_LIBTOOL AC_OUTPUT(Makefile) This will produce the libraries libnn.a and libnn.so.0.0.0 -- Rafael |
From: <jc...@fe...> - 2003-02-28 14:34:54
|
On Friday 28 February 2003 13:51, Rafael Laboissiere wrote: | * Christophe TROESTLER <deb...@ti...> [2003-02-28 13:49]: | > Wouldn't the better solution be that the author of libnn agrees to | > merge the patch in his sources? Has this been asked? I sent him the patch, but he didn't show much interest. He is using "triangle", which he thinks is more robust than Qhull, and would have to maintain code he is not familiar with. | Probably, but there will be still the problem of asking the users to | build and install libnn in their system. I think that this is the | most important concern. If we integrate libnn in our source tree, I | can quickly generate a Makefile.am with Libtool support for it. | | Actually, it is already done. Here is the Makefile.am: | | lib_LTLIBRARIES = libnn.la | libnn_la_SOURCES = delaunay.c hash.c istack.c linear.c minell.c \ | nnai.c nnpi.c nncommon.c triangle.c | libnn_la_LDFLAGS = -version 0:0:0 -lm | AM_CPPFLAGS = -I. -DME_UTIL -DTRILIBRARY hmm, I was thinking to put the new libraries object files into libplplot, to easy the linking of users apps. But if we install libnn and libcsa the user can use the libraries independently. What do you think about this? Joao | And here is the configure.ac: | | AC_INIT(nn.h) | AC_CONFIG_HEADERS(nnconfig.h) | AM_INIT_AUTOMAKE(nn, 1.23) | AM_PROG_CC_STDC | AM_PROG_LIBTOOL | AC_OUTPUT(Makefile) | | This will produce the libraries libnn.a and libnn.so.0.0.0 |
From: Rafael L. <lab...@ps...> - 2003-02-28 15:22:55
|
* João Cardoso <jc...@fe...> [2003-02-28 14:36]: > hmm, I was thinking to put the new libraries object files into > libplplot, to easy the linking of users apps. But if we install libnn > and libcsa the user can use the libraries independently. What do you > think about this? I would prefer to generate separate shared libraries for nn and csa, if possible. In this case, there will be separation both in the source tree and in the final result. A "bonus track", as you mention, is the fact that users can link separately with the libraries. For that, I can imagine generating a Debian package called, say, plplot-nn-csa. An aside note: have you came across a "bug" in nnpi.c where hash.c is included instead of hash.h? -- Rafael |
From: <jc...@fe...> - 2003-02-28 15:56:23
|
On Friday 28 February 2003 15:09, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-02-28 14:36]: | > hmm, I was thinking to put the new libraries object files into | > libplplot, to easy the linking of users apps. But if we install | > libnn and libcsa the user can use the libraries independently. What | > do you think about this? | | I would prefer to generate separate shared libraries for nn and csa, | if possible. In this case, there will be separation both in the | source tree and in the final result. OK, but configure should be run only once, checking for Qhull, defining=20 a HAVE_QHULL in config.h, and them making csa and (conditionally) nn.=20 libnn and (conditionally) libcsa and (conditionally) libqhull must then=20 be added to the dependency libs of libplplot, the same that is done=20 with libfreetype(1). Rafael, if you have time, could you setup things for this :-? Then I only have to commit src/plgriddata.c, examples/c/x21c.c, and the=20 changes to nn/delauny.c (and the patch file itself). In my sources, which I don't have at hand, I only use from the original=20 tarball the *.[ch] files plus README, where the license is (2).=20 triangle.* doesn't need (and shouldn't) be committed. | A "bonus track", as you mention, is the fact that users can link | separately with the libraries. For that, I can imagine generating a | Debian package called, say, plplot-nn-csa. | | An aside note: have you came across a "bug" in nnpi.c where hash.c is | included instead of hash.h? I don't have the sources at hand. Also, I worked with nn and csa=20 versions which are not the current ones. Joao (1)-Another point that I have not digged into is the float/double issue.=20 While Qhull can be compiled for both float or double (we can check for=20 this at configure time), nn and csa use doubles; one might have to=20 disable nn/csa if the user wants to compile plplot with floats. (2)- Please take a look at the license. It looks a bit confusing for a=20 civilian. When I ask Pavel (nn/csa author's) for a clarification, he=20 said: >This licence does _not_ explicitely demand > ><BEGIN excerpt from GPL> >b) You must cause any work that you distribute or publish, that in=20 whole=20 >or in part contains or is derived from the Program or any part thereof,=20 >to be licensed as a whole at no charge to all third parties under the=20 >terms of this License.=20 ><END> > >Therefore I would be happy if we quietly implied that "BOTH SOURCE AND=20 >OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE" >refers to the _modified_ code only, not the whole application it is=20 used > in. I _think_ it should be legally safe to use this code in commercial > applications as long as the modified code retains copyright and is=20 made > public. |
From: Rafael L. <lab...@ps...> - 2003-02-28 18:31:27
|
* João Cardoso <jc...@fe...> [2003-02-28 15:57]: > Rafael, if you have time, could you setup things for this :-? > Then I only have to commit src/plgriddata.c, examples/c/x21c.c, and the > changes to nn/delauny.c (and the patch file itself). Please, commit all the necessary files to the CVS repository, including the nn and csa ones (should we create a lib/ directory for that in the CVS tree? in this case, you could put the files under lib/nn/ and lib/csa/). I will then make the changes in configure.ac and create the necessary Makefile.am's. > (1)-Another point that I have not digged into is the float/double issue. > While Qhull can be compiled for both float or double (we can check for > this at configure time), nn and csa use doubles; one might have to disable > nn/csa if the user wants to compile plplot with floats. Is that really necessary? Can't you cast the values returned by nn/csa with PLFLOAT? > (2)- Please take a look at the license. It looks a bit confusing for a > civilian. When I ask Pavel (nn/csa author's) for a clarification, he > said: > > >This licence does _not_ explicitely demand > > > > <BEGIN excerpt from GPL> > > b) You must cause any work that you distribute or publish, that in whole > > or in part contains or is derived from the Program or any part thereof, to > > be licensed as a whole at no charge to all third parties under the terms of > > this License. > > <END> > > > > Therefore I would be happy if we quietly implied that "BOTH SOURCE AND > > OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE" > > refers to the _modified_ code only, not the whole application it is used > > in. I _think_ it should be legally safe to use this code in commercial > > applications as long as the modified code retains copyright and is > > made public. Looking at the License statement in the README file and Pavel's comments above, I think that nn and csa can be considered free software. If you are really concerned about this, we can ask in the mailing list debian-legal. -- Rafael |
From: <jc...@fe...> - 2003-02-28 19:24:21
|
On Friday 28 February 2003 18:18, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-02-28 15:57]: | > Rafael, if you have time, could you setup things for this :-? | > Then I only have to commit src/plgriddata.c, examples/c/x21c.c, and | > the changes to nn/delauny.c (and the patch file itself). | | Please, commit all the necessary files to the CVS repository, OK, I will do it ASAP. | including the nn and csa ones (should we create a lib/ directory for | that in the CVS tree? There is already a lib directory, but holds font and map files. We could=20 take the opportunity to change this, as the files in that directory all=20 have cvs version 1.1, and no cvs history will be lost. They could be moved to a new directory called "data", after all they are=20 installed in $(prefix)/...../data/. Only in the main Makefile.am a data subdirectory needs to be added in=20 src_dirs to accomplish this. Does everybody agrees with this? | in this case, you could put the files under | lib/nn/ and lib/csa/). I will then make the changes in configure.ac | and create the necessary Makefile.am's. | | > (1)-Another point that I have not digged into is the float/double | > issue. While Qhull can be compiled for both float or double (we can | > check for this at configure time), nn and csa use doubles; one | > might have to disable nn/csa if the user wants to compile plplot | > with floats. | | Is that really necessary? Can't you cast the values returned by | nn/csa with PLFLOAT? The default plplot configuration will be with-double, as everybody=20 agreed on this (even if by omission). If the user specified that he wants floats instead, he must have its own=20 reasons, and must have what he wants (and deserves). Don't you agree? | | > (2)- Please take a look at the license. It looks a bit confusing | > for a civilian. When I ask Pavel (nn/csa author's) for a | > clarification, he | > | > said: | > >This licence does _not_ explicitely demand | > > | > > <BEGIN excerpt from GPL> | > > b) You must cause any work that you distribute or publish, that | > > in whole or in part contains or is derived from the Program or | > > any part thereof, to be licensed as a whole at no charge to all | > > third parties under the terms of this License. | > > <END> | > > | > > Therefore I would be happy if we quietly implied that "BOTH | > > SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE" | > > refers to the _modified_ code only, not the whole application it | > > is used in. I _think_ it should be legally safe to use this code | > > in commercial applications as long as the modified code retains | > > copyright and is made public. | | Looking at the License statement in the README file and Pavel's | comments above, I think that nn and csa can be considered free | software. If you are really concerned about this, we can ask in the | mailing list debian-legal. If it's OK for you is fine for me :) Joao |
From: Rafael L. <lab...@ps...> - 2003-02-28 20:20:14
|
* João Cardoso <jc...@fe...> [2003-02-28 19:27]: > There is already a lib directory, but holds font and map files. We could > take the opportunity to change this, as the files in that directory all > have cvs version 1.1, and no cvs history will be lost. > They could be moved to a new directory called "data", after all they are > installed in $(prefix)/...../data/. > Only in the main Makefile.am a data subdirectory needs to be added in > src_dirs to accomplish this. > Does everybody agrees with this? Okay for me. > | Is that really necessary? Can't you cast the values returned by > | nn/csa with PLFLOAT? > > The default plplot configuration will be with-double, as everybody agreed > on this (even if by omission). My recollection is that Maurice objected. > If the user specified that he wants floats instead, he must have its own > reasons, and must have what he wants (and deserves). Don't you agree? I agree, but you did not answer my question, probably because I made a typo. Here I go again: Can't you cast the values returned by nn/csa with PLFLT? > | Looking at the License statement in the README file and Pavel's > | comments above, I think that nn and csa can be considered free > | software. If you are really concerned about this, we can ask in the > | mailing list debian-legal. > > If it's OK for you is fine for me :) Let us assume that nn/csa is free software. We must though remind to add a note at the PLplot copyright file. -- Rafael |
From: <jc...@fe...> - 2003-02-28 20:42:28
|
On Friday 28 February 2003 20:07, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-02-28 19:27]: | > There is already a lib directory, but holds font and map files. We | > could take the opportunity to change this, as the files in that | > directory all have cvs version 1.1, and no cvs history will be | > lost. | > They could be moved to a new directory called "data", after all | > they are installed in $(prefix)/...../data/. | > Only in the main Makefile.am a data subdirectory needs to be added | > in src_dirs to accomplish this. | > Does everybody agrees with this? | | Okay for me. | | > | Is that really necessary? Can't you cast the values returned by | > | nn/csa with PLFLOAT? | > | > The default plplot configuration will be with-double, as everybody | > agreed on this (even if by omission). | | My recollection is that Maurice objected. Yes, it slipped from my mind until I saw Alan's last e-mail. I have just=20 now replied to it. | > If the user specified that he wants floats instead, he must have | > its own reasons, and must have what he wants (and deserves). Don't | > you agree? | | I agree, but you did not answer my question, probably because I made | a typo. Here I go again: Can't you cast the values returned by nn/csa | with PLFLT? No, data arrays are passed by reference. With nn/csa/qhull array data=20 flows in both directions. If the user wants to use floats because he has huge amounts of float=20 data we would have convert it all back and forth. And the main user=20 concern, memory space, would be jeopardized anyway.=20 Joao |
From: Rafael L. <lab...@ps...> - 2003-02-28 21:14:12
|
* João Cardoso <jc...@fe...> [2003-02-28 20:45]: > No, data arrays are passed by reference. With nn/csa/qhull array data > flows in both directions. If the user wants to use floats because he has > huge amounts of float data we would have convert it all back and forth. I see. My proposal was to do the cast transparently in your plgriddata function, so that the user would never know. > And the main user concern, memory space, would be jeopardized anyway. Is memory space the main concern? I never knew that! Why should we care about this anachronic PLFLT thing if computers are delivered today with 3 Gb of RAM, typically? ;-) -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-02-28 21:30:38
|
Rafael Laboissiere writes: > Is memory space the main concern? I never knew that! Why should we care > about this anachronic PLFLT thing if computers are delivered today with 3 Gb > of RAM, typically? ;-) My laptop only has 256M of memory.. Another reason as Alan mentions is to handle legacy codes. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2003-02-28 21:21:34
|
On Fri, 28 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > | I agree, but you did not answer my question, probably because I made > | a typo. Here I go again: Can't you cast the values returned by nn/csa > | with PLFLT? > > No, data arrays are passed by reference. With nn/csa/qhull array data > flows in both directions. > If the user wants to use floats because he has huge amounts of float > data we would have convert it all back and forth. And the main user > concern, memory space, would be jeopardized anyway. I take your point about memory space, but users may still want single-precision to work as a convenience because their application programme is inherently single precision. We do serve the scientific plotting community, and there is still a large number of fortran single-precision applications around (as I am just re-discovering in my current contract). It is extremely convenient to be able to use PLplot directly from such a large application without having to do anything specia= l with the precision of the PLplot arguments (or the inconvenient alternative of writing the results to a file which is then read by a special double-precision PLplot application). Thus, I hope very much that you do make an effort to completely support bot= h single and double (by allocating the space, copying the arrays, etc.) just as in the rest of PLplot. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-03-01 03:45:09
|
On Friday 28 February 2003 21:20, Alan W. Irwin wrote: > On Fri, 28 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > | I agree, but you did not answer my question, probably because I mad= e > > | a typo. Here I go again: Can't you cast the values returned by nn/c= sa > > | with PLFLT? > > > > No, data arrays are passed by reference. With nn/csa/qhull array data > > flows in both directions. > > If the user wants to use floats because he has huge amounts of float > > data we would have convert it all back and forth. And the main user > > concern, memory space, would be jeopardized anyway. > > I take your point about memory space, but users may still want > single-precision to work as a convenience because their application > programme is inherently single precision. We do serve the scientific > plotting community, and there is still a large number of fortran > single-precision applications around (as I am just re-discovering in my > current contract). It is extremely convenient to be able to use PLplot > directly from such a large application without having to do anything > special with the precision of the PLplot arguments (or the inconvenient > alternative of writing the results to a file which is then read by a > special > double-precision PLplot application). > > Thus, I hope very much that you do make an effort to completely support > both single and double (by allocating the space, copying the arrays, et= c.) > just as in the rest of PLplot. Please see my other e-mail on "configuration defaults". In short, I think= that=20 if the user has specified float we must not use doubles. Joao > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astron= omy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the Canadian Centre for Climate Modelling= and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Rafael L. <lab...@ps...> - 2003-02-28 21:35:14
|
* Maurice LeBrun <mj...@ga...> [2003-02-28 15:29]: > Rafael Laboissiere writes: > > Is memory space the main concern? I never knew that! Why should we care > > about this anachronic PLFLT thing if computers are delivered today with 3 Gb > > of RAM, typically? ;-) > > My laptop only has 256M of memory.. > > Another reason as Alan mentions is to handle legacy codes. Okay, I got the points. I was just joking above... I am looking forward for my next workstation with 3Gb RAM, though. -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-03-01 10:31:17
|
Rafael Laboissiere writes: > * Maurice LeBrun <mj...@ga...> [2003-02-28 15:29]: > > > Rafael Laboissiere writes: > > > Is memory space the main concern? I never knew that! Why should we care > > > about this anachronic PLFLT thing if computers are delivered today with 3 Gb > > > of RAM, typically? ;-) > > > > My laptop only has 256M of memory.. > > > > Another reason as Alan mentions is to handle legacy codes. > > Okay, I got the points. I was just joking above... I am looking forward > for my next workstation with 3Gb RAM, though. Me too. :) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |