-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While I totally see that it's convenient to have the XML source in the generated file, I'd still say it's a bad idea to encourage people to use that feature.
For example: User Alice has composed a flowgraph in GRC and has modified the python source code, actually implementing something. In former times, Alice would obviously distribute the python code separately from the GRC file; thus, no one wonders why the re-synthesized python code doesn't do anything useful. After the proposed embedding mechanism has been well established, Bob expects that the Python file is _equivalent_ to the GRC file (which it isn't). He tries to re-synthesize and run the Python file, which doesn't do anything useful. This leads to confusion on Bob's side. I think it'd be a nice idea to have a bundle file type (which would then take the shape of a python file containing the xml as a string), but not make it available as default. There is a factual difference between a GRC file and a GNU Radio application, and I don't think we do our users a favour if we blur this line. I think what this whole agreement that it'd be nice to have the GRC bundled with the python code stems from the fact that there are might be a lot of python files out there generated by GRC but the .grc files are not available to the public. (Which -- from my perspective -- is not too true; there are a lot of obsolete GRC files out there that hardly tell you what they did before block naming changed. The proposed scheme doesn't solve that.) This is more of a community / communication / platform problem than a GRC issue. Greetings, Marcus On 03.12.2013 14:25, Raydel Abreu (CM2ESP) wrote: > That will easy a lot the problem in the future. It seems > interesting and I guess it won't be too hard to implement! > > Raydel > > > 2013/12/2 Dan CaJacob <[email protected]> > >> I have an interesting (to me anyway) idea: >> >> What if we added a default option to the GRC-XML-to-python >> converter to add the contents of the original GRC file as a big, >> delineated comment blob. Then, a simple tool could pull the GRC >> back out of the python file anytime and you could go back and >> forth. An option when building would disable the verbose output >> for those publishing code or who just don't want the extra >> cruft. >> >> It's a little lame, but it solves the problem. I know I've had >> to hand-craft many old GRCs from python files when the original >> GRC was lost or the originator was other than myself. The >> problem has often crept up with GRCs not properly updated for new >> versions of code, where the blocks go missing in the GRC >> representation (I think there was talk of fixing this - graying >> them out or something). >> >> Very Respectfully, >> >> Dan CaJacob >> >> >> On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech <[email protected]> >> wrote: >> >>> Think of the Python that gets emitted by GRC as object code. >>> What you're asking is to convert said object code back into >>> reasonable source code. >>> >>> Such things exist for *actual* machine object-code, but, they >>> produce damned-ugly results. >>> >>> on Dec 02, 2013, *Raydel Abreu (CM2ESP)* <[email protected]> >>> wrote: >>> >>> Oh, that's bad, I guess I should use instead the old >>> code-reading method.... >>> >>> Raydel >>> >>> >>> 2013/12/2 Marcus Leech <[email protected]> >>> >>>> There's no automatic mechanism for doing that. >>>> >>>> >>>> on Dec 02, 2013, *Raydel Abreu (CM2ESP)* <[email protected]> >>>> wrote: >>>> >>>> Hello, >>>> >>>> Is it possible to go back and convert a Python GNU Radio code >>>> back into the GRC Flow Graph from which it was generated? >>>> >>>> Cheers, >>>> >>>> Raydel, CM2ESP >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > > > > _______________________________________________ Discuss-gnuradio > mailing list [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSneADAAoJEAFxB7BbsDrLptMH/0YekQtGqESHefeDcYED1AHb IIppUKW3srBOkTJ16gLqJaqApse5Qxm0yqmG8Ph/3R5qeuAY7RZFn06wkVJ0exWq SndU02omQ1XnOcx3Q2K9Foz4zwcvn3FTLR1f5XMi7U9aA+eiIESqGCvbzPXCZ6l9 jYHDNZ53BqT5/7Ix78NnttxEZkq+naqnojMTzExvTq+vU/CpUabvE0ol6xjPsbsU SzTVpLBYUeyqGaUtnY3lRvSgE7oy6W2Z+9KYSUj/v2YMw1HEjXNbI+2aL9MpnIS1 o9RUD9hyour13qU1XlvWKZsrh6hotBFwmFypxzOXZC6VnqDnDFKIMiJ9bUIDgVE= =vc8u -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
