home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / fortran / 5143 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  3.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!pagesat!spssig.spss.com!uchinews!kimbark!jfu2
  2. From: jfu2@kimbark.uchicago.edu (Carlo Graziani)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: dbx headache
  5. Message-ID: <1993Jan22.171934.15193@midway.uchicago.edu>
  6. Date: 22 Jan 93 17:19:34 GMT
  7. References: <93021.234529MATOVICM@QUCDN.QueensU.CA> <1993Jan22.135940.9828@msdrl.com>
  8. Sender: news@uchinews.uchicago.edu (News System)
  9. Reply-To: jfu2@midway.uchicago.edu
  10. Organization: University of Chicago
  11. Lines: 53
  12.  
  13. In article <1993Jan22.135940.9828@msdrl.com> ball@msdrl.com (Richard Ball) writes:
  14. >MATOVICM@QUCDN.QueensU.CA () writes:
  15. >: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
  16. >: programs. Examining arrays is pain in a neck unless you deal with the
  17. >: size a(3,3) or similar. Is there any way to say e.g.
  18. >:   print a from 155 to 175 (and possibly to specify the increment).
  19. >: Or, is there any other UNIX (public domain) debugger that can handle
  20. >: arrays frinedly?
  21. >
  22. >your dbx should let you do
  23. >&a(155)/20f
  24. >to print the 20 elements of a in floating point format starting at element
  25. >155. It's not the most friendly way but it is better than listing the whole
  26. >thing.
  27.  
  28. Yeah, but sadly this only allows contiguously stored array elements to
  29. be displayed.  It would be nice to be able to display _logically_ contiguous
  30. elements, even when they are not stored contiguously i.e. "print A(1,7-15)",
  31. or some such syntax.
  32.  
  33. More generally speaking, dbx is a relentless headache when debugging
  34. fortran code.  In its incarnation on sun4's, locating trapped floating point
  35. exceptions requires laborious procedures that work haphazardly, at best.
  36. Often operation which might be expected to generate floating point
  37. exceptions (logs of negative numbers, for example) generate segmentation
  38. violations instead, and dbx appears to halt in a part of the code unrelated
  39. to where the problem occurred.
  40.  
  41. Case sensitivity is another hassle.  dbx may be set to be case insensitive
  42. if required, but for reasons that defy comprehension this affects the
  43. way dbx understands filenames as well, so that after a "dbxenv case
  44. insensitive" it is impossible (for example) to change to a directory
  45. with a partially capitalized name.
  46.  
  47. I'm no expert on the subject, but I suspect that the problem has to do
  48. with the fact that dbx was not designed as a fortran debugger, and that
  49. it was "fortranized" by a series of awkward patches.  Unfortunately, I
  50. am aware of no alternative available for Unix workstations.  I feel that
  51. this is a serious limitation in the developement environment offered by
  52. vendors of fortran packages for unix.
  53.  
  54. I can't say I miss working on a VAX, but I sure do miss the VAX fortran
  55. environment.
  56.  
  57. Carlo
  58.  
  59. -----------------------------------------------------------------------------
  60. Carlo Graziani           |   Warning:  some of the above may not be a fully  |
  61. Dept. of Physics         |   correct representation of profound cosmic truth.|
  62. University of Chicago    |                                                   |
  63.                          |  "It's fun to have fun, but you have to know how!"|
  64. carlo@nu.uchicago.edu    |                           -The Cat in the Hat     |
  65. -----------------------------------------------------------------------------
  66.