Re: Next steps for profiler

[Rik]

>>> >> * In general for the profiler, should I add tests?  I'm much in 
>>> >> favour of testing as much as possible, but I'm not sure how to do 
>>> >> this best. Maybe by some hierarchy of test-functions which call 
>>> >> sleep at some points?  And then compare the profiler output with 
>>> >> expected times up to some "epsilon"?
>> > 
>> > I don't think meaningful tests can be made other checking that it 
>> > errors out correctly when you give it the wrong output arguments. 
>> > Demos as you've been making are good. You can't predict what the
>> > times will be as (1) this can in the end depend on a lot of Octave
>> > code that is not part of the profiling code, so you would be testing
>> > a lot more than just the profiler (2) depends on hardware.
> Hm, I think that if we just use test functions without calling a lot of
> Octave intrinsics and 'sleep' to take up time, it should (possibly) be
> doable to get more or less reliable times (after some rounding).  But I
> also think that this may be fragile and so it may be better to just not
> try adding tests.
I, personally, am not that interested in seeing tests for the profiler
beyond the basic ones outlined above.  If we need something to really vet
the profiler I would make it a fixed test script and put it in the tests/
directory and not have it get run on a regular basis.
> 
> Regarding the next projects (as per your other message):  I thought that
> a first kind of UI would be most useful -- but this is now already
> implemented with profshow.  So my next steps (after the recursive flag
> printing, which is trivial) will be to tackle operators and anonymous
> functions and hope that I'll have more luck this time. ;)
> 
> BTW, nice to know that Matlab doesn't do operators -- maybe we can
> really be first for them! :)
I'm definitely interested in operators, but less so in anonymous functions.
 If you have to prioritize I would do operators first and anonymous
functions as time allows.

Cheers,
Rik