@jcsahnwaldt, seems like there's no progress anymore :(

Hmm, I would like the solution to be efficient also.
Maybe we could add that to the description?
I think the test that call stack is actually exceeded was a good one, since it eliminates a lot of the cheat solutions. Then the difficulty of this kata might also increase a bit :)

What do you think?

btw, do you know if tagging users do actually notify them?

Let's just keep that test case removed for now.

It's a good question. I would maybe say that if the solution can't handle a limit betweeen 20k and 50k, then it isn't good enough?

I don't know what's best.

I removed the test for now. Here's why...

While I wrote the description above, I had an idea for a new solution. Different from all previous solutions, as far as I can tell: Instead of first defining all functions and then calling them, it defines the functions as it goes along. In other words, it creates a new function and immediately calls it, and inside that new function it decides whether it needs to create yet another function, and so on. :-)

But it builds the functions by calling eval on the source code of the existing function, which is pretty slow, and the maximum call stack test times out.

So I deleted the test to make my beautiful new solution pass. :-) But of course, we can always restore the test later if we want.

Checking that the solution exceeds the stack size when limit is very large is a nice idea, but there are some problems.

• The maximum call stack size test currently picks a random limit value between 10,000 and 20,000. But when the limit is below ca. 12,000, the call stack size is not exceeded, no error is thrown, error1 and/or error2 is undefined, and assert.equal(error1.toString(), error2.toString()) crashes.
• We could fix that by picking much higher limit values that always lead to a stack overflow, e.g. 100,000 or higher. But a problem with this approach is that the solution first has to define all these functions, and that takes some time. If the test picks limit values that are guaranteed to lead to a stack overflow when the functions are called, some solutions may time out while building the functions.
• Different solutions have different maximum stack sizes, depending on how large each call frame is. Some solutions may get a stack overflow for a limit of 5,000, others only when the limit is 20,000. Hard to predict.
• If V8 ever implements tail call optimization, the test won't work anymore. But that's unlikely to happen in the forseeable future. :-)

The current test crashes every now and then, so we have to fix that. But what should we do? I guess we could just remove the test. Due to the issues mentioned above, making it really reliable and useful seems like a bit of work...

Hm... Testing that the solution exceeds the stack size is a nice idea, but there are some problems. I'll open another issue...

Nice! Somehow my fix for the Error.prepareStackTrace problem got lost. I guess you were editing an older version. Or something like that. The user interface of the editor isn't helpful in such cases. :-) Anyway, no big deal, I restored my fix. It was just one line.

@jcsahnwaldt, I added an additional test case, that expects the function to throw maximum call stack size error when called with a huge limit. I think that would catch some of the cheat solutions, but that test could also be easy to check by throwing an exception if limit is greater than a specific number. Anyways it doesn't hurt to have it :)

Thank you very much!!!

@MikChan, @ThisIsUndefined, @skeate, @Fbasham, @Voile, @Kacarott: Please have another look at this kata. @Brainie and I put a lot of work into improving it. The description is clearer and more precise, and the API is simpler, cleaner and more secure against cheating.

Your solutions have been invalidated due to the API changes, but the core idea is the same, and it should be easy to update your solutions to make them work again.

Have fun! Please also update your votes. The average currently stands at 71%, but I think this kata can and should be approved soon. It deserves at least 80%. I'd say if deserves 100%. :-)

Fixed it. It was a small change in the end, but it took me a long time to figure out how Error.prepareStackTrace works. Its documentation isn't very detailed.

And playing with Error.prepareStackTrace means messing with how the system generates stack traces, so when something goes wrong, there's no stack trace. The output box turns red and shows an error code at the top. That's pretty much all...

I initially thought we might be able to delegate to the original implementation of Error.prepareStackTrace for actual errors, but Error.prepareStackTrace is usually undefined, so there seems to be no way to find that original implementation.

Then I thought we could just return the first argument given to Error.prepareStackTrace in case of actual errors, but that didn't work either...

In the end I found out that the stack property of the first argument is already set when Error.prepareStackTrace is called, and we can simply return that. Phew.

While I cleaned up the test error messages, I realized that due to my messing with the innards of the Error class, the JavaScript engine fails to produce any messages for many common errors. :-(

For example, if I have a syntax error in my solution and run it, that fails without any message. It's hard to even recognize that the run failed, because there's so little output.

I'll try to fix this. I think we have to replace the prepareStackTrace in a smarter way.

I tried to improve the failure messages and replaced

assert.deepEqual(depth,limit);

by

assert.equal(limit, depth, `wrong stack depth - expected ${limit}, found ${depth}`);

(The default error message of assert.equal is really quite confusing: which one is the expected value in "expected 10 to be equal to 2"?)

I also replaced

throw new Error('The call stack contains multiple function calls with the same name!');

by

assert.fail('The call stack contains multiple function calls with the same name!');

Seems cleaner.