RS> You really should be doing the calculation on the unarchived
 RS> size, not the archived size, coz the packing ratios vary quite
 RS> a bit between PKT and QWK since the common strings are
 RS> different.

 BL> Yair... but you tend to get a consistent average over various
 BL> packets and sizes.

 RS> And consistent averages arent any use when trying to detect if
 RS> a message or two got lost. With a particular ratio on a
 RS> particular PKT/QWK pair you never know if it was an exceptional
 RS> collection of messages or some dropped.

  A single dropped message will show up in the converter itself, and
ought to be checked there. I was more concerned about a dropped
packet, if it failed to unzip for some reason, or failed to be read if
it had a fulty header, or such. Once the converter opens the packet it
just keeps on truckin'. A broken message will throw it out of kilter
so that it misses a null terminator, and it will fail then, and
generate an error.

 RS> Yeah, thats mostly the PATH and SEENBYS getting dropped, but
 RS> the business of unpacked to packed size is surprisingly complex
 RS> and you dont even get the same effect over all the archive
 RS> formats. Any dictionary style compression has to give odd and
 RS> hard to predict behaviour at times.

  Yair. I replace the PATH and SEENBYS with spaces, and I had lots 
of spaces in the QWK message front and back, because QWK pads out to 
128-byte records with spaces. I trimmed them but it made no difference 
to the archive, which was compressing consecutive spaces rather well.

 RS> Yeah, no argument that its definitely harder and slower. OTOH I
 RS> dont believe the other is good enough.

  It's made worse by my twitter. RTL gave me the poos yesterday in
AVTech, and it only took three lines of code to add a twitter to the
converter, but 150 messages became 127, and it ruins all my ratios! 

  I'm stumped. I can't count the messages in the packet archives; just
the packets, and now even the sizes don't mean anything. If I open the
archive to count messages, I don't include possible unzip errors. All
I can do is count packets in the unopened archives, and make sure I
process the correct number of packets, and then count messages to make
sure I write as many to QWK as I read from PKT (including twits).

 RS> Fact remains tho, for a reliable safety check message counter
 RS> in PKTs, you need a completely different alg, new code, the
 RS> works. I'm not convinced its particularly difficult.

  I dont agree with that philosophy. Two stuffed algorithms are worse
than one good one. 

 RS> Nope, you certainly do have to actually scrutinise the unzipper
 RS> error code, not just ignore it like is done now, but thats dead
 RS> easy.

  How? 

 RS> The other big deficiency is the inconsistency, the netmail
 RS> being quite different in detail to the echomail etc.

  Yair! That's what gives me the shits most of all. You have to
actually write two different headers and footers for the message. I
can't imagine why they did that, especially when it introduces a
conflict over the "AREA:" line.

 BL> Writing code is very like designing a circuit;

 RS> Its not as similar as you might think actually.

 BL> you stuff around until you find code that *wants* to work
 BL> because it can't do anything else.

 RS> Really good code is often the result of an inspiration on an
 RS> approach which really is intrinsically bullet proof,
 RS> particularly WRT the alg. Some approaches are bullet proof,
 RS> others arent. 

  This is what I said, using different words. In my experience, a good
ciruit is one that *wants* to work, and code is similar because it is
the same principle. Events that are conditional on other events almost
always stuff up. Youy discover this by testing - doing weird things.

 BL> Bugs are mostly oversights, not errors in the computer itself.

 RS> Yes, the vast bulk of them are indeed silly stuff which when
 RS> you can focus on the area which is stuffing up your reaction is
 RS> 'shit, how fucking obvious, what a dill'. Not all tho. There is
 RS> a whole class of problem found in the testing stage where you
 RS> just assume a particular alg is viable and it just plain aint,
 RS> you have had a brain fart and havent considered one possibility
 RS> which actually does occur in the real data being processed. And
 RS> at times that makes the alg totally unusable. 

  Yair... the second is a logic flaw. It amazes me how something
sounds quite sensible until you find the flaw. Language is quite
imprecise, and our brains are designed to operate on estimates, but
yoiuy get the same thing in circuit design. This is what has surprised
me most of all about programming as I get deeper into it: how similar
it is to what I've been doing for the last 35 years in circuit design.
You make the same silly assumptions, and get the same bites on the
bum.

  The difference is that VB suits my approach very well - a flameproof
compiler that protects itself against my wildest guesses. The BC++
compiler is a monster to me. The C language itself is easier than VB,
but you need to get it right or it will do something totally mad. The
restrictions in VB are actually protections.

 RS> There are ALSO a few which really are due to the machine. That
 RS> Pentium bug is an example of that. Computers are far far more
 RS> complex than any other electronic device and they inevitably
 RS> always have imperfections which can at times fang your arse
 RS> severely.

  Yes... I'll give you that - and limits on the language and the
compiler - and bugs in that! You find the same thing with faulty
components and hardware in the real world; inherent flaws you have to
work around and live with.

 RS> PKT2QWK is plenty complex enough to see the problem. Even a PKT
 RS> joiner can be, tho usually isnt.

  I wrote a joiner first, and then the twitter, and the converter is 
not much different. All it adds is a struct to create the QWK header. 
It's no big deal, Rod. It has to be, if I can make it work.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---