Text 80, 99 rader
Skriven 2005-02-13 20:49:26 av mark lewis (1:3634/12)
     Kommentar till text 77 av Maurice Kinal (1:153/401.1)
Ärende: MSGID
=============
 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)