x/playground: support txtar input files

[bradfitz]

(Pulling out of related third-party imports bug #31944)

This is a tracking bug to support multiple input files.

We'll start with txtar format, and use txtar behind the scenes when saving shared snippets. But we might add web UI to have separate <textarea> boxes later.

[gopherbot]

Change https://golang.org/cl/177043 mentions this issue: playground: support multiple input files in txtar format

[dmitshur]

@bradfitz The current implementation of splitFiles in CL 177043 is described as:

If src isn't in txtar format, it returns a file named "prog.go".

Have you considered a behavior where the first file doesn't need to specify the -- prog.go -- header? E.g.:

package main
func main() {println(foo)}

-- prog2.go --
package main
const foo = "this is okay"

The txtar archive comment, if present, becomes prog.go content.

Or, a more important/common situation if as I understand correctly that future shared snippets (that import third-party packages?) will have a go.mod file automatically appended:

package main

func main() { [...] }

-- go.mod --
module [...]

The motivation is similar to how v1 of modules doesn't require a /v1 suffix, only v2+ does. Most snippets are just one .go file, and the second file may end up being just an automatically generated go.mod file. It seems unfortunate to require -- prog.go -- header on top of every snippet because of that.

The advantage of the current requirement of first header is that it's more visible when txtar is used or not used.

[dmitshur]

Oh, I see now that the code already does that. I missed that there's no return in the if v := bytes.TrimSpace(a.Comment); len(v) > 0 { block.

Edit: The function documentation was misleading; I'll leave a comment in code review.

[bradfitz]

It even has tests! ;)

[dmitshur]

I missed the test case because it wasn't in between the two other test cases where I expected to see it. I left a comment about that too. 😛

[gopherbot]

Change https://golang.org/cl/177421 mentions this issue: playground: format go.mod files; fix paths in formatting errors

[ianthehat]

It would be really cool if you could map the files into the sandbox so you could have data files in the set, allowing things like
https://play.golang.org/p/EbMXTpZSndB

[bradfitz]

@ianthehat, I plan to add that, but doing it with the nacl backend would involve doing some wasted work, as I'd need to do the whole zip thing that we do for tests now with misc/nacl/mkzip.go and make some syscall changes to shove it in.

I'd rather do it once we've moved the playground to linux/amd64, and then just write the files to "disk" (tmpfs) and access them directly.

[dmitshur]

Multiple input files are supported (via txtar format) by now, so I'll close this.

Adding a web UI to have separate <textarea> boxes seems to be better tracked in a new dedicated issue.

/cc @toothrot