This is the output of current master:

nightly-20191123 [release]
compiled with: llvm 7.1.0 -- cc (Alpine 8.3.0) 8.3.0
Defaults: pic=true
Building builtin -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/builtin
Building . -> /tmp/tmp.olfgho/main
Building collections -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/collections
Building ponytest -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/ponytest
Building time -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/time
Building random -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/random
Building itertools -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/itertools
Generating
 Reachability
 Selector painting
 Data prototypes
 Data types
 Function prototypes
 Functions
 Descriptors
Writing ./main.ll

expected output: the LLVM IR from ./main.ll and no compilation logs.

It would be finest if we had (headless) browser-based integration tests, verifying the basic operations this playground offers.

Any pointer on good tools to use here are very much welcome.

As part of it, we can move the docker image builds into a pr.yml like we have in other repos.

Related to ponylang/pony-tutorial#546

This could be implemented statically into static/web.html at first, but it would make sense to prospectively make it dynamic by converting it to a template and creating the tags depending on the Query params.

• snippet file name?
• preview image of snippet, code, or gist
• extract docstrings from snippets and gists as description (could technically even be interpreted as frontmatter to support more than just the description)

I know, I'm crazy, but one should be allowed to dream every once in a while 😉

To verify that the playground (minus the frontend) is actually working, we need some integration tests to run upon every PR and merge to main:

• Running some piece of code after calling the API
• Compiling some piece of code to ASM/LLVM IR output
• OPTIONAL: sharing a gist using the github API - this one is hard to mock, actually.

For more information on how this is imagined to look like:

• https://doc.rust-lang.org/book/ch11-03-test-organization.html#integration-tests
• https://github.com/testcontainers/testcontainers-rs

• STDOUT
• STDERR
• Exit Code

Would it make sense to refactor getQueryParameters() to use URL/URLSearchParams, so we don't have to maintain custom code over native one or do you prefer not to fix something that ain't broken?

By the way, this

function optionalLocalStorageGetItem(key) {
    return localStorage.getItem(key) ?? null;
}

and so can

theme = optionalLocalStorageGetItem("theme");
set_theme(editor, themelist, theme ?? "GitHub");

as well as

var themes = themelist.themes;
themes.sort((a, b) => a.caption.localeCompare(b.caption));

Then, we have

var classes = mappings[arguments[1]];
if (classes) {
    return '<span class="' + classes + '">' + arguments[2] + '</span>';
}
return arguments[2];

The following is an interesting case:

it could either be rewritten as

if (req.status == expect) {
    if (on_success) {
        on_success(req.responseText);
    }
} else if (on_fail) {
    on_fail(req.status, req.responseText);
}

or

if (req.status == expect && on_success) {
    on_success(req.responseText);
}
if (req.status != expect && on_fail) {
    on_fail(req.status, req.responseText);
}

Next, we have a bunch of these:

asmButton.onclick = compile.bind(window, "asm", result, session.getValue(), asmButton);

irButton.onclick = compile.bind(window, "llvm-ir", result, session.getValue(), irButton);

gistButton.onclick = shareGist.bind(window, result, session.getValue(), gistButton);

clearResultButton.onclick = clear_result.bind(window, result);

themes.onkeyup = themes.onchange = set_theme.bind(window, editor, themelist, themes.options[themes.selectedIndex].text);

request.ontimeout = set_result.bind(window, result, "<p class=error>Connection timed out" +
                "<p class=error-explanation>Are you connected to the Internet?");

One could possibly also refactor editGo(), editShowRegion(), editShowLine(), and editShowPoint(), but that'd be slightly more than a simplification.

Miscellaneous

• className vs classList
• fetch vs XMLHttpRequest
• setAttribute('data-*') vs dataset
• onclick vs addEventListener()