EOS Feature Request/Bug: Regular Expression support

[fapnip]

Regular expressions seem to be broken in EOS's JS interpreter. Any chance of getting them supported?

Code: Select all

var test = 'this is a text';
console.log('test1', test); // this works
var test2 = test.replace(/text/, 'test'); // this apparently doesn't work, but doesn't log an error on the console.  test2 is never set.
console.log('test2', test2); // this does not execute.  Do we never return from the interpreter's async (mode 2) regexp?

Same problem for string.match, .split, .search, etc.

Regular expressions are kinda a big deal in JavaScript. There are a number of things that are much more difficult to do without them.

[fapnip]

Looks like EOS is setting regexp mode 2 (or maybe mode 0, though it seems to be set to default) from here:
https://neil.fraser.name/software/JS-In ... egexp.html

If currently mode 0, could we try mode 2?

If currently mode 2, can that be switched to mode 1? The only real risk here is that a badly written regexp could "crash" the js runtime. There's no real security risk to mode 1. You could create a similar problem with something like while(true){}. (Though a misbehaving regexp could freeze the js runtime running the interpreter, not just the interpreted script. But still no security risk.)

[fapnip]

@seraph0x: Is there any chance for functional regexp in EOS?

I have a few things I want to try that'll basically require them. It would be nice to know if I just need to permanently shelve these ideas and move on.

[fapnip]

After more experimentation, it looks like the interpreter is indeed using mode 2 (asynchronous), and order of execution is lost when a regexp is used.

While impractical to use, the following does work:

On start page:
1. eval action:

Code: Select all

var regexpResult = ('this is a text').replace(/text/, 'test'); // This will only happen after a timer action has started. We effectively cede control to the next action at this point.
console.log('Regexp complete'); // Regexp is now done

2. Page timer action for any amount of time. This is needed to allow the regexp to run asynchronously
3. Say: <eval>regexpResult</eval> // If we do this before the timer, it will fail.

This will say "This is a test".

Execution of the start pages's eval effectively pauses at the regexp operation until the timer starts. Once the timer starts, the asynchronous regexp operation completes, and the rest of the code in the eval is allowed to continue (the console log in this case.)

So, the easiest fix for this is for EOS to set REGEXP_MODE = 1. The only real issue that could happen here is that a badly written regexp could freeze up the JS runtime in an infinite loop.

[undeniable_denial]

I endorse this request.

Eval-actions getting interrupted at every RegExp makes them almost unusable. I think mode 2 can be fine, but EOS needs to finish the web workers and the rest of the eval-action before continuing with the next action.

[RemiHiyama]

Seems like the behavior might be different in different browsers.

I have a project I'd been working on that involved multiple say actions in a row (well, and each was inside an if action, but that shouldn't make a difference), each of which displays text that's been fed through a javascript function that replaces a number of tokens with different values.

Code: Select all

function procline(line) {
	var temp = line;
	console.log("Procline: " + line)
	(A bunch of replace functions go here...)
	console.log("Procline 2: " + temp)
	return temp;
}

In Chrome, the first log message appears when it seems like it should, but the second only appears after clicking on the say -after- that one.

In Firefox, the second log message -never- appears, or at least it hasn't so far before something causes the tease to lock, which was not a problem the last time I worked on this.

And Edge throws a SecurityError, after which no text displays at all. (Unlike the others, which display junk.)

Removing the log lines changes the behavior somewhat... but it's never really correct.

I'm pretty sure this was not how things behaved before.

I tried changing things so the text was assigned to a variable in an eval tag, followed by a timer, and then had it displayed, but this only seemed to work when the text wouldn't actually change, even with a fairly long timer. (And they shouldn't really take a noticeable amount of time to complete to begin with.)

[fapnip]

Unfortunately, we're at the mercy of seraph0x's willingness to set REGEXP_MODE = 1.

Because of the way EOS uses the JS interpreter, mode 2 just isn't a workable solution.

[seraph0x]

Ask and you shall receive - I've enabled REGEXP_MODE=1. Because each tease is running in its own tab, I'm not too concerned with teases locking up.

This update to Eos did include some other changes, too. Hopefully I didn't break anything - didn't have very much time to test.

[Shattered]

Ask and you shall receive - I've enabled REGEXP_MODE=1. Because each tease is running in its own tab, I'm not too concerned with teases locking up.

This update to Eos did include some other changes, too. Hopefully I didn't break anything - didn't have very much time to test.

I fear you may have broke...literally everything, my latest tease is now unplayable and variable inputs don't seem to work at all

The 3 places I've tested in my tease the 'prompt' command doesn't proceed to anything once you type something in. It did before.

[seraph0x]

I fear you may have broke...literally everything, my latest tease is now unplayable and variable inputs don't seem to work at all

The 3 places I've tested in my tease the 'prompt' command doesn't proceed to anything once you type something in. It did before.

The prompt bug is fixed now, so please test again and let me know if there are any other issues.

[fapnip]

Ask and you shall receive - I've enabled REGEXP_MODE=1. Because each tease is running in its own tab, I'm not too concerned with teases locking up.

This update to Eos did include some other changes, too. Hopefully I didn't break anything - didn't have very much time to test.

Thank you!