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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 8 Dec 2015 20:15:23 +0100
> From: Vasilij Schneidermann <v.schneidermann@gmail.com>
> Cc: 22114@debbugs.gnu.org
> 
> > 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?

Removing the check is not what I alluded to.  Removing the check just
lifts the artificial limitation that shouldn't have been there to
begin with.

The problem I didn't want to work around is the one solved by this
hunk:

  @@ -846,12 +844,12 @@

   (defun profiler-report-cpu ()
     (let ((profile (profiler-cpu-profile)))
  -    (when profile
  +    (when (and profile (profiler-profile-log profile))
	 (profiler-report-profile-other-window profile))))

   (defun profiler-report-memory ()
     (let ((profile (profiler-memory-profile)))
  -    (when profile
  +    (when (and profile (profiler-profile-log profile))
	 (profiler-report-profile-other-window profile))))


IOW, the original test was incorrect, and caused errors if only one of
the 2 profiles was collected (as it usually is, since the memory
profiler is mostly useless, so the only really useful one is the cpu
one).

> Considering that this problem hasn't been reported before, I doubt
> anyone has been using the profiler seriously

Actually, I use it all the time.  I just never need to produce again
the same report, that's all.