Re: [Discuss-gnuradio] What does "Feedback" mean in the issue tracker?

[Kevin Reid]

On Oct 25, 2014, at 5:27, Jeff Long <address@hidden> wrote:

> On 10/24/2014 09:02 PM, Kevin Reid 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 Reid                                  <http://switchb.org/kpreid/>