TIP: Click on subject to list as thread! ANSI
echo: c_plusplus
to: TIM HUTZLER
from: MIKE LUTHER
date: 1998-04-08 13:31:00
subject: Re: Need More Memory

Tim... 
 
 > TH: TH>Just what are you try'n to do? 
 > TH:  
 > TH: MH>Trying to read in nodelist.* 
 > TH:  
 > TH: ??? 
 > TH:  
 > TH: How do you *read-in* a node list? Nodes are the stuff heaps are 
 > TH: made 
 > TH: of. Are you reading a file and creating a linked list? This file 
 > TH: "nodelist"... what's in it? 
 
He'll have to answer for himself, but likely as in FidoNet - NodeList... You 
know as in Zone, Net, Node and all that data.  At current size of, what is 
it, a couple megs in raw form?  The older programs make use of it via indexes 
of keys, which are binary techniques from disk files.  At least my old Opie 
does.  Programs which prepare these key files, may do the work up in segments 
of multiple open files, such as QNODE seems to do, using segments of memory 
such as you suggested; upper memory at that... 
 
An observer's hunch here is that he wants to creat a class of Nodelist, whose 
members are the various elements or fields of each record entry, so that 
other parts of his program may 'inherit the Whole Earth FidoNet' ... 
 
     or .... worse.....  :) 
 
I considered that sort of technique in an attempt to cross-reference any 
amateur radio operators QTH on earth, to the nearest FidoNet node.  I wimped 
out and used Btrieve to generate the index of some 1,750,000 records and 
fifty odd keys needed in my professional system instead.  The project was 
done to test the use of FidoNet as an emergency communications system in time 
of disaster, relative to the United States ham radio Field Day contest 
several years ago.  I simply merged in the FidoNet NodeList to the whole 
Amatuer Radio Callbook data into one huge and more complex NodeList! 
1,750,000 + 36,000 nodes was trivial...  Incidentally, my P-133 and fast wide 
SCSI box took over THREE DAYS non-stop to create the required system in 
BTRIEVE 6.15.2 with all the keys...  grin... 
 
Now all in memory prior to the disk write...  WOW! .... :) 
 
Incidentally, the excercise was HIGHLY successful!  Fido - CAN - do that! 
 
Now that I have started work in C++ I can see real ways to use the class 
concept to do things I never could have done.. (easily?)  in the Basic PD7 
arena... but talk about a huge memory model, about 3/4 gig.... phew! 
 
I think I'll expand the thread, perhaps, anticipating what he may find for 
other considerations in his vison quest... 
 
I still am having a great deal of trouble handling huge arrays of variable 
length strings that "lowly" PD7 with it's municipal memory trash truck easily 
did - including, dimensioning them for negative to positive elements. That 
let me swap array planes easily in memory for two threads of the needed work 
and never worry about the PD7 auto-destructive trash can... 
 
Now in C++ ... 
 
    This data will self-destruct in 6 minutes, James.... 
 
    "But Sir, I'm in C++ mode! at this end!", 
 
    as the computer goes up in smoke from the forgotten Byte From Hell! 
 
I keep thinking dit dit dit dah, dah, dah, dah; dit dit dit dah, dah, dah, 
dah, every time I go back to the workbench at this... grin... 
                    
In C++, try DIM A$(-100 to +100) for variable length strings where the 
elements of the array change constantly in the application and six networked 
clients (or more) need access to the open file that holds the constantly 
changing record of this information at the same time as binary file 
operations with full record lock and so on.  See how fast you can do that job 
from scratch in C++ vs. PD7.... You can code a whole system for that work in 
a few afternoons in PD7 friend, right out of the box! 
 
Yeah.. I can envision a *LOT* of things one could do with the NodeList in 
memory in C++ that I think he may be thinking about ... :) 
 
I can also envision his frustration at C++ as well - from personal experience 
- as I'm still fighting to get to be at the head of my class... :) 
 
 
Mike @ 117/3001 
 
 
--- Opus-CBCS 1.73a
---------------
* Origin: Ziplog Public Port (1:117/3001.0)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.