Allow custom package logos & add OpenGraph #286

WebFreak001 · 2018-02-26T22:24:35Z

This is a split part of #265, just only for package logos

This commit goes slightly different on the caching name due to the comments, but still keeps all image files. This time the user specifies the revision of the icon and gets the default package if it is not found. If the user does not specify one they get the current logo. I decided to go for this approach due to archiving or embedding purposes, especially on google etc. where an old image of the repository might be wanted.

@MartinNowak @wilzbach

This is a split part of dlang#265, just only for package logos This commit goes slightly different on the caching name due to the comments, but still keeps all image files. This time the user specifies the revision of the icon and gets the default package if it is not found. If the user does not specify one they get the current logo. I decided to go for this approach due to archiving or embedding purposes, especially on google etc. where an old image of the repository might be wanted.

dlang-bot · 2018-02-26T22:24:36Z

Thanks for your pull request and interest in making D better, @WebFreak001! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

wilzbach

Left a few comments. I love the new default logo though I'm not sure it's a good idea to use it as defaut logo (in terms of branding). Maybe a greyish or slightly alternated version of it should be used as default logo, s.t. it's clear that it's not the dub logo but a default logo.

wilzbach · 2018-02-28T02:43:34Z

public/styles/common.css

+	img.packageLogo {
+		display: block;
+		float: none;
+		max-width: 100%;


Isn't this a bit too large on mobile?

made it so it isn't higher than 220px now, it can still be a wide logo but square logo will be smaller now. It does not stretch (at least not in chrome)

Shouldn't we require logos to be square and convert them otherwise? This usually makes such design things a lot easier.

hm I'm actually a fan of supporting flat logos such as banners, isn't that much more work with html and css

wilzbach · 2018-02-28T02:45:08Z

source/dubregistry/internal/utils.d

+///   file = the file to convert
+///   name = the logo name to put in uploads/logos
+///   deleteExisting = if false, throw an exception if the files already exist
+///   deleteFinish = if true, delete the input file after at least one successful conversion


FWIW DStyle would be /** ... */ and require a body + Returns:

https://dlang.org/dstyle.html

Yeah, unfortnately it wasn't possible so far to persuade Walter into fixing the semantics for this. What this will do is to create one paragraph per line instead of a single one.

wilzbach · 2018-02-28T02:46:09Z

source/dubregistry/internal/utils.d

+///   name = the logo name to put in uploads/logos
+///   deleteExisting = if false, throw an exception if the files already exist
+///   deleteFinish = if true, delete the input file after at least one successful conversion
+auto generateLogo(NativePath file, string name, bool deleteExisting = false, bool deleteFinish = true) @safe


Use std.typecons.Flag or a config struct. Otherwise this gets really hard to read on the calling site.

wilzbach · 2018-02-28T02:48:15Z

source/dubregistry/internal/utils.d

+	}
+	catch (Exception e)
+	{
+		(() @trusted => send(owner, e.toString()))();


Does https://dlang.org/phobos/std_concurrency.html#.ownerTid not work with Vibe.d?

I think it should, but the vibe.d's earlier re-implementation before the compatibility additions, didn't have that feature, so all examples are still explicitly passing the owner (opened vibe-d/vibe.d#2091).

wilzbach · 2018-02-28T02:49:16Z

source/dubregistry/internal/utils.d

+
+		string base = buildPath(logoOutputFolder, name);
+		string pngOutput = base ~ ".png";
+		auto png = spawnProcess(["convert", file.toNativeString, "-resize", "512x512>", pngOutput]);


Why the >? `
There are no ouput streams.

the > makes sure aspect ratio is kept, it's not a pipe and spawnProcess couldn't pipe anyway

wilzbach · 2018-02-28T03:11:39Z

views/view_package.dt

 	- auto title = "Package " ~ packageName ~ " version " ~ versionInfo["version"].get!string;

+	// facebook & co.
+	meta(property="og:url", content="http#{req.tls ? `s` : ``}://#{req.host}/packages/#{packageName.split(':')[0]}")


how about wrapping the host things into a functions? #{req.registryURL}

wilzbach · 2018-02-28T03:12:23Z

views/view_package.dt

+	// facebook & co.
+	meta(property="og:url", content="http#{req.tls ? `s` : ``}://#{req.host}/packages/#{packageName.split(':')[0]}")
+	meta(property="og:type", content="article")
+	meta(property="og:title", content="Package #{packageName.split(':')[0]} on DUB")


splitter and do we really have to use split here?

wilzbach · 2018-02-28T03:12:31Z

views/view_package.dt

+	//- TODO: register dub twitter account
+	meta(name="twitter:site", content="@D_Programming")
+	meta(name="twitter:url", content="http#{req.tls ? `s` : ``}://#{req.host}/packages/#{packageName.split(':')[0]}")
+	meta(name="twitter:title", content="Package #{packageName.split(':')[0]} on DUB")


splitter and do we really have to use split here?

wilzbach · 2018-02-28T03:12:49Z

views/view_package.dt

+		- auto logo = packageInfo["logo"].opt("");
+
+		- if (logo.length)
+			img.packageLogo(src=logo, alt="#{packageName.split(':')[0]} logo")


splitter and do we really have to use split here?

wilzbach · 2018-02-28T03:15:44Z

design/package-logo.svg

+       x="10.739017"
+       id="image5884"
+       xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAg0AAAIJCAIAAACp65nVAAAAA3NCSVQICAjb4U/gAAAgAElEQVR4
+nO3dyW8beX7//6rivkmkREryItNLe2u7DTc83ZPpZIJJgEGOQc7Jf5BzECT/RoCcghxyCJIAOc0E


Why do you use inline png here?

uhh, dunno what inkscape did there. I had the D logo in there once but it didn't look so good, maybe it still kept it

s-ludwig · 2018-02-28T08:43:04Z

Agree with the default logo. Reducing opacity and/or adding a checker pattern or similar could be used to signal that it's a default logo, too.

s-ludwig · 2018-02-28T09:06:37Z

BTW, a relatively cheap way to instantly get some non-default icons would be to use the organization avatar on GitHub (not if the owner is a user obviously, though) and the project avatar for GitLab and Bitbucket. Could be a new field in dubregistry.repositories.repository.RepositoryInfo.

Edit: Or rather the org avatar for Bitbucket, too.

This way wide logos will still stay wide, rectangle logos won't be larger than 220x220px which is roughly half the display width at the breakpoint and a bit more than half the display width on regular mobile displays

WebFreak001 · 2018-03-05T18:59:07Z

@s-ludwig made the default logo gray

WebFreak001 · 2018-03-08T08:50:49Z

I think getting a default logo on registration time or something like that is scope of another PR.

WebFreak001 · 2018-03-09T17:36:22Z

mergable now?

s-ludwig · 2018-03-10T14:27:27Z

I would second the question of whether to store logos as files or in the database. For the mentioned reasons I'd lean towards database, it also won't work with the current setup, because the registry runs as an unprivileged user without write access to its own directory.

BTW, does the convert invocation always scale to 512, or will it only do downscaling?

Apart from that I'd say everything is ready.

WebFreak001 · 2018-03-10T14:28:46Z

yeah ok I will check how well that is doable.

convert with > only downscales

MartinNowak

Fairly nice so far.

BTW, a relatively cheap way to instantly get some non-default icons would be to use the organization avatar on GitHub (not if the owner is a user obviously, though) and the project avatar for GitLab and Bitbucket. Could be a new field in dubregistry.repositories.repository.RepositoryInfo.

Just scrape og:image from the repo sites initially to bootstrap the logos, then we don't need a repetitive default logo.

Also I would second to use the db instead of the filesystem to store the logos, simplified highly-available setups, backups, and migration of the service.

MartinNowak · 2018-03-11T14:04:30Z

views/view_package.dt

+	meta(property="og:description", content=versionInfo["description"].opt!string)
+	meta(property="og:site_name", content="DUB Package Registry")
+	meta(property="og:locale", content="en_US")
+	meta(property="article:author", content=user.fullName.length ? user.fullName : user.name)


MartinNowak · 2018-03-11T14:08:22Z

views/view_package.dt

 	- import userman.controller;
 	- auto title = "Package " ~ packageName ~ " version " ~ versionInfo["version"].get!string;

+	- auto normalizedPackageName = packageName.splitter(':').front;


findSplit(':')[0]

What's the advantage of findSplit?

@wilzbach oh actually I just found out that if a packageName were to be empty, this method would crash because split and splitter return an empty array for an empty string...

100 comments on this pr 🎉

Yeah, but that's not going to happen, is it?
Anyhow, if you are experiencing this problem somewhere else, there you might like orElse

dlang/phobos#5154

I'm also a big fan or safeDeref, but I'm not sure whether the version on the NG supports ranges out of the box.

s-ludwig · 2018-03-11T14:27:17Z

Just scrape og:image from the repo sites initially to bootstrap the logos, then we don't need a repetitive default logo.

Didn't realize that they augmented the repo size with that! Nice.

wilzbach · 2018-03-11T14:34:26Z

FYI: the default github avatars use a "technology" that's called identicon. You can even skip the query to github and create such icon on-demand, e.g.

https://identicon-api.herokuapp.com/dub-registry/200?format=svg

Or a newer service: https://jdenticon.com/#icon-dub-registry

See also:

MartinNowak · 2018-03-11T14:39:52Z

FYI: the default github avatars use a "technology" that's called identicon. You can even skip the query to github and create such icon on-demand, e.g.

We would just fetch the logo once for each package initially and on registration of new packages, really trivial and saves a manual step in case the organization/user logo is already the right choice and continues to work across github/gitlabs/bitbucket's feature set (e.g. per-repo logos https://gitlab.com/gitlab-org/gitter).
Extracting meta og:image should be easy with a Regex instead of requiring a full-blown HTML parser.

WebFreak001 · 2018-03-13T21:26:13Z

logos are now stored inside mongo as bson binary objects, however caching got removed due to this as sendFile isn't used anymore.

have file revs only show when changed

wilzbach

Looks really good!

wilzbach · 2018-03-13T22:26:03Z

source/dubregistry/dbcontroller.d

+			m_packages.update(["name": packname], ["$unset": ["logo": 1, "logoHash": 1]]);
+	}
+
+	bdata_t getPackageLogo(string packname, out bdata_t rev)


This a question of design/personal preferences, but I typically return tuples in such cases. Hence out of interest, why did you go with out?

I go struct or out, but never tuple because it requires me to import something rather large. Selective imports don't help with compilation time in most of phobos.

std.typecons is already imported in other modules (and even in vibe.d), so there's no extra import cost.
Also FWIW we reduced the total import time of all Phobos modules to < 0.5s with 2.079. On my machine it's even less than 0.2s now

See: https://dlang.org/changelog/2.079.0.html#std-experimental-all

wilzbach · 2018-03-13T22:29:06Z

source/dubregistry/internal/utils.d

+			a.put(chunk);
+	})();
+
+	return cast(bdata_t)a.data.idup;


Appender uses the GC to allocate plus it's local, so you can use assumeUnique and avoid the idup copy

Or change to appender!(immutable(ubyte)[])

is there some way to read all output from a File stream? I don't know any and I basically just took this code from std.process.execute

well, in this case you could simply use execute - this would save a few lines?
(I will look into making modifying execute)

execute converts to a string, but the std output gets a binary png file. I don't want to risk an eventual std.utf.validate getting in there.

I will look into making modifying execute

dlang/phobos#6276 (for a start)

I don't want to risk an eventual std.utf.validate getting in there.

FTR with cast(immutable(ubyte)[]) execute(["convert", ...]) validate isn't called.
Appender uses ElementEncodingType, not ElementType to avoid auto-decoding.

Just for completeness, there is vibe.stream.operations.readAll to read all of a stream into a buffer.

does it work for std.stdio.File like you get when spawning a process?

No, would have to be wrapped inside a StdFileStream for that, but that is rather ineffecient currently.

wilzbach · 2018-03-13T22:30:56Z

source/dubregistry/registry.d

 import dub.semver;
 import dub.package_ : packageInfoFilenames;
-import std.algorithm : canFind, countUntil, filter, map, sort, swap;
+import std.algorithm : any, canFind, countUntil, filter, map, sort, swap;


Any isn't used anymore

wilzbach · 2018-03-13T22:33:49Z

source/dubregistry/web.d

+			// make sure requester actually supports svg, if a custom IDE or tool for fetching images is used it should only get png if it doesn't support svg.
+			// if requester is an IDE sending Accept: */*, but not accepting SVG it's their own fault.
+			foreach (accept; req.headers.get("Accept", "").splitter(",")) {
+				if (accept.startsWith("image/*", "image/svg", "*/*", "*/svg")) {


Isn't this among?

image/*; q=0.8, image/svg+xml

eventually gonna make a PR to vibe.d for proper Accept parsing

wilzbach · 2018-03-13T22:38:14Z

source/dubregistry/web.d

+	void postSetLogo(scope HTTPServerRequest request, string _packname, User _user)
+	{
+		enforceUserPackage(_user, _packname);
+		const(FilePart) logo = request.files.get("logo");


FYI the braces aren't needed here. In fact, just const should work too.

wilzbach · 2018-03-13T22:40:10Z

source/dubregistry/web.d

+		enforceUserPackage(_user, _packname);
+		const(FilePart) logo = request.files.get("logo");
+		enforceBadRequest(logo != FilePart.init);
+		auto renamed = NativePath.fromString(logo.tempPath.toString ~ logo.filename.name.extension);


NativePath.fromString should ideally accept a range...

Definitely wouldn't hurt from a convenience POV, but it stores a string inside anyway, so that it couldn't eliminate the allocation.

or maybe some rename filename/last segment? (or any segment even)

so that it couldn't eliminate the allocation.

Hmm, well I guess it could be templatized (would be nice with the hopefully soon upcoming RCString), but it's a different story entirely.
Anyhow I opened an issue, s.t. it's not totally forgotten (vibe-d/vibe.d#2119).

wilzbach · 2018-03-13T22:43:11Z

source/dubregistry/registry.d

+			throw new Exception("Failed to generate logo");
+	}
+
+	void unsetPackageLogo(string pack_name)


FWIW this is typically called delete (though I don't want to get into this nitpicking)

wilzbach · 2018-03-13T22:46:46Z

source/dubregistry/web.d

 		redirect("/my_packages/"~_packname);
 	}

+	@auth @path("/my_packages/:packname/set_logo")


FWIW this is usually mapped on /logo and only the http method is used to distinguish between get, post and delete.

well all other endpoints are like this too

Yeah, let's keep that for another day. The current scheme is just used to avoid HTTP method override hacks to account for the form based nature of the interface.

s-ludwig

@wilzbach Anything left from your side?

wilzbach

LGTM too - though SVG upload ends in an non-terminating request for me. Maybe we should simply disallow svg for now and only accept png + jpg?

wilzbach · 2018-03-18T14:48:59Z

source/dubregistry/dbcontroller.d

+			]]);
+		}
+		else
+			m_packages.update(["name": packname], ["$unset": ["logo": 1, "logoHash": 1]]);


It's quite untypical to use 1 as null value.

this is $unset, not $set

Yes and I don't mind that you use 1.
It's just more common to use 0 or -1

(Of course that mongodb itself promotes such a crap API is a different story)

hm just took the first result off google when searching for how to unset

wilzbach · 2018-03-18T14:53:50Z

source/dubregistry/dbcontroller.d

+		auto hash = bpack.tryIndex("logoHash");
+		if (!hash.isNull)
+			rev = hash.get.get!BsonBinData.rawData;
+		return logo.get.get!BsonBinData.rawData;


It would be really to cool to have something like safeDeref for Mongo's data, it could then be sth. like:

rev = bpack.try.logoHash.rawData.get!BsonBinData; return bpack.try.logo.rawData.get!BsonBinData;

wilzbach · 2018-03-18T15:00:29Z

views/my_packages.package.dt

+			h3 Logo
+			- string logoPath = "/packages/" ~ packageName ~ "/logo";
+			img.packageLogo(src=logoPath)
+			input(name="logo", type="file", accept="image/*", onchange="updateLogoPreview(this)")


Maybe accept="image/x-png,image/jpeg" or accept=".png, .jpg, .jpeg" for now?

wilzbach · 2018-03-18T15:00:54Z

source/dubregistry/web.d

+		enforceUserPackage(_user, _packname);
+		const FilePart logo = request.files.get("logo");
+		enforceBadRequest(logo != FilePart.init);
+		auto renamed = NativePath.fromString(logo.tempPath.toString ~ logo.filename.name.extension);


Check file extensions here?

wilzbach · 2018-03-18T15:02:09Z

source/dubregistry/internal/utils.d

+{
+	static assert (isWeaklyIsolated!(typeof(&generateLogoUnsafe)));
+	static assert (isWeaklyIsolated!NativePath);
+	return (() @trusted => async(&generateLogoUnsafe, file).getResult())();


This should to timeout after X seconds and terminate the convert process (at the moment it doesn't)

for style

WebFreak001 · 2018-03-18T18:56:32Z

@wilzbach the issue with the hanging was actually an issue because of the code, fixed it now and svgs should work now, but because now we are restricting to png, bmp, jpg and gif it wont

wilzbach

Thanks for addressing the infinite upload loop. I left a few more nits (some of them are really just comments)

wilzbach · 2018-03-19T09:38:41Z

views/my_packages.package.dt

+			if (f.size > 1024 * 1024)
+				document.querySelector(".logoError").textContent += "Error: Image file size too large! ";
+			if (f.type != "image/png" && f.type != "image/gif" && f.type != "image/jpeg" && f.type != "image/bmp")
+				document.querySelector(".logoError").textContent += "Warning: Invalid image type. ";


On uploading an invalid image - I see the following:

Idea: reorder these two messages to check for the image type first and then immediately return the function if the user used an invalid image type.
This also prevents them from hitting upload

wilzbach · 2018-03-19T09:42:27Z

source/dubregistry/internal/utils.d

+
+	auto sizeInfo = execute(["identify", "-format", "%w %h %m", firstFrame]);
+	if (sizeInfo.status != 0)
+		return new LogoGenerateResponse(null, "Malformed image.");


Isn't this what exceptions are for? (I know that async / Future doesn't really support this at the moment)

I would throw here, but it was broken when I tried

Yeah I'm aware - Future doesn't really support exceptions like es6 promises.

And it also can't, at least in a safe way, because of their thread-local nature in D, especially since the latest RC additions. It should require the callback to be nothrow, though.

wilzbach · 2018-03-19T13:52:26Z

source/dubregistry/internal/utils.d

+}
+
+// need to return * here because stack returned values get destroyed for some reason...
+private LogoGenerateResponse* generateLogoUnsafe(NativePath file) @safe


That's weird (and looks like a bug in async). We should probably look into reducing and fixing it. A simple example works:

/+dub.sdl: dependency "vibe-core" version="~>1.4" +/ import vibe.core.core; import vibe.core.concurrency; import vibe.core.log; import core.time; void main() { struct Foo { int r; string k; } auto val = async({ 10.msecs.sleep; auto f = Foo(2, "aa"); return f; }); 2.msecs.sleep; logInfo("Result: %s", val.getResult()); runApplication; }

wilzbach · 2018-03-19T14:01:25Z

views/my_packages.package.dt

+			img.packageLogo(src=logoPath)
+			p.logoError.error
+			label
+				| Select new Logo (at most 1 MiB, optimal size 512x512)


Nit: typically max. is used for this (or not displayed at all except for the error case)

wilzbach · 2018-03-19T14:06:48Z

source/dubregistry/internal/utils.d

+	timer.stop();
+	if (result != 0)
+	{
+		if (!timer.pending)


You manually stop the timer before, so this can never happen.
While this shouldn't be a problem anymore now that only a few image formats and sizes are allowed, ideally such timing code should be put in utils, s.t. it's easier to abstract / test / reuse it (or part of vibe-core).
For now the timeout from coreutils might be simpler and less error-prone to use?

wilzbach

I'm really running out of points here ;-)
Imho we should merge this. There are still a few small points, but they can be done after to this PR (e.g. the upload button could be set to disabled by default and only enabled when it can be used)

wilzbach · 2018-03-19T23:04:16Z

views/my_packages.package.dt

+			if (!f) return;
+			document.querySelector(".logoError").textContent = "";
+			if (f.type != "image/png" && f.type != "image/gif" && f.type != "image/jpeg" && f.type != "image/bmp")
+				document.querySelector(".logoError").textContent += "Warning: Invalid image type. ";


Oh I meant to use return to avoid creating the object url and displaying something that's invalid.

I used this because it signals the user that the image is now broken instead of showing the valid previous image.

s-ludwig · 2018-03-21T10:57:24Z

So, let's pull the trigger!

BTW, I made some package graphics back when designing the new DUB logo. The logo on the left side is not right, but this could be adjusted to serve as a more refined package logo later on:

WebFreak001 · 2018-03-21T11:21:42Z

yeah that looks pretty cool, but I can imagine that it won't look good as small icon. I designed my icon so that it still looks good and recognizable even at 16x16. Though for large icons that could be cool. Maybe use the other D logo now that they are considering to rebrand to for the right side? Also I would remove or redo the shadows at the bottom

Compare:

s-ludwig · 2018-03-21T11:33:31Z

I don't think we should ever display the project logo that small, because who knows how the custom ones look like. But due to the coarse red strips it actually looks pretty decent in tiny sizes: (the "D" could be made brighter at that size to stay readable)

True with the shadows. they need a frame or more space to the bottom to work like this. I missed the rebranding topic, do you have a reference?

WebFreak001 · 2018-03-21T11:40:57Z

uh I think I asked in #offtopic on slack once if the D logo there on https://github.com/dlang-community/artwork is the new D logo and they are planning on doing this, though it still has problems with small sizes like icons.

s-ludwig · 2018-03-21T12:07:24Z

Ah okay, I see. My feelings about using it as the language logo are a little bit mixed, although it definitely is an awesome logo in general. Just as a side note, it could also make sense to go for a more gentle redesign, such as separating the moons and adjusting the shape of the "D". For example regarding the moons:

MartinNowak · 2018-03-26T23:09:20Z

Nice to see this merged :).

I'd still say we should seed all package logos with the homepage/repo's og:image instead of adding a default logo. It simply reduces the necessary initial configuration for package maintainers.

wilzbach reviewed Feb 28, 2018

View reviewed changes

WebFreak001 added 8 commits February 28, 2018 21:20

Convert D text in package logo svg to curve

8e15f86

Send default logo as svg if supported

764cdf2

move code to using async

d6a4836

Switch to only supporting one file format

f0a48f7

Use std.typecons.flags for generateLogo

4aaa739

make max logo height on mobile 220px

f7bb3e5

This way wide logos will still stay wide, rectangle logos won't be larger than 220x220px which is roughly half the display width at the breakpoint and a bit more than half the display width on regular mobile displays

Normalize package name & use splitter in metadata

4db721c

Made default logo grayscale

bc339f2

MartinNowak reviewed Mar 11, 2018

View reviewed changes

Make logos store inside mongodb

2a048e4

bring back old logo behavior

744f81f

have file revs only show when changed

wilzbach reviewed Mar 13, 2018

View reviewed changes

adjust to changes

610cfe6

s-ludwig approved these changes Mar 16, 2018

View reviewed changes

wilzbach approved these changes Mar 18, 2018

View reviewed changes

wilzbach reviewed Mar 18, 2018

View reviewed changes

webfreak added 3 commits March 18, 2018 19:02

unset using 0

cd77fb1

for style

proper file checks for logo

9d1ba0f

restrict selection to png, jpg, gif and bmp

bbe716b

Give errors using JS before submitting

574afc2

wilzbach approved these changes Mar 19, 2018

View reviewed changes

WebFreak001 added 2 commits March 19, 2018 18:45

use timeout command instead of manual timeout

4871fd2

minor frontend logo upload improvements

4cbf1f1

wilzbach approved these changes Mar 19, 2018

View reviewed changes

made upload button disabled and only enable on valid images

2392c6d

s-ludwig merged commit e9411cb into dlang:master Mar 21, 2018

MartinNowak mentioned this pull request Apr 27, 2018

Make it possible to either turn off the documentation tab or point it elsewhere #312

Closed

Uh oh!

Allow custom package logos & add OpenGraph #286

Allow custom package logos & add OpenGraph #286

Uh oh!

Conversation

WebFreak001 commented Feb 26, 2018

Uh oh!

dlang-bot commented Feb 26, 2018

Uh oh!

wilzbach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

s-ludwig commented Feb 28, 2018

Uh oh!

s-ludwig commented Feb 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WebFreak001 commented Mar 5, 2018

Uh oh!

WebFreak001 commented Mar 8, 2018

Uh oh!

WebFreak001 commented Mar 9, 2018

Uh oh!

s-ludwig commented Mar 10, 2018

Uh oh!

WebFreak001 commented Mar 10, 2018

Uh oh!

MartinNowak left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

s-ludwig commented Mar 11, 2018

Uh oh!

wilzbach commented Mar 11, 2018

Uh oh!

MartinNowak commented Mar 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

s-ludwig commented Feb 28, 2018 •

edited

Loading

MartinNowak left a comment •

edited

Loading

MartinNowak commented Mar 11, 2018 •

edited

Loading

WebFreak001 commented Mar 13, 2018 •

edited

Loading

WebFreak001 Mar 14, 2018 •

edited

Loading

wilzbach Mar 14, 2018 •

edited

Loading