102615607 gets stack overflow but runs fine locally. I'm generating input according to this comment (BledDest correct me if I'm wrong), and I'm using vm arguments -Xmx1024m -Xss64m, as suggested by the memory limit and this blog. Just in case testcase 50 was generated differently, I also tried generating input using n = 1e8 which worked fine, albeit taking 150 seconds and requiring a lot more memory. So now I am somewhat confused: Why am I getting stack overflow?

		private String generateInput() {
			StringBuilder ans = new StringBuilder();
			ans.append("1").append("\n");
			int n = (int) 1e8, k = 100000;
			ans.append(n).append(" ").append(k).append("\n");
			BigInteger bi = new BigInteger("1".repeat(k), 2);
			for(int i = 0; i<n; i += k) {
				ans.append(bi.toString(2));
				bi = bi.subtract(BigInteger.ONE);
			}
			return ans.toString();
		}

Edit: Things take an interesting turn...
For the past ~6 months, I've always been setting the stack size to a large amount in order to avoid stack overflow javadoc. The behavior of the method had always been consistent, and it worked fine for a long time. However, the behavior changed during the last contest. 102588854 was fine, but 102610828 40 minutes later gave MLE on test 1. I changed the stack size from 1<<28 to 1<<27, which fixed the problem for 102611202 and 102612993. However, 102615154 which was submitted only 5 minutes later gave an unexpected MLE on test 6, which is quite strange, considering it had previously worked fine for 5 tests.

Now it seems that 1<<27 is fine again 102660282. However, it gives a strange error message, leading me to suspect there's an issue with the grader. I then tried setting the stack size to 1<<29, which gave an unsurprising MLE on test 1 102714946. What particularly interests me is that setting the stack size to 1<<29 works fine on custom invocation. In addition, 102660282 also works on custom invocation (once again, assuming that the testcase is generated according to BledDest's comment). I think this strange behavior calls for some investigation MikeMirzayanov? Although JavaDoc doesn't make any guarantees to the method, I think it should remain fairly consistent, especially during contests. In addition, custom invocation should produce the same results as the grader, since the whole point of it is to simulate the grader.

		private String generateInput() {
			StringBuilder ans = new StringBuilder();
			ans.append("1").append("\n");
			int n = (int) 1e6, k = 500000;
			char[] arr = new char[k];
			Arrays.fill(arr, '1');
			ans.append(n).append(" ").append(k).append("\n");
			for(int i = 0; i<n; i += k) {
				ans.append(arr);
				int j = k-1;
				for(; arr[j]=='0'; j--) {
					arr[j] = '1';
				}
				arr[j] = '0';
			}
			return ans.toString();
		}

KKiYeer was in the list of testers (check UPD 1), but this person participated in the contest, taking 30th place and gaining 226 rating. Hmmm...

Today when I was looking at my in contest submissions, I noticed that my D submission passed system tests in 639 ms. However, I remembered that it passed pretests in 872 ms 96579469. I checked my terminal history (I use cf tool for submitting) and it turns out my memory was correct.

I then decided to try and resubmit my in contest submission that had TLE'd 96576806. To my surprise, it AC'd with 842 ms 96606564!

Now, 200 ms difference and AC vs TLE is quite large. Is there a reason behind this, and could this be related to the queue at the beginning of the contest?

Hello CodeForces,
due to the lack of a debugging template in Java (and really just any template in Java), I have decided to write my own template. To use it, add -DLOCAL to your custom VM Parameters. Note that you must use LOCAL = System.getProperty("ONLINE_JUDGE")==null; for CodeForces; this is not necessary for other OJs. Then call dbg(what you want to print) to print the "what you want to print" part to stderr.

To be more exact, when calling dbg(), It will print "Line #%d: [%s]" to stderr, where %d is the line number where you called dbg() and %s is the parameters, separated by commas. For each parameter, if it is able to be iterated using a for each loop (e.g. an array or some class implementing Iterable), it will be printed as {%s} where %s is each element printed, recursively, separated by commas. Otherwise, the .toString() method will be used.

Unfortunately, there is no way to get the names of the variables passed into the parameters of a method in Java, so I'd recommend calling dbg("variable_name", variable) to make it easier to read.

The code is not very clean (mainly due to the fact that arrays can't be cast to Iterable and because primitives can't be used in parametized methods). Please comment below if you have any suggestions or additions to the template (e.g. a class which this dbg method fails to print properly). I'll try to keep the code updated to the best of my ability.

public static class Debug {
	//change to System.getProperty("ONLINE_JUDGE")==null; for CodeForces
	public static final boolean LOCAL = System.getProperty("LOCAL")!=null;
	private static <T> String ts(T t) {
		if(t==null) {
			return "null";
		}
		try {
			return ts((Iterable) t);
		}catch(ClassCastException e) {
			if(t instanceof int[]) {
				String s = Arrays.toString((int[]) t);
				return "{"+s.substring(1, s.length()-1)+"}";
			}else if(t instanceof long[]) {
				String s = Arrays.toString((long[]) t);
				return "{"+s.substring(1, s.length()-1)+"}";
			}else if(t instanceof char[]) {
				String s = Arrays.toString((char[]) t);
				return "{"+s.substring(1, s.length()-1)+"}";
			}else if(t instanceof double[]) {
				String s = Arrays.toString((double[]) t);
				return "{"+s.substring(1, s.length()-1)+"}";
			}else if(t instanceof boolean[]) {
				String s = Arrays.toString((boolean[]) t);
				return "{"+s.substring(1, s.length()-1)+"}";
			}
			try {
				return ts((Object[]) t);
			}catch(ClassCastException e1) {
				return t.toString();
			}
		}
	}
	private static <T> String ts(T[] arr) {
		StringBuilder ret = new StringBuilder();
		ret.append("{");
		boolean first = true;
		for(T t: arr) {
			if(!first) {
				ret.append(", ");
			}
			first = false;
			ret.append(ts(t));
		}
		ret.append("}");
		return ret.toString();
	}
	private static <T> String ts(Iterable<T> iter) {
		StringBuilder ret = new StringBuilder();
		ret.append("{");
		boolean first = true;
		for(T t: iter) {
			if(!first) {
				ret.append(", ");
			}
			first = false;
			ret.append(ts(t));
		}
		ret.append("}");
		return ret.toString();
	}
	public static void dbg(Object... o) {
		if(LOCAL) {
			System.err.print("Line #"+Thread.currentThread().getStackTrace()[2].getLineNumber()+": [");
			for(int i = 0; i<o.length; i++) {
				if(i!=0) {
					System.err.print(", ");
				}
				System.err.print(ts(o[i]));
			}
			System.err.println("]");
		}
	}
}

UPD:* Just realized that CodeForces doesn't allow you to query any property other than "ONLINE_JUDGE". I have accordingly updated the code and added a note.

Hello CodeForces,
I'd like to propose a new (minor) feature. As we all know, we can set the visibility of tags for unsolved problems by going to problemset and then checking or unchecking the "Show tags for unsolved problems" checkbox.
When solving problems, if I don't have an idea of the solution, I sometimes may take a look at the tags to give me some hints. However, this can get pretty annoying. When I want to show problem tags, I then have to go to problemset, check the checkbox, and then reload the page. The only option to avoid this is to show problem tags for all problems, but this causes me to sometimes get a peek at the tags before I really need to.
As a solution, I propose that users are given the option of hiding/showing a problem's tags on the page of the problem. To be more exact, you can set the default visibility of tags on the problemset page. Then, when visiting a problem, the tags will be shown/hidden based on your default setting. You then can show/hide the tags through the problem page if you want to.

MikeMirzayanov would you please suggest adding this feature?
Any suggestions/improvements/ideas are welcome! Feel free to comment below.