-
Notifications
You must be signed in to change notification settings - Fork 18k
x/pkgsite: don't show un-runnable examples as runnable #9679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Did a quick run through of stdlib examples. There were some I couldn't check because #23095 seems to effect quite a few examples. Other than os/exec, the patterns I saw were: A lot of tests aren't playable due to files not existing. For the go/* packages this would be fixed by #23603. For the rest that use files, they appear to fall into two categories:
https://golang.org/pkg/crypto/x509/#example_Certificate_Verify runs locally but fails on the playground with "certificate has expired or is not yet valid", presumably because of the fake time. https://golang.org/pkg/log/syslog/#example_Dial doesn't run because syslog.Dial isn't defined on nacl I'm 99.999% sure this example deadlocking is a bug but will leave it up to the experts: https://golang.org/pkg/net/#example_Listener Similarly for https://golang.org/pkg/net/http/#example_Get replying "Get http://www.google.com/robots.txt: dial tcp: Protocol not available" Some of these examples have output and some don't. If they all did that could be used to build a static list of non-runnable examples. (But then it's not clear if they're not runnable due to programmer error or playground limitations). Given the variety and subtlety among the examples that don't run, maybe an annotation like If the examples that cannot ever be run on the playground are tagged as such, there could probably be some sort of playground trybot that makes sure examples match their output when run on the playground. |
Not that I know of. |
Cool. I'll create CL. |
Change https://golang.org/cl/122237 mentions this issue: |
Also, is it worth minimizing this issue by making more examples runnable? For example: https://golang.org/cl/122237 |
Relates to #9679 Change-Id: I68951f664d2a03812dae309c580c181869d8af21 Reviewed-on: https://go-review.googlesource.com/122237 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
Change https://golang.org/cl/145838 mentions this issue: |
Updates #9679 Change-Id: I53412cf0142364de5f76e8affc15d607bfa2ad23 Reviewed-on: https://go-review.googlesource.com/c/145838 Run-TryBot: Yury Smolsky <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]>
Change https://golang.org/cl/146118 mentions this issue: |
64 examples out of 610 in go/src/... won't run in Playground. How can we mark the examples that should not be played? EDIT: I mean that those 64 examples [when ran] return errors unrelated to their code. Basically they are broken for the user. I am sure they confuse people here and there. |
Ideally, every example should be runnable on the playground. Any that can possibly be rewritten to be runnable should be, of course. Since this is playground specific, it shouldn't be in That leaves a comment that |
Posting the results of running all the examples against the playground. Most of them are Some examples take too long, like time.Tick, but that should be okay when new version godoc will be deployed. It will show output even when the example has timed out. Feel free to make any of those examples playground-friendly.
|
This documentation example was broken: https://golang.org/pkg/image/png/#example_Decode. It did not have the "io" package imported, The package was referenced in the result type of the function. The "playExample" function did not inspect the result types of declared functions. This CL adds inspecting of parameters and result types of functions. Fixes #28492 Updates #9679 Change-Id: I6d8b11bad2db8ea8ba69039cfaa914093bdd5132 Reviewed-on: https://go-review.googlesource.com/c/146118 Run-TryBot: Yury Smolsky <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Robert Griesemer <[email protected]>
The example for exec.Command won't run in the playground sandbox because it depends on 'tr'.
http://golang.org/pkg/os/exec/#Command
There are other such examples. We should probably detect (somehow) that they won't run, and not display them as runnable examples on golang.org.
The text was updated successfully, but these errors were encountered: