-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
GNU Radio 3.8 support #14
Comments
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? |
There are a few steps to doing this while maintaining compatibility with 3.7, so I'll make a project to make tracking easier. |
No big deal if master does 3.8 only |
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. |
well thats helpful 👍 |
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. |
@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? |
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? |
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 :-) |
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.
|
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.
The text was updated successfully, but these errors were encountered: