From: Thomas J. D. <to...@fi...> - 2005-04-11 12:50:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Would it make sense to consider eliminating PLINT etc and moving to something more standard? When I first started using PLplot, I found the use of PLINT etc really weird. There is a more widely used standard library called GLib (http://developer.gnome.org/doc/API/glib/) that defines portable basic types. For example, "gint" for integers etc. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCWnCkndxDHhfZZdsRAqTmAKCDVl7q6VRS2ajg71dm2Qfoc/6TxwCfaSd9 fmcRndmP0j9o5hjKMi3dMAw= =2qtD -----END PGP SIGNATURE----- |
From: Thomas J. D. <to...@fi...> - 2005-04-14 13:02:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arjen, Alan, > > >> But isn't <stdint.h> the way to go? I mean, it is already there even > > >> if it not included in all currently used compilers. > > > > > > You are probably right. I only bring up Glib because I am familiar > > > with it, although I don't really understand the cross-platform issues. > > > My concern is more to move away from PLINT etc in general to something > > > more standard. The use of PLINT etc surprised me when I first started > > > using PLplot. > > > > Actually, I like the use of PLINT and PLFLT in plplot. That gives us a > > large degree of centralized control over exactly how we are going to handle > > integer and floating types. > > > > I agree with Alan: I have been involved in several projects where > cross-platform and cross-language portability is important and each > defines its own set of special types to control the exact types. This is > in fact canonicalised in the latest Fortran standard, Fortran 2003, > where some emphasis is put on the interoperability between C and > Fortran, leading to a module defined by the compiler with specific > "kinds" to facilitate a smooth transfer. > > Though much of the time the problem is with floating-point numbers, the > rise of 64-bits platforms is putting the burden on integers instead. Here is my problem: I am using both PLplot and Gnome types in the GCW driver. How do I translate between the two in a cross-platform way? Do I need to cast everything? What about our users who are using multiple libraries, each with their own defined types? Let me know your suggestions; I really don't know the answers. In general, standards are good because they reduce complexity, and reduce the learning curve for new users. My feeling is that we should adhere to standards wherever possible. Standard approaches are available for cross-platform types, and I don't see why we shouldn't use them. It's not clear to me that the added control makes up for the complexity that is introduced. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXmftndxDHhfZZdsRAtmnAKCnuxsKfWsitbsMebTGpCSMRX1B3QCgjoUH FztnZ5YaWp84W72oxLy9rdc= =jn4Q -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2005-04-14 16:25:34
|
On 2005-04-14 09:54-0300 Thomas J. Duck wrote: > In general, standards are good because they reduce complexity, and > reduce the learning curve for new users. My feeling is that we should > adhere to standards wherever possible. Standard approaches are available > for cross-platform types, and I don't see why we shouldn't use them. It's > not clear to me that the added control makes up for the complexity that is > introduced. With PLINT we get the best of both worlds, central control and the possibility of standardization. There is no doubt we should define PLINT in a standard way (which is the point of this thread), but if one standard falls out of favour and another is proposed to replace it, all we have to do is redefine PLINT without going through zillions of lines of code trying to track down all instances. So in answer to your prior question which I failed to quote, I believe that in the gcw device driver you should use PLFLT and PLINT wherever possible and just do the appropriate cast for the gnome library arguments when required. 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: <mj...@ga...> - 2005-04-14 21:24:03
|
Alan W. Irwin writes: > On 2005-04-14 09:54-0300 Thomas J. Duck wrote: > > > In general, standards are good because they reduce complexity, and > > reduce the learning curve for new users. My feeling is that we should > > adhere to standards wherever possible. Standard approaches are available > > for cross-platform types, and I don't see why we shouldn't use them. It's > > not clear to me that the added control makes up for the complexity that is > > introduced. > > With PLINT we get the best of both worlds, central control and the > possibility of standardization. There is no doubt we should define PLINT in > a standard way (which is the point of this thread), but if one standard > falls out of favour and another is proposed to replace it, all we have to do > is redefine PLINT without going through zillions of lines of code trying to > track down all instances. > > So in answer to your prior question which I failed to quote, I believe that > in the gcw device driver you should use PLFLT and PLINT wherever possible > and just do the appropriate cast for the gnome library arguments when > required. Couldn't have said it better. IMO, the existing approach /is/ the least complex, and allows for a great deal of flexibility. As for interfacing to other libraries etc, wrappers -- possibly using sizeof() for genericity -- are useful in hiding the complexity (which btw is often simply moved rather than created or destroyed). -- Maurice LeBrun mj...@ga... |
From: Arjen M. <arj...@wl...> - 2005-04-15 07:01:05
|
Hello all, I tried to update/commit a few files just now, but I got all kinds of error messages from CVS. Is anything wrong with CVS at Sourceforge or is the problem on my side? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-15 07:15:15
|
Arjen Markus wrote: > > Hello all, > > I tried to update/commit a few files just now, but I got > all kinds of error messages from CVS. Is anything wrong > with CVS at Sourceforge or is the problem on my side? > I retried half an hour later: still the same problem. Browsing the repository does work however. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-15 09:34:56
|
Arjen Markus wrote: > > Hello all, > > I tried to update/commit a few files just now, but I got > all kinds of error messages from CVS. Is anything wrong > with CVS at Sourceforge or is the problem on my side? > > Regards, > The problem was on my side: I had forgotten to add "plplot" after cvsroot - the error messages were not very revealing about this error. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-11 13:03:12
|
"Thomas J. Duck" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Would it make sense to consider eliminating PLINT etc and moving to > something more standard? When I first started using PLplot, I found the > use of PLINT etc really weird. There is a more widely used standard > library called GLib (http://developer.gnome.org/doc/API/glib/) that > defines portable basic types. For example, "gint" for integers etc. > But isn't <stdint.h> the way to go? I mean, it is already there even if it not included in all currently used compilers. Regards, Arjen |
From: Thomas J. D. <to...@fi...> - 2005-04-11 18:39:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arjen, > But isn't <stdint.h> the way to go? I mean, it is already there even > if it not included in all currently used compilers. You are probably right. I only bring up Glib because I am familiar with it, although I don't really understand the cross-platform issues. My concern is more to move away from PLINT etc in general to something more standard. The use of PLINT etc surprised me when I first started using PLplot. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCWsKHndxDHhfZZdsRAmx4AKDOpE0G6k04bn1FmcYi9toEaUVvigCgnq3M pJjCFdjFaVPNnzECn8MSdFs= =jb+T -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2005-04-11 18:53:12
|
On 2005-04-11 15:31-0300 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Arjen, > >> But isn't <stdint.h> the way to go? I mean, it is already there even >> if it not included in all currently used compilers. > > You are probably right. I only bring up Glib because I am familiar > with it, although I don't really understand the cross-platform issues. > My concern is more to move away from PLINT etc in general to something > more standard. The use of PLINT etc surprised me when I first started > using PLplot. Actually, I like the use of PLINT and PLFLT in plplot. That gives us a large degree of centralized control over exactly how we are going to handle integer and floating types. 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: Arjen M. <arj...@wl...> - 2005-04-13 06:18:32
|
"Alan W. Irwin" wrote: > > On 2005-04-11 15:31-0300 Thomas J. Duck wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Arjen, > > > >> But isn't <stdint.h> the way to go? I mean, it is already there even > >> if it not included in all currently used compilers. > > > > You are probably right. I only bring up Glib because I am familiar > > with it, although I don't really understand the cross-platform issues. > > My concern is more to move away from PLINT etc in general to something > > more standard. The use of PLINT etc surprised me when I first started > > using PLplot. > > Actually, I like the use of PLINT and PLFLT in plplot. That gives us a > large degree of centralized control over exactly how we are going to handle > integer and floating types. > I agree with Alan: I have been involved in several projects where cross-platform and cross-language portability is important and each defines its own set of special types to control the exact types. This is in fact canonicalised in the latest Fortran standard, Fortran 2003, where some emphasis is put on the interoperability between C and Fortran, leading to a module defined by the compiler with specific "kinds" to facilitate a smooth transfer. Though much of the time the problem is with floating-point numbers, the rise of 64-bits platforms is putting the burden on integers instead. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-13 11:35:04
|
Hello, while we are at it, why not introduce a PLLONGLONG (or PLINT64) too: not all systems (notably Windows/MSVC) like the idea of a "long long". I ran into this problem with ..lib/csa/nan.h :( (I want to add plgriddata() to the list of functions supported under the win32 driver). Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-13 11:46:14
|
Hello all, I did a fresh checkout of PLplot 5.5.0 to test some of the changes I made for the win32 driver and I ran into a problem with the header file plhershey-unicode.h: it does not exist in the CVS tree. >From the comments in an older version I see I have to rebuild it via a small program. The current build scripts for win32 do not do that. I myself can work around that and I will enhance the build scripts. This went unnoticed so far because the Linux configuration does do this. When I later tried the Windows build system, the file was already there ... Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-04-13 16:42:21
|
On 2005-04-13 13:34+0200 Arjen Markus wrote: > Hello, > > while we are at it, why not introduce a PLLONGLONG (or PLINT64) too: > not all systems (notably Windows/MSVC) like the idea of a "long long". > > I ran into this problem with ..lib/csa/nan.h :( (I want to add > plgriddata() to the list of functions supported under the win32 driver). This is a new topic so I have decided to change the subject line. I had no idea we used long long anywhere in PLplot. Looking closer at lib/csa/nan.h, what is going on is a long long is being used to set up a (64-bit) bit pattern which is then cast to double to make the appropriate bit pattern for big-endian or little-endian double-precision NaN. This is over-complicated and unnecessarily brings long long into the mix. Could somebody here with the requisite C and endian skills set up the required NaN bit patterns directly without using long long? I have seen this done elsewhere, but I cannot remember the details. 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: Alan W. I. <ir...@be...> - 2005-04-13 17:06:11
|
On 2005-04-13 13:45+0200 Arjen Markus wrote: > Hello all, > > I did a fresh checkout of PLplot 5.5.0 to test some of the changes > I made for the win32 driver and I ran into a problem with the > header file plhershey-unicode.h: it does not exist in the CVS > tree. > >> From the comments in an older version I see I have to rebuild > it via a small program. The current build scripts for win32 > do not do that. I myself can work around that and I will > enhance the build scripts. There are a number of files like this one which are purposely not in CVS because they are generated files. Examples are the tcl interface (generated by perl), the python and java interfaces (generated by swig), all the many files generated by the autotools apps, and plhershey-unicode.h which is generated in the include directory by building the plhershey-unicode-gen app there and then running ./plhershey-unicode-gen $(top_srcdir)/fonts/plhershey-unicode.csv \ plhershey-unicode.h (See include/Makefile.am for details.) If you want to use the full version of PLplot from cvs, you are going to have to have perl, swig, and the autotools installed, and also a rule for building plhershey-unicode-gen and running it to create plhershey-unicode.h in your build scripts. Note a much easier course is simply to use the tarballs (which by design include all the interface files and include/plhershey-unicode.h mentioned above) and forget about cvs for windows. This is especially a good tactic now that Tom is producing development tarballs on a regular basis. 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: Arjen M. <arj...@wl...> - 2005-04-14 06:40:31
|
"Alan W. Irwin" wrote: > > There are a number of files like this one which are purposely not in CVS > because they are generated files. Examples are the tcl interface (generated > by perl), the python and java interfaces (generated by swig), > all the many files generated by the autotools apps, and plhershey-unicode.h > which is generated in the include directory by building the > plhershey-unicode-gen app there and then running > > ./plhershey-unicode-gen $(top_srcdir)/fonts/plhershey-unicode.csv \ > plhershey-unicode.h > > (See include/Makefile.am for details.) > > If you want to use the full version of PLplot from cvs, you are going to > have to have perl, swig, and the autotools installed, and also a rule for > building plhershey-unicode-gen and running it to create plhershey-unicode.h > in your build scripts. > > Note a much easier course is simply to use the tarballs (which by design > include all the interface files and include/plhershey-unicode.h mentioned > above) and forget about cvs for windows. This is especially a good tactic > now that Tom is producing development tarballs on a regular basis. > Yes, I understand this - I guess I am in a special position: - maintaining the only, AFAIK, driver that does not use ./configure - using the CVS repository for maintenance and for building the Linux version of the library Well, as long as I am the only one in that special position, there is no real problem - I just have to be careful with my Windows builds, as they might rely on what was done for Linux :) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-14 06:42:55
|
"Alan W. Irwin" wrote: > > On 2005-04-13 13:34+0200 Arjen Markus wrote: > > > Hello, > > > > while we are at it, why not introduce a PLLONGLONG (or PLINT64) too: > > not all systems (notably Windows/MSVC) like the idea of a "long long". > > > > I ran into this problem with ..lib/csa/nan.h :( (I want to add > > plgriddata() to the list of functions supported under the win32 driver). > > This is a new topic so I have decided to change the subject line. > > I had no idea we used long long anywhere in PLplot. Looking closer at > lib/csa/nan.h, what is going on is a long long is being used to set up > a (64-bit) bit pattern which is then cast to double to make the appropriate > bit pattern for big-endian or little-endian double-precision NaN. > > This is over-complicated and unnecessarily brings long long into the mix. > Could somebody here with the requisite C and endian skills set up the > required NaN bit patterns directly without using long long? I have seen this > done elsewhere, but I cannot remember the details. > Well, I have always shunned these special bit patterns, but am I wrong in guessing that: static NaN = 0.0 / 0.0 ; is applicable to all C compilers? (The only thing I can imagine is that some compilers give a warning or an error on this ...) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-14 07:22:04
|
Arjen Markus wrote: > ] > Well, I have always shunned these special bit patterns, but am I wrong > in > guessing that: > > static NaN = 0.0 / 0.0 ; > > is applicable to all C compilers? (The only thing I can imagine is that > some compilers give a warning or an error on this ...) > That should of course has been static double NaN = 0.0 / 0.0 ; but since Pavel informed me about the fix in the current version of CSA, there is no need anymore for this. Regards, Arjen |