My question is about tf.function-decorated function which complains about that variable is used twice ?
ValueError: tf.function-decorated function tried to create variables on non-first call.
How can i debug this in colab/jupyter notebook to get the name of this variable?
You should give a look this section of this article - it contains the description of the problem you're facing right now.
In short, you're defining inside a function a tf.Variable (one or more). Even though you call this function only once, tf.function executes the function more than 1 time to convert it to its graph representation, making tf.function raise the exception you're getting.
You have to refactor your code in order to declare any variable outside the function body. At the time of writing, there is no way to know which variable caused the error (since ever tf.Variable declared in the object would make tf.function to raise the same error)
Related
I would like to modify an Xcos block from within a gateway function using the new (non-legacy) Scilab API, for example, replace the block's model property by a new model structure. In other words, do the same as the Scilab command(s):
m = scicos_model()
block.model = m
However, I did not manage to achieve this behavior with the functions from Scilab 6 API: a block created by standard_define() is correctly passed to my gateway function, where this argument is available as scilabVar of type 128. On the other hand, the Scilab help claims that a block is a "scilab tlist of type "Block" with fields : graphics, model, gui and doc".
Attempts
Assume scilabVar block taken from gateway function argument, string constants of type wchar_t[], scilabVar model holding the result of scicos_model():
Application of function scilab_setTListField (env, block, "model", model) returns error status (as its equivalents for MList and List do)
Knowing that property .model is at index 3, a setfield (3, model, block) called through scilab_call ("setfield", ...) also fails.
This is not surprising: when called directly from the Scilab command line, it ends up with
setfield: Wrong type for input argument #3: List expected. .
However, a getfield (3, block) works, so that at least read access to the block's data fields is possible.
An external helper function
function block = blockSetModel (block, model)
block.model = model
endfunction
also called through scilab_call("blockSetModel", ...) actually returns a block with changed model,
but the original block passed to this function remains unchanged.
Although ugly, this gives at least a way to construct an individual block structure
which needs to be returned as a copy.
Summary
So, is there simply a function missing in the API, which returns the TList (or whatever) behind a type 128 pointer variable?
Or is there any other approach to this problem I was unable to discover?
Background
The goal behind is to move the block definition task from the usual interfacing "gui" function (e.g. a Scilab script MyBlock.sci) into own C code. For this purpose, the interfacing function is reduced to a wrapper around a C gateway, which, for example, usesscilab_call ("standard_define",...) to create a new block when being called with parameter job=="define".
Modification of the contained model and graphics objects through the Scilab API works fine since these are standard list types. However, getting or setting these objects as attributes .model and .graphics of the
original block fails as described above.
Starting from Scilab/Xcos 6.0.0, the data-structure behind a block is no more an MList (or TList) so you cannot upgrade the model to your own MList. All the data behind are stored using a classical MVC within a C++ coded Block.hxx.
On each try you made, a serialization/deserialization happens to reconstruct the block model field as a Scilab value.
Could you describe what kind of field you want to append/edit regarding the block structure ? Some of the predefined fields might be enough to pass extra information.
I'm trying to display "number of items on the output stream" in the flowgraph.
Is there a way to access the function: block__nitems_written(unsigned int which_output) from the flowgraph?
So far I have tried "from gnuradio import gr" and then use gr.block__nitems_written(0) as a value in a variable. The error I get is:
module object has no attribute block__nitems_written.
I think I am not calling the function properly. Any help will be appreciated!
You're confusing things! That's not a property of a flow graph.
Each block has its own number of items that it's written to its output ports.
Hence, it's a method of gr.block, which you can only call with a block instance, i.e. typically as self.nitems_written(0) within a block's work method.
How can we tell if the calling of $cast is of a function or of a task. How would calling of each differ? One thing I understand is that with the function call, I'll be able to use assert(). But other than that, what tells us if the call is of the $cast function or the $cast task? In either case, we'd be doing something like $cast(pkt, pkt1);
LRM gives the syntax of the $cast function as
function int $cast( singular dest_var, singular source_exp );
and of the $cast task as
task $cast( singular dest_var, singular source_exp );
and goes on to explain that
Use of $cast as either a task or a function determines how invalid assignments are handled.
When called as a task, $cast attempts to assign the source expression
to the destination variable. If the assignment is invalid, a run-time
error occurs, and the destination variable is left unchanged.
When called as a function, $cast attempts to assign the source expression
to the destination variable and returns 1 if the cast is legal. If the
cast fails, the function does not make the assignment and returns 0.
When called as a function, no run-time error occurs, and the
destination variable is left unchanged.
Please explain.
Your comment is correct: if $cast is used as part of an expression, it is considered called as a function. That wording is derived from Verilog terminology when functions could only be used in an expression and never could exist as a simple statement like a task call. But once SystemVerilog added functions with void return types, that wording does not fit as well anymore.
The variable scope behavior seems quite strange. The code block
tp = 1
function test2()
println(tp)
end
works perfectly well while
function test()
if tp==0
tp=tp-1
end
end
gives the exception "tp not defined". What is wrong?
This is tricky due to the way variables are implicitly defined as local or global, and the fact that definitions later in a function can affect their scoping in the whole function.
In the first case, tp defaults to being a global variable, and it works as you expected. However, in the second case, you assign to tp. This, as is noted in the scope of variables section of the manual:
"An assignment x = y introduces a new local variable x only if x is neither declared global nor introduced as local by any enclosing scope before or after the current line of code."
So, by assigning to tp, you've implicitly declared it as a local variable! It will now shadow the definition of your global… except that you try to access it first. The solution is simple: explicitly declare any variables to be global if you want to assign to them:
function test()
global tp
if tp==0
tp=tp-1
end
end
The behavior here is finely nuanced, but it's very consistent. I know it took me a few reads through that part of the manual before I finally understood how this works. If you can think of a better way to describe it, please say something!
i'd like to know if there is any possibility to read out dynamic variable names?
Since the programm that passes the variables to my script calls them just "in1, in2, in3" etc.
Hopefully there is any way to make a loop, because it is pretty annoying to handle every input separately...
Here is what i've tried so far, but it just gives me an error.
for i=1,19,2 do
myvar[i] = ["in"..i]
end
I'm quite new to Lua, but i hope the solution is not that difficult :D
Edit:
Oh I'll try to give you some more information. The "Main" Program is no not written in Lua and just set theese "in1 ... " variables. It is a kind of robotic programmic software and has a lot of funktions build in. Thats the whole thing so i can not simply use other variable names or an array. So it is not a function or anything else related to Lua...
Here is a little Screenshot http://www.bilderload.com/daten/unbenanntFAQET.jpg
At the moment the Lua script just passes the the first input.
It depends on what you mean by "dynamic variable names."
The names of local variables do not exist. Local variables are any variable declared as a function parameter or with the local keyword. Local variables are compiled into offsets into the Lua stack, so their names don't exist. You can't index something by name to get them.
Global variables are members of the global table. Therefore, these ways to set a global variable are equivalent:
globalVar = 4
_G.globalVar = 4
_G["globalVar"] = 4
Since the programm that passes the variables to my script calls them just "in1, in2, in3" etc.
The program that passes variables to your script doesn't get to name them. A variable is just a placeholder for a value. It has no ownership of that value. When your function gets arguments, your function gets to name them.
You haven't said much about the structure of your program, so I can't really give good advice. But if you just want to take some number of values as parameters and access them as inputs, you can do that in two ways. You can take a table containing values as a parameter, or you can take a varargs:
function MyFunc1(theArgs)
for i, arg in ipairs(theArgs) do
--Do something with arg.
end
end
function MyFunc2(...)
for i, arg in ipairs({...}) do
--Do something with arg.
end
end
MyFunc1 {2, 44, 22} --Can be called with no () because it takes a single value as an expression. The table.
MyFunc2(2, 44, 22)
Whoever wrote the code that spits out these "dynamic variables" didn't do a good job. Having them is a bad habit, and might result in data loss, cluttering of the global name space, ...
If you can change it, it'd be much better to just output a table containing the results.
That said, you're not to far off with your solution, but ["in"..i] is no valid Lua syntax. You're indexing into nothing. If those variables are globals, your code should read:
for i=1,19,2 do
myvar[i] = _G["in"..i]
end
This reads the values contained by your variables out of the global table.
Try this
myvar={ in1, in2, in3, in4, in5, in6, in7, in8, in9, in10, in11,
in12, in13, in14, in15, in16, in17, in18, in19 }
if the variables are passed as global variables, or this
myvar = {...}
if the variables are passed as arguments to the script.