Subj : proposed new nodelist To : Jasen Betts From : mark lewis Date : Fri Aug 16 2002 02:04 pm ml>> i dunno... i'm visualizing the flow in pascal (actually)... i'm ml>> just seeing the first row filled and then the reading of the next ml>> line and parsing it for each field just not being that hard... and ml>> then to overlay the changed fields on the old, no biggie... kinda ml>> like using a buffer to store the data in and then using different ml>> structures that are overlaid right on top of that buffer... gosh, ml>> what is/was the term used for that ml>> [time passes] ml>> pkthead1 absolute bheader; JB> You can't just "absolute" them over each other because then JB> reading one would erase the next... i understand that... its the concept... that code snip is from one of my PKT analyzers... it hops between the different ones searching for the one that has the least amount of "garbage" in the fields so as to determine what PKT type (2, 2.0, 2+) is being used... ml>> understand but also hear others "screaming" about the "bulkiness" ml>> and duplication of the data... that has always been a bitch... ml>> "the nodelist is too large. why can't we cut it down in physical ml>> size? JB> size doesn't really worry me... sure whn it was 3 megs it took JB> about 20% of my hard space to edit it (for a friend with an JB> amiga who didn't have enough ram - neither did I but wordstar JB> doesn't need big ram to edit a big file) right but it does (still) bother many... this network is dropping folk all the time... the ones who are left are many of our older members... there will come a time when the average age of a fidonet sysop is >50... i suspect that its close to that now if not already more... ml>> true but it'll still build out to be a line once you get to ml>> the line terminator.. JB> depends how you code the reading... EOL is EOL is EOL, no matter how you code it... JB>>> 255?, that short? why? ml>> ummm, turbo pascal is still used by many newbie (and long time) ml>> developers... not to mention that there are even bbs message base ml>> formats built on that particular limit... the HMB MSGTXT.BBS file ml>> is one such... nothing but rows of strings.. JB> so pascal programmer will have to treat a long-line file JB> as lines containing fileds rather than just a bunch of JB> strings, can't! can't read lines/strings longer then 255 characters by default... can only do so with 'outside' code, not stuff already existing in all languages... JB> as soon as they decide to they can ignore a line they can do JB> READLN; and they'll be at the next line. won't work on lines greater then 255 characters... definitely not for a new coder with the free TP 5.5 from borland's site... JB> they'll have to use a "readfield" procedure for getting the JB> data from the file into strings but that shouldn't be a big JB> hassle, they only need to write it once, and can use it for JB> all fields. if done using the ttextrec object (actually not JB> "ttextrec", but that's the naem in the online help) it JB> needn't mean yhe inefficinet practice of repeatedly reading JB> a single character searching for a comma.) ahhh... i see (now) that you are also thinking in OOP style coding... i haven't been... i'm a procedural type of guy... JB>>> yeah 255 is pretty cramped, way too short for my proposal. JB>>> Probably fewer than 10 rulesets would suffice for 99% of fidonet ml>> agreed... and my thoughts are that they'd likely be coded in the ml>> program and this reside in the .EXE (to use dos think for a ml>> moment).. JB> could be, but that makes upgrades hard on the bandwidth unless JB> external rulesets can be used too. what bandwidth? we're talking about a small tool that should be less than 50k... allowing for external rulesets also opens the door for someone to screw something up... )\/(ark * Origin: (1:3634/12) .