{
    "format": Number,
    "language": String,
    "interpreter": Any,
    "code": String,
    "input": String,
    "options": _, // flags/args
    "misc": { ... } // settings
}

{
"format": Number,
"language": String,
"interpreter": Any,
"code": String,
"input": String,
"options": _,
"misc": { ... }
}

The _ is unnecessary but I just want to make sure we're on the same page for the nested ones!

Do we need anything else?

Settings will be needed for some languages

Re: format, will we ever be changing the key names?

We might at some point, better to have a way to indicate that

Def better safe than sorry!

Maybe there should be a `"version"` as well?

Ooh, separate? Sure. The more the merrier

Langs that don't use them will ignore them anyway

It could just go under `"settings"` I guess

Good idea. On the one hand I don't want to overclutter it, on the other hand, making them remember who the parent is might be annoying re:

having version within settings or having everything be separate

In other words, there are pros/cons to having everything be separate, and grouping ?

Maybe there should be a `"language"` key, that has the language ID and version?

Oh? version goes there?
I meant to have that, yeah!

We could move it, I guess. I do like it going under language, though

Maybe instead of `"name"` it should be `"id"`

hmmm, idk, where would the id come from?

an ids.json?

An ID could be specified with each language, since language names might have punctuation that is difficult to deal with

Example: ??? or ///

<><

Wow, you're good at this! Yeah, you're right

I wouldn't worry too much, I don't think, on starting with a premature json either. Should be pretty easy to refactor at this point

Another thing to consider: Different interpreters. For example, CPython vs PyPy. Maybe another field under `"language"`?

Good point

Are we having "name" in addition to "id" under language
Or "name" instead?

I don't think having the client specify the name is necessary if the ID is already there
w
Actually, I say interpreter & version under "settings"

haha, did i getcha?

Maybe the interpreter and version can be merged

or were you going to say merged elsewhere?

> I'm thinking maybe since different languages have different ways of having different interpreters, it could be an `"interpreter"` object? I can think of some things that might require being able to have multiple different settings there. Like if you have packages, for example.

Mind copy/pasting into chat?

Which part? Just everything after the >?

Yeah, just that!

My proposed response format:

{
    "format": Number,
    "finished": Boolean,
    "data": Data[]
}

// Data:

{
    "id": String,
    "data": DataFormat OR DataFormat[],
    "collapse": Number
}

// ???

// DataFormat:

{
    "id": String,
    "data": String,
    "formatting": String
}

Example:

{
    "format": 1,
    "finished": true,
    "data": [
        {
            "id": "out",
            "data": [
                {
                    "data": "[10, 11, 12]\n\n",
                    "formatting": "normal"
                },
                {
                    "data": "ReferenceError: x is not defined",
                    "formatting": "red"
                }
            ]
        }
    ]
}

Example with `STDOUT`/`STDERR` (just the `data`):

[
    {
        "id": "stdout",
        "data": {
            "data": "[10, 11, 12]",
            "formatting": "normal"
        }
    },
    {
        "id": "stderr",
        "data": {
            "data": "ReferenceError: x is not defined",
            "formatting": "normal"
        }
    }
]

{
    "format": 0,
    "stdout": String,
    "stderr": String,
    "misc": { ... }
}

**Improvement proposal:**

Instead of having `

JSON.data` as an array of `Data[]`, we can use an object with `{id: Data}` pairs. That's similar to what we did with `inputJSON.misc`, and gets rid of some ugly syntax.

That would mean my cluttered `stdout`/`stderr` example would instead look like:

["1", "2", "Fizz"]
["4", "B"]

{
    "format": 0,
    "data": {
        "stdout": ["abc", "def", {}, ],
        "stderr": ["SyntaxError"]
    }
}

{
    "stdout": {
        "data": "[10, 11, 12]",
        "formatting": "normal"
    },
    "stderr": {
        "data": {
            "data": "ReferenceError: x is not defined",
            "formatting": "normal"
        }
    }
}

stdout: hi
stderr: bye
formatting: (normal, red)


   {
      stdout:
      stderr: 
   }

---

Thanks Red!

Wait, but please still do yours!
Just wanted to note my thoughts before I take a quick break to watch Joshie (brother), lol my typing is getting so slow

No problem :p

And mine before I go for ~10 mins:

{
    // imperative
    "format":_,
    "stdout":_,
    "stderr":_,
    "misc": { ... },

    // ideas
    "state":_,
    "debug":_,
    
    // some other stuff for repl-based things
    // for now we'll do
    "repl": { ... }
}

---

I'm over here! At the bottom. Can you see me?

Yep!

Wahooo :))

So, I was thinking maybe we could use Go for the `start` script. And I was also thinking we could make a single multi-purpose start script, and pass in instructions about what to run based on the requested language

So like, we'd have a JSON object that looks something like this:

{
"run": "python3 code.py",
"outputJSON": {...}
}

Can you remind me also, precisely, what exactly the start script does, please?

Yeah. It takes the `outputJSON` from the client, and runs the interpreter within the container/sandbox. So like, for Python, it'd take the code and input and run something like `python3 code.py < input`

Got it, thanks! I just have to refresh on the outputJSON for a quick sec.

Me too, actually

Damn. It's amazing how much you can forget.

I'm wondering if I should start trying to add some of the basic feature we'll need for repl support, or at least places in the library where support for repls can be easily added

---
Okay, in here!

I'm here!

Hi hi!!

So, I can't remember a single thing, you start!

## Template Features? Start File stuff

