mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 3 1 2 3
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Slightly faster initialisation (<1s rather than 2s):
Code:
alias ctimems {
  if (!$var(%ctimems.ticks,0) || !$var(%ctimems.ctime,0) || (!$isid)) {
    var %ctime = $calc($ctime + 1), %ticks
    while (%ctime > $ctime) %ticks = $ticks
    set -e %ctimems.ticks %ticks
    set -e %ctimems.ctime $ctime
  }
  return $left($calc(%ctimems.ctime + (($ticks - %ctimems.ticks) / 1000) + .0001),-1)
}


And $timestampms:
Code:
alias timestampms {
  var %tsfmt = $timestampfmt
  if (s isin %tsfmt) {
    %tsfmt = $replacex(%tsfmt,ss,ss.xxx,s,s.xxx)
    var %ct = $ctimems
    return $replacex($asctime(%ct,%tsfmt),.xxx,$right(%ct,4))
  }
  else return $timestamp
}

Last edited by Protopia; 31/08/17 07:05 PM.
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
1. there's a bug in that where $ctimems always returns the ctime value for when the variables were initialized

2. If speed is what you are after, you'll want something such as:
Code:
;; Builtin command & identifier calls are forced via ! and ~ respectively. Doing so bypasses script-equivalent lookups

;; same usage as $ctime, and the above $ctimems
alias ctimeex {

  ;; Use hashtables over global variables, can be quite a bit faster
  ;; No need to track $ctime
  ;; $ticks can overflow and roll back to zero, so check for overflow condition
  !if (!$~isid || !$~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) {
  
    ;; create the hashtable
    !if (!$hget(misc)) hmake misc 1
    
    ;; Use inline arthmatic to avoid the overhead of calling $calc()
    !var %ctime $~ctime + 1
    
    ;; Use $v1 to store $ticks instead of a tracking variable
    !while ($~ctime < %ctime && $~ticks) { !noop }
    
    ;; store the ticks
    !hadd misc milliseconds.ticks $~v1
    
    ;; if used as command, stop processing
    !if (!$~isid) return
  }

  ;; Inline arthmatic to, yet again, avoid the overhead of $calc()
  ;; Done immediately to increase accuracy of the return value
  !var %ms $~ticks - $~hget(misc, milliseconds.ticks), %ms %ms % 1000

  ;; Return ctime with 3 digits of ticks in the decimal position; $calc is avoided
  !return $~+($~ctime, ., $~base(%m,10,10,3))
}

;; Uses the same formatting as $asctime with the addition of the following format items:
;      x: milliseconds as-is, so if the millisecond value is 95ms, x is replaced with "95"
;    xxx: milliseconds padded to 3 places so if the millisecond value is 95ms, xxx is replaced with "095"
alias timestampex {

  ;; existence & overflow check 
  !if ($~hget(misc, milliseconds.ticks) == $null || $v1 > $ticks) { ctimeex }
  
  ;; Immediately calculate the offset
  !var %ms $~ticks - $~hget(misc, milliseconds.ticks), %ms %ms % 1000

  ;; Using $replacexcs so only a single pass is made over the input AND the x/xxx replace matching is case-sensitive
  ;;   Replace xxx with the padded milliseconds
  ;;   Replace x with non-padded milliseconds value
  !return $~replacexcs($~asctime($~ctime, $~timestampfmt), xxx, $~base(%ms, 10, 10, 3), x, %ms)
}



;; initialization events
on *:LOAD:ctimems
on *:START:ctimems



Without comments, blank lines, or verbose var names:
Code:
alias ctimeex {
  !if (!$~isid || !$~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) {
    !if (!$hget(misc)) hmake misc 1
    !var %c $~ctime + 1
    !while ($~ctime < %c && $~ticks) { !noop }
    !hadd misc milliseconds.ticks $~v1
    !if (!$~isid) !return
  }
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~+($~ctime,.,$~base(%m,10,10,3))
}
alias timestampex {
  !if ($~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) ctimeex
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~replacexcs($~asctime($~ctime,$~timestampfmt),xxx,$~base(%m,10,10,3),x,%m)
}
on *:LOAD:ctimeex
on *:START:ctimeex



Note: $ticks is the best that can be done with pure mSL, but by its nature the accuracy can very substantially. I would not suggest using $ticks, or methods involving it if doing anything that requires time precision.

Last edited by FroggieDaFrog; 01/09/17 11:58 AM.

I am SReject
My Stuff
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Many thanks for this optimised version.

I don't find the $ctimems bug you report.

But I found this morning that there was considerable drift between $ctime and the integer part of $ctimems. But no idea why.

If the ticks-based calculation can drift, then you cannot append the ms calc to the end of $ctime either.

That said, I really appreciate the ideas about speed. Of course the big delay is the loop waiting for $ctime to click over which can be up to a second. But the speed optimisations might be useful for the whole of the rest of my script which processes practically every message as an event - and if it takes too long it can be overwhelmed by the quantity of messages in one or several busy channels.

How much benefit is there from !command and $~identifier and use of a hash table rather than variable lookup and using several inline calculations rather than one $calc? Is this something I should be doing throughout my script?

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Originally Posted By: Protopia
I don't find the $ctimems bug you report.
In your ctimems alias, you make use of the value stored in %ctimems.ctime but its only updated when the variable is first created: $left($calc(%ctimems.ctime + (($ticks - %ctimems.ticks) / 1000) + .0001),-1)



Originally Posted By: Protopia
How much benefit is there from !command and $~identifier
For a single call its VERY MINOR; as in pico-seconds faster. Across multiple calls it can trim off milliseconds or even, depending on the script, seconds to minutes in the case of long-running loops.



Originally Posted By: Protopia
and use of a hash table rather than variable lookup
This is dependent on the mIRC environment. The more variables in use the slower referencing variables becomes. By creating a hashtable with only related variables, non-related data doesn't have to be skipped over before getting to the desired value. This is a small time save(if any at all if there's no variables) but can be impactful on heavy-processing scripts if there's alot of variables in play.



Originally Posted By: Protopia
using several inline calculations rather than one $calc?
Given the context, $calc is very slow. It has to parse brackets, process the identifiers & variables fed into it, etc etc. That parsing takes a fair bit of time. Inline arithmetic is much faster but very limited: can only be done in variable-setting statements, only one math operation can be done, neither side of the operator can contain spaces.



Originally Posted By: Protopia
Is this something I should be doing throughout my script?
The short answer is no. The methodologies used above are to push processing time as low as possible; many of which come from scripting speed-challenges from back in the day. Instead I recommend coding the way that makes sense to you with the following guidelines:
  • Always use ()'s around conditions and {}'s around code-blocks for if-then-else statements, while statements, events, and alias declarations. There's some wonkiness with condition resolution that the brackets fix. Also makes your code far more readable
  • Spaces after commas. If you are passing parameters into an identifier, use a space after the comma to separate the parameters. It doesn't affect the code in any way but does make the code alot clearer.
  • Don't use pipes(|) to separate commands unless forced; instead use a new line. Again, makes your code quite a bit easier to read

Last edited by FroggieDaFrog; 01/09/17 11:46 AM.

I am SReject
My Stuff
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: FroggieDaFrog
Originally Posted By: Protopia
I don't find the $ctimems bug you report.
In your ctimems alias, you make use of the value stored in %ctimems.ctime but its only updated when the variable is first created: $left($calc(%ctimems.ctime + (($ticks - %ctimems.ticks) / 1000) + .0001),-1)

No - because $ticks-%ctimems.ticks makes up the difference.

Originally Posted By: FroggieDaFrog
Originally Posted By: Protopia
How much benefit is there from !command and $~identifier
For a single call its VERY MINOR; as in pico-seconds faster. Across multiple calls it can trim off milliseconds or even, depending on the script, seconds to minutes in the case of long-running loops.

I would hope that mIRC keep a record of what aliases are defined and where so it doesn't have to scan every script every time it needs to scan for a script alias. But if it does, that could be a significant amount of time, especially with large and complex scripts..

Originally Posted By: FroggieDaFrog
Originally Posted By: Protopia
and use of a hash table rather than variable lookup
This is dependent on the mIRC environment. The more variables in use the slower referencing variables becomes. By creating a hashtable with only related variables, non-related data doesn't have to be skipped over before getting to the desired value. This is a small time save(if any at all if there's no variables) but can be impactful on heavy-processing scripts if there's a lot of variables in play.

Worth doing then.

Originally Posted By: FroggieDaFrog
Originally Posted By: Protopia
using several inline calculations rather than one $calc?
Given the context, $calc is very slow. It has to parse brackets, process the identifiers & variables fed into it, etc etc. That parsing takes a fair bit of time. Inline arithmetic is much faster but very limited: can only be done in variable-setting statements, only one math operation can be done, neither side of the operator can contain spaces.

So for a very big $calc, it would be quite unreadable if split into multiple inline %x %y + %z lines. But for simple calc's (esp. those embedded in a string, it could be quite beneficial without losing readability.

Originally Posted By: FroggieDaFrog
Originally Posted By: Protopia
Is this something I should be doing throughout my script?
The short answer is no. The methodologies used above are to push processing time as low as possible; many of which come from scripting speed-challenges from back in the day. Instead I recommend coding the way that makes sense to you with the following guidelines:
  • Always use ()'s around conditions and {}'s around code-blocks for if-then-else statements, while statements, events, and alias declarations. There's some wonkiness with condition resolution that the brackets fix. Also makes your code far more readable
  • Spaces after commas. If you are passing parameters into an identifier, use a space after the comma to separate the parameters. It doesn't affect the code in any way but does make the code alot clearer.
  • Don't use pipes(|) to separate commands unless forced; instead use a new line. Again, makes your code quite a bit easier to read

I already follow most of these because I value readability. I did find a gotcha with missing brackets, so my code now has brackets everywhere. I don't currently use spaces after commas, but I will start doing this.

P.S. $ticks appear to increment in 15-16ms steps. So the first tick after ctime clicks over will be on average 8ms pas the second. Adjusting the $tick by 8 will stop you getting ms = 000 with ctime not clicked over.I will post revised code here a bit later for people to look at.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
The math operation trick with /var is extremely useful and much much faster than $calc, $calc is terribly slow, if you want to speed up processing you should do that as it matters.

Prefixing command with ! and identifier with $~ has not proven to be speed up anything processing for me (tested with an A* algorithm which is quite heavy). You also don't need to prefix keyword command such as /if /elseif /else /while /break /continue /return /var as you can't override them with an alias (unsure if /goto is overridable)

Edit: maroon pointed out /return is overridable.

Last edited by Wims; 01/09/17 07:34 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
A few more optimisation techniques I have used:

Use token functions to do string functions. For example, to get the extension of a file name use
Code:
$gettok(%fn,-1,$asc(.))


Try to search token lists or hash tables or custom listbox lines using wild matches like $wildtok or $fline or regex for more complex searches.

The key here is that the fewer script instructions you run to achieve your functionality the faster it runs. When you use token functions or wild-matches or regex or hash table searches to achieve your functionality you use fewer but more powerful instructions which run in compiled mIRC code rather than achieving it through many more mIRC script lines being interpreted, so it should be substantial faster.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Just ask Khaled to add support for a $ctimems or $ctimex identifier with millisecond resolution. He's already working with 100-nanosecond resolution coming back from the Windows API for SystemTimeInfo/LocalTimeInfo clock polling. It would be trivial to make this available to mSL.

You might even convince him to add milliseconds to $asctime(), and auto-detect the presence of 'ms' to treat the input ctime as millisecond ctimex.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Fixed bugs:
Code:
alias ctimeex {
  if (!$~isid || !$~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) {
    if (!$hget(misc)) hmake misc 1
    !var %c $~ctime + 1
    while ($~ctime < %c) { !noop }
    !hadd misc milliseconds.ticks $~ticks
    if (!$~isid) !return
  }
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~+($~ctime,.,$~base(%m,10,10,3))
}
alias timestampex {
  if ($~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) ctimeex
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~replacexcs($~asctime($~ctime,$~timestampfmt),xxx,$~base(%m,10,10,3),x,%m)
}
on *:LOAD:ctimeex
on *:START:ctimeex


I'll mention again; ticks is not really viable if your want is accuracy. There's quite a bit of overhead that costs precious milliseconds using this methodology. Between the scripted calculations and mIRC's internal lookups ticks can be off by upto 100ms in some cases.


I am SReject
My Stuff
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Here is an illustration of the incorrect result that can be produced by such code:

Code:
//window -h @timestamp | var %a $asctime($calc($ctime + 60),nn) | .timer -ho $asctime(HH) $+ : $+ %a 1 0 .timera -ho 1000 0 aline @timestamp $!!timestampex $!(|) if ($timer(a).reps == 0) $!({) savebuf @timestamp timestamp.txt $!(|) window -c @timestamp $!(})
Note that in this case I made the alias timestampex returning $timestamp $+ : $+ %ms for the sake of that test (my $timestampfmt is [HH:nn:ss]). This code creates a timer executing on the top of the next minute (if my timestamp is 22:50:18, it executes at 22:51) and then create a high-res timer which will execute 1000 times as fast as possible, echoing the value of $timestampex, here are the result: https://pastebin.com/MH7Vq1Nq and line 128 you can read:
Quote:
[05:34:01]:990
[05:34:01]:6
[05:34:02]:21



#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
That feature has been already suggested - ignored.

https://forums.mirc.com/ubbthreads.php/ub...ds_i#Post257052


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
Here is an illustration of the incorrect result that can be produced by such code:

Code:
//window -h @timestamp | var %a $asctime($calc($ctime + 60),nn) | .timer -ho $asctime(HH) $+ : $+ %a 1 0 .timera -ho 1000 0 aline @timestamp $!!timestampex $!(|) if ($timer(a).reps == 0) $!({) savebuf @timestamp timestamp.txt $!(|) window -c @timestamp $!(})
Note that in this case I made the alias timestampex returning $timestamp $+ : $+ %ms for the sake of that test (my $timestampfmt is [HH:nn:ss]). This code creates a timer executing on the top of the next minute (if my timestamp is 22:50:18, it executes at 22:51) and then create a high-res timer which will execute 1000 times as fast as possible, echoing the value of $timestampex, here are the result: https://pastebin.com/MH7Vq1Nq and line 128 you can read:
Quote:
[05:34:01]:990
[05:34:01]:6
[05:34:02]:21



This is because $ticks increments in 15ms or 16ms jumps - presumably because that is the rate of the windows timer currently used. So unless there is a way of using a higher resolution timer in windows, it is less of a bug and more of a feature.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: FroggieDaFrog
I'll mention again; ticks is not really viable if your want is accuracy. There's quite a bit of overhead that costs precious milliseconds using this methodology. Between the scripted calculations and mIRC's internal lookups ticks can be off by up to 100ms in some cases.

I agree - if you want real ms accuracy, then $ticks is not good enough for several reasons:
  1. If you are trying to calculate the time between mIRC events accurately, the resolution for $ticks is only 15ms or 16ms, so the interval could be as much as 32ms out.
  2. If you are wanting accuracy against an external clock, then not only do you have the above, but you also have to account for mIRC's overhead, the accuracy of the Windows clock etc.


But if all you want is a ms timestamp which gives greater accuracy that integer seconds and shows an approximate ms time, of if you want e.g. to measure 10ths of a second, then it is quite good enough.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
It's more related to the fact that $ticks and $ctime are not related. You can calculate time passing with $ticks to an accuracy of $ticks's accuracy, and that would work fine. Here you are doing just that but you stick the result to $ctime without 'sync'.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
It's more related to the fact that $ticks and $ctime are not related. You can calculate time passing with $ticks to an accuracy of $ticks's accuracy, and that would work fine. Here you are doing just that but you stick the result to $ctime without 'sync'.

$ticks are not actually "timer ticks" - timer ticks are (on my system) every 15-16ms. $ticks is a ms timer which is updated by 15 or 16ms every time a timer tick occurs.

When you get $ctime clicking over, then the $tick value could be anywhere from 0 to 16ms old. So if you add (say) 8 to the tick value, then that will be more likely to be accurate. But more importantly, this also ensures you don't get $ctimems like:
  • 45678.985
  • 45678.000
  • 45679.016
but instead:
  • 45678.977
  • 45678.992
  • 45679.008
You can then save ($tick + 8) % 1000 as an offset and do $ctime + ((($tick - offset) % 1000) / 1000) to get the $ctimems.

Last edited by Protopia; 02/09/17 08:56 PM.
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Quote:
$ticks are not actually "timer ticks" - timer ticks are (on my system) every 15-16ms. $ticks is a ms timer which is updated by 15 or 16ms every time a timer tick occurs.
I have no idea what you are trying to say, $ticks is based on your system timer:
Originally Posted By: https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms724408(v=vs.85).aspx
The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Quote:
then that will be more likely to be accurate. But more importantly, this also ensures
So first it's more likely to be accurate, and then it ensures it will work? that's contradictory.
Getting lower chances to get a buggy display by adding 8 to $ticks does not solve the problem. Getting rid of the problem and having a timestamp correctly handling millisecond are two different things!


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
Quote:
$ticks are not actually "timer ticks" - timer ticks are (on my system) every 15-16ms. $ticks is a ms timer which is updated by 15 or 16ms every time a timer tick occurs.
I have no idea what you are trying to say, $ticks is based on your system timer:
Originally Posted By: https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms724408(v=vs.85).aspx
The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Exactly! We are saying the same thing even if my terminology was not great.
Originally Posted By: Wims
Quote:
then that will be more likely to be accurate. But more importantly, this also ensures
So first it's more likely to be accurate, and then it ensures it will work? that's contradictory.
Getting lower chances to get a buggy display by adding 8 to $ticks does not solve the problem. Getting rid of the problem and having a timestamp correctly handling millisecond are two different things!

By adding 8, the range of inaccuracy goes from 0-16 ms early to +/- 8ms. In other words it is correct to within 8ms instead of correct to within 16ms.

However, you may be right that adding 8 makes it less buggy rather than definitely not buggy. I will need to think about this when I am less tired. It may be that we need to use the following $ticks value as the offset which will be 10-16 greater.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
I was still getting drift. So in the end I switched to a different approach to my event trace log where I store $ticks at the start of an event and then show the increment as various trace entries are made during the event handling.

Events almost always take < 1s to execute so this approach is just fine for my requirement.

Joined: May 2018
Posts: 1
B
Mostly harmless
Offline
Mostly harmless
B
Joined: May 2018
Posts: 1
i couldn't get the following script to work in mIRC 7.52 . i've set the timestamp to both [hh:nn:ss.x] and [hh:nn:ss.xxx] and neither work. am i missing something?

Originally Posted By: FroggieDaFrog
Fixed bugs:
Code:
alias ctimeex {
  if (!$~isid || !$~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) {
    if (!$hget(misc)) hmake misc 1
    !var %c $~ctime + 1
    while ($~ctime < %c) { !noop }
    !hadd misc milliseconds.ticks $~ticks
    if (!$~isid) !return
  }
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~+($~ctime,.,$~base(%m,10,10,3))
}
alias timestampex {
  if ($~hget(misc,milliseconds.ticks) == $~null || $~v1 > $~ticks) ctimeex
  !var %m $~ticks - $~hget(misc,milliseconds.ticks),%m %m % 1000
  !return $~replacexcs($~asctime($~ctime,$~timestampfmt),xxx,$~base(%m,10,10,3),x,%m)
}
on *:LOAD:ctimeex
on *:START:ctimeex


Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
It depends on what you mean by "doesn't work."

If you mean setting your timestamp format to contain .x or .xxx and expecting the channel window to show milliseconds in your timestamp instead of x's, then no it doesn't, because that timestamp only recognizes parameters defined for $asctime.

But if you mean using $timestampex in a script then getting the string where your timestamp format is replaced by the milliseconds, then yes it does work.

If you want to use $timestampex without having .xxx showing in your [timestamp], you can change that last line of the alias to not reference $timestampfmt at all, and instead hard-code the string into the alias.

Code:
old:
!return $~replacexcs($~asctime($~ctime,$~timestampfmt),xxx,$~base(%m,10,10,3),x,%m)
new:
!return $~replacexcs($~asctime($~ctime,HH:nn:ss.xxx),xxx,$~base(%m,10,10,3),x,%m)


As an aside, when testing this just now, I see that in spite of the script attempting to identify the variance between where $ticks/1000 rolls-over differently than $ctime does, I've found that it doesn't completely eliminate the .nnn number rolling over from .99something to .00something without changing $ctime.

To prevent this completely, your hash table would instead need to hold a long-term constant that's a value that would be added to $ticks to obtain the number of ticks since 1/1/1970. The hashtable constant would be calculated something like:

old
!hadd misc milliseconds.ticks $~ticks
new
!hadd misc milliseconds.ticks $calc($~ctime * 1000 - $~ticks)

Then %m would be created like:

var %m $~hget(misc,milliseconds.ticks) + $ticks

You'd then use $left(%m,-3) as a parameter to $asctime in place of $ctime, and use $right(%m,3) in place of the xxx milliseconds. This would be zero-padded already, so wouldn't need to use $base to add the leading zeroes.

This would still have the same milliseconds error as before, occasionally showing the wrong ctime value, but it would never cycle milliseconds past 999 to 000 without displaying the higher ctime time string.

Page 2 of 3 1 2 3

Link Copied to Clipboard