Tue 15 Aug 2017 05:05:20 PM UTC, comment #8:
I made a few changes here (http://hg.savannah.gnu.org/hgweb/octave/rev/185f850aa543). The issue was that we were asking people to experiment with using different numbers of input and output arguments and they could see how that was communicated to nlhs and nrhs. However, if they did experiment with more than 0 outputs then the code would produce an error which isn't very user-friendly. They might think they had not understood the example, or not coded it correctly.
I think this issue has been resolved so I'm going to close this report.
|
Tue 15 Aug 2017 03:08:47 PM UTC, comment #7:
I looked and I don't see anything to fix. I don't see where we show any examples of calling functions with more outputs than they produce and expecting things to work. Did I miss something?
If we want to document this behavior, then it seems like it belongs in more introductory material or in the description of how functions or [x,y,...] = foo () assignment statements work, not in the .oct and .mex file guide.
|
Tue 15 Aug 2017 02:34:03 PM UTC, comment #6:
OK, I can take a look at fixing those things.
|
Tue 15 Aug 2017 02:11:40 PM UTC, comment #5:
Seems reasonable to be Matlab-compatible in this regard as it is generally easier on the programmer if the interpreter stops as close to the location in the code where an error occurred. Having an undefined value and propagating it through several m-files before something eventually fails is unfriendly.
Alas, it also creates some more work. The documentation and code examples in Appendix A : External Code Interface now need to be updated as helloworld.cc, myhello.c, mex_demo.c all produce errors now when called with multiple outputs.
|
Tue 15 Aug 2017 01:10:12 PM UTC, comment #4:
I checked a set of changesets that should address this issue:
http://hg.savannah.gnu.org/hgweb/octave/rev/85488effc0ff
http://hg.savannah.gnu.org/hgweb/octave/rev/47c44b822d11
http://hg.savannah.gnu.org/hgweb/octave/rev/7662b441e2ea
The first should fix the problem with attempting to print undefined values returned from functions. It also considerably simplifies returning values from functions, so I hope it improves performance, if only slightly. It also changes the behavior of Octave: now outputs that are not initialized in a function are left undefined instead of being set to []. And attempting to assign an undefined value returned from a function is an error. So I fixed one place where that was a problem and also eliminated the now unused Octave::undefined-return-values warning ID.
|
Tue 15 Aug 2017 12:27:17 AM UTC, comment #3:
Yes, totally agree about the error not making sense.
|
Tue 15 Aug 2017 12:26:17 AM UTC, comment #2:
Octave usually just issues a warning, rather than a full error for this situation. Even if an error was to be printed, it should be something reasonable rather than something strange about wrong_type_argument.
I tried this, but unfortunately it didn't work.
|
Mon 14 Aug 2017 11:50:14 PM UTC, comment #1:
I do see your point however, the Matlab output for this file is:
So an error would make sense (if we want to Matlab compatible in this respect).
|
Mon 14 Aug 2017 11:28:41 PM UTC, original submission:
Since this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/2e4033e1f28f) the MEX interface returns undefined objects rather than empty matrices ([]) for unused outputs. It is Matlab compatible that these objects be undefined, however it causes problems back in Octave.
Example code is taken from mex_demo.c in the examples/code directory.
Compile and then run
It seems like Octave might need to prune the octave_value_list that is returned to only non-null values.
|