I was using FC7(32-bit) and GRC 0.69 for a little while. I too noticed
GRC closing completely, but I do not have enough details to back-up
your exact pattern. Come to think about it though, it happened more
often than not in graphs that had a lot of sinks in them…
I have not used GRC in some time, but I do have to say that if it
doesn’t exist already, it would have been nice to have access to the
code of the actual graph that was being created. Something like an
“export to .py” or if you really wanted to win my heart a gnu-radio
3.2 “export to c”.
Hello,
On Jan 17, 2008 1:56 PM, Jeffrey K. [email protected] wrote:
I was using FC7(32-bit) and GRC 0.69 for a little while. I too noticed
GRC closing completely, but I do not have enough details to back-up
your exact pattern. Come to think about it though, it happened more
often than not in graphs that had a lot of sinks in them…
Strange. I have been running GRC on ubuntu and never noticed this.
Flow graphs are run with os.system(“./ExecFlowGraphGUI.py
myflowgraph.xml”). So the flow graph is running as a separate process.
The stop button in GRC calls a kill -9 on the pid of this process.
Perhaps this has something to do with the flowgraph begin executed
from the same shell as GRC.
May I ask what version of python 2.4, 2.5, 3?
Is there someway to make this more robust?
In the meantime, you can run ./ExecFlowGraphGUI.py myflowgraph.xml
manually in a separate shell (should help).
I have not used GRC in some time, but I do have to say that if it
doesn’t exist already, it would have been nice to have access to the
code of the actual graph that was being created. Something like an
“export to .py” or if you really wanted to win my heart a gnu-radio
3.2 “export to c”.
Good news then: I plan to work on GRC this semester. One of the goals
is to generate the .py files. To do this, I will turn grc into a
module that actually has to appear in the python path, such as “import
grc”. This module will contain custom signal blocks and wrappers for
some of the blocks.
I suppose, once that all works, there could be a separate set of block
definitions for c++ blocks, and one could make flow graps in GRC and
export it to cpp. As long as the GUI is general enough.
If any one has any wishlist requests, let me know.
-Josh
On Jan 17, 2008, at 2:04 PM, Josh B. wrote:
Strange. I have been running GRC on ubuntu and never noticed this.
Flow graphs are run with os.system("./ExecFlowGraphGUI.py
myflowgraph.xml"). So the flow graph is running as a separate process.
The stop button in GRC calls a kill -9 on the pid of this process.
Perhaps this has something to do with the flowgraph begin executed
from the same shell as GRC.
May I ask what version of python 2.4, 2.5, 3?
Josh,
I tried grc on a Fedora Core 6 installation, Python 2.4, and see this
crash (sometimes, maybe even “usually”) when the graph has been
edited. I don’t think it ever crashed on a run where the graph hadn’t
been changed.
Steve
On Jan 17, 2008, at 3:35 PM, Steve Bunch wrote:
I tried grc on a Fedora Core 6 installation, Python 2.4, and see
this crash (sometimes, maybe even “usually”) when the graph has been
edited. I don’t think it ever crashed on a run where the graph
hadn’t been changed.
Josh,
Followup: retrying grc on Fedora 8 (Python 2.5), Core 2 quad, 32-bit,
recent installation of GNURadio 3.1svn, grc from svn current, I have
no crashes observed in dozens of edits and reruns of a previously-
often-failing graph.
Steve
On Friday 18 January 2008 09:20:55 Steve Bunch wrote:
no crashes observed in dozens of edits and reruns of a previously-
often-failing graph.
G’day,
I’ve rebuilt and installed GNU Radio svn-7461 as of today on a system
running
python-2.4.4 and swig-1.3.31. It still crashes when started and stopped
a few
times, three times in this particular case, with message shown below.
This
was using example noisy_sinusoid.grc.xml application provided by the GRC
package. This is reproducable at will. Note the “TypeError: ‘str’ object
is
not callable” and the message just prior to the coredump.
barossa: {18} ./Editor.py …/examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! -> continuing…
No module named serial in RS232 Sink! -> continuing…
Removing empty category “Custom”…
<<< Welcome to GRC 0.69 >>>
Loading: “…/examples/noisy_sinusoid.grc.xml”
Done
Showing:
“/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml”
Executing:
“/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml”
No module named serial in RS232 Source! -> continuing…
No module named serial in RS232 Sink! -> continuing…
Removing empty category “Custom”…
Verbose:
Traceback (most recent call last):
File “/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py”, line
248,
in ?
exit(0)
TypeError: ‘str’ object is not callable
Done
Executing:
“/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml”
No module named serial in RS232 Source! -> continuing…
No module named serial in RS232 Sink! -> continuing…
Removing empty category “Custom”…
Verbose:
Traceback (most recent call last):
File “/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py”, line
248,
in ?
exit(0)
TypeError: ‘str’ object is not callable
Done
Executing:
“/home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml”
No module named serial in RS232 Source! -> continuing…
No module named serial in RS232 Sink! -> continuing…
Removing empty category “Custom”…
Verbose:
Traceback (most recent call last):
File “/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py”, line
248,
in ?
exit(0)
TypeError: ‘str’ object is not callable
/home/wulf/projects/gnuradio/grc/src/ActionHandler.py:68: GtkWarning:
Invalid
text buffer iterator: either the iterator is uninitialized, or the
characters/pixbufs/widgets in the buffer have been modified since the
iterator was created.
You must use marks, character numbers, or line numbers to preserve a
position
across buffer modifications.
You can apply tags and insert marks without invalidating your iterators,
but any mutation that affects ‘indexable’ buffer contents (contents that
can
be referred to by character offset)
will invalidate all outstanding iterators
gtk.main()
Segmentation fault (core dumped)
barossa: {19}
cheerio Berndt