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)

.