discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?


From: Marcus D Leech
Subject: Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?
Date: Wed, 7 Oct 2020 11:47:30 -0400

Thanks Ron. 

Sent from my iPhone

> On Oct 7, 2020, at 6:04 AM, Ron Economos <w6rz@comcast.net> wrote:
> 
> Here's the PR.
> 
> https://github.com/gnuradio/gnuradio/pull/3818
> 
> Here's the updated file if you want to do a quick test.
> 
> http://www.w6rz.net/multiply_const_v_python.cc
> 
> It goes in gnuradio/gr-blocks/python/blocks/bindings
> 
> Ron
> 
>> On 10/6/20 23:04, Ron Economos wrote:
>> It's only in 3.9. It was merged on June 19, 2020.
>> 
>> Ron
>> 
>>> On 10/6/20 22:49, Marcus D. Leech wrote:
>>> On 10/07/2020 01:40 AM, Ron Economos wrote:
>>>> Okay. I'm going to submit a pull request for this. I'll post the patch 
>>>> later when I'm sure it's working. It may take a while.
>>>> 
>>>> Ron
>>>> 
>>> Thanks, Ron.
>>> 
>>> Was the pybind11 transition done 3.8-->3.9 or 3.7-->3.8?
>>> 
>>> [My world is still mostly 3.7, but I'm running some of my code on a 3.9 
>>> system, at the ATA/HCRO]
>>> 
>>> 
>>>> On 10/6/20 22:34, Marcus D Leech wrote:
>>>>> The system I’m trying this on
>>>>> Is Python 3.8.
>>>>> 
>>>>> I get no warnings at all, no exceptions.  Nothing.
>>>>> 
>>>>> It just silently screws the pooch.
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Oct 7, 2020, at 1:21 AM, Ron Economos <w6rz@comcast.net> wrote:
>>>>>> 
>>>>>> It's a bug. The set_k() function has been left out of the pybind11 
>>>>>> binding.
>>>>>> 
>>>>>> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/python/blocks/bindings/multiply_const_v_python.cc
>>>>>>  
>>>>>> 
>>>>>> On my system, I get a warning:
>>>>>> 
>>>>>> Exception in thread Thread-1:
>>>>>> Traceback (most recent call last):
>>>>>>    File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
>>>>>>      self.run()
>>>>>>    File "/usr/lib/python3.6/threading.py", line 864, in run
>>>>>>      self._target(*self._args, **self._kwargs)
>>>>>>    File "/home/ubuntu/xfer/multiply.py", line 87, in 
>>>>>> _variable_function_probe_0_probe
>>>>>>      val = 
>>>>>> self.blocks_multiply_const_vxx_0.set_k([1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1])
>>>>>> AttributeError: 'gnuradio.blocks.blocks_python.multiply_const_vcc' 
>>>>>> object has no attribute 'set_k'
>>>>>> 
>>>>>> Ron
>>>>>> 
>>>>>>> On 10/6/20 21:59, Marcus D Leech wrote:
>>>>>>> A vector is what I want and this works flawlessly in GR3.9
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>>>> On Oct 7, 2020, at 12:57 AM, Ron Economos <w6rz@comcast.net> wrote:
>>>>>>>> Try the "Fast Multiply Constant" block instead. The "Multiply 
>>>>>>>> Constant" block requires that the constant be a vector.
>>>>>>>> 
>>>>>>>> Ron
>>>>>>>> 
>>>>>>>>> On 10/6/20 21:08, Marcus D. Leech wrote:
>>>>>>>>> This is an apparent problem in 3.9.0.0-git
>>>>>>>>> 
>>>>>>>>> In grc, create a multiply_const with a vector size > 1
>>>>>>>>> 
>>>>>>>>> Have a function_probe block that sets the constant on a regular 
>>>>>>>>> basis--perhaps from a variable, or a function call or the like.
>>>>>>>>> 
>>>>>>>>> The constant will never be updated, even thought the function_probe 
>>>>>>>>> setter is getting called.  It's like the statement that contains the
>>>>>>>>>    muitiply_const_vxx.set_k() is never even getting evaluated, 
>>>>>>>>> because if the value inside the set_k is itself a function call, that 
>>>>>>>>> function
>>>>>>>>>    is never called.
>>>>>>>>> 
>>>>>>>>> This caused me to pull my hair out (well, figuratively).
>>>>>>>>> 
>>>>>>>>> Now the originating flow-graph .grc file originated from GR 3.7 but 
>>>>>>>>> GRC 3.9 didn't appear to have any problem converting it and the
>>>>>>>>>    generated python looks entirely valid.  This is almost like 
>>>>>>>>> Python3 is simply quietly ignoring the entire statement and I cannot
>>>>>>>>>    understand why.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>> 
>> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]