The most likely reason it's returning that error, is because you're creating a list that is $$26^5$$, which is 11881376. I'm pretty sure a list that length would use up too much memory.
why do you need every single five letter combination in a list? this is a massive memory hog and i can't imagine you doing anything with this where you actually need every single combination in a list at once. where is this being used?
It's to show inefficient methods of code-cracking (and why you should always use a secure password). This would be to show some of the downsides of brute-forcing- although it does cover every possible combination, it takes forever to run and takes forever to get a list to check.
Now that I say this, I think that a 4-letter combination list is a better option... it won't take nearly as long to load in on people's computers (I'm showing this at a school I'm going to).
But still, my question remains: if you have enough memory to handle it, can you change the size limit put on the "combinations" primitive?
I now realize it's not actually a limit because of memory. The script returns a result, I just don't know why it doesn't let you do it in the combinations block.
which is just under a million items, took about a second on my not-that-fast computer so I may be misremembering. (I was trying to experiment to see if I'm right about "uninterruptable," but it ran too fast for me to get to the stop sign or even to click the block again!) But in any case, yes, I think this is the only primitive that takes exponential time and space in the size of the inputs, which made Jens nervous; newbies should feel safe playing with blocks to figure out what they do.
Maybe we should have a context menu option to let it run unbounded, I dunno. One more thing to discuss for the next release.
... of course, if you want an interruptable and unbounded version you can and should write it yourself, like this definition by @bh , one of the most beautiful things on Earth (don't y'all agree?):
I totally agree with @jens , this is amazing @bh, the optimized version is lightning fast. Beautiful implementation. Is this the same official version used in the current snap?
Now, I made a tail recursive version of combinations by using a helper function. Originally it's performance is terrible - this is surprising, the reason is I am using append, I examined the code, found out the entire sequence would be reversed if I used the adding item in front of list block. But a quick reverse of the input list order before calling the helper function fixed that.
I really appreciate this experiment, as it helps to understand the performance hit using append versus item in front of list block.
After the fix, I compared your version speed against mine, there is virtually no noticeable differences.