Re: Carl's notes

[Harry Binswanger hb@xxxxxxxx]

Carl,
I didn't think about the 77 byte limitation, but it makes sense. I
definitely initialize the s/g for the string in question, now I'll have to
a length test on it too. No problem there.
And thanks for the parsing program: I've decoded it and saved it for future
use.
I've spent the last 10 days almost solidly programing in XPL, to take
existing data and put it into new tables for use in a relational database.
It's been grueling but fun. The only result I can't account for is the
appearance in the data files, after running one program on them, of an
occasional 0Ahex at the beginning of a line. There's no 0A in my XPL, but I
guess something happened with regard to an 0A0C pair. Somehwere I must have
been treating it as one byte, somehow. Not important. I just CI it out by
hand afterwards.

--Harry
Reply to note from Harry Binswanger  Sat, 30 Aug
2008 12:03:55 -0400

Harry:

> I'm working on some items in a comma-separated database, and
> it's given me occasion to use the VA@ feature for extracting a
> substring.
> ...
> It's much easier to do > than to search for the
> third comma in a line, or parse it. And much cleaner.

A cautionary note:  (where "nn" is a Save/Get
identifier, and x the data-segment number) -- the feature you're
finding so handy (and it certainly is... handy) -- is a subset of
, which was also introduced in Xy4.  returns *the
first 77 bytes* of Save/Get nn, whether or not S/G nn is
initialized. (If S/G nn is not initialized,  returns a zero-
byte string.) This provides a pithy and memory-efficient way to
query the contents of a S/G (more precisely, the first 77 bytes
thereof) without first testing whether the S/G is initialized; it
avoids the cumbersome SUbroutine-crash test for initialization that
was necessary in Xy3. (If all you want to do is test whether a S/G
is initialized, without querying its contents, use
{less_than}0>...; S/G nn is unitialized if 
equals -1.)

The nugget to take away here is that VA@nn canNOT read past the 77th
byte of S/G nn -- and, it follows, neither can . If your
target segment lies past the 77th byte, you're out of luck with VA@.
You have to switch to an iterative XS parsing procedure, like this:

XPLeNCODE v2.0
b-gin [UNTITLED]
{<}SV01,segment1,segment2,segment3,segment4,segment5,segment6
,segment7,segment8,segment9,segment10,segment11,segment12,seg
ment13,segment14,segment15,segment16,segment17,segment18,segm
ent19,segment20,segment21,segment22,segment23,segment24,segme
nt25,segment26,segment27,segment28,segment29,segment30,segmen
t31,segment32,segment33,segment34,segment35,segment36,segment
37,segment38,segment39,segment40,segment41,segment42,segment4
3,segment44,segment45,segment46,segment47,segment48,segment49
,segment50,{>};*; Data[cr|lf];*;[cr|lf]{<}SV02,,{>};*; Separa
tor = "," (e.g.)[cr|lf]{<}SV03,43{>};*; Desired segment = 43{032}
(e.g.)[cr|lf]{<}SV04,{>};*; Contents of desired segment (on E
Xit)[cr|lf]{<}SV05,{>};*; XS parse placeholder for right-side
 string[cr|lf]{<}SX06,{<}IS01{>}{>};*; Working copy of data S
/G 01[cr|lf];*;[cr|lf]{<}CUa,03{>}{<}XS06,02,04,,05{>}{<}SX06
,{<}IS05{>}{>}{<}LBa{>};*; Do it (parse 43 times)[cr|lf];*;[c
r|lf]{<}PR@04{>}{<}EX{>};*; Prove it[cr|lf]
-nd
XPLeNCODE

XS parsing is fast but has the potential to cause out-of-memory
errors and destabilize XyWrite when S/G 01 (the data set) is
relatively large (depending on available memory, you might encounter
problems if S/G 01 is larger than, say, 3-4Kb. In that event, there
are alternatives).

So, yes,  is "much easier", but be aware of its
limitations.

--
Carl Distefano
cld@xxxxxxxx


Harry Binswanger
hb@xxxxxxxx