GNU Radio 3.8 support

[ncorgan]

Currently on master and for GNU Radio 3.8, whenever that comes along, GRC has moved over to using YAML files to describe GNU Radio blocks, and gr_modtool generates these for new OOT modules.

For compatibility with GNU Radio 3.8, GrPothosUtil.py will need to be able to parse these.

[guruofquality]

I knew this day would come, but I have dreaded its arrival. Its the yaml format basically just the same crap, same file name different extension? Same data layout when parsed, dictionaries, keys and lists?

[ncorgan]

The filenames seem to be the same (extension aside). From a data layout perspective, as an example, here's how gr::blocks::add_xx has changed:

• 3.7
• 3.8

From using it in some WIP OOT modules, I prefer the new usage, but I can't speak to the difficulty of parsing for gr-pothos.

[ncorgan]

WIP here: https://github.com/pothosware/gr-pothos/tree/gr3.8

[ncorgan]

There are a few steps to doing this while maintaining compatibility with 3.7, so I'll make a project to make tracking easier.

[guruofquality]

No big deal if master does 3.8 only

[ncorgan]

Looks like they did the job for us in 3.8: https://github.com/gnuradio/gnuradio/tree/master/gr-utils/blocktool

No need for ugly GRC file parsing, they output a super-convenient JSON file. Minus the PothosFlow docs, this is essentially a weekend project now.

[guruofquality]

well thats helpful 👍

[ncorgan]

The only downside is now it's seconds per file. They're using pygccxml under the hood. I have no idea what makes it so slow, but it may be worth just storing the JSON output. It's what they do for their blocktool usage.

[guruofquality]

@ncorgan I was thinking of getting one more windows installer build out this year (as we speak), and moving the whole windows installer thing over to recent msvc and gr 3.8. Its a ton of brand new build issues and dependency changes, etc, pandoras box. I think its reasonable to move this project over to 3.8+ permanently. How far along were you, and is it something you wanted to tackle?

[ncorgan]

https://github.com/pothosware/gr-pothos/tree/wip/gr3.8

This is what I had so far. If I recall, I think the major thing left is generating the block functions from BlockTool's output. I put some TODOs in for some other stuff, as well as a file listing obsolete build-time stuff to remove once this is done. If you're already on this, would you mind taking this part?

[guruofquality]

I was going to jump strait to requiring 3.9 The odd number releases were always better anyway

Wow, blocktool is like walking through molasses with concrete boots on using dial up. What is blocktool's output giving us that cppheaderparser was not?

I can see checking in blocktool output though. It looks like it uses clang++ or something, and im worried to make the generation take too much time or have too many dependencies (I want to build on windows as well). Even requiring gnuradio to actually show up in the python path and import correctly may be a bit too much :-)

[ncorgan]

BlockTool output was just easier to parse than the GRC YAML, and I’m lazy. That parsing is 99% of the time, and I believe even GR stores the output for the new PyBind stuff.

…

On Jan 29, 2021, at 10:12, Josh Blum ***@***.***> wrote:  I was going to jump strait to requiring 3.9 The odd number releases were always better anyway Wow, blocktool is like walking through molasses with concrete boots on using dial up. What is blocktool's output giving us that cppheaderparser was not? I can see checking in blocktool output though. It looks like it uses clang++ or something, and im worried to make the generation take too much time or have too many dependencies (I want to build on windows as well). Even requiring gnuradio to actually show up in the python path and import correctly may be a bit too much :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.