[m-rev.] for review: Fix failing tabled_typeclass test case.

[Julien Fischer]

Hi Zoltan,

On Tue, 7 Aug 2018, Zoltan Somogyi wrote:

> On Tue, 7 Aug 2018 07:43:51 +0000 (UTC), Julien Fischer <jfischer at opturion.com> wrote:
>> That's fine.  (Although, for testing purposes it would be
>> useful to have a way to tell the debugger to print *all* I/O actions
>> in order to avoid hardcoding specific numbers as here.)
>
> I don't think that would be a good idea in general. I added such limits
> after one too many experiences with output that was so large and was
> being produced so quickly that it effectively locked up my computer.
> No doubt the small size of main memories and slow speed of CPUs at the time
> (by today's standards) helped by crowding out the code that was attempting
> to process any input that aimed to stop the flood. Nevertheless, even if this
> does not happen, getting a million lines of output that takes every part
> of e.g. the debugger history you are interested in beyond the scrollback
> limit of your terminal window is bad enough.
>
> There may well be a case for increasing the default limit, but I would vote
> against removing *all* limits.

I wasn't intending it to be a user facing feature, just something that
would avoid us having to hardcode I/O action numbers in the tests cases.
I'm fairly certain that none of the debugger test cases generate
millions of I/O actions.   (Being able to lift the default limit, as in
the declarative debugger, would suffice as well.)

Julien.