What does "Feedback" mean in the issue tracker?

GNU Radio
1

What does it mean in the GNU Radio issue tracker for an issue to have
the status “Feedback”?

Two of my bugs have been in this state and I don’t know what this means
about them. I thought it might mean “asking for reporter’s response” but
in the one case I gave it and got no response (#667), and in the other
the update reads like just diagnosing the bug (#713).

I’d like to get this clarified so I can be assured I’m doing the right
thing in my bug reporting.

–
Kevin R. http://switchb.org/kpreid/

2

On 10/24/2014 09:02 PM, Kevin R. wrote:

What does it mean in the GNU Radio issue tracker for an issue to have the status
“Feedback”?

Usually “Feedback” does mean “waiting for user feedback”. But in this
case, I think it means “hmm, have to think about that”. Both reports
have the same underlying cause. The second one, to do with the
resampler, was exposed when some timing code was fixed.

In your phase_bug.py, it’s interesting that removing the lock()/unlock()
pair in _do_connect() makes the error go away. This probably means that
the buffer calculations Tom mentions are not being done during a
restart(), which happens at unlock(). The restart() function does not
call flatten(), as start() does. I don’t know whether the flowgraph can
be reflattened in restart(). If so, that might be a fix. Tom?

In the mean time, setting up a couple of multiply_const blocks and
changing the constant at runtime will work as a switch, even though it’s
not as efficient. Or, putting a stop()/wait()/start() around the call to
_do_connect() in both phase-bug.py and try_die.py makes things work
correctly, but might not be what you want.

  • Jeff
3

On Oct 25, 2014, at 5:27, Jeff L. [email protected] wrote:

On 10/24/2014 09:02 PM, Kevin R. wrote:

What does it mean in the GNU Radio issue tracker for an issue to have the
status “Feedback”?

Usually “Feedback” does mean “waiting for user feedback”. But in this case, I
think it means “hmm, have to think about that”. Both reports have the same
underlying cause. The second one, to do with the resampler, was exposed when some
timing code was fixed.

I had understood the response to #667 (though it was unclear, hence my
request for clarification) as that two internal connections to the input
port of a hier block should be considered independent – capable of
having passed different numbers of samples depending on how much work
the downstream blocks have done – at the moment the graph is locked and
modified. (Which makes sense, though is IMO poor usability, now that
I’ve had it pointed out.) Thus, not the same bug at all.

(As it happens, I believe there is an actual bug that I failed to
correctly reproduce for reporting – the original program I reduced
phase-bug.py from did not have two separate connections to the hier
block port. I haven’t commented on this before because there’s been no
particular use to it until I have a corrected test case.)

In the mean time, setting up a couple of multiply_const blocks and changing the
constant at runtime will work as a switch, even though it’s not as efficient.

In my application, the modification to the flow graph may be entirely
unrelated to the subgraph affected by the bug, and may be due to the
user requesting different processing (hence, creating new subgraphs), so
it’s not really possible to stick to non-reconfiguring changes. Also,
disabling unneeded processing is an important feature, because it makes
the difference between reasonable CPU use and an uncomfortably toasty
laptop.

Or, putting a stop()/wait()/start() around the call to _do_connect() in both
phase-bug.py and try_die.py makes things work correctly, but might not be what you
want.

That might be a useful workaround; I’ll keep it in mind.

Thanks for the information and suggestions.

–
Kevin R. http://switchb.org/kpreid/