From: <jc...@fe...> - 2003-10-13 23:03:22
|
Hi, Although possible, it is not likely that any system has dynamic loading and don't have shared libraries, or that a user wants dynamic drivers and don't want dynamic libraries, so, why not: RCS file: /cvsroot/plplot/plplot/configure.ac,v retrieving revision 1.108 diff -r1.108 configure.ac 463a464,467 > if test "$enable_shared" != "yes"; then > enable_dyndrivers="no" > fi > Recently I configured with --disable-shared, and forget to disable-dyndrivers, and the result what a failed make. Do anybody foresee any problem with this? Joao |
From: Arjen M. <arj...@wl...> - 2003-10-14 06:33:51
|
Jo=E3o Cardoso wrote: >=20 > Hi, >=20 > Although possible, it is not likely that any system has dynamic loading= and > don't have shared libraries, or that a user wants dynamic drivers and d= on't > want dynamic libraries, so, why not: >=20 > RCS file: /cvsroot/plplot/plplot/configure.ac,v > retrieving revision 1.108 > diff -r1.108 configure.ac > 463a464,467 > > if test "$enable_shared" !=3D "yes"; then > > enable_dyndrivers=3D"no" > > fi > > >=20 > Recently I configured with --disable-shared, and forget to disable-dynd= rivers, > and the result what a failed make. >=20 > Do anybody foresee any problem with this? >=20 I guess you mean: users who want dynamic libraries but static drivers. That is something that I can not imagine to be useful... (I use a static library and dynamic drivers) Regards, Arjen |
From: <jc...@fe...> - 2003-10-15 13:27:52
|
On Tuesday 14 October 2003 07:33, Arjen Markus wrote: | Jo=E3o Cardoso wrote: | > Hi, | > | > Although possible, it is not likely that any system has dynamic | > loading and don't have shared libraries, or that a user wants | > dynamic drivers and don't want dynamic libraries, so, why not: | > | > RCS file: /cvsroot/plplot/plplot/configure.ac,v | > retrieving revision 1.108 | > diff -r1.108 configure.ac | > 463a464,467 | > | > > if test "$enable_shared" !=3D "yes"; then | > > enable_dyndrivers=3D"no" | > > fi | > | > Recently I configured with --disable-shared, and forget to | > disable-dyndrivers, and the result what a failed make. | > | > Do anybody foresee any problem with this? | | I guess you mean: users who want dynamic libraries but static | drivers. That is something that I can not imagine to be useful... | | (I use a static library and dynamic drivers) Your system is Cygwin, right? And is there some reason for using static libs and dynamic drivers? Or=20 is it just one of the four combinations of shared/dyndriver that=20 worked? Can you send us the config.summary file, at the top of the=20 build dir? Thanks, Joao | | Regards, | | Arjen | | | | ------------------------------------------------------- | This SF.net email is sponsored by: SF.net Giveback Program. | SourceForge.net hosts over 70,000 Open Source Projects. | See the people who have HELPED US provide better services: | Click here: http://sourceforge.net/supporters.php | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@wl...> - 2003-10-15 13:56:29
|
Jo=E3o Cardoso wrote: >=20 > On Tuesday 14 October 2003 07:33, Arjen Markus wrote: > | Jo=E3o Cardoso wrote: > | > Hi, > | > > | > Although possible, it is not likely that any system has dynamic > | > loading and don't have shared libraries, or that a user wants > | > dynamic drivers and don't want dynamic libraries, so, why not: > | > > | > RCS file: /cvsroot/plplot/plplot/configure.ac,v > | > retrieving revision 1.108 > | > diff -r1.108 configure.ac > | > 463a464,467 > | > > | > > if test "$enable_shared" !=3D "yes"; then > | > > enable_dyndrivers=3D"no" > | > > fi > | > > | > Recently I configured with --disable-shared, and forget to > | > disable-dyndrivers, and the result what a failed make. > | > > | > Do anybody foresee any problem with this? > | > | I guess you mean: users who want dynamic libraries but static > | drivers. That is something that I can not imagine to be useful... > | > | (I use a static library and dynamic drivers) >=20 > Your system is Cygwin, right? >=20 No, I use Ms Visual C/C++ to compile the library on Windows. The reason for using static libraries as much as possible is=20 more that installation and deployment gets simpler. Also there seems to be an issue with the DLL-version of PLplot on Windows (or is that a relict in the comments?) > And is there some reason for using static libs and dynamic drivers? Or > is it just one of the four combinations of shared/dyndriver that > worked? Can you send us the config.summary file, at the top of the > build dir? >=20 Here it is: Configure results: command: ./configure --no-reexec system: sparc-sun-solaris2.6 have_x: yes prefix: /usr/local CC: gcc=20 CXX: g++=20 F77: g77=20 LIB_TAG: d devices: dg300 hp7470 hp7580 lj_hpgl imp ljii ljiip mem null pbm plmeta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt conex tek4010f tek4107f xfig xwin Available device drivers: static: =09 dynamic: dg300.la hpgl.la impress.la ljii.la ljiip.la mem.la null.la pbm.la plmeta.la ps.la pstex.la tek.la xfig.la xwin.la Compilation options: with_debug: no with_opt: yes with_warn: no with_profile: no Library options: enable_shared: yes enable_static: yes with_rpath: yes with_double: yes Optional libraries: with_qhull: no with_csa: yes with_freetype: no with_pthreads: no Language Bindings: enable_tcl: no enable_itcl: no enable_cxx: yes enable_f77: yes enable_java: no enable_python: no enable_octave: no =20 Regards, Arjen |
From: <jc...@fe...> - 2003-10-15 15:48:23
|
On Wednesday 15 October 2003 14:56, Arjen Markus wrote: | Jo=E3o Cardoso wrote: | > On Tuesday 14 October 2003 07:33, Arjen Markus wrote: | > | Jo=E3o Cardoso wrote: | > | > Hi, | > | > | > | > Although possible, it is not likely that any system has dynamic | > | > loading and don't have shared libraries, or that a user wants | > | > dynamic drivers and don't want dynamic libraries, so, why not: | > | > | > | > RCS file: /cvsroot/plplot/plplot/configure.ac,v | > | > retrieving revision 1.108 | > | > diff -r1.108 configure.ac | > | > 463a464,467 | > | > | > | > > if test "$enable_shared" !=3D "yes"; then | > | > > enable_dyndrivers=3D"no" | > | > > fi | > | > | > | > Recently I configured with --disable-shared, and forget to | > | > disable-dyndrivers, and the result what a failed make. | > | > | > | > Do anybody foresee any problem with this? | > | | > | I guess you mean: users who want dynamic libraries but static | > | drivers. That is something that I can not imagine to be useful... | > | | > | (I use a static library and dynamic drivers) | > | > Your system is Cygwin, right? | | No, I use Ms Visual C/C++ to compile the library on Windows. | The reason for using static libraries as much as possible is | more that installation and deployment gets simpler. | | Also there seems to be an issue with the DLL-version of PLplot | on Windows (or is that a relict in the comments?) | | > And is there some reason for using static libs and dynamic drivers? | > Or is it just one of the four combinations of shared/dyndriver=20 | > that worked? Can you send us the config.summary file, at the top | > of the build dir? | | Here it is: | | Configure results: | | command: ./configure --no-reexec | system: sparc-sun-solaris2.6 | have_x: yes | prefix: /usr/local | CC: gcc | CXX: g++ | F77: g77 | LIB_TAG: d | devices: dg300 hp7470 hp7580 lj_hpgl imp ljii ljiip mem null pbm | plmeta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt | conex tek4010f tek4107f xfig xwin | | Available device drivers: | static: | dynamic: dg300.la hpgl.la impress.la ljii.la ljiip.la mem.la null.la | pbm.la plmeta.la ps.la pstex.la tek.la xfig.la xwin.la | | Compilation options: | with_debug: no with_opt: yes | with_warn: no with_profile: no | | Library options: | enable_shared: yes enable_static: yes Ah, but you have build shared libraries. How sure are you that the=20 drivers are not using the shared version of plplot? In linux we use the "ldd" command to find out what the dependences of a=20 dynamic object are. E.g., "ldd pbm.so" in my system shows that it=20 requires libplplot; "ldd xwin.so" shows that libX11.so is also needed,=20 etc. Is there an equivalent command in windows? Or perhaps the file manager=20 shows the properties of a file, showing its dependences? Could you=20 please try to check this? Thanks, Joao | with_rpath: yes with_double: yes | | Optional libraries: | with_qhull: no with_csa: yes | with_freetype: no with_pthreads: no | | | Language Bindings: | enable_tcl: no enable_itcl: no | enable_cxx: yes enable_f77: yes | enable_java: no enable_python: no | enable_octave: no | | | | Regards, | | Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-16 06:32:46
|
Jo=E3o Cardoso wrote: >=20 > Ah, but you have build shared libraries. How sure are you that the > drivers are not using the shared version of plplot? >=20 I was too hasty yesterday: On Linux I specifically link with the archive library and use the=20 shared drivers (well, dynamic in the parlance of the HOWTO document). I hought I was doing the same on Windows, but that is not the case: I just have the plplib.lib there (not the DLL). This library contains the win3 driver.=20 > In linux we use the "ldd" command to find out what the dependences of a > dynamic object are. E.g., "ldd pbm.so" in my system shows that it > requires libplplot; "ldd xwin.so" shows that libX11.so is also needed, > etc. > Is there an equivalent command in windows? Or perhaps the file manager > shows the properties of a file, showing its dependences? Could you > please try to check this? >=20 I know there are tools for this, but as I am more a UNIX/Linux person than a Windows person, I use an idiosyncratic method for these things: I take=20 the executable file into a file viewer and search for ".dll" or the like :) No, I made a mistake. I am using a static library and static drivers (perhaps even just one, as the printing function is failing ...) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-16 09:00:03
|
Hello, I am using the Windows driver win3 under Windows and I found a problem when printing via the Windows printing system: When the driver initialises the coordinate system, it always uses the handle to the plot window (hwnd) to get the client rectangle. This is not the correct method if, like me, you want to print. I will implement a solution/workaround and send the corrections around (it is but one of a series of workarounds that I have had to implement because of my perhaps special situation). Regards, Arjen |
From: Alan W. I. <ai...@us...> - 2003-10-16 14:34:37
|
On 2003-10-16 13:30+0200 Arjen Markus wrote: > Olof Svensson wrote: > > > > Hi again, > > > > Alan can correct me if I'm wrong or missing something (that's why I send > > him copies of these emails...), I think your tasks can be resumed to > > these: > > > > * Change my name to yours in the README.txt and INSTALL.txt files so > > people know who is currently maintaining this port of plplot. > > > > * Submit patches either done by yourself or someone else who has sent a > > patch to you. These patches must be prepared in a special way, it's not > > difficult and you might already have done it. It could even be that > > you'll be appointed to be a plplot developer so that you can submit > > directly to the CVS server. Alan offered me this possibility but I > > declined since I was already dragged away from the project. > > > > * Test the sys/win32/msdev port when new releases are being prepared, if > > possible on many versions of Windows (98/ME/2k/XP). > > > > That's it! I'll still be passively following the project, so if you have > > any difficulties you can always contact me. > > > > > > Hm, that sounds within reach of my capabilities (skills and invested > time :). > I am actually already known on SF (username: arjenmarkus), but so far I > have not done much CVS work via SF (my skills there are a bit rusty, > because > my company in their infinite wisdom have turned to VSS - but my quarrels > with VSS are a very different subject, more appropriate for a sunny > sidewalk > with plenty of spirits). > > Okay, count me in. > > Regards, > > Arjen > Sounds good to me too. I am going to put this back on the list since it involves the change of responsibility for sys/win32/msdev. My perception is that before Olof's tenure, the windows interest in PLplot was essentially zero since we hadn't maintained sys/win32/msdev for years. However, because of his initial complete refurbishment of sys/win32/msdev/ plus his steady maintenance ever since the windows interest in PLplot has been growing steadily. So thanks, Olof, for a fine effort! And welcome aboard, Arjen, as the new windows maintainer for PLplot! Thanks for being willing to take on this responsibility. For now, let's work with patches and see how it goes. The format I prefer is generated the following way (on Linux): diff -Naur plplot_old plplot_new > plplot.patch where both old and new are clean trees (no compilations done in them). Please look at the plplot.patch result to insure it really does have only the change you want. I won't spend a lot of time reviewing your patch before committing it (especially when changes are small and confined to the sys/win32/msdev/ area). Essentially, you are completely responsible for sys/win32/msdev so that if you make a mistake, I refer all e-mails to you. :-) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-10-17 07:33:55
|
Hello, some further information on my problem with printing under Windows: One strange problem is that the picture I get out of the printer does not resemble the original at all. It turns out that this may very well be due to the fact that PLplot expects monitors (!) to have a 4:3 aspect ratio. In the debugger I get the following information: - clpxma = 32767 - clpyma = 42597 whereas normally clpyma < clpxma. This then seems to lead to negative y-coordinates (wrapping due to the long->short conversion of large values). Any suggestions of how to cope with this? How does the PostScript driver solve this? Note: I am plotting in portrait mode. Regards, Arjen |
From: Alan W. I. <ai...@us...> - 2003-10-17 16:02:11
|
On 2003-10-17 09:29+0200 Arjen Markus wrote: > [out of order] Note: I am plotting in portrait mode. > Any suggestions of how to cope with this? How does the PostScript > driver solve this? It's been a long time since I implemented the -portrait option and also modified the -a option so that character aspect ratios remained unchanged (so a circle remains a circle and does not turn into an ellipse). I can no longer remember the details. But as I recall, -portrait is a special convenience option (combining specific option values for -ori, and -a) only implemented for certain file devices such as postscript where portrait or landscape is completely supported by the standards. I don't know whether your xwindows device is implemented properly, but I would ignore -portrait, and instead, I suggest you just play with the -a, -ori, and -freeaspect options (use the -h option to find out what they are) to see whether you can get what you want. I just played with these for -dev xwin and all looked well for integer -ori values. For non-integer -ori, and non-unity aspect ratios, there is still the long-standing problem with our transformation formulas that distort the result. HTH. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ai...@us...> - 2003-10-26 04:52:05
|
On 2003-10-23 12:32+0200 Arjen Markus wrote: > Hello Alan, > > please find a small set of corrected and new (but otherwise untested :() > examples in the attachment. > > I had intended testing them before I would send them to you, but > other stuff is more pressing at the moment. I send them anyway > so you know I have not forgotten about it. I am switching this thread to the list. Thanks, Arjen, for your donated examples. I had a quick look and I noticed you followed the current model which is to accommodate the weird demands of m4 processing. That's made me think some more about that model, and I don't really like it since is is not necessary and forces our "fortran" sources that are under cvs control to have a mixture of m4 and fortran commands in them. All we really need is clean double-precision fortran example programmes with absolutely no single-precision in them at all. (Also no references to m4 in them as well.) Then we can use that as default and use a sed script to convert to single-precision when necessary. Accordingly, I have taken _all_ the fortran examples from cvs head, m4 processed them to get them in double-precision form with no further reference to m4 embedded in the result, then copied the results back to the *.fm4 so that version is simply the double-precision default version. (I will probably change the *.fm4 suffix later to reflect this change.) single precision is not implemented at the moment. I have done the same thing for your new examples 17-19 and committed the result to cvs. I have also taken your 2nd, 3rd, and 5th example modifications, did a bit more work with them and committed the results. examples 2 and 5 are now consistent with other language interfaces while more work needs to be done with example 3. There is still quite a bit to do to clean up all our fortran examples at the moment. It sounds like Arjen is just as busy as I am at the moment so it may be quite a while before either of us gets to these so other volunteers are most welcome to help clean this us. Stupid constructs that resulted from the m4 processing like dble (0.4) have to be converted to 0.4d0. In fact all constants should be converted to the "d0" form to get rid of all single precision and to ultimately make it easy to convert the double-precision result to single using a sed script. Also, Arjen's examples 17 and 19 show we are missing some fundamental fortran API in bindings/f77 (For now, to get around those link problems and to allow the other examples to be linked, use the -k option on make check.) Also, Arjen's example 18 exposes (I think, although I haven't had time to look into it further) a minor problem with the present fortran API. Finally, there is a lot more consistency work to do for many of the other examples. But thanks very much, Arjen, for making a good start. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-10-27 07:33:34
|
"Alan W. Irwin" wrote: > > Thanks, Arjen, for your donated examples. > They are, as I said, untested :( > I had a quick look and I noticed you followed the current model which is to > accommodate the weird demands of m4 processing. That's made me think some > more about that model, and I don't really like it since is is not necessary > and forces our "fortran" sources that are under cvs control to have a > mixture of m4 and fortran commands in them. > Yes, I wanted to stay as closely to the originals as I could. As I am not familiar with m4 (I know of it, I do not _know_ it), I did not want to invent new stuff - for instance to solve a problem with the interface to sleep(). If you want to consider an alternative to sed, you might think of "coco" - it is a solution for conditional programming in Fortran. I have not really looked at it yet, but it sounds interesting enough. Another way around some platform-dependent issues is to use include files: - Have the configuration script copy the right implementation of certain functions or data to the standard name - Let the compiler do its job as usual. For instance: provide a standard interface to sleep() (example x17) and implement that as: subroutine sleepf( seconds ) real seconds include 'sleep.inc' return end > All we really need is clean double-precision fortran example programmes with > absolutely no single-precision in them at all. (Also no references to m4 in > them as well.) Then we can use that as default and use a sed script to > convert to single-precision when necessary. > This means: any floating-point number should be annotated with "d0", like 1.0d0 instead of 1.0. And the REAL type should become DOUBLE PRECISION (This is the FORTRAN 77 standard). > Accordingly, I have taken _all_ the fortran examples from cvs head, m4 > processed them to get them in double-precision form with no further > reference to m4 embedded in the result, then copied the results back to the > *.fm4 so that version is simply the double-precision default version. (I > will probably change the *.fm4 suffix later to reflect this change.) single > precision is not implemented at the moment. > > I have done the same thing for your new examples 17-19 and committed the > result to cvs. > Thanks > I have also taken your 2nd, 3rd, and 5th example modifications, did a bit > more work with them and committed the results. examples 2 and 5 are now > consistent with other language interfaces while more work needs to be done > with example 3. > > There is still quite a bit to do to clean up all our fortran examples at the > moment. It sounds like Arjen is just as busy as I am at the moment so it > may be quite a while before either of us gets to these so other volunteers > are most welcome to help clean this us. > :) Yes - the remaining examples require more work to restructure them. Probably best to start anew: I found that converting the C version to FORTRAN is partly a question of removing semicolons and converting a few control constructs (well, a bit more than that, but you can get a fair productivity) > Stupid constructs that resulted from the m4 processing like dble (0.4) have > to be converted to 0.4d0. In fact all constants should be converted to the > "d0" form to get rid of all single precision and to ultimately make it easy > to convert the double-precision result to single using a sed script. > > Also, Arjen's examples 17 and 19 show we are missing some fundamental > fortran API in bindings/f77 (For now, to get around those link problems and > to allow the other examples to be linked, use the -k option on make check.) > Also, Arjen's example 18 exposes (I think, although I haven't had time to > look into it further) a minor problem with the present fortran API. > > Finally, there is a lot more consistency work to do for many of the other > examples. But thanks very much, Arjen, for making a good start. > Thanks again. For me the steps right now are: - Get the CVS head and work from there - Get the FORTRAN version of PLplot working - Get the other examples into shape I will do that the coming few weeks (but time is precious :), unless some volunteer wants to take over. Regards, Arjen |
From: Alan W. I. <ai...@us...> - 2003-10-27 15:59:36
|
On 2003-10-27 08:33+0100 Arjen Markus wrote: > As I am not familiar with m4 (I know of it, I do not _know_ it) Same here. > I did > not > want to invent new stuff - for instance to solve a problem with the > interface > to sleep(). If you want to consider an alternative to sed, you might > think > of "coco" - it is a solution for conditional programming in Fortran. I > have not > really looked at it yet, but it sounds interesting enough. I had never heard of coco, but I had a quick look, and it seems quite interesting. Thanks for drawing it to my attention. > > Another way around some platform-dependent issues is to use include > files: > - Have the configuration script copy the right implementation of certain > functions > or data to the standard name > - Let the compiler do its job as usual. > > For instance: provide a standard interface to sleep() (example x17) and > implement > that as: > > subroutine sleepf( seconds ) > real seconds > include 'sleep.inc' > return > end > For now, I am willing to settle for making double work on Linux g77, and later single with the aid of sed. That approach could be expanded further; at the last place where I performed a fortran contract they used sed exclusively to massage the fortran source (250 000 lines of it!) to make it work on their several different fortran compilers/hardware platforms. However, I also agree that configured include files will also work nicely in many cases when sed is not up to the task, and now there is also the possibility of going with coco. Lots of food for thought here, and for now I think we should just concentrate on double-precision Linux g77 for the examples. N.B. My above remarks only pertain to the examples; the fortran API wrapper in bindings/f77 that we have now has a much simpler task to do, and it has worked pretty well for many different compilers in the past. Nevertheless, I intend to change that current m4 based approach to a sed based one when I get a chance. > > All we really need is clean double-precision fortran example programmes with > > absolutely no single-precision in them at all. (Also no references to m4 in > > them as well.) Then we can use that as default and use a sed script to > > convert to single-precision when necessary. > > > > This means: any floating-point number should be annotated with "d0", > like > 1.0d0 instead of 1.0. Yes! > And the REAL type should become DOUBLE PRECISION > (This is the FORTRAN 77 standard). Please not. I prefer some of useful Vax/VMS extensions to that standard which allow you to, for example, drop all statement numbers so you can have clean looking fortran code; DO ....ENDDO, being the primary example. Also, real*8 rather than DOUBLE PRECISION. vax/vms fortran was so ubiquitous that it essentially formed its own standard, and most modern "f77" fortran compilers (e.g., g77) comform to that standard (at least the parts that were used by nearly everybody in the vax/vms heyday in the 1980's and early 90's). It's my vax/vms fortran background showing here, but my first reaction when I see "DOUBLE PRECISION" in fortran source is this code is really old and poorly maintained. > > For me the steps right now are: > - Get the CVS head and work from there > - Get the FORTRAN version of PLplot working > - Get the other examples into shape > > I will do that the coming few weeks (but time is precious :) Understood. Anything you can do will be much appreciated. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-10-27 13:12:29
|
With respect to the new FORTRAN 77 examples: I noticed that the source files (*.fm4) have tabs instead of spaces. I am not a fan of tabs, as they get treated very differently in terms of number of spaces and the like. Should we use tabs or should we stick to spaces? Regards, Arjen |
From: Alan W. I. <ai...@us...> - 2003-10-27 16:14:58
|
On 2003-10-27 14:09+0100 Arjen Markus wrote: > With respect to the new FORTRAN 77 examples: > > I noticed that the source files (*.fm4) have tabs instead of > spaces. I am not a fan of tabs, as they get treated very > differently in terms of number of spaces and the like. > > Should we use tabs or should we stick to spaces? I used to be a fan of tabs so some/all of this is probably due to me. But I am not a fan any more so I planned to move to spaces in any case. Don't bother doing this by hand. Good fortran source editors like jed or emacs make such white-space conversion a snap. If you don't have access to such, let me know, and I will make the conversion. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-10-28 10:21:50
|
"Alan W. Irwin" wrote: > > > For now, I am willing to settle for making double work on Linux g77, and > later single with the aid of sed. That approach could be expanded further; > at the last place where I performed a fortran contract they used sed > exclusively to massage the fortran source (250 000 lines of it!) to make it > work on their several different fortran compilers/hardware platforms. > However, I also agree that configured include files will also work nicely in > many cases when sed is not up to the task, and now there is also the > possibility of going with coco. Lots of food for thought here, and for > now I think we should just concentrate on double-precision Linux g77 for > the examples. > Yes, I did some work on example x15. Ran into the problem that my printout of the documentation was still incomplete ... ;) > N.B. My above remarks only pertain to the examples; the fortran API wrapper > in bindings/f77 that we have now has a much simpler task to do, and it has > worked pretty well for many different compilers in the past. Nevertheless, > I intend to change that current m4 based approach to a sed based one when I > get a chance. > Sure. By the way: Fortran does allow subroutines and functions to be passed as arguments. This could mean that the plcont/plshade can be made more inline with the C versions. (The only limitation oon the Fortran side is that you can not _store_ such arguments). > > > > This means: any floating-point number should be annotated with "d0", > > like > > 1.0d0 instead of 1.0. > > Yes! I have added "d0" to any real I came across in example x15. > > > And the REAL type should become DOUBLE PRECISION > > (This is the FORTRAN 77 standard). > > Please not. I prefer some of useful Vax/VMS extensions to that standard > which allow you to, for example, drop all statement numbers so you can have > clean looking fortran code; DO ....ENDDO, being the primary example. Also, > real*8 rather than DOUBLE PRECISION. vax/vms fortran was so ubiquitous that > it essentially formed its own standard, and most modern "f77" fortran > compilers (e.g., g77) comform to that standard (at least the parts that were > used by nearly everybody in the vax/vms heyday in the 1980's and early > 90's). > > It's my vax/vms fortran background showing here, but my first reaction when > I see "DOUBLE PRECISION" in fortran source is this code is really old and > poorly maintained. > Okay, I did follow your example of using real*8 instead of double precision (I know of it via IBM's Fortran compiler). I was not aware of g77's support for do/enddo, though. That is good news. The situation can be summarized as follows: - real*8 is supported by g77 and by most other compilers out in the world (it is tolerated in the Fortran 90 standard) - do/enddo is supported too (and is part of the Fortran 90 standard) - ! comments ditto Good. Regards, Arjen |