Tue 22 Aug 2017 03:20:49 AM UTC, comment #11:
I haven't looked at the details yet but this breaks doctest.
https://github.com/catch22/octave-doctest/issues/167
I'll see if I can track it down further later, see if we (doctest) are doing something wrong...
|
Wed 09 Aug 2017 06:26:30 PM UTC, comment #10:
Understood.
Re your question, it was just for added convenience. Here's one example where I use this:
For example, I'm used to things like
structunmakemy(s)
which unpacks its fields in the current scope.
I should switch to something like
unpackfields("s", fieldnames(s){:});
|
Wed 09 Aug 2017 06:07:23 PM UTC, comment #9:
The problem is that assignin (or eval, or load) can create variables. That causes trouble for lookup of non-local names. If you want things to work properly, then write it like this:
But I have to ask, why do you want to use assignin here instead of just writing
|
Wed 09 Aug 2017 05:42:09 PM UTC, comment #8:
(reposting, with corrected verbatim tags.)
Does this mean that things like these will stop working? In the example below, I use _setM to set M. _callsub works on a separate K.
But, main() still wants to rely on _setM for setting a separate M.
In other words, I was very happy with your explanation and understood that _callsub() won't have access to M, and that _callsubs should only work on K's set within the body.
But, my main() still wants to rely on _setM to set a lot of other /unrelated/ variables. Will that now stop working?
|
Wed 09 Aug 2017 05:26:49 PM UTC, comment #7:
Does this mean that things like these will stop working? In the example below, I use _setM to set M. _callsub works on a separate K.
But, main() still wants to rely on _setM for setting a separate M.
In other words, I was very happy with your explanation and understood that _callsub() won't have access to M, and that nested functions should only work on K's set within the body.
But, my main() still wants to rely on _setM to set a lot of other /unrelated/ M variables. Will that now stop working? :(
<verbatim>
function main();
_setM();
(do stuff with M here)
K = 2;
_callsub_on_K();
function _callsub();
K +=3 ;
endfunction
endfunction
function _setM();
assignin("caller", "M", 1);
endfunction
</verbatim>
|
Wed 09 Aug 2017 05:15:16 PM UTC, comment #6:
I pushed the following changeset so now you should see an error at the point where variable creation is attempted:
http://hg.savannah.gnu.org/hgweb/octave/rev/4b0e0cae49db
|
Wed 09 Aug 2017 04:54:19 PM UTC, comment #5:
John,
Understood. Thanks for explaining.
Dave
|
Wed 09 Aug 2017 11:34:25 AM UTC, comment #4:
I think we already tag these workspaces as "static" for the JIT compiler, but the parse tree evaluator doesn't use that info. We should probably fix that so we can give a better diagnostic.
|
Wed 09 Aug 2017 11:32:38 AM UTC, comment #3:
I'm not sure we should attempt to support assignin uses that add variables to nested function scopes. From the following documentation, it seems that this is explicitly disallowed in Matlab:
https://www.mathworks.com/help/matlab/matlab_prog/variables-in-nested-and-anonymous-functions.html?s_tid=gn_loc_drop
The reason it works when you add the "disp (K)" in the testmy function is that then the variable name is present in the symbol table when the function is parsed, not just added later when the function is executed.
|
Wed 09 Aug 2017 11:25:03 AM UTC, comment #2:
Reposting with verbatim tag so we don't have to rely on pastebin data...
|
Wed 09 Aug 2017 05:12:04 AM UTC, comment #1:
It messed up the indentation. Here it is for better readability:
https://pastebin.com/HgUSAZ5A
|
Wed 09 Aug 2017 05:10:46 AM UTC, original submission:
I'm using 4.2.1 on debian via stretch-backports.
Nested function fails to inherit a variable. Below, _callsub, a nested function, says that K is unknown.
function testmy();
_setK();
_callsub();
## disp(K) uncommenting this removes the bug!
function _callsub();
disp(K) ## says that K is unknown!
endfunction
endfunction
function _setK();
assignin("caller", "K", 1);
endfunction
|