[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] What does "Feedback" mean in the issue tracker?
From: |
Kevin Reid |
Subject: |
Re: [Discuss-gnuradio] What does "Feedback" mean in the issue tracker? |
Date: |
Sat, 25 Oct 2014 07:55:46 -0700 |
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/>