TRACE in NetRexx Programs.
Locked
TRACE in NetRexx Programs.
 
|
The major question (from *my shop*) is:
Why the hell should a PRODUCTION Version of a Compiled Class STILL use TRACE, when it is already debugged ?? Wouldn't it be better to seek for other mechanisms, for the run-time version to seek for OTHER methods, like ASSERTIONS ? I'm lovings ASSERTIONS! I'm putting them into my programs, and they do tell me, when some algorithms of mine are wrong (which happens from time to time) I'm only using TRACE in the early DEVELOPMENT CYCLE of a program..... ... *OR* , when I found a *BUG* , *to DEBUG the BUG* (of my program) (Sorry, MFC, to say that) Thomas Schneider.
Tom. (ths@db-123.com)
|
|
|
> Why should a PRODUCTION Version of a Compiled Class > STILL use TRACE, when it is already debugged ?? Tom, I think you have not been reading the earlier posts. NetRexx includes (and improves upon) the Rexx Trace instruction. However, when you compile with the 'notrace' option (or put notrace in an options instruction) then all trace instructions are ignored. They generate no code or overhead, so of course they can be in a 'production version'. When (sometime later) you discover a bug, remove the notrace option and your tracing is back in action (and quite probably is in all the right places) -- without any edits to the code. Assertions are a different approach to similar problems, and I use them to warn people who modify my code that they are violating some assumptions (e.g., invariants) that I as the original author made. Assertions are not very useful for guarding against original bugs, however, because if you can write the assertion you have already thought about the edge case in question. And, like trace, assertions are only 'free' if you can turn them off with a switch, or if they can be resolved at compile time. Mike |
TRACE in NetRexx Programs.
|
|
Hi Mike,
our whole *discussion* (when ANY) is distracting. And I don't like that. You did just a marvelous Job in designing NetRexx, and implementing a 'reference implementaion', namely this on IBM, that I am deep in your thank-full-ness. I do know, howeverm I have had an opposite meaning than you for years, +BUT+ PLEASE; ONLY IN DETAILS: I DO like what you did (it's a LOT). I do *not* like to *fight* (** unless OBVIOUSLY necessary**) And, *for completeness*, *You* will be the last man on Earth which whom I' would fight... You are simply better .... Thomas. PS: Nevertheless, I'll try to complete my Rey (Rexx for Java) release now. ============================================================================= Mike Cowlishaw schrieb: > > >> Why should a PRODUCTION Version of a Compiled Class >> STILL use TRACE, when it is already debugged ?? >> > > Tom, I think you have not been reading the earlier posts. NetRexx includes > (and improves upon) the Rexx Trace instruction. > > However, when you compile with the 'notrace' option (or put notrace in an > options instruction) then all trace instructions are ignored. They generate > no code or overhead, so of course they can be in a 'production version'. > > When (sometime later) you discover a bug, remove the notrace option and your > tracing is back in action (and quite probably is in all the right places) -- > without any edits to the code. > > Assertions are a different approach to similar problems, and I use them to > warn people who modify my code that they are violating some assumptions > (e.g., invariants) that I as the original author made. Assertions are not > very useful for guarding against original bugs, however, because if you can > write the assertion you have already thought about the edge case in > question. > > And, like trace, assertions are only 'free' if you can turn them off with a > switch, or if they can be resolved at compile time. > > Mike > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > >
Tom. (ths@db-123.com)
|
TRACE in NetRexx Programs.
|
|
In reply to this post by Mike Cowlishaw
Agreed!
I did'nt talk about that, Mike (see next post from me...) And please let me know wether we should discuss this personally (mail to mail) or ON THIS GROUP! Thanks a lot, Thomas. ======================================================= Mike Cowlishaw schrieb: > > >> Why should a PRODUCTION Version of a Compiled Class >> STILL use TRACE, when it is already debugged ?? >> > > Tom, I think you have not been reading the earlier posts. NetRexx includes > (and improves upon) the Rexx Trace instruction. > > However, when you compile with the 'notrace' option (or put notrace in an > options instruction) then all trace instructions are ignored. They generate > no code or overhead, so of course they can be in a 'production version'. > > When (sometime later) you discover a bug, remove the notrace option and your > tracing is back in action (and quite probably is in all the right places) -- > without any edits to the code. > > Assertions are a different approach to similar problems, and I use them to > warn people who modify my code that they are violating some assumptions > (e.g., invariants) that I as the original author made. Assertions are not > very useful for guarding against original bugs, however, because if you can > write the assertion you have already thought about the edge case in > question. > > And, like trace, assertions are only 'free' if you can turn them off with a > switch, or if they can be resolved at compile time. > > Mike > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > >
Tom. (ths@db-123.com)
|
TRACE in NetRexx Programs.
|
|
Hi Mike, and ibm-netRexx Group, again (last time for today)
What David Requena, and Kemit Kiser, and I (sorry), ... have been discussing was: STATIC vs, DYNAMIC *TRACE* As far as I can see, from the Generated Java Code, with the REFERENCE NetRexx Compiler, *IF* there is a TRACE INSTRUCTION there in, *AND* there is no TRACE OFF instruction in the method in question preceeding, *THEN* the original *NetRexx Source Code* is **copied** to the generated Java Program .... *END-IF* I'm pretty sure about that, but it has been 5 years ago that I actually did have *any* need to look at the NetRexx Generated Java code ..... ... I'm very simple: If NetRexx works, I#m using it ... 'AND' NetRexx works..... *End of discussion, on this list* From my side, at least. The whole design and implementation of NetRexx simply is: *** The best COMPUTER language I've ever seen *** ... and I do know PL/I, COBOL, FORTRAN, BASIC, Rexx, Object Rexx, NetRexx, Java, C, C++,C#, Polish, English, Italian. Slowakian, Hungarian, French, Macedonian, Greek, *and* Deutsch (GERMAN, sorry I forgot the translation) .... *all of them a (1) BIT * ********************************************** A BIT is a BIT is A bit. (Tautology) 2 BITS are 2 BITS. (Tautology) ( which implies 3 BITS are THREE BITS) 1 BIT ist ein BIT ist ein BIT (Tautology) ********************************************** Tom. ================================================================= Thomas Schneider schrieb: > Agreed! > I did'nt talk about that, Mike (see next post from me...) > > And please let me know wether we should discuss this personally (mail > to mail) > or ON THIS GROUP! > > Thanks a lot, > Thomas. > ======================================================= > Mike Cowlishaw schrieb: >> >> >>> Why should a PRODUCTION Version of a Compiled Class STILL use TRACE, >>> when it is already debugged ?? >>> >> >> Tom, I think you have not been reading the earlier posts. NetRexx >> includes >> (and improves upon) the Rexx Trace instruction. >> >> However, when you compile with the 'notrace' option (or put notrace >> in an >> options instruction) then all trace instructions are ignored. They >> generate >> no code or overhead, so of course they can be in a 'production >> version'. >> When (sometime later) you discover a bug, remove the notrace option >> and your >> tracing is back in action (and quite probably is in all the right >> places) -- >> without any edits to the code. >> Assertions are a different approach to similar problems, and I use >> them to >> warn people who modify my code that they are violating some assumptions >> (e.g., invariants) that I as the original author made. Assertions >> are not >> very useful for guarding against original bugs, however, because if >> you can >> write the assertion you have already thought about the edge case in >> question. >> >> And, like trace, assertions are only 'free' if you can turn them off >> with a >> switch, or if they can be resolved at compile time. >> >> Mike >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> > >
Tom. (ths@db-123.com)
|
|
|
Thomas,
There was some email exchange on the list about dynamic class generation and parsing a few days ago. I don't remember any discussion of this in relation to the tracing though. Should we discuss these matters when Rey is finally out? This way we all will be able to see what is exactly your point. Some things just are easier to explain in code when it is in context :-) Note also that in most occasions, just a code snippet in the body of your email suffices to illustrate your point. This shouldn't disturb anyone on the list who's not interested in receiving file attachments. Just my 2 cents :-) --- Saludos / Kind regards. David Requena El 15/02/2010 23:45, Thomas Schneider escribi?: > Hi Mike, and ibm-netRexx Group, again (last time for today) > > What David Requena, and Kemit Kiser, and I (sorry), > > ... have been discussing was: > > STATIC vs, DYNAMIC *TRACE* > > As far as I can see, from the Generated Java Code, with the REFERENCE > NetRexx Compiler, > *IF* there is a TRACE INSTRUCTION there in, > *AND* there is no TRACE OFF instruction in the method in question > preceeding, > *THEN* the original *NetRexx Source Code* is **copied** to the generated > Java Program .... > *END-IF* > > I'm pretty sure about that, but it has been 5 years ago that I > actually did have > *any* need to look at the NetRexx Generated Java code ..... > > ... I'm very simple: > > If NetRexx works, I#m using it ... > > 'AND' NetRexx works..... > > *End of discussion, on this list* > > From my side, at least. > > The whole design and implementation of NetRexx simply is: > > *** The best COMPUTER language I've ever seen *** > > ... and I do know PL/I, COBOL, FORTRAN, BASIC, Rexx, Object Rexx, > NetRexx, Java, C, C++,C#, > Polish, English, Italian. Slowakian, Hungarian, French, Macedonian, > Greek, > > *and* Deutsch (GERMAN, sorry I forgot the translation) > .... > *all of them a (1) BIT * > ********************************************** > A BIT is a BIT is A bit. (Tautology) > 2 BITS are 2 BITS. (Tautology) ( which implies 3 BITS are > THREE BITS) > 1 BIT ist ein BIT ist ein BIT (Tautology) > ********************************************** > Tom. > ================================================================= > > Thomas Schneider schrieb: >> Agreed! >> I did'nt talk about that, Mike (see next post from me...) >> >> And please let me know wether we should discuss this personally (mail >> to mail) >> or ON THIS GROUP! >> >> Thanks a lot, >> Thomas. >> ======================================================= >> Mike Cowlishaw schrieb: >>> >>> >>>> Why should a PRODUCTION Version of a Compiled Class STILL use >>>> TRACE, when it is already debugged ?? >>> >>> Tom, I think you have not been reading the earlier posts. NetRexx >>> includes >>> (and improves upon) the Rexx Trace instruction. >>> >>> However, when you compile with the 'notrace' option (or put notrace >>> in an >>> options instruction) then all trace instructions are ignored. They >>> generate >>> no code or overhead, so of course they can be in a 'production >>> version'. When (sometime later) you discover a bug, remove the >>> notrace option and your >>> tracing is back in action (and quite probably is in all the right >>> places) -- >>> without any edits to the code. Assertions are a different approach >>> to similar problems, and I use them to >>> warn people who modify my code that they are violating some assumptions >>> (e.g., invariants) that I as the original author made. Assertions >>> are not >>> very useful for guarding against original bugs, however, because if >>> you can >>> write the assertion you have already thought about the edge case in >>> question. >>> >>> And, like trace, assertions are only 'free' if you can turn them off >>> with a >>> switch, or if they can be resolved at compile time. >>> >>> Mike >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > |
The Rey Compiler (ReyC).
|
|
OK. David.
I'll work for a couple of days again *and* send *NOT* out any e-mails. *ONLY that you*, and some others, do understand: What I'm trying to do here with Rey (and ReyC, the Rey Compiler) is no more and no less than: --- Accepting ANY REXX Dialect as INPUT --- including 'classic Rexx', (Open) Object Rexx, and NetRexx --- and exectutng it in a JAVA environment. I would NOT like to disturb anybody..... But I was thinking a LOT of years about languahes, and a / any DIALECTS: I think, it might be worthwhile to finish my efforts.... But I will be quiet for some time... I do Really NOT want to disturb anybody in his/her currents efforts. OK? Tom. ============================================================== David Requena schrieb: > Thomas, > > There was some email exchange on the list about dynamic > class generation and parsing a few days ago. I don't > remember any discussion of this in relation to the tracing > though. > > Should we discuss these matters when Rey is finally out? > This way we all will be able to see what is exactly > your point. Some things just are easier to explain in code > when it is in context :-) > > Note also that in most occasions, just a code snippet in the > body of your email suffices to illustrate your point. This > shouldn't disturb anyone on the list who's not interested > in receiving file attachments. > > Just my 2 cents :-) > > --- > > Saludos / Kind regards. > David Requena > > > El 15/02/2010 23:45, Thomas Schneider escribi?: >> Hi Mike, and ibm-netRexx Group, again (last time for today) >> >> What David Requena, and Kemit Kiser, and I (sorry), >> >> ... have been discussing was: >> >> STATIC vs, DYNAMIC *TRACE* >> >> As far as I can see, from the Generated Java Code, with the REFERENCE >> NetRexx Compiler, >> *IF* there is a TRACE INSTRUCTION there in, >> *AND* there is no TRACE OFF instruction in the method in question >> preceeding, >> *THEN* the original *NetRexx Source Code* is **copied** to the generated >> Java Program .... >> *END-IF* >> >> I'm pretty sure about that, but it has been 5 years ago that I >> actually did have >> *any* need to look at the NetRexx Generated Java code ..... >> >> ... I'm very simple: >> >> If NetRexx works, I#m using it ... >> >> 'AND' NetRexx works..... >> >> *End of discussion, on this list* >> >> From my side, at least. >> >> The whole design and implementation of NetRexx simply is: >> >> *** The best COMPUTER language I've ever seen *** >> >> ... and I do know PL/I, COBOL, FORTRAN, BASIC, Rexx, Object Rexx, >> NetRexx, Java, C, C++,C#, >> Polish, English, Italian. Slowakian, Hungarian, French, >> Macedonian, Greek, >> >> *and* Deutsch (GERMAN, sorry I forgot the translation) >> .... >> *all of them a (1) BIT * >> ********************************************** >> A BIT is a BIT is A bit. (Tautology) >> 2 BITS are 2 BITS. (Tautology) ( which implies 3 BITS are >> THREE BITS) >> 1 BIT ist ein BIT ist ein BIT (Tautology) >> ********************************************** >> Tom. >> ================================================================= >> >> Thomas Schneider schrieb: >>> Agreed! >>> I did'nt talk about that, Mike (see next post from me...) >>> >>> And please let me know wether we should discuss this personally >>> (mail to mail) >>> or ON THIS GROUP! >>> >>> Thanks a lot, >>> Thomas. >>> ======================================================= >>> Mike Cowlishaw schrieb: >>>> >>>> >>>>> Why should a PRODUCTION Version of a Compiled Class STILL use >>>>> TRACE, when it is already debugged ?? >>>> >>>> Tom, I think you have not been reading the earlier posts. NetRexx >>>> includes >>>> (and improves upon) the Rexx Trace instruction. >>>> >>>> However, when you compile with the 'notrace' option (or put notrace >>>> in an >>>> options instruction) then all trace instructions are ignored. They >>>> generate >>>> no code or overhead, so of course they can be in a 'production >>>> version'. When (sometime later) you discover a bug, remove the >>>> notrace option and your >>>> tracing is back in action (and quite probably is in all the right >>>> places) -- >>>> without any edits to the code. Assertions are a different approach >>>> to similar problems, and I use them to >>>> warn people who modify my code that they are violating some >>>> assumptions >>>> (e.g., invariants) that I as the original author made. Assertions >>>> are not >>>> very useful for guarding against original bugs, however, because if >>>> you can >>>> write the assertion you have already thought about the edge case in >>>> question. >>>> >>>> And, like trace, assertions are only 'free' if you can turn them >>>> off with a >>>> switch, or if they can be resolved at compile time. >>>> >>>> Mike >>>> >>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> >>>> >>> >>> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > >
Tom. (ths@db-123.com)
|
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |