Hi DM,
A couple of JS functions I noticed were added in Synchronet 3.19 are setTimeout() and setInterval(). If I understand it correctly, it sounds like these functions are meant to call a callback function after a specified period of time (with setInterval() doing so repeatedly)?
I'm currently running a Synchronet build from February 2, 2022. I tried making a simple test script to use those functions and see what happens, but it seems they aren't calling the callback functions I'm giving them. I'm not sure if I'm using them correctly:
var intervalID = js.setInterval(function() {
console.print("Interval function!\r\n");
}, 1000);
var timeoutID = js.setTimeout(function() {
console.print("Timeout function!\r\n");
}, 1000);
for (var i = 0; i < 10; ++i)
{
console.print("Loop!\r\n");
mswait(1000);
}
js.clearInterval(intervalID);
js.clearTimeout(timeoutID);
console.print("Waiting....\r\n");
mswait(3000);
console.pause();
With that code, I see the "Loop!" output, but I don't see the output from the callbacks for setInterval() or setTimeout().
Also, the jsobjs.html page says setInterval() returns an object, but it actually seems to return a number (I outputted the type for the object I got back and it said it's a number).
Deuce added those methods, I think for the ircd.js? So you'll probably need to reach out to him for some assistance. I haven't tried using those methods myself yet.
A couple of JS functions I noticed were added in Synchronet 3.19 are setTimeout() and setInterval(). If I understand it correctly, it sounds
With that code, I see the "Loop!" output, but I don't see the output from the callbacks for setInterval() or setTimeout().
Also, the jsobjs.html page says setInterval() returns an object, but it actually seems to return a number (I outputted the type for the object I got back and it said it's a number).
With that code, I see the "Loop!" output, but I don't see the output
from
the callbacks for setInterval() or setTimeout().
If you add this:
js.do_callbacks = true;
your script won't terminate after it finishes its initial run. It enters a state analagous to the node.js event loop. Timeouts, intervals, and other callbacks will be fired as specified.
(You could probably put that line anywhere, but I put it at the bottom just as a matter of form.)
The "initial run" thing is important. None of your callbacks will be fired until the script has finished. This means that you should drop the 'for' loop and everything after it from your example script. They only serve to delay the script from finishing its run (and worse, clear the interval and timeout before they have a chance to be fired).
As you can probably imagine, you need to plan ahead and write your script according to a certain pattern if you plan to use this feature. At the moment, it's best used under jsexec or the services thread; I don't think there's adequate support for it in the terminal server context.
Hmm.. I'm wondering if setInterval() and setTimeout() can be used as I expected. I was thinking I could use those to have a function be called while my script is doing other things. Say, for example, in SlyEdit, if I wanted it to udpate the time in the corner of the screen at a regular interval, I was thinking I could use setInterval() to have it run a function to do that at a regular interval (while the user is still editing a message). But with the behavior you describe, I'm not sure if that would be possible?
setInterval() to have it run a function to do that at a regular
interval (while the user is still editing a message). But with the
behavior you describe, I'm not sure if that would be possible?
I don't think it's possible yet.
You're probably taking input from the user via console.getkey inside of a loop. You may be doing this in a single main loop, or in several places. Any such loop will block the script and prevent timers from running.
The solution would be to have your script define a bunch of functions, etc., register a callback that gets fired when the user hits a key, and then simply exit without blocking / looping. At this point everything flows from your timers and input handler. Now your timers are free to run, and won't be blocked except maybe briefly by your input callback. Unless SlyEdit was designed in a very modular way, this probably means a huge refactoring.
I'm using SlyEdit right now, and I noticed that if I pause for a minute, the clock doesn't update until I hit a key. So I imagine you're using console.getkey.
Here's an easier solution to updating the clock on a
schedule:
load('event-timer.js');
const t = new Timer();
function updateClock() {
// do stuff here
}
function getKey() {
var k;
while (!k && !js.terminated) {
t.cycle();
k = console.inkey(K_NONE, 25);
}
return k;
}
t.addEvent(1000, true, updateClock);
Obviously simplistic, but the idea would be to use the custom getKey function as a drop-in replacement for console.getkey. Now you've got a timer that will be allowed to run while you wait for user input.
const t = new Timer();
| Sysop: | Nitro |
|---|---|
| Location: | Portland, OR |
| Users: | 3 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 09:48:57 |
| Calls: | 136 |
| Files: | 751 |
| Messages: | 89,479 |