Re: [Discuss-gnuradio] I have a trouble with new types in python!

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mostafa,


On 07.05.2014 16:34, Mostafa Alizadeh wrote:
> 
> #define X 0x01864CFB

Attention! This is a preprocessing define. This means that /prior/ to
compilation, all occurences of X will be replaced by 0x01..., so your
compiler will never see X.

Is it possible that you want to define a default option for your make
function? That works! you can just have a make function with a
function stub like
...::make(int param1, float param2, unsigned char param3, int param4 =
0x0186);

Again, XML files are only useful for defining the graphical
representation of a GNU Radio block in GRC, it's not meant to define
constants. There are ways to do that, but most of the time it's not
what you want.
You can set default values for input fields in the block options, you
can also do dropdown menus. I don't know what you're really trying to
do, so you might be best of to look at different blocks in GRC and
find one that fits your problem best, and copy that block's XML.

Greetings,
Marcus


> and I should pass X, instead of  this 0x01864CFB which is 32 bits
> number to my "make" function of my block.
> 
> What do you prefer for making a GRC xml file for this block?
> 
> best,
> 
> 
> 
> On Wed, May 7, 2014 at 5:54 PM, Marcus Müller
> <address@hidden>wrote:
> 
>> Hi Mostafa, this question is far more complex than you'd expect.
>> I'll try to explain: - GRC is but a graphical interface to python
>> code, which itself offers access GNU Radio blocks, partly written
>> in python, mostly written in C++ and wrapped to python. It's
>> always important to remember that GRC != GR - As you noticed,
>> there is not always a direct matching between C++ and python
>> types. This is an inherent problem caused by the fact that they
>> are different internally. - When you create a block, and set up
>> everything accordingly (which gr_modtool will do for you), then
>> SWIG will generate wrapper code to make these classes (which are
>> types!) available as blocks in python - also, you can generate
>> XML files to represent blocks in GRC. Again, this will only be
>> used to generate python code! If you want to define things so 
>> that you can not only use them in python, generate XML. This is
>> covered in the "writing out of tree modules" tutorial. - there is
>> a difference between sample streams and variables: a variable in
>> GRC is usually used to configure parameters of a block. I don't
>> really see a reason not to use a standard integer value here; ok,
>> you're wasting dozens of bits. But honestly, you do that once, it
>> doesn't matter. - for streams, there is a byte type. Internally,
>> neither python, nor GNU Radio care about the type; they just care
>> about the item size, so defining things like "bit", packed in
>> "byte" does never make a difference.
>> 
>> Hope that was a little helpful, Marcus Müller
>> 
>> 
>> 
>> On Wed, May 7, 2014 at 3:01 PM, Mostafa Alizadeh
>> <address@hidden>wrote:
>> 
>>> Hello everybody, I have a new type in my gnuradio blocks which
>>> are defined in c++. However, the GRC don't know them. *The
>>> first question is how I could make GRC of such blocks? *
>>> 
>>> I think if I could be able to define them in python I could add
>>> new types to the GRC of the block. Although I'm not so familiar
>>> with python, I want to define new type as it was previously
>>> defined in c++ as :
>>> 
>>> *typedef unsigned char   bit; *
>>> 
>>> *how could I define such variable in python!!!? *(may it helps
>>> me to make my GRC block)
>>> 
>>> Thank,
>>> 
>>> _______________________________________________ 
>>> Discuss-gnuradio mailing list address@hidden 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> 
>>> 
>> 
> 
> 
> 
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTalFKAAoJEBQ6EdjyzlHtRHwIAJnlorrctCzyARolZl4gc6mJ
7gTeGZc43oGj/1Ise3I7lqcY7lmBMkErGDLiKWsyWYOW0HTSHobDQr9xOY/UK5j+
HtaFAec2WeX9spTLNUBg87ZLTJlWBjoEvl6nT9xvbJSXDvoIBzF1cQ7EY1TkVU5V
zLWRxwMA1G6LeP9JGCuxlA1t92hP7gLR+UOoff1EmWx2HbwF4Jin8frn6irrzqpi
SCQ3X5VoMT2/vX10lFgbumEUhijTr5q9m3JvMIA2n7CBdq5SrLEpqjgZIHUPUxOs
nAN9h6UZ8mSfAvxjik8X1frDpp0rJxl2iZH+r69OILBAt+nQQJzb88LHyRh7UyQ=
=bJMO
-----END PGP SIGNATURE-----