TZUTC: -0400
MSGID: 27.fido-pascalle@1:3634/12 23042ccf
REPLY: 15.fido-pascalle@3:633/410 2303cca8
PID: Synchronet 3.18a-Linux  Apr 12 2020 GCC 7.5.0
TID: SBBSecho 3.10-Linux r3.159 Apr 12 2020 GCC 7.5.0
CHRS: ASCII 1
NOTE: FSEditor.js v1.103
  Re: Re: Still here
  By: Tony Langdon to mark lewis on Tue Apr 21 2020 15:47:00


 ml>> in fact, the delay routine is the one that lead to all the runtime
 ml>> 200 errors because of the way they did the calibration loop and didn't
 ml>> check if the result was zero before trying to divide it by the number
 ml>> of seconds the calibration loop ran...

 TL> Yeah I don't recall striking that in the TP days. Or is this
 TL> a FP only bug?

it is absolutely a borland bug... it affects all of their languages that used
that form of delay calibration... nothing at all to do with FPC... it reared
its head when machines got fast enough for the calibration loop run to
completion within the same second... so they increased the loop count and got
bitten again when machines sped up again... i think they had one more round of
it before someone finally smartened up and finally figured out another way to
calibrate the delay routine...

the calibration loop? they were executing a certain number of NOOPs because
NOOPs had a known execution time that didn't vary... so they'd execute say
10000 of them and subtract the start time from the end time to figure out the
speed of the machine... when those NOOPs were all done in the same second, end
- start equaled zero but they didn't check for this before doing their
division and thus raising the RT 200 defect notification...

 TL>>> And that's the part I need to learn. ;)  Reading FP documentation
 TL>>> on network programming and using the libraries didn't help.

 ml>> yeah, there's sample code for web available... i think they're in
 ml>> lazarus... there are a couple of others, too, IIRC...

 TL> I'm not interested in web for most of my applications.

the idea of my statement was to point to the existing working examples ;)

 TL> TCP or UDP sessions are usually more useful to me, because I want
processes to be able to talk across the network plainly. :)

that can still be done even if using a so-called web-server/web-client setup ;)

client sends a request.
server sends some sort of response.
client does its thing.

the request could be some format you come up with or maybe it would be
something in JSON or using AJAX or something else... the response could be
similar, as well... it just depends on what you want done...

i can envision serving JAM message bases directly to a client without any
intervening format layering... maybe no binary by converting that to ASCII
text for the transmittal... having a client/server message reader like that
would be a first step toward doing a client/server BBS setup... sure, it would
be a dedicated client for the users but then maybe the client would reside
server side and convert to standard traditional terminal sequences so the
entire client/server thing is completely hidden from the users...


)\/(ark
--- SBBSecho 3.10-Linux
 * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
SEEN-BY: 1/120 123 10/0 1 14/5 15/0 18/0 19/36 20/4609 90/1 102/401
SEEN-BY: 103/705 9999 106/201 116/18 116 120/331 340 601 123/0 25
SEEN-BY: 123/50 115 140 150 170 755 135/300 153/757 7715 154/10 203/0
SEEN-BY: 214/22 218/0 1 215 401 410 530 700 720 802 820 221/0 222/2
SEEN-BY: 226/16 30 227/114 229/101 426 452 616 1014 230/150 152 240/5832
SEEN-BY: 249/206 317 400 250/1 261/38 100 266/512 267/155 275/100
SEEN-BY: 280/464 5003 282/1031 1056 291/100 111 292/8125 317/3 320/119
SEEN-BY: 320/219 322/757 340/400 341/66 342/13 200 396/45 423/120
SEEN-BY: 633/280 640/1321 712/848 801/161 189 1502/119 2320/105 3634/0
SEEN-BY: 3634/12 15 27 50 119 5020/715 1042
PATH: 3634/12 261/38 218/700 103/705 280/464 229/426