Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Port checking and timers

 [1/5] from: mat:eurogamer at: 26-Nov-2000 19:12


Hello, I've got a rudimentary IRC bot working in Rebol. However it's all a hideous kludge because the only way I've seen to check to see if a port has data is to wait for it. Is there a more elegant way? Would empty? <port> work on a low-level TCP port? Also, is there any built-in time type functions or do you have to build your own based off now/time? (with resolution only as accurate as a second). -- Mat Bettinson - EuroGamer's Gaming Evangelist with a Goatee http://www.eurogamer.net | http://www.eurogamer-network.com

 [2/5] from: holger:rebol at: 26-Nov-2000 12:01


On Sun, Nov 26, 2000 at 07:12:56PM +0000, Mat Bettinson wrote:
> Hello, > > I've got a rudimentary IRC bot working in Rebol. However it's all a > hideous kludge because the only way I've seen to check to see if a > port has data is to wait for it. > > Is there a more elegant way? Would empty? <port> work on a low-level > TCP port?
No. empty? can only be used with ports that are buffered into a series, not with "direct" ports. With current experimentals you can use wait [port 0] to check if a direct port has data. Alternatively, if you opened your port with /no-wait you can just copy from the port (without blocking) to get all data waiting at the port.
> Also, is there any built-in time type functions or do you have to > build your own based off now/time? (with resolution only as accurate > as a second).
The resolution of the time! datatype is one nanosecond. To get the current date/time with the highest possible resolution provided by the operating system use now/precise (with current experimentals only). If you only need the time, without the date, use now/precise/time. The exact resolution depends on the platform, but is one microsecond in most cases. -- Holger Kruse [holger--rebol--com]

 [3/5] from: larry::ecotope::com at: 26-Nov-2000 12:24


Hi Holger
> The resolution of the time! datatype is one nanosecond. To get > the current date/time with the highest possible resolution provided > by the operating system use now/precise (with current experimentals > only). If you only need the time, without the date, use now/precise/time. > > The exact resolution depends on the platform, but is one microsecond > in most cases. >
Using Core 2.4.39.3.1 (the Windows version), it seems that now/time/precise returns a time with a resolution of only 0.01 second, not microsecond or even millisecond. Is there some way of obtaining the higher precisions mentioned by you and Jeff. Thanks -Larry

 [4/5] from: holger:rebol at: 26-Nov-2000 12:55


On Sun, Nov 26, 2000 at 12:24:07PM -0800, Larry Palmiter wrote:
> Using Core 2.4.39.3.1 (the Windows version), it seems that now/time/precise > returns a time with a resolution of only 0.01 second, not microsecond or > even millisecond. Is there some way of obtaining the higher precisions > mentioned by you and Jeff.
It depends on the Windows version. Windows NT provides the millisecond value correctly, whereas Windows 98 only seems to provide multiples of ten for the millisecond time value. OS limitation... -- Holger Kruse [holger--rebol--com]

 [5/5] from: lmecir:mbox:vol:cz at: 27-Nov-2000 9:44


Hi, Holger wrote:
> The resolution of the time! datatype is one nanosecond. To get > the current date/time with the highest possible resolution provided
<<quoted lines omitted: 6>>
> [holger--rebol--com] > --
I am including my Time-tick function, which I used to find out, that the resolution of my computer timer is 55 milliseconds (a notebook with MS Windows 95). Warning! Works only with Rebol/Core 2.4.39.3.1 or newer. Regards Ladislav seconds: func [ {Compute difference between dates in seconds} a [date!] "first date" b [date!] "second date" ] [ b - a * 86400 + (to decimal! b/time) - (to decimal! a/time) + (b/zone/hour - a/zone/hour) * 3600 ] time-tick: function [ { Time the clock tick for a computer. Works reliably, if the execution time of the innermost loop block is shorter than the clock tick time, otherwise it gives the innermost loop block execution time instead. } accuracy [decimal!] ] [ guess count start time result prev cur ticks ] [ guess: 0 count: 1 while [ ticks: 0 start: prev: now/precise loop :count [ if :prev <> cur: now/precise [ ticks: :ticks + 1 prev: :cur ] ] time: seconds start cur result: 0 any [ ticks <= 0 ( result: time / ticks (abs result - guess) / result + (3 / ticks) > accuracy ) ] ][ guess: result count: count * 2 ] result ]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted