[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Parse



Robert wrote:
On condition that you keep the size down to the minimum. We'll send your
license -- you have to post it on the wall, inspectors are entitled to see it
on demand.

I'll post it next to my liquor license.

BTW, S/G 101 is one or two bytes, 103 is one byte, 102 is 40 bytes max.
Within a chain of programs, parents
and children, transient Save/Gets continue to live -- they even survive the
crash of a child (assuming the S/G in question wasn't a direct casualty of the
crash, i.e. was not part of the procedure that crashed). So as long as there
is no overall break in program execution (i.e. you don't restart sopme element
manually) , you could use a transient S/G as your flag.
Really? I didn't know that. Might as well leave them as now set, since I'm
posting the license.
One other, very important thing: use CLEARSGTS to wipe out the content of your
"compiler" S/Gs when you exit it -- and any other program utilizing permanent
Save/Gets that consume much memory. CLEARSGTS (much improved in the imminent
v115, BTW) does a remarkable thing, which native XyWrite cannot do (except for
"ordinary Save/Gets 0-9,A-Z): it not only zeroes out the length of specified
Save/Gets, it actually de-initializes them -- they are completely GONE! You
can re-initialize and re-use them at any time, of course, but for the nonce,
they vanish -- remember that even zero-length Save/Gets have memory overhead.

7+ Kbytes is too long for an XPL program!
I'm beginning to wonder about that myself. I'm thinking of re-writing it in
Python, a language similar to Perl but more user-friendly. But a) I'm a
real novice in Python and b) I'd have to give up SEarch and CI for "regular
expression" language.
 I'll bet its full of gratuitous verbosity.

By your standards, sure.
 Use HILITE to inspect the code; you'll probably find that
many S/Gs are used only once or twice, in a limited part of the program, and
can be re-used elsewhere. RENUMBER and RELABEL it so that it has a rational
structure.
Those look helpful. I take it that the idea is to find S/Gs used only once,
and if there are say 7 of those, re-use the same S/G 7 times.
If I may brag, my "compiler" already prints out a list, at the bottom of
the program, of every S/G, in sequence, with it's source-language
equivalent--e.g.,:
74 = date.code$
75 = ftp.filename$
So I can scan that for S/Gs used only once, which I haven't done, but will do.
Re RENUMBER and RELABEL: the "compiler" also assigns the numbers and labels
in sequence, from the git-go. (But I can also instruct it to assign any
particular S/G number I want to any particular source-code variable.)
 Then, at the end of the PM, say something like:

JM 2.clearsgtsQ2 ;*;
Will do, sounds like a clean way to go. But why not clear all the numbers
out, once the program is finished?
> BTW, since I make U2 calls, I "reserve" S/G 50--never use it.

Good boy.
I do my best. Oh, and to be honest, I have to do this because I use 50 in
calling some U2 routines that use it.

Regards,
Harry

Harry Binswanger
hb@xxxxxxxx