Subj : proposed new nodelist
To   : mark lewis
From : Jasen Betts
Date : Sat Aug 17 2002 09:41 pm

JB>> You can't just "absolute" them over each other  because then
JB>> reading one would erase the next...

ml> i understand that... its the concept...

explain the concept then.

that code snip is from one
ml> of my PKT analyzers... it hops between the different ones
ml> searching for the one that has the least amount of "garbage" in
ml> the fields so as to determine what PKT type (2, 2.0, 2+) is being
ml> used..

right, a sort of fuzzy-logic (if you'll excuse the buzz-word) pattern matching


ml>>> understand but also hear others "screaming" about the
ml>>> "bulkiness" and duplication of the data... that has always been
ml>>> a bitch... "the nodelist is too large. why can't we cut it down
ml>>> in physical 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 amiga
JB>> who didn't have enough ram - neither did I but wordstar doesn't
JB>> need big ram to edit a big file)

ml> right but it does (still) bother many... this network is dropping
ml> folk all the time... the ones who are left are many of our older
ml> members... there will come a time when the average age of a
ml> fidonet sysop is >50... i suspect that its close to that now if
ml> not already more..

there seemz to bemore young people outside of zone 1.

ml>>> true but it'll still build out to be a line once you get to the
ml>>> line terminator..

JB>> depends how you code the reading...

ml> EOL is EOL is EOL, no matter how you code it...

I guess I didn't understand what you meant by "build out to be a line"

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
ml>>> base formats built on that particular limit... the HMB
ml>>> MSGTXT.BBS file is one such... nothing but rows of strings..

JB>> so pascal programmer will have to treat a long-line file as lines
JB>> containing fileds rather than just a bunch of strings,

ml> can't! can't read lines/strings longer then 255 characters by
ml> default... can only do so with 'outside' code, not stuff already
ml> existing in all languages..

Name one general purpose language that can't handle lines longer than 255
characters witout using external procedures.

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.

ml> won't work on lines greater then 255 characters... definitely not
ml> for a new coder with the free TP 5.5 from borland's site..

New coders?

program longlines;
procedure readfield (var f:text;var s:string);
var c:char;
b:byte;
begin
 b:=0;
 if not eoln(f) then
  repeat
     read(f,c);
     if (c <> ',')  and (b < 255) then
       begin
        inc(b);
        s[b]:=c;
       end
  until eoln(f) or (c = ',');
  s[0]:=char(b)
end;

var
nl:text;
master,number,what,where,who,sysflags,ctype,caddr,cflags:string;
c:integer;
begin
 assign(nl,'nodelis2.'); reset(nl);

 while not eof(nl) do begin
   readfield(nl,master);
   readfield(nl,number);
   readfield(nl,what);
   readfield(nl,where);
   readfield(nl,who);
   readfield(nl,sysflags);
   writeln (master:6,number:6,what:15,where:20,who:20,sysflags);
   c:=1;
   while not eoln(nl) do begin
     readfield(nl,ctype);
     readfield(nl,caddr);
     readfield(nl,cflags);
     writeln('           (',c,') ',ctype:6,' ',caddr:-30,' ',cflags );
     inc(c);
   end;
   readln(nl);
 end
end.

JB>> they'll have to use a "readfield" procedure for getting the data
JB>> from the file into strings but that shouldn't be a big hassle,
JB>> they only need to write it once, and can use it for all fields.
JB>> if done using the ttextrec object (actually not "ttextrec", but
JB>> that's the naem in the online help) it needn't mean yhe
JB>> inefficinet  practice of repeatedly reading a single character
JB>> searching for a comma.)

ml> ahhh... i see (now) that you are also thinking in OOP style
ml> coding... i haven't been... i'm a procedural type of guy..

The above avample doesn't use any OO stuff,  messing with textrec seems to
require assembler code (I don't have propper docs or example code so I've
stopped looking at that.

JB>>>> yeah 255 is pretty cramped, way too short for my proposal.

JB>>>> Probably fewer than 10 rulesets would suffice for 99% of
JB>>>> 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.

ml> what bandwidth? we're talking about a small tool that should be
ml> less than 50k...

but has to run on half a dozen different operating systems...
are you going to distribute binaries for all of them?

allowing for external rulesets also opens the
ml> door for someone to screw something up..

It also allows for someone to fix something.

-=> Bye <=-

---
* Origin: Misery loves company, but company does not reciprocat (3:640/531.42)

You are viewing proxied material from cvs.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.