playground behaves different from local machine

[T L]

The code from the std go/types package parses the demo code well on local machine, but not in playground:

https://play.golang.org/p/BlHHgdscaXj

What is the cause?

[T L]

> However, the playground has no GOROOT or build cache or anything available: https://play.golang.org/p/RPGwtZSJSPQ

But, isn't it ok to let the playground own a GOROOT?

On Mon, Dec 23, 2019 at 5:47 AM Axel Wagner <axel.wa...@googlemail.com> wrote:

Parsing is not the problem, type-checking is. For that, the type-information of the imported packages (in this case "fmt") must be loaded from somewhere. However, the playground has no GOROOT or build cache or anything available: https://play.golang.org/p/RPGwtZSJSPQ

There will always be programs that don't run on the playground but run locally, FWIW. That's the nature of a sandbox :)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com.

 

[Axel Wagner]

Sorry for the off-list response, that was unintentional.

I think it might be okay, but I could also think of a couple of reasons against it. AFAIK, Go programs for the playground are compiled with a patched stdlib (at least they used to be, to do the faketime-stuff. I don't know if we're already at a point where the playground needs *no* custom patches anymore). If so, the code in GOROOT might or might not be the same as the one used to compile the code, which might be confusing. There's also the general "just that there's no reason *not* to do X isn't a reason *to do* X" (i.e. the conservative approach of Go in general). But really, I can't answer what ought to be or what will be - just what is :) If you feel this is a use-case that should be supported, it might be worthwhile to file an issue (which can get an authoritative response).

And just FYI (I'm not saying it's a practical approach here), it is theoretically possible to make the program work today, using the playground's support for multiple files: https://play.golang.org/p/KLZR7NlVZNX

Though you probably also need to add some playground-specific code to set environment variables or things like that.

[T L]

Looks the multiple trick is not a theory. That is cool!

I don't know if this is an issue known for a long time.

If it is not, I would file an issue some time later.