Hi Andreas, On 06/05/2015 12:51 PM, Andreas Ladanyi wrote: > Hi Marcus, > >> Dear Andreas, >>> How is it possible to fill a python grc variable block with data from >> another block C++ variable. >> not really. GRC variables are a concept that doesn't exist in the flow >> graph or, really, in the python file that GRC generates. They just are >> python variables used when setting up the block > Setting up means to insert the block in the flow graph and configure > them ?! >> , and if they are used in >> a field for which the block specified a callback method, that method >> will be included in a python function that gets called by blocks that >> GRC knows can change variables (e.g. GUI input elements); this mechanism >> of calling the callbacks doesn't really work without special glue; > ok and this glue (swig file) is produced by a process triggered by the > make command in a gr_modtools environment ? There's more glue involved than just swig here. Again, all the magic that happens behind the curtain can be found when you read the generated python code. You'll notice that for some graphical input elements, there are functions defined that these input widgets get instructed to inform as soon as things change. That works because the GUI toolkits allow for this kind of callback-emulation. > > How can i tell gr_modtools or make to produce a callback function or > howto program a callback function in the C++ code and the <callback> > xml tag in the block xml file myself for my own block so a grc python > variable name from flow graph could be inserted in a field of my new > block later when configuring my new block in the flow graph ? Not at all. You'll need to analyze the way the XML blocks for example of the qtgui widgets are written, and what the generated python code looks like, and then you'll have to manually copy that. >> >> I heartily invite you to do this the "GNU Radio way": Using message >> passing as the way to exchange information between blocks inherently >> solves the multithreading problems that otherwise would arise (for >> example, assume you'd be able to change the taps of a FIR whilst that >> FIR's work() function is working; what's the correct behaviour? How do >> you avoid segmentation faults when the new taps are shorter than the old >> ones?). Also, it lets users understand where data/commands flow rather >> than hiding that behind a variable name. > Yes i read the message passing chapter and the pmt and will go in > detail later. Really, do it sooner than later; I do like variables as a means of thinking when constructing my flow graph, they are O.K. for GUI widgets, but things get ugly the moment you really want to use them from within a block -- as you might have noticed :) GRC variables originally were really meant only to be used by python during flow graph creation, and the whole dynamic reconfigurability of variables at run time came later, but before message passing worked the way it does now -- if I may throw in wild speculation, I'd assume that if GRC was re-invented today, it would just set up a message handler for each block using a variable, and just allow the block author to specify what happens in that message handler, as well as forcing every variable-changing block to have a message output port; but: GRC has been around for quite some time, and its maintenance is a remarkable effort, plus people get slightly irritated when their block XML stops working.
Is there a particular reason why you wouldn't use messages? If you need to use a block that doesn't take instructions via messages, write a hier block that accepts messages from the blocks inside of it, and translates them into getter/setter calls on other blocks; or, better even, if you think the block you want to use would profit generally from having a message port for commands/settings, fix that up-stream. There's virtually no overhead to having a message port/handler! Best regards, Marcus _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio