bug#22114: 24.5; [PATCH] Allow profiler.el to display reports after stopping

[Vasilij Schneidermann]

> I prefer to solve the problem rather than work around it.

I'm not sure I'm understanding this correctly.  How is your suggestion
of just removing the check for whether the profiler is running not a
workaround?  The only way I see of solving this without extra code in
the frontend is by fixing the underlying C code, but you've confirmed
that this is not an option.  At least not without restructuring
profiler.c heavily.

To prove that I'm not the crazy one here, I've written two example
programs in Ruby (with ruby-prof) and Python (with cProfile).  Both of
them calculate a Fibonacci number in a profiler run, then display the
recorded data.  You can easily verify that the profiler behaves
idempotently and does not just discard data on a whim by editing these.
This does make a lot of sense if you consider that profiling data is
precious and would make sure it isn't easily lost unless someone
intentionally discards it.  I've been told by others that other tools
like gprof, perf and callgrind don't reset either, therefore my
conclusion on the topic is that Emacs is the odd one in this group.

Considering that this problem hasn't been reported before, I doubt
anyone has been using the profiler seriously and this change will not
disrupt anyone's workflow (which would need to be weird anyways because
the only user-visible part that did change is that stopping doesn't
prevent you from viewing a profiler run).

profile.rb
Description: application/ruby

profile.py
Description: Text Data