- Interpreted: `[interpreter] code < input`
- Compiled: `[compiler] code && ./compiled < input`

We'd likely need ways for the language adder to specify what commands are needed to do those steps and what format they follow. E.g., `gcc -o compiled code.c`

A few examples would be enough though, right?

Oh wait, I was thinking of the templates being pre-compiled so you'd essentially just drop them into a folder with the interpreter

It's a lot easier for us if we require them to compile themselves after adding the correct command format

It gets compiled? I thought it ran like:
`node start.js`

Oh, right!

Go also has an interpreted thing for what it's worth.

`go run main.go`

Same disadvantages as node though; you need the whole Go interpreter

Oh, I see. You want an executable.

Right, that aside, I was still thinking we'd just provide example files, and they would compile it on their own so like:

start.go

1 ...
2 ...

23 python3 code < input

99 ...

So this would be our template. And then they'd go in and change line 23 to `node code < input`, and build that.

So we wouldn't have to worry about all the parameters and stuff they might want to change. We'd just give them several examples.

I'd rather not make them download Go though...maybe some sort of config could be passed to a single Go script?

Does Python come installed in the containers?

No, but it's not as big

Okay, just a second. We're thinking about these templates totally differently.

I thought they were gonna want to do loads of customizations, for some reason. So in my mind, these templates were *examples* for them to work off, and put together different elements from different examples that they wanted.

But that all depends on how many things they

No no, no need!

It just depends on how much customizing stuff we come up with. I think there's way less than I thought, in which case we can totally do a config file, and we'll do the heavy lifting for them that way.

What I was thinking was just nice if there were like a million and one different things they could do with the start file.

Haha, true! I sense an esolang...

I think that'd be great then honestly. If we're gonna make examples, we should probably make most of them in Python.

You mean in terms of languages, right?

Yeah

Yeah, for sure. There's no limit on how many langs we can give them!

But in terms of what I want to prioritize, I want to work on the base starts for "power-users" like us. The config and pre-compiled stuff will be easier to do later.

So when I put templates, really what I meant are what are some neat examples/features we want to demo in a start file, that I can get cracking on after I have the basic one translated!

## Examples

- Additional debug info (timing, cpu usage, etc.)
- Library usage (numpy)
- Possibly, but not sure if that goes in `start` necessarily
- That's fine for now. If it *could* go in start, I'll add it to start
- Different cell/tape sizes for brainfuck (probably just command line options to a Python or JS based interpreter that can handle that)
- Coloring STDERR red

True, okay so far, simplified, we have:
- change outputJSON
- add other files/libraries
- change inputJSON

Honestly there's not much "creativity" possible/necessary in the start files tbh. They should really just do one job, and do it well.

I was thinking in terms of colors, other odd stuff, or like what I'm doing

What I'm doing would send back visual information
I thought there might be toher things like that we could give them to toy with

That's true

Will you be online tomorrow?

Actually...why not have a couple dozen base `start`s? We could start with just Python and Go, and work our way up over time. That way people can choose between writing their own off of our template, or using a precompiled one with a config

Python appears to be 40 MB or so. A bare alpine install is 6 MB, so it's not tiny, but not that bad either. 40 MB _definitely_ won't make a speed difference, or use up an amount of disk space worth even thinking about.

Nothing stops them from writing their own start file, ours would just be one option. In theory, they could even design a language that just happens to take I/O with `inputJSON` and `outputJSON` and they wouldn't need a `start` at all

I see what you mean, yeah. Maybe we could do both?

True, which is why I thought we'd have start.py, and others. But I didn't realize we'd want the compiled bit.

I wonder how much of this could be done with sh...

Oh, I'm thinking of Go

Node's pretty big, so it won't be packaged with most of our base languages

Idea: The Go script calls a shell script, maybe?

---

---
---
---
# Final Stuff

## Input

// Input
{
    "format": Number,
    "language": String,
    "interpreter": Any,
    "code": String,
    "input": String,
    "options": _, // flags/args
    "misc": { ... } // settings
}

## Output

// Output
{
    "format": Number,
    "finished": Boolean,
    "data": Data[]
}

// Data
{
    "id": String,
    "data": DataFormat OR DataFormat[],
    "collapse": Number
}

// DataFormat
{
    "id": String,
    "data": String,
    "formatting": String
}

## Todo

* `outputJSON` validation (confirm_output in json_parser.js)
* repl
* Python image
* write steps for making it
* Background pre-loaded containers for common langs
* make it really easy to add your own esolang
* function vs stdin/stdout
* if interpreter/compiler is written in language we already host-- make that even easier
* make it easy to add an existing language
* write a bash script so you download the thingy, run the script and you're good to go
* add command to pre-load container for a language
* priveleged users (maybe cgcc with rep > n)
* general interactive stuff

## Progress

`ws.js` has been refactored into four classes:

- `WS`: Handles WS server itself, and spawns `Conn`s for each connection
- `Conn`: Handles I/O with WS connections, pinging, and some other useful abstractions
- `Actor`: Abstracts away what `Conn` you're dealing with
- Allows for:
- Reconnecting when a WS is dropped (due to network issues)
- Adding an API in addition to WS
- Preloading containers
- `Cast`: Manages `Actor`s, pinging

## Output 2

{
    "format": 0,
    "data": {
        "a": "abc\nxyz",
        "b": ["abc\n", "xyz"],
        "c": "",
        "d": []
    }
}

## `start`

Features needed:

- Run normal code
- Run code in a language based