[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: Some XY IV encoding and U2 questions (Carl/Robert)
- Subject: Re: Some XY IV encoding and U2 questions (Carl/Robert)
- From: wbass@xxxxxxxx
- Date: Mon, 29 Dec 2008 03:40:55 -0700 (MST)
Carl, thanks again for your reply.
In a certain way, your reply was little more than I was after. It probably
wouldn't hurt for me to give you a clue as to what I'm up to, so you might
have a better idea where I'm coming from, so that you don't waste your
time giving me more information than I need.
I'm in the final throws of testing a grossly updated set of 'DOS' programs
which I call XYENC and XYDEC, which I plan to make generally available.
The first thing that would make sense for you to do (assuming you're
interested) would be go to the directory (with a browser)
basspad.com/xywrite/
which has no "index.html" file, so it just gives you a directory listing,
and you can download/view whatever you see there.
If you will download the file "xyencdec.zip" (and unzip it) you will get a
XyWrite III file that describes both what the programs do, and also a few
things that I think the programs will be useful for.
Briefly, XYENC is designed to encode an XPL program in an all ASCII format
that's as editable in notepad as it is in XyWrite, and also designed so
that encoded XPL program can actually be read *and understood* just about
as easily (or easier) in notepad as the original program can be understood
using XyWrite. The XYDEC program gets you the original back.
In encoding something like a XyWrite 3 byte encoded data char, XYENC
translates it (usually) to two bytes - a "prefix" (a ":" or ";") and
the 1
byte version of the 3 byte encoded character. That's 3 bytes encoded in
well under 2 bytes, so obviously, information is lost. On decode, XYDEC
will expand the 1 byte version of the character back to the 3 byte
version, but will translate it back to a STANDARD 3 byte encoding (it will
do XY III flavor for a ":" prefix or XY IV "search char" encoding for a
";" prefix). So, in some way, my question was: would this be good enough,
or must I be able to reconstruct non-standard original encodings as well?
I think you answered that -- you guys do/did have reasons for using
non-standard encodings.
You can read the document to see how I handled the problem generally.
I would welcome comments and suggestions. If tweaking the definition of
the program a bit would make it a lot more useful to someone, I'd also be
interest in suggestions of that kind.
Although I've update XYENC/XYDEC to be as inclusive of XyWrite IV as I
know how to be, you should be aware than I am not a XyWrite IV user. I use
XyWrite III+, and at this point am unlikely to switch. My attempts at
using IV have all been excercises in frustration, and to the extent that I
have gotten it running, it runs 100 times slower than III+ for some of the
stuff that I really care about (mostly, loading files quickly for
searching). So I'm not motivated to persue IV.
At the moment, there are three other zip files at the site I indicated.
Also a couple of html pages. The html pages are redundant with two of the
zips, so I don't particularly recommend them to any XyWrite owner. Let me
say a few words about the three other zips, though.
They all represent work in progress.
I have written over time some documents on XyWrite III+, that document a
variety of things about how XyWrite works. In a way, the documents cover
some of the same kind of stuff that you (Carl) and Robert have written
over the years. I'm trying to update them, according to new stuff I've
learned over time.
But my documents are targetted at a much different audience than your's
and Robert's, in my view.
Firstly, most of the stuff that you and Robert have done start with the
assumption that the reader (a) has XyWrite (IV even), and (b) knows his
way around XyWrite pretty damn well already. The stuff I'm writting trys
not to make those assumptions.
Secondly, my documents are targetted more at designers than users. Not so
much a "here's how you manipulate 3 byte codes," but rather "3 bytes codes
were used because ..." and "here were some design conflicts and
consequences of using 3 byte codes."
Anyway, for anyone that is interested, the files "overvw1" and "overvw2"
are what would be read first. Each section in those overviews has (or will
have) a "further detail" document, but the only one at the site at the
moment is the "keyboard" one.
These documents are all a work-in-progress, and probably hard to comment
on in the sense that one can't tell at this time whether things that are
missing are things that I overlooked, or whether they are things that
"just aren't there yet." Since there is only one, partially completed
"details" document, it's pretty clear that a great deal of stuff "just
isn't there yet."
Even though, I would think that folks could get an idea of where I'm
trying to go, from what is there.
Also, there is some new material in the documents, that might find some
discussion.
Any comments on any of those documents would be welcome.
Wally Bass