Re: [Discuss-gnuradio] Python pass parameter as const *gr_complex?

[Ludwig Stephan (CR/AEH4)]

Thank you, Tom, for your enlightening answer. Please let me ask two additional 
questions:

1) If I understood your explanation correctly, as a consequence of this, one 
could not use the decision_maker method within a block, which is coded solely 
in python. Right?

2) Isn't "const gr_complex*" a type, which is used very often in the block I/O 
interfaces, and shouldn't, thus, the GR configuration of SWIG already let it 
know how to translate python/complex to gr_complex?

Best regards 

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology 
(CR/AEH4) 
Renningen 
70465 Stuttgart 
GERMANY 
www.bosch.com 

Tel. +49(711)811-8809 
Fax +49(711)811-1052 
Mobile +49(172)5630639 
address@hidden 

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk 
Hoheisel, Christoph Kübel, 
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller 
Von: address@hidden [mailto:address@hidden Im Auftrag von Tom Rondeau
Gesendet: Dienstag, 20. Januar 2015 15:57
An: Ludwig Stephan (CR/AEH4)
Cc: address@hidden
Betreff: Re: [Discuss-gnuradio] Python pass parameter as const *gr_complex?

On Wed, Jan 7, 2015 at 7:57 AM, Ludwig Stephan (CR/AEH4) <address@hidden> wrote:
Hi list,
 
I am trying to use the gr::digital::constellation::decision_maker(.) method 
from python, but I get an error message.
In order to reproduce call in python:
 
import gnuradio.digital
a = gnuradio.digital.constellation_qpsk()
b = complex(1+1j)
a.decision_maker(b)
=> TypeError [..] argument 2 of type ‘gr_complex const*’
The C++-implementation is wrapped by SWIG, where the error occurs.
 
This might be a silly question, but what am I doing wrong?
 
Thanks for any help.
 
Best regards
 
Stephan Ludwig

Hi Stephan,

You're not doing anything wrong per se, but the block isn't really meant to be 
used that way. SWIG needs to be told how to handle some types of argument 
formats, and it hasn't been told how to handle this one.

The post 3.7 way we've been handling SWIG is to just include the public .h file 
as the interface, so all methods are exported into SWIG. A class like this 
needs that method to be public for use as a contained object in the block that 
calls it, but it's not really meant for use outside like this. Not that it 
couldn't be, but you'd have to work with SWIG to let it understand how to call 
that function with the proper input type.

Tom