Menu
▾
▴
plplot-devel
|
From: Doug H. <dh...@uc...> - 2003-03-04 22:32:44
Attachments:
plsym.c
plsym.c.patch
|
Hi Rafael: I was wondering if you could do me a favor. I have a small
patch
to PLplot 5.2.0 which should not cause any problems. I don't have
developer CVS access
and in any case I don't have all the GNU autoconf tools up to the right
version to get the CVS
source to build.
The patch is attached, along with the complete new version of plsym.c.
This patch affects the plmtex() function. Currently one can plot left
and right of the axis, with text parallel or perpendicular to the axis by
specifying 'side' = ('l', 'r', 'lv' or 'bv'). One cannot, however, plot
with text perpendicular to
the axis on the top or bottom. My patch adds the 'tv' and 'bv'
specifiers. I have tested this
under linux and it seems to work.
Could you apply this patch to the current CVS?
Thanks much!
--Doug Hunt
|
|
From: Rafael L. <lab...@ps...> - 2003-03-05 09:53:34
|
* Doug Hunt <dh...@uc...> [2003-03-04 15:32]:
> The patch is attached, along with the complete new version of plsym.c.
> This patch affects the plmtex() function. Currently one can plot left and
> right of the axis, with text parallel or perpendicular to the axis by
> specifying 'side' = ('l', 'r', 'lv' or 'bv'). One cannot, however, plot
> with text perpendicular to the axis on the top or bottom. My patch adds
> the 'tv' and 'bv' specifiers. I have tested this under linux and it seems
> to work.
>
> Could you apply this patch to the current CVS?
I applied your patch and it seems to work correctly. Since it does not
break anything and does not introduce backwards incompatibilities, I went on
and CVS committed it. The documentation in doc/docboook/src/api.xml has
been also updated accordingly.
Thanks for your contribution.
How is the work on the PLplotOO module going?
--
Rafael
|
|
From: Doug H. <dh...@uc...> - 2003-03-05 17:04:02
|
Thanks, Rafael!
I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO')
into the PDL CVS. There are some bugs still which I plan on fixing
today. It has conditional compile support for both plplot versions
5.1.1 and 5.2.0.
BTW: Is there a better way of determining the version of plplot
installed on a system besides looking at the file name that the
libplplotd.so symlink points to?
Regards,
Doug
Rafael Laboissiere wrote:
>* Doug Hunt <dh...@uc...> [2003-03-04 15:32]:
>
>
>
>>The patch is attached, along with the complete new version of plsym.c.
>>This patch affects the plmtex() function. Currently one can plot left and
>>right of the axis, with text parallel or perpendicular to the axis by
>>specifying 'side' = ('l', 'r', 'lv' or 'bv'). One cannot, however, plot
>>with text perpendicular to the axis on the top or bottom. My patch adds
>>the 'tv' and 'bv' specifiers. I have tested this under linux and it seems
>>to work.
>>
>>Could you apply this patch to the current CVS?
>>
>>
>
>I applied your patch and it seems to work correctly. Since it does not
>break anything and does not introduce backwards incompatibilities, I went on
>and CVS committed it. The documentation in doc/docboook/src/api.xml has
>been also updated accordingly.
>
>Thanks for your contribution.
>
>How is the work on the PLplotOO module going?
>
>
>
|
|
From: Rafael L. <lab...@ps...> - 2003-03-05 17:55:06
|
* Doug Hunt <dh...@uc...> [2003-03-05 10:03]:
> I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO')
> into the PDL CVS. There are some bugs still which I plan on fixing
> today. It has conditional compile support for both plplot versions
> 5.1.1 and 5.2.0.
Great. When is the next release of PDL (or your module) expected to come
out?
> BTW: Is there a better way of determining the version of plplot
> installed on a system besides looking at the file name that the
> libplplotd.so symlink points to?
Please, never, never, NEVER, do this. Although the library soname have
coincided with the package version up to now, this is not going to be
necessarily the case in the future.
If you have pkg-config installed, you can use
pkg-config plplot-double --modversion
if PLplot was build --with-double, or
pkg-config plplot --modversion
if not.
For more information on pkg-config, see:
http://www.freedesktop.org/software/pkgconfig/
--
Rafael
|
|
From: Doug H. <dh...@uc...> - 2003-03-05 21:43:21
|
Rafael: >* Doug Hunt <dh...@uc...> [2003-03-05 10:03]: > > > >>I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO') >>into the PDL CVS. There are some bugs still which I plan on fixing >>today. It has conditional compile support for both plplot versions >>5.1.1 and 5.2.0. >> >> > >Great. When is the next release of PDL (or your module) expected to come >out? > Hopefully soon, but no date has been set. I would guess 1-2 months. > > > >>BTW: Is there a better way of determining the version of plplot >>installed on a system besides looking at the file name that the >>libplplotd.so symlink points to? >> >> > >Please, never, never, NEVER, do this. Although the library soname have >coincided with the package version up to now, this is not going to be >necessarily the case in the future. > OK, I now changed my auto-detector in Makefile.PL to do a test compile and check the allowed number of args in plpoly3 instead of looking at the library version. I can't assume that any target system will have pkg-config installed. All: Please keep the API-breaking changes to an absolute minimum! The code for perl/PDL to detect different versions is ugly and takes much time to maintain. It would have been preferable to just create a new plpoly3 function with the extra argument instead of changing the old one. Thanks! Doug Hunt > >If you have pkg-config installed, you can use > > pkg-config plplot-double --modversion > >if PLplot was build --with-double, or > > pkg-config plplot --modversion > >if not. > >For more information on pkg-config, see: > > http://www.freedesktop.org/software/pkgconfig/ > > > |
|
From: Rafael L. <lab...@ps...> - 2003-03-06 10:12:18
|
* Doug Hunt <dh...@uc...> [2003-03-05 14:43]: > >Great. When is the next release of PDL (or your module) expected to come > >out? > > > Hopefully soon, but no date has been set. I would guess 1-2 months. Super. That will coincide with the next release of PLplot. > OK, I now changed my auto-detector in Makefile.PL to do a test compile and > check the allowed number of args in plpoly3 instead of looking at the > library version. I can't assume that any target system will have > pkg-config installed. You might also use the plgver API function. > All: Please keep the API-breaking changes to an absolute minimum! The > code for perl/PDL to detect different versions is ugly and takes much time > to maintain. It would have been preferable to just create a new plpoly3 > function with the extra argument instead of changing the old one. I agree 100 % with you. I think that the changes in the API were inappropriate, both in plpoly3 and plend1/plend. This was done probably because we thought that PLplot were not yet a so big and important project and that users usually recompile their applications for every release. We wrongly thought then that "improving" the API by breaking backward compatibility would be a service to the community. However, since PLplot is marching towards ubiquitous presence (call it World domination, if you want :-) we have to be careful with this kind of breakage. Indeed, there will be users around not willing to upgrade from 5.1.1 to 5.2.0, but wanting to install bindings like the PDL one. Fortunately, you detected the problem and will cope with it in your PDL module. We have only to apologize our users for this mess. Even worse, in the last release we were not careful enough as regards the soname versioning. With 5.2.0 installed, the system dynamic linker/loader will happily link programs compiled for 5.1.1 with the new library and these applications are likely to crash. The system loader does this (at least the ld.so of Linux) because the libraries in version 5.1.1 and 5.2.0 have the same soname (libplplot5), although there are backward incompatibilities. Actually, the soname for 5.2.0 must have been libplplot6. Too late, too bad... We will try to be more careful on these issues in the future. -- Rafael |
|
From: Vince D. <vi...@sa...> - 2003-03-11 08:02:58
|
A year or two ago I reported a problem with the .map and .fnt files (in 'lib' at that time). They are not marked a 'binary' in cvs, and consequently are corrupted when checked out on any non-unix platform. Now that they have been moved to 'data' someone has made the same mistake again. Can someone on unix fix this problem please? -- Vince <http://www.santafe.edu/~vince> |
|
From: Rafael L. <lab...@ps...> - 2003-03-11 11:01:28
|
* Vince Darley <vi...@sa...> [2003-03-11 01:02]: > A year or two ago I reported a problem with the .map and .fnt files (in > 'lib' at that time). They are not marked a 'binary' in cvs, and > consequently are corrupted when checked out on any non-unix platform. Now > that they have been moved to 'data' someone has made the same mistake > again. > > Can someone on unix fix this problem please? Fixed in CVS. Could you please tell me if it works for you? -- Rafael |
|
From: Rafael L. <lab...@ps...> - 2003-10-28 21:27:20
|
* Vince Darley <vi...@sa...> [2003-03-11 01:02]: > A year or two ago I reported a problem with the .map and .fnt files (in > 'lib' at that time). They are not marked a 'binary' in cvs, and > consequently are corrupted when checked out on any non-unix platform. Now > that they have been moved to 'data' someone has made the same mistake > again. I do not quite understand your problem. Short after Joao moved the files from lib to data, I did the necessary changes in the file permission. This was done exactly on Tue Mar 11 10:52:30 2003 (see http://cvs.sf.net/viewcvs.py/plplot/CVSROOT/loginfo). Indeed, this is what happens here: $ cd data $ rm -f * 2>/dev/null $ cvs update >/dev/null 2>&1 $ ls -l globe.map -rwxr-xr-x 1 rafael rafael 33602 2003-10-28 22:17 globe.map The files *_are_* executable, but I do not know what you mean by "marked binary". > Can someone on unix fix this problem please? In order to "fix" problems like this in the CVS tree, one does not need to be on Unix. Actually, it is done by changing the CVSROOT/loginfo file and this can be done from any system. See the comments that I put at the end of that file. CAVEAT: USE THIS "FEATURE" VERY CAREFULLY, OTHERWISE THE CVS TREE CAN BE SCREWED UP. -- Rafael |
|
From: Vince D. <vi...@sa...> - 2003-10-28 21:37:24
|
I'm not talking about file permissions. Unix uses LF as a linefeed. Windows uses CR-LF. MacOS uses CR. Therefore when cvs checks out a file on a non-unix platform, it performs on the fly line-ending conversion. This obviously mangles any binary files. Cvs as some '-kb' option to specify that a file is not ascii. That's what we need here. I know I could try to fix this from Windows, but it's much easier from Unix because you automatically have a non-corrupted version of the file! I don't. Perhaps some notes about this can be added to Plplot's developer documentation so we don't run into the same problem next time the whole source tree is re-arranged ;-) cheers, -- Vince <http://www.santafe.edu/~vince> On Tue, 28 Oct 2003, Rafael Laboissiere wrote: > * Vince Darley <vi...@sa...> [2003-03-11 01:02]: > > > A year or two ago I reported a problem with the .map and .fnt files (in > > 'lib' at that time). They are not marked a 'binary' in cvs, and > > consequently are corrupted when checked out on any non-unix platform. Now > > that they have been moved to 'data' someone has made the same mistake > > again. > > I do not quite understand your problem. Short after Joao moved the files > from lib to data, I did the necessary changes in the file permission. This > was done exactly on Tue Mar 11 10:52:30 2003 (see > http://cvs.sf.net/viewcvs.py/plplot/CVSROOT/loginfo). > > Indeed, this is what happens here: > > $ cd data > $ rm -f * 2>/dev/null > $ cvs update >/dev/null 2>&1 > $ ls -l globe.map > -rwxr-xr-x 1 rafael rafael 33602 2003-10-28 22:17 globe.map > > The files *_are_* executable, but I do not know what you mean by "marked > binary". > > > Can someone on unix fix this problem please? > > In order to "fix" problems like this in the CVS tree, one does not need to > be on Unix. Actually, it is done by changing the CVSROOT/loginfo file and > this can be done from any system. See the comments that I put at the end of > that file. > > CAVEAT: USE THIS "FEATURE" VERY CAREFULLY, OTHERWISE THE CVS TREE CAN BE > SCREWED UP. > > -- > Rafael > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
|
From: Rafael L. <lab...@ps...> - 2003-10-29 00:22:01
|
* Vince Darley <vi...@sa...> [2003-10-28 14:37]:
> I'm not talking about file permissions. Unix uses LF as a linefeed.
> Windows uses CR-LF. MacOS uses CR. Therefore when cvs checks out a file
> on a non-unix platform, it performs on the fly line-ending conversion.
> This obviously mangles any binary files. Cvs as some '-kb' option to
> specify that a file is not ascii. That's what we need here.
Oh, I see. Sorry for my misunderstanding.
> I know I could try to fix this from Windows, but it's much easier from
> Unix because you automatically have a non-corrupted version of the file!
> I don't.
This has hopefully been fixed by Alan.
> Perhaps some notes about this can be added to Plplot's developer
> documentation so we don't run into the same problem next time the whole
> source tree is re-arranged ;-)
Looking at the CVS documentation, I found a way to fix this problem forever.
I added the following to the CVSROOT/cvswrappers file:
cglobe.map -k 'b'
globe.map -k 'b'
plstnd5.fnt -k 'b'
plxtnd5.fnt -k 'b'
usaglobe.map -k 'b'
usa.map -k 'b'
This change has not been tested, but should be okay.
--
Rafael
|
|
From: <jc...@fe...> - 2003-10-29 10:57:38
|
On Wednesday 29 October 2003 00:21, Rafael Laboissiere wrote: | * Vince Darley <vi...@sa...> [2003-10-28 14:37]: | > I'm not talking about file permissions. Unix uses LF as a | > linefeed. Windows uses CR-LF. MacOS uses CR. Therefore when cvs | > checks out a file on a non-unix platform, it performs on the fly | > line-ending conversion. This obviously mangles any binary files. | > Cvs as some '-kb' option to specify that a file is not ascii. | > That's what we need here. | | Oh, I see. Sorry for my misunderstanding. | | > I know I could try to fix this from Windows, but it's much easier | > from Unix because you automatically have a non-corrupted version of | > the file! I don't. | | This has hopefully been fixed by Alan. | | > Perhaps some notes about this can be added to Plplot's developer | > documentation so we don't run into the same problem next time the | > whole source tree is re-arranged ;-) | | Looking at the CVS documentation, I found a way to fix this problem | forever. I added the following to the CVSROOT/cvswrappers file: | | cglobe.map -k 'b' | globe.map -k 'b' | plstnd5.fnt -k 'b' | plxtnd5.fnt -k 'b' | usaglobe.map -k 'b' | usa.map -k 'b' | | This change has not been tested, but should be okay. It looks like that all this was my fault. Sorry. Can you do it also for examples/c/lena.pgm? I don't know why Vince hasn't complained about it. Joao |
|
From: Rafael L. <lab...@ps...> - 2003-10-29 12:21:42
|
* João Cardoso <jc...@fe...> [2003-10-29 11:56]: > Can you do it also for examples/c/lena.pgm? I don't know why Vince > hasn't complained about it. I just committed the change to cvswrappers. Vince, could you please test if this works for you? -- Rafael |
|
From: Vince D. <vi...@sa...> - 2003-10-29 12:29:56
|
I'm not sure, but the file has size 194052 bytes for me. If that's the same as for you, then no line-conversions have happened. -- Vince On Wed, 29 Oct 2003, Rafael Laboissiere wrote: > * Jo=E3o Cardoso <jc...@fe...> [2003-10-29 11:56]: > > > Can you do it also for examples/c/lena.pgm? I don't know why Vince > > hasn't complained about it. > > I just committed the change to cvswrappers. > > Vince, could you please test if this works for you? > > -- > Rafael > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
|
From: Rafael L. <lab...@ps...> - 2003-10-29 13:12:31
|
* Vince Darley <vi...@sa...> [2003-10-29 05:29]: > I'm not sure, but the file has size 194052 bytes for me. If that's the > same as for you, then no line-conversions have happened. No, I have 194047 here. It should be fixed now. Could you try again, please? -- Rafael |
|
From: Vince D. <vi...@sa...> - 2003-10-29 13:36:23
|
On Wed, 29 Oct 2003, Rafael Laboissiere wrote: > No, I have 194047 here. It should be fixed now. Could you try again, > please? It's correct now -- I get 194047 too. Thanks! Vince. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X