Go playground short URL retention?

1,063 views
Skip to first unread message

Matt Harden

unread,
Jun 1, 2014, 9:22:48 PM6/1/14
to golang-nuts
The playground service at play.golang.org is a wonderful tool for discussion of Go code, giving as it does a shared environment in which to easily run simple programs. As a result though, much of the conversation on this group refers to code sitting behind a short URL that points to the playground. That means an archive of the group doesn't include much of the Go code being discussed. I did do a test with a very early short URL from this group and it does still resolve. But can we rely on that forever? Do we as a community have a plan to keep an archive of all that code? I would hate to see some of the history of Go lost to posterity because the playground goes away or is replaced by something better, or the database of short URLs is pruned back some time in the future.

Am I worrying for nothing?

Thanks,
Matt

Brad Fitzpatrick

unread,
Jun 1, 2014, 9:41:31 PM6/1/14
to Matt Harden, golang-nuts
We have no plans to delete them. They're tiny, too, so there's no motivation.

Perhaps for peace of mind we could offer downloads of all code snippets there where the link appeared on a golang-{dev,nuts} mailing list.




--
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.
For more options, visit https://groups.google.com/d/optout.

Matt Harden

unread,
Jun 1, 2014, 9:53:51 PM6/1/14
to Brad Fitzpatrick, golang-nuts
Even without motivation to delete, things become stale over time. I'm thinking decades from now when people want to study the early history of the then legendary language known as Go. The mailing list seems likely to be archived over the long term. I'm not so sure about the playground.

Wouldn't it be neat if the ML repeater automatically included the code from any playground links as attachments?

Brad Fitzpatrick

unread,
Jun 1, 2014, 9:58:12 PM6/1/14
to Matt Harden, golang-nuts
That seems like it would be more distractingly annoying than neat.

Andrew Gerrand

unread,
Jun 1, 2014, 11:27:30 PM6/1/14
to Matt Harden, golang-nuts

On 2 June 2014 11:22, Matt Harden <matt....@gmail.com> wrote:
Am I worrying for nothing?

It's my concern, too. But I'm the person who operates play.golang.org. I intend for the links to last forever.

Andrew

Rui Ueyama

unread,
Jun 2, 2014, 1:09:35 AM6/2/14
to Matt Harden, Brad Fitzpatrick, golang-nuts
On Sun, Jun 1, 2014 at 6:53 PM, Matt Harden <matt....@gmail.com> wrote:
Even without motivation to delete, things become stale over time. I'm thinking decades from now when people want to study the early history of the then legendary language known as Go. The mailing list seems likely to be archived over the long term. I'm not so sure about the playground.

Wouldn't it be neat if the ML repeater automatically included the code from any playground links as attachments?

That'd be annoying if we do that for golang-nuts itself, but you could write a mailing list repeater that forwards mails to other mailing list created solely for backup purpose.

roger peppe

unread,
Jun 2, 2014, 6:21:48 AM6/2/14
to Andrew Gerrand, Matt Harden, golang-nuts
I've sometimes wondered if there might be some interesting stats
that could be extracted from the play.golang.org "corpus".
e.g. what's the size distribution of snippets? what percentage
are valid Go? Are there some interesting similarity groupings?

Marvin Renich

unread,
Jun 2, 2014, 12:33:20 PM6/2/14
to golang-nuts
(Please do not CC me; I am subscribed.)

* Matt Harden <matt....@gmail.com> [140601 21:54]:
> Even without motivation to delete, things become stale over time. I'm
> thinking decades from now when people want to study the early history of
> the then legendary language known as Go. The mailing list seems likely to
> be archived over the long term. I'm not so sure about the playground.
>
> Wouldn't it be neat if the ML repeater automatically included the code from
> any playground links as attachments?

Long term retention was initially a secondary concern of mine, but this
concern was assuaged by previous assertions that the links would be
retained indefinitely.

My primary concern, however, is one of efficiency. golang-nuts is a
high-volume mailing list, and being able to quickly recognize which
threads are of interest to me is much more important than the longevity
of the playground links. Needing to click a link and switch to a
different app to determine if a small snippet of go code is interesting
is a huge distraction.

