T.R | Title | User | Personal Name | Date | Lines |
---|
292.1 | | GOLD::OPPELT | Moved to GOLD::OPPELT, DTN 297-5642, MRO2-4/E14 | Fri Aug 22 1986 17:11 | 7 |
|
We are willing to consider linking macro into our application.
Also, if this has been discussed elsewhere, please refer us
to it to aviod repetition of REPLYs.
Joe O.
|
292.2 | you may not like this but... | FROST::HARRIMAN | ACK Phfft! | Fri Aug 22 1986 17:49 | 42 |
| I can't think of an overly convenient way since fortran doesn't
allow that sort of thing directly (outside of the symbolic debugger)
however...
An indirect way to do it would be to set up arrays (i.e. lists)
of your variables. You would need at least three if not four arrays,
one to contain your integers, one to contain reals, one to contain
characters, and one to contain the names. Optionally you could get
confusing and have the names array point to the index of the other
data arrays. a small picture of what i'm talking about would be
like this:
name_pointer_array(x, y)
| +-->data type (1=char,2=integer,3=real, etc)
+----->points to array containing names of variables.
name_array(x, y)
| +---> pointer into actual variable index
----> actual names of variables
character_array(x)
+---> character elements, indexed
integer_array(x)
+-----> integer elements, indexed
real_array(x)
+--------> real elements, indexed
you then search the names array for your name match. When you find
a name match, you must trace the links back to the value.
Of course this means you must make every variable in your application
an array element. And you must manage EVERYTHING inside of the program,
like you must remember what array something is in. You could write
a function to do that (chasing names back to locations) and it would
make things easier. If you can follow this then you have a chance,
if you can't maybe one of the other hackers has a better idea (like
Ford?)... Like I said, I can't think of any easier way that FORTRAN
(or any other higher level language other than LISP) can do this.
|
292.3 | How about this... | 15749::GORDON | Think of it as evolution in action... | Sat Aug 23 1986 01:40 | 30 |
| Try this on for size:
structure /var_descriptor/
character name*31
byte type
integer*2 length
integer*4 pointer
end structure
record /var_descriptor/ vars(max_vars)
Initialize all your variables (you might want them in alpha order
so you can do binary search on vars(i).name)...
vars(1).name = 'VAR1'
vars(1).type = int !define convenient parameters for types
vars(1).length = 4 ! most useful for strings
vars(1).point = %loc(VAR1)
Once you have the record index based on .name, do a branch based
on .type and pass %VAL(vars(i).point) to a subroutine. The only
catch here is character data - you could keep a spare buffer around
as large as the longest character variable and use LIB$SCOPY_R_DX
to copy the pointer. If this is not clear, send me MAIL
(ANYWAY::GORDON) or give me a call.
I know it's ugly, and unwieldy (although less so that .-1) but
you're asking a lot from poor FORTRAN.
--Doug
|
292.4 | NAMELIST | DELNI::CANTOR | Dave Cantor | Sat Aug 23 1986 14:50 | 9 |
| In Fortran, perhaps you can put all the variables in which
you are interested into a NAMELIST. Then read the name of
the variable you want displayed, and write out the value using
a write statement specifying the namelist.
I'm not sure this can really be done. It's been years since
I've done anything serious in Fortran.
Dave C.
|
292.5 | | PASTIS::MONAHAN | | Mon Aug 25 1986 06:32 | 6 |
| Why not lift the code from Debug that does what you want? Debug
reads a symbol table for the image, and knows location and data
type for every variable (provide you compile and link right). I
haven't looked at the code, but I would expect that if you compile
and link with "/DEBUG" then there would probably be a routine address
that you could call with the right arguments.
|
292.6 | Can't always get what you want . . . | GALLO::AMARTIN | Alan H. Martin | Mon Aug 25 1986 18:30 | 5 |
| This sounds a lot like topic 178 in TLE::DEBUG (q.v.), where someone else
said "I have to translate variable names to runtime addresses". I would
summarize the answers by those in the know as "No, you only *think* you
have to do it".
/AHM
|
292.7 | an offer! | BARAKA::LASTOVICA | Norm Lastovica | Mon Aug 25 1986 22:34 | 3 |
| RE: .-2
And, if you can figure out how to get the debugger code ripped
out and interfaced with a user program, I'll buy you dinner!
|
292.8 | I never refuse a free meal | PASTIS::MONAHAN | | Tue Aug 26 1986 04:17 | 2 |
| re: .7 Promise :-) I did it in VMS V2 days, but you'll have to
come across the pond to pay...
|
292.9 | Gosh, a plane ride isn't cheap | BARAKA::LASTOVICA | Norm Lastovica | Tue Aug 26 1986 21:40 | 4 |
| re: .-1
Well, OK, but seems foolish for you to buy me a ticket just
for a free dinner... ;-) Course the other half of the deal was
that I get the results of the work!!
|
292.10 | | OCKER::PUCKETT | Fortran will never die | Wed Aug 27 1986 04:04 | 4 |
| Discussed in TLE::DEBUG press KP7
I forget the note number though
- Giles
|
292.11 | | TAV02::NITSAN | Nitsan Duvdevani, Digital Israel | Thu Aug 28 1986 07:31 | 13 |
| If you don't mind slow response...
READ ... BUFFER
OPEN (UNIT=1,...)
WRITE (1,...) ' INCLUDE GLOBAL_SECTION'
WRITE (1,...) ' PRINT ' // BUFFER
WRITE (1,...) ' END'
CLOSE (UNIT=1)
CALL LIB$SPAWN ('@COMP_LINK_RUN_1',...)
. . .
(just kidding)
Nitsan
|