On 2012-07-09 17:29, Michael Bloom wrote:
On 07/08/2012 09:22 AM, Johnny Billquist <b...@softjar.se> wrote:
On 2012-07-08 13:58, Michael Bloom wrote:
version of TECO, it might be beneficial to make as much use of "local Q
registers" (those with two char names beginning with "."), so that you
don't unintentionally accumulate data that you no longer need. You
could think of them as a TECO equivalent to "alloca()".
They came after V36. But they are not strictly needed, as you can push
down Q-registers yourself if you want to play with them without
affecting someone else.
The whole point is avoiding the need to push Q-registers. It is all too
easy to make a mistake when pushing Q-registers that costs you a lot of
debugging time. If you don't push Q regs, you never have to pop them!
If you have local Q regs, there is little legitimate use for
pushing/popping them other than to rapidly copy both parts of one q-reg
to another q-reg (it's a good idea to use q-regs as two member structs,
when you can)
Right. Just pointing out that local Q-registers came after V36, and that
there is another solution for the same problem if you happen to be
running pre-V40. Having the language help you is a good thing though. I
agree.
Not sure when and why you'd need 32-bit arithmetic, though...
I'm not sure either, since, as I've already admitted, I don't know the
HTTP protocol. But I did want to make a suggestion about long
arithmetic, just in case HTTP packets _did_ contain 32 bit fields upon
which arithmetic might be performed. With a heads up about this,
Richard can look for places where this might be needed, and plan
accordingly. It's always beneficial to strategize how to deal with
problems prior to dealing with them, rather than just jumping in to
code, and then figuring out how to "handle each bridge as it is
encountered".
I can't remember seeing anything that really needs 32-bit arithmetic in
the protocol.
I doubt you'll ever have TECO leak memory. However, you can run out of
memory, so cleaning up your Q-registers, especially if you know they
might store lots of data, is a good idea.
(TECOs memory handling is rather simplistic, not to mention well
tested by now, which is why I doubt you have any memory leaks.)
Of course, TECO itself is robust, but . . .
I was not referring to *TECO* leaking memory, but rather the program
running /within/ TECO, which may append to q register space, push
q-regs without popping them, or make memory disappear in other ways. If
you've ever written a reasonably large TECO program (such as the DECUS
11-737 package that I previously mentioned), you've got a good chance
of having experienced trying to debug a TECO memory leak. This is the
kind of place where defensive programming really shines. As one of my
college profs was known to say "The main prerequisite for debugging is
''bugging''. And especially with a language that so resembles line noise
as TECO does, avoiding "bugging" takes care.
Leaking memory, to me, implies that it is lost. Just being sloppy and
not freeing up memory you have allocated and still keeps track of is not
the same as leaking memory. But yes, keeping your memory usage under
control is also a good thing.
Dumping out a file is something TECO can do all day long without a
problem.
You can either do it page by page yourself, or let teco do it.
I was assuming that Richard planned to take use of the TECO data
manipulation facilities, not just use it as a glorified "cat"
Well, the HTTP protocol is almost more or less just a glorified cat...
There isn't that much to it, really.
Johnny
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
