Bug 14099 – Promote DPaste (dpaste.dzfl.pl) to run.dlang.org

DPaste (http://dpaste.dzfl.pl/) is a collaborative D pastebin, with integrated compilers and VM execution environment (it can save and run code pasted online). DPaste is already used on the D website front page (http://dlang.org/), for the "edit and run" widget. This is a proposal to make it officially a part of dlang.org: promote the website to run.dlang.org, and add a link to it on the D website (e.g. under the "Resources" submenu). The source code can be made publicly available if necessary. The backend is currently hosted on my server (same server hosting the D forum and wiki). The frontend (dpaste.dzfl.pl) is currently running somewhere else, but I've gotten a copy running at the temporary URL http://dpaste-fe.k3.1azy.net/ . nazriel, the creator of DPaste, doesn't seem to have much time to work on it lately, but has agreed to provide database dumps for the current instance. Johnathan Marler, who worked on asm.dlang.org, has volunteered to look into DPaste, and investigate whether it would be possible to merge DPaste with asm.dlang.org. @ Walter / Andrei: What do you think?

As a note, it might be worth changing the default paste lifetime to 24 hours rather than defaulting to no expiry.

(In reply to Orvid King from comment #1) > As a note, it might be worth changing the default paste lifetime to 24 hours > rather than defaulting to no expiry. Why? They take basically no space, and saving has to be done explicitly (rather than every time "Run" is clicked).

First step is to make it http://paste.dlang.org. Also it should be hosted entirely on our server.

Oh, I saw http://run.dlang.org after I replied. Not sure which is the better name, but we need to have a good name for Marin Nowak's repl.

Merging with asm doesn't sound too attractive.

(In reply to Andrei Alexandrescu from comment #3) > First step is to make it http://paste.dlang.org. Also it should be hosted > entirely on our server. That might not be easy. Can your server even host a virtual machine? (In reply to Andrei Alexandrescu from comment #4) > Oh, I saw http://run.dlang.org after I replied. Not sure which is the better > name, but we need to have a good name for Marin Nowak's repl. Is the repl going to be yet another service with an overlap in functionality? It should be all one service. (In reply to Andrei Alexandrescu from comment #5) > Merging with asm doesn't sound too attractive. Why not? Otherwise one would need to update compilers on both services for every new version.

(In reply to Vladimir Panteleev from comment #6) > (In reply to Andrei Alexandrescu from comment #3) > > First step is to make it http://paste.dlang.org. Also it should be hosted > > entirely on our server. > > That might not be easy. Can your server even host a virtual machine? Well we have to. The way I see it if a bus hits you tomorrow there's no more forum no more paste etc. We need to bring our dependencies into the organization. Please discuss with Jan Knepper. > (In reply to Andrei Alexandrescu from comment #4) > > Oh, I saw http://run.dlang.org after I replied. Not sure which is the better > > name, but we need to have a good name for Marin Nowak's repl. > > Is the repl going to be yet another service with an overlap in > functionality? It should be all one service. > > (In reply to Andrei Alexandrescu from comment #5) > > Merging with asm doesn't sound too attractive. > > Why not? Otherwise one would need to update compilers on both services for > every new version. They can share backends, but asm is forked from gcc.godbolt.org and Iain mentioned it wouldn't be great if it diverged much.

(In reply to Andrei Alexandrescu from comment #7) > Well we have to. The way I see it if a bus hits you tomorrow there's no more > forum no more paste etc. We need to bring our dependencies into the > organization. I'm all for increasing the bus factor, but is the situation with Jan much different? It would be great if we had more redundancy, but this is boring stuff that no one wants to do. If you can convince someone to talk to me, we can get the ball rolling. I can start by setting up a mirror for dlang.org. And, done! Just point dlang.org to k3.1azy.net in the event it's needed. You already have shell access to update it. > They can share backends, but asm is forked from gcc.godbolt.org and Iain > mentioned it wouldn't be great if it diverged much. Sounds reasonable, OTOH the service is pretty basic - much simpler than DPaste, which has VM execution, accounts, themes, etc.

(In reply to Andrei Alexandrescu from comment #7) > Well we have to. I don't mind this in principle, but I'm also not looking forward to moving it myself. If you can find someone to get the VM stuff and everything to run on FreeBSD, I'll happily flip the switch on the frontend. Maybe we should seriously consider compartmentalizing (e.g. using Docker) ALL our services, so they can be moved around on a whim as needed. But I'm not familiar with the technology, and Docker refuses to run on my server (yay golang).

(In reply to Vladimir Panteleev from comment #8) > (In reply to Andrei Alexandrescu from comment #7) > > Well we have to. The way I see it if a bus hits you tomorrow there's no more > > forum no more paste etc. We need to bring our dependencies into the > > organization. > > I'm all for increasing the bus factor, but is the situation with Jan much > different? Yes. > It would be great if we had more redundancy, but this is boring stuff that > no one wants to do. If you can convince someone to talk to me, we can get > the ball rolling. I'll start a thread with you and Jan to get you what you need. > I can start by setting up a mirror for dlang.org. And, done! Just point > dlang.org to k3.1azy.net in the event it's needed. You already have shell > access to update it. I don't understand what this would accomplish.

> Maybe we should seriously consider compartmentalizing (e.g. using Docker) ALL our services, so they can be moved around on a whim as needed. Yes please. It makes local testing, reproduction and migration really easy. FYI: run.dlang.io is an docker image which gets built and pushed to Dockerhub. Now if the server that runs run.dlang.io crashes one day, it's in theory as easy as "docker run" on a new server (in practice, there's Nginx config + SSL + local config, but it could be a lot worse). > This is a proposal to make it officially a part of dlang.org: promote the website to run.dlang.org, and add a link to it on the D website (e.g. under the "Resources" submenu). The source code can be made publicly available if necessary. -> https://github.com/dlang/dlang.org/pull/2312 > I'm all for increasing the bus factor, but is the situation with Jan much different? > ... > I can start by setting up a mirror for dlang.org. And, done! Just point dlang.org to k3.1azy.net in the event it's needed. You already have shell access to update it. This now got worse as there's dlang.org/blog + dlang.org/lists, because in the event of a downtime, you can simple copy/paste the snapshot from https://docarchives.dlang.io/v2.079.0

Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/b2f779912123e6cc5593d954e5619b2874652143 Fix Issue 14099 - Promote run.dlang.io to Resources https://github.com/dlang/dlang.org/commit/b7c97e4ae72fb82050116af013fca8002c17665e Merge pull request #2312 from wilzbach/fix-14099 Fix Issue 14099 - Promote run.dlang.io to Resources merged-on-behalf-of: Vladimir Panteleev <[email protected]>