Tutorial for local js debugging / Tip for easy readline() emulation

This information could be useful to beginner and intermediate programmers so I decided to share it with you.

Scenario:

Sometimes with more complex problems it is useful to switch from coding directly in the browser IDE to running the code locally.

One of the best reasons of doing so is arguably the ability to debug your program, which is of course not possible on server side run code.
When I say debug your code I mean not simply printing out statements and figuring out what is wrong but using breakpoints and inspecting the states on a step by step basis.

We are going to use javascript in this example for simplicity but this should be possible in any language. Some requiring more initial effort than others, depending on whether or not you get generators out of the box, but it’s of course possible however not too trivial to roll your own.

So as a first step we’ve just slapped a copypasta of our code in the browser IDE between two tags in a local file and saved it, then loaded the file in the browser.

Problem:

The first problem is the function “print”, but this is easily solved by aliasing it to console.log, as well as printErr:

const print = console.log.bind(console);
const printErr = print;

Now the real “problem” is that readline() function.
We could just replace each readline() call with hardcoded strings, which is what I’ve been doing initially.
But I got tired of this quickly and there is of course a better way:
Generators.

Explaining generator functions is out of the scope of this tutorial and there already exists enough information to be found in the webs.
In a nutshell they can halt at arbitrary points after "yield"ing a value and return that value to the caller as normal functions would, but they persist after returning that value and keep track of the internal state and context and where the execution halted so they can carry on when they are called the next time. If that sounds a bit like an iterator to you then thumbs up! Generators are iterators that iterate over values which can be generated on the fly.

Solution

Cutting to the chase, here is the required code to emulate readline (Example input from the Hidden word puzzle)

function* __readline(){
	let lines = `2
		BAC
		BOB
		3 3
		BAC
		BOB
		RED`.split(/\n\s*/)
	while(lines.length) yield lines.shift()
}
const _readline = __readline();
function readline(){
	return _readline.next().value
}

Now on the first readline call, 2 is returned, then BAC, then BOB, then 3 3, and so on until there is no line left in the array.

The nice thing about this is that now all we need to do for new tests is to update the lines variable with a new block of lines or array, which can easily be extracted for copy+paste from the browser IDE with a few lines of code and also once finished the whole thing can be used 1:1 minus the monkey patching stuff and it will work without requiring any post-editing.

Let me know if that was useful, you spot any typos or you have any other comments, cheers.

2 Likes

The real problem comes when you want to use a multiplayer javascript AI with a local arena like brutaltester (or any other local arena). You have to read from the standard input.

In NodeJS, reading the standard input is asynchronous. So you can’t expect to code a readline function easily. The console.log in NodeJS is asynchronous too.

In the end, the solution is simple. Do not use NodeJS to do that :smiley: Just use SpiderMonkey.

You can’t use readSync on stdin?

That doesn’t resolve the console.log asynchronous problem :frowning:
And last time i tried, reading stdin with a readSync does not work.

But switching to SpiderMonkey resolve everything (and you don’t have to recode print and readline). So i didn’t search for long.

For undelayed input it should definitely work with sync.

node -e 'console.log(require("fs").readFileSync("/dev/stdin", "utf8"))' <<< $'hello\nworld'

But this is a different issue. What my original post is about is much simpler, it’s just about having a comfortable way to import puzzles to run in the local browser so you can use “debugger;” and don’t have to change any code around between the server and local environment, no node or other external javascript runtime/engine needed.

Will you tell us more about setting up SpiderMonkey in the context of Bot challenges?

I got fairly excited with running the code locally until I faced issues you describe with node’s line reading approach. Unfortunately it doesn’t look as trivial to setup SpiderMonkey as it was to setup the brutal-test branch to run with Eclipse!