The best of both worlds would be to have each play.golang.org link
include approx. 5 to 20 lines of the most relevant part of the code, but
this requires the human who creates the link to select the relevant
part. If the "share" link included up to 20 lines of the selection if
anything was selected (with "..." or some other marker to indicate
missing top and/or bottom parts of code), the entire code if nothing was
selected but the code was less than 20 lines, and no code otherwise, I
believe reading through the list would be much more convenient. The
code should be indented with a small number of spaces (e.g. 2).

As an example, http://play.golang.org/p/duRF5gXJEP

package main

import "fmt"

func main() {
fmt.Println("Hello, playground")
}

would look like that, but a longer snippet,
http://play.golang.org/p/kMhHvbl4SG

...
conn, err := net.Dial("unix", os.Getenv("SSH_AUTH_SOCK"))
if err != nil {
log.Fatal(err)
}
defer conn.Close()
ag := agent.NewClient(conn)
auths := []ssh.AuthMethod{ssh.PublicKeysCallback(ag.Signers)}

config := &ssh.ClientConfig{
User: username,
Auth: auths,
}
client, err := ssh.Dial("tcp", server, config)
if err != nil {
log.Fatalln("Failed to dial:", err)
}
...

might look like the above; note that the same amount of indentation is
removed from all lines, so relative indentation is preserved, but the
snippet is not shifted way to the right just because the selection
happens to be several levels of indentation deep.

I would also be in favor of replacing tabs with a fixed number of spaces
(four is my preference) to help prevent right-creep, but that is just an
implementation detail. (For clarification, just in the snippet copied
with the link, not in the playground.)

For comparison, the link http://play.golang.org/p/duRF5gXJEP and the
longer snippet http://play.golang.org/p/kMhHvbl4SG convey _much_ less
information in the message. To see what these are, you must click the
links and change your mental focus to a different app (which in my
workflow is in a different "workspace", for some definition of
workspace).

The playground link allows readers to easily run the code, modify it,
and run it again. Having a small, relevant part of the code in the
message helps with continuity and efficiency when trying to read quickly
through a high-volume mailing list when only a subset of the messages
are of interest to a given reader.

...Marvin

Nate Finch

unread,
Jun 2, 2014, 2:25:01 PM6/2/14
to golan...@googlegroups.com, mr...@renich.org
Write a browser extension that automatically gets the code and inlines it, or shows it in a popup.   It probably wouldn't be that hard.  Though, since you mention switching apps, maybe you're using a desktop/mobile mail reader which would make that more difficult.

rogerjd

unread,
Jun 2, 2014, 2:48:28 PM6/2/14
to golan...@googlegroups.com, matt....@gmail.com
Great!
We can use it as reference, and rely on it being there in the future.

BTW, Is there a way to search based on code in the editor (ie: func name, var name or comment)?
In case, I coded some work and the link was lost or not saved? (and later would like to find it).
(Use browser history, maybe?)

Thanks,
Roger

Marvin Renich

unread,
Jun 2, 2014, 2:56:52 PM6/2/14
to golan...@googlegroups.com
* Nate Finch <nate....@gmail.com> [140602 14:25]:
> Write a browser extension that automatically gets the code and inlines it,
> or shows it in a popup. It probably wouldn't be that hard. Though, since
> you mention switching apps, maybe you're using a desktop/mobile mail reader
> which would make that more difficult.

I do not understand this. I do not read mail in a browser, I use a
text-only email client (mutt). I hate popups, and most of the uses on
major web sites I find to be obnoxious. Even if I weren't opposed to
them, they would slow down sifting through the large volume of mail in
this list, rather than speed it up, which is the whole point of my
suggestion.

...Marvin

Nate Finch

unread,
Jun 2, 2014, 4:45:06 PM6/2/14
to golan...@googlegroups.com
My apologies, I mainly access the group through the Web UI at https://groups.google.com/forum/#!topic/golang-nuts/  Sometimes I forget that many people primarily access the group through its mailing list features (I do both, though I prefer the web UI).

Also, I'd note that I cannot uncheck the "cc original author" checkbox in the web UI, and therefore cannot avoid CC'ing you.  My apologies again.

Dominik Honnef

unread,
Jun 3, 2014, 2:57:41 AM6/3/14
to golan...@googlegroups.com
Write a mutt display filter that fetches and inlines the contents of
playground links.

Or select which threads to care about like many people: boring/useless
subject? body without substance/information? skip.

--
Dominik Honnef
Reply all
Reply to author
Forward
0 new messages