Re: uniqcomp.pm - Working for others?

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Patricia M. Godfrey"  on Sat, 12
Nov 2005 16:04:52 -0500

Patricia:

> Or am I "finding the mare's nest by the pursuit of the red
> herring"?

Reminds me of the rather astute comment of Congressman
Markey (D, Mass), after the phony budget compromise was
tabled last week, excluding North Slope drilling, that
"the only wildlife protected by this bill is the red
herring." (Doubtless they pay staffers to think up cute
stuff like that.) Has anybody actually said "mare's nest"
in the last 250 years? Horses sometimes *do* hide their
young in tall grass FWIW (cows always do), so it isn't
entirely fabulous. One of the Belgians that I use for
lumbering (work horses, that is, 18 hands at the sway of the
back, maybe 20 at the withers -- waaay over my head) foaled
two years ago, and tried to conceal her baby for a few days
-- comical! This monster animal was always hanging in one
spot, while the little one staggered about.

Okay... whew. What a mess. Both Carl and I have built
fixes into our encode/decode routines (his QPE/QPD, my
ENCODE/DECODE) to handle padded spaces on the right, lone
Ascii-10 line endings (instead of 13+10), and multiple
contiguous (gratuitous) carriage returns. Plus a couple of
other refinements. That should go 99.9% of the way. The
FACT however is, that the ENCODE and DECODE of these
programs did not exploit any flaws in those two programs:
UNIQOMP was perfectly encoded, and decoded perfectly. (But
not if you had gratuitous space chars at the end of lines,
or bad line endings (not 13/10), or Thunderbird bars at the
beginning of lines, or gratuitous carriage returns (as Harry
reported).

All four versions in your 2VERS.COD are identical, as I'm
sure you know (I did an FD/FM of #1 against #2, # , and #4
-- identical). Moreover, they're identical to what I sent.
So you shouldn't be having a problem.

> Despite being ZIPped, the file (I'm using the ZIPPEd
> version) got corrupted in transit.

How do you know that? You got a problem, if that's true!
But if its true, you go to XySearch and grab another copy,
from the msg:
 http://xywrite.org/msg01614.htm
When I DL that ZIP from XySearch, it is not corrupt, it
unZIPs perfectly, and again it is identical to what I sent.
ZIPs, you know, simply do not make mistakes: they ZIP
perfectly, and they UnZIP perfectly. (But ZIP files can get
messed up in transit -- very very rarely, nowadays almost
unheard of.)

> I'm running on 98SE, Russ on an emulator in Mac. Russ,
> emulation of what? DOS? Win9x? If 9x, that may well be
> the monkey wrench in the works; we've been through this
> before, though it seems improbable.

9x under Windows, improbable. Can't vouch for Apple though
-- simply don't know how Apple stores files, treats line
endings, etc. Let's test your hypothesis under Win95, using
your two "possessive/genitive" files... perfect result.
Testing two 357K files with numerous differences... perfect.

> Uniqomp isn't doing any command/kmd calls is it?

No. You can see that it isn't -- we're talking about 19
lines of code here! There aren't any calls to other frames,
or to anything unusual. Very conservative XPL.

> I get different results when I re-encode
> (i.e., Decode a program in xplncode, then run ENC on
> the XplNcode). Is this somethine skew-whiff in my system,
> a meaningless artifact, or a problem?

When I paste the above quotes into XyWrite, they have extra
spaces at the ends of lines. When I paste my own msgs, no
spaces... I'm not making this up -- you try it.

But yes, that can happen, especially if there are references
to ENCODE/DECODE in the program that you're ENCODEing/DECODEing.
And Ascii-10 can be (or has been) very troublesome.
All this has been fixed in the new code I mentioned
above.

I'm beginning to wonder whether this isn't somehow related
to something lacking in user setups? Can you Redline, for
example? That would be a basic requirement. RED ON/RED
OFF? Does Redlining work, are MoDes set by it? Redlining
does require that there be INSERT/DELETE entries in the PT=1
"MODE TABLE" in your PRiNter file, e.g.:
...
MD IN=(*+INSERT)
MD DN=(*+DELETE)
...
and also in the "ATTRIBUTE DEFINITIONS", e.g. (HPLJ-4.PRN):
...
AT:DELETE
AT#_??\
ET
;
AT:INSERT
AT??]
AT=2
ET
...

While playing around with UNIQOMP, I saw a few subtle
issues:

1) I wasn't doing a thorough job of mimicking Redlining, in
that I wasn't sensitized to the prevailing mode going into
the addition/deletion, and hence wasn't *restoring it* after
indicating the addition/deletion. I do now.

2) Using the PEV command is a really handy way to restore
the status ante, but there's one wee problem. **If** there
is a MoDe other than NorMal at the point of an *addition*,
PEV indicates those additions by setting  at the
beginning of the addition, and restoring the prevailing MoDe
at the end of the addition. (Deletions, whether removed
with "Y"es or restored with "U"ndo, are not marked in any
way -- the prevailing MoDe, ah, prevails!) So far so good.
The *problem* is that UNIQOMP is indicating (what it treats
as) "additions" by marking them as Redlining does, as
"additions". But they *aren't* really additions, at least,
not in the sense of an edit that you introduce while
Redlining is active. Actually, they're just changes that
you made to the text subsequent to the time that the earlier
"comparison" text was written. But PEV will set them to
 at the beginning and restore the prevailing MoDe at
the end. Again, this is ONLY a problem if a MoDe other than
NorMal is in effect at the point of the addition.

There are several workarounds. First, if you just want to
restore the status quo ante, command RECA. That
brings your original back. Second, I could write a
dedicated routine to manage this issue -- probably the best
solution -- a PEV without any drawbacks. Let's face it:
UNIQOMP is mostly an informational toy, and I almost always
just RECAll after marveling at it.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------