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
Oh, that’s bad, I guess I should use instead the old code-reading
method…
Raydel
2013/12/2 Marcus L. [email protected]
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
gzip -> base64 encode the grc file into some comments in the python file
perhaps?
a smallish grc file appears to be on the order of 1000 chars with such
an encoding
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]
-----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:
What if we added a default option to the GRC-XML-to-python
problem has often crept up with GRCs not properly updated for new
wrote:Raydel, CM2ESP
mailing list [email protected]
Discuss-gnuradio Info Page
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frankly, if you really want to inline the GRC file in the generated
python, I’d just have one large multiline Python string holding that
file as-is. With a little magic you could even let the python program
re-synthesize itself given a certain command line argument.
Anyway: I can’t imagine how the single-line-comment will not clutter
the source code tremendously and make it hard to read and build upon
(which is what I use GRC mainly for).
I think the main problem with GRC-generated python is not the fact
that it’s hard to recraft (unless your GRC graphs span multiple
screens and you run out of pencil retracing that on paper), but the
fact that due to progress, block names change between releases, and so
do arguments; thus, reading the source code often brings more clarity
than looking at a half-decapitated flowgraph, even when it’s embedded
in the source.
Greetings,
Marcus
On 02.12.2013 23:22, Tim wrote:
back out of the python file anytime and you could go back and
them out or something).
What you’re asking is to convert said object code back intomailto:[email protected]> wrote:
_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSnYc5AAoJEAFxB7BbsDrLcP8H/1GqveUwP02dqD0TtX0ZhADM
nSUd/HOx/rGqC1ATHq1vItKTv98spB0ZVf2EUCyOZK5uvES2YMu8KqrTUXemchzH
93nwJ6/Z2apAYAccRtpf5r83Cx9DRyKwUlR4KvW3LBVmqlgYbFE3eYgG2mmsDODz
VgOqgg+fcMQQP+h0rsETiCHb8kN/STayPp6iVxsLDSXlTXKqNu4yXZfy5WvCQOm/
C6Lj3R7DXMKVJEcs/Z0KYvHIYdaK6fVLjsp9ltwDe5qqQaZPkOs+YnJKur3ND++F
ayDdmySX5PevAeSJLsRmFWmOh62sI03JyP4NjYiE+kOS5te/hakqA1qiyFOWfbc=
=xJtK
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 05.12.2013 22:47, Sebastian Koslowski wrote:
Oh that feels nice, thank you.
Ok, let’s say the whole file minus prologue - there is a timestamp in
there 
Thinking about that, I realize what could be useful would be a
screenshot of the flowgraph, displayed when using a certain command
line flag on the python file, just to give people an idea what the fg
looks like. It could blow up file size by up 100kB (assuming
moderately large flowgraphs), but embedding the png and displaying it
on command would seem nice, and “fairly easy”* to implement.
Greetings
Marcus
*“fairly easy” is a trademark of the devil inc.; no liability is taken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSoYWcAAoJEAFxB7BbsDrLkesH/ij0LmJ+EzR5BEQi5LnWD+wp
dolxqjXEwIEfrHLQAQiWh/GYNi5rP8RgH+acx7LwNeetzYuVq2yXaTJl4OTgFo2/
BsVvSgWAMGCHDdnPb2bu+Kq2JJtRIXEc2pC8cf8cOhyOzTenusy3SwEkadO/P5u8
XDNwapPEmdxei1HRz+axjqHZPa48ro8YoYBH5txYEWe+1Oj3EYDHxN/a1LSpSlfs
h0Ly/ay9aeDfyAfunwDEZH2/R1kPH2+bd2erRxSJJoVqKJX0FBCiALMqiidUQcBB
WZnnS2eIaDebd3fevZMejrVS5ySzqkgoPNjW3pSv+ddbmC055wKTxse02Fq1NRo=
=gZWk
-----END PGP SIGNATURE-----
Hi,
I tend to agree with Marcus - if anything, this should be an opt-in
feature. I would prefer a combination of a setting per flowgraph or
generate.
As for the issue with modified python code: this could be easily caught
with a hash over the whole file. On (re-)import an automated
re-synthesize and diff could be used to analyze what changed.
On 12/03/2013 02:43 PM, Marcus M. wrote:
This is more of a community / communication / platform problem than a
GRC issue.
Very True.
Sebastian
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Sebastian Koslowski
Research Associate
Kaiserstrae 12
Building 05.01
76131 Karlsruhe, Germany
Phone: +49 721 608-46275
Fax: +49 721 608-46071
Email: [email protected]
Web: http://www.cel.kit.edu/
KIT University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Sebastian Koslowski
Research Associate
Kaiserstrae 12
Building 05.01
76131 Karlsruhe, Germany
Phone: +49 721 608-46275
Fax: +49 721 608-46071
Email: [email protected]
Web: http://www.cel.kit.edu/
KIT University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association
On 12/06/2013 09:06 AM, Marcus M. wrote:
Ok, let’s say the whole file minus prologue - there is a timestamp in
there
…
Thinking about that, I realize what could be useful would be a
screenshot of the flowgraph, displayed when using a certain command
line flag on the python file, just to give people an idea what the fg
looks like. It could blow up file size by up 100kB (assuming
moderately large flowgraphs), but embedding the png and displaying it
on command would seem nice, and “fairly easy”* to implement.
Hm, this sounds more like something that should go in some
“Export/Publish” feature than a mode of saving. Bundling a grc file,
it’s screenshot and a synthesized python. I’m not sure if python is the
right container format.
Sebastian
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Sebastian Koslowski
Research Associate
Kaiserstrae 12
Building 05.01
76131 Karlsruhe, Germany
Phone: +49 721 608-46275
Fax: +49 721 608-46071
Email: [email protected]
Web: http://www.cel.kit.edu/
KIT University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sounds like instead of having an “export to bundle file” we should
have a “export to my github account, notify a flowgraph directory”
button.
On 06.12.2013 21:14, Koslowski, Sebastian (CEL) wrote:
what the fg looks like. It could blow up file size by up 100kB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSojHgAAoJEAFxB7BbsDrLJKMIAJLa4xeQdw1SOd/KCacalXR4
uKavMtuVpTXexi4HG/4nsndL2R9dGcB8YYz/mMFegbZksh+vNiWSotSVM8b+qASL
F7z/IZz3IImebw5YeIu8iFXkMu9M7K6otxA93D01ydRzmrufq02sKhQQOOvHGAhh
m00dgb3kj/g9kYbVuiA6u7YAXuA9frVUo5LSmx2Luw2edSkK0SVZ1BJDBhCXuOtG
qfIdN7J9gJecq2CTWFgah930IqLGP7z4b67d0dwGc5/7w9Q6bIdAikcQdUM9Un8n
S4MMjpTWZnfBZiA/o7Hl/55V9PShvezs3HheMiOGQz/HYgSXfHyFlO7UMfGxHOs=
=64c3
-----END PGP SIGNATURE-----