Subj : MSGID To : Maurice Kinal From : mark lewis Date : Sun Feb 13 2005 08:49 pm ml>> but then it wouldn't have been storable in a longint ;) MK> Do you mean 64 bits? no... 32bits... isn't that what you been "fussing" about? ;) in pascal, a longint is a signed 32bit number... MK> That would be extremely doable. Then again it potentially MK> could mean 128 bits to a few systems. MK> You must be doing 16 bit DOS-think. ;-) that's where fido was designed and built ;) ml>> ya gotta remember when this stuff was developed and what languages ml>> were being used... (borland) pascal was one of the most common... ml>> basic and c were also used with c getting more use as time marched ml>> on... MK> It doesn't matter. I was working with 64 bit systems back MK> then and had to port FORTRAN source from my 386-16, where I MK> liked to experiment with ideas, to a 64 bit UNIX enviroment. MK> I managed. What is their excuse? My best guess is they MK> didn't really understand what they were doing. Has little to MK> do with language unless one can't think beyond it's MK> "limitiations". nah, it has everything to do with hobbiests developing and creating the network we lovingly call fidonet... ml>> if one takes a good look at structures for many FTN tools, apps, and ml>> even bbs', one can easily see the pascal influence by the data ml>> structures used... MK> I suppose but most of what I see has little to do with any MK> language whatsoever. Most of the problems relate to lack of MK> vision rather then any so-called OS limitation, such as DOS, MK> which is obviously still haunting all of us. that may very well be... today, the problem is "all the old guys" and not wanting to update or upgrade as well as fear of the unknown... seems that those remaining who helped develope fidonet have lost their curiousity in their waning years O:) MK> The reason I like perl is that I can easily experiment with MK> ideas without jumping through too many hoops and could port MK> these scripts to a compilable language without too much MK> difficulty. Also perl kick's butt when compared to other MK> scripting languages as far as basic IO goes, as well as the MK> availabilty of some truly good modules. that's wierd... i've seen stuff done in perl (and other similar languages) to be a lot slower than the same stuff in compiled form from pascal, delphi, and some of that C stuff ;) MK> For instance MK> comparing perl to php I have found the same functions are MK> vastly superior in perl and yet looking out there on the web I MK> see the opposite being employed. That is one reason I don't MK> care much for web interfaces, although there are a few other MK> good reasons as well which don't have much to do with perl, so MK> I won't bother elaborating. Anyhow perl works great on the MK> console so I am happy with it. i hear ya there! MK> I believe a good perl ftn module would be a desirable MK> commodity. What do you think? it is possible... then again, i look around and see folk converting their squish message bases to mbox format and using "stuff" on the backside to access it... i'm not sure, but i suspect that fidonet.sensationcontent.??? is doing the same... it's either that or stuffing it in a sql database and throwing mucho horsepower at it for the access speed to retrieve it... the connection speed is another factor, altogether... i see something very similar, here... we have a 23000+ person genelogy database that is very fast in several geneology programs... i've pulled a complete gedcom ("kinda" similar to xml) 5.5 format and have two different web programs to work with it... one is just for viewing and uses a cgi .CMD to fire off a modula program for accessing the data... another is all php and using a mysql database... now, i don't have any of today's fast horses in the stable, either... the webserver is running on a PII 266 with 96meg of ram and houses a lot of other services... the sql server is running mandrake linux 7.2 on a P200 no-mmx with 64meg of ram... the difference is staggering compared with the locally run geneology database programs... the cgi program is possibly faster than the php app but it doesn't do anywhere near what the php app does... in fact, the php app is very close to the LDS PAF program... it allows editing and addition of the data... however, i believe that there are some things that can be done in the php program (actually stuff to do with mysql) that can greatly increase the database access... now, if it'll also just leave the gedcom behind other than using it solely for importing into the database, i'm sure that'll increase its speed majorly... FWIW: a gedcom file is a simple ASCII text file... the one that i'm working with is right at 16meg in size ;) )\/(ark * Origin: (1:3634/12) .