home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / stubs / stubber.cmm < prev    next >
Encoding:
Text File  |  1988-05-03  |  3.8 KB  |  87 lines
  1.      
  2.      
  3.                      Comments on Porting
  4.                         Body Stubber
  5.                          by WIS JPMO
  6.                          to DEC Ada
  7.                                                                Tool 31
  8.                                                                August 12, 1985
  9.      
  10. COMPILATION
  11. -----------
  12.   A VMS command file was created from the ordered list of compilation
  13.   units provided in STUBBERSR.DIS.
  14.      
  15.   We were able to recompile the Body Stubber with only minor changes
  16.   in three files.  Errors occurred due to incorrect usage of "in"
  17.   mode parameter between subprogram specifications and bodies and in
  18.   one instance, lack of a generic instantiation in the body of a
  19.   procedure.
  20.      
  21.      
  22.    1.  In file ROSDEP.TXT:
  23.              line 39 inserted "in" into specification
  24.              line 260 inserted "in" to match specification
  25.              line 63  inserted "in" into specification
  26.              line 108 inserted "in" to match specification
  27.      
  28.    2.  In file GETOKEN.TXT
  29.              line 65 was added: a generic instantiation for INT_IO
  30.              line 66 was changed from "use integer_io" to "use INT_IO"
  31.      
  32.    3.  In file STUBSUP.TXT
  33.              line 69 inserted "in" into specification
  34.              line 113 inserted "in" to match specification
  35.  
  36.  
  37.      
  38. EXECUTION
  39. ---------
  40.   We were able to execute the Body Stubber and it appeared to be in workable
  41.   condition.  A test file called TEST.TXT was made containing only the
  42.   specification of ROSDEP.TXT.  The Body Stubber prompted the user for the
  43.   file name (assuming a ".TXT" file extension) and after getting the filename,
  44.   the Body Stubber 'stubbed' the file TEST.TXT and output the results into
  45.   a file named TEST2.TXT.
  46.  
  47. ====================
  48. 30-Aug-86 19:18:41-MDT,1991;000000000001
  49. Return-Path: <MHJohnson.F15@HI-MULTICS.ARPA>
  50. Received: from HI-MULTICS.ARPA by SIMTEL20.ARPA with TCP; Sat 30 Aug 86 19:18:28-MDT
  51. Date:  Sat, 30 Aug 86 20:12 CDT
  52. From:  Mark Johnson <MHJohnson@HI-MULTICS.ARPA>
  53. Subject:  Comments about PAGER and STUBBER
  54. To:  RCONN@SIMTEL20.ARPA
  55. Message-ID:  <860831011209.244072@HI-MULTICS.ARPA>
  56.  
  57. I recently received a copy of the Ada Repository and am running it
  58. through the VERDIX Ada compiler for VMS.  I have noticed a few problems
  59. with these programs that you might be interested in.  I can submit a
  60. full `comments' file if you are interested.
  61.  
  62. For PAGER (and I believe a number of other tools), there is a defined
  63. exception handler for NAME_ERROR, but not for USE_ERROR.  This causes
  64. problems on VMS 4.3 for filenames that have a dash (-) in them.
  65. Apparently, VMS does not consider a dash to be an illegal character, but
  66. won't allow a filename with a dash to be created (perhaps it can read a
  67. file w/ a dash in it...).  Adding USE_ERROR to the exception handler
  68. along with NAME_ERROR fixes this problem.
  69.  
  70. For STUBBER there is a much more insidious problem with the handling of
  71. the end of file.  Lines 277 through 281 of ROSDEP.TXT (procedure GETC)
  72. should have the if statements exchanged.  According to the Ada LRM,
  73. 14.3.4, para 24, the function END_OF_FILE returns TRUE if a file
  74. terminator is next or if a combination of line, page, and file
  75. terminator are next.  The VERDIX Ada runtime returns TRUE for
  76. END_OF_FILE at the end-of-line, end-of-file pair of the input file.
  77. This causes GET_NEXT_TOKEN to blow up since it keeps reading past the
  78. end of file.
  79.  
  80. Other than that, I haven't had too many problems with the conversions.
  81. Progress is somewhat slow due to the availability of time for this task,
  82. but I should have some more comments to send in over the next few weeks.
  83. Thanks for all the good work in maintaining the repository.  I hope to
  84. use it again in the future.
  85.  
  86.   --Mark <MHJohnson @ HI-MULTICS.ARPA>
  87.