Thu 13 Feb 2014 05:35:44 AM UTC, comment #11:
I pushed this change, with just one more test added to what I had attached here:
http://hg.savannah.gnu.org/hgweb/octave/rev/2bd78ab75b23
This will be part of the Octave 4.2 release.
|
Tue 11 Feb 2014 05:09:34 PM UTC, comment #10:
Thanks, I'll polish that (add another test case or two and comments) and push it to the default branch (since it changes the results of the which function under certain conditions, not suitable for the stable branch).
|
Tue 11 Feb 2014 04:27:10 PM UTC, comment #9:
Hi Mike, it's indeed much simpler and returns the same results :-)
|
Tue 11 Feb 2014 01:27:04 PM UTC, comment #8:
Hi Pantxo, sorry for not posting on this bug report earlier and duplicating effort, but I have a simpler diff that I worked up one day a couple weeks ago but hadn't yet finished. Can you look at and test the attached and let me know if it does the same for you? I think it should suffice.
(file #30510)
|
Tue 11 Feb 2014 11:51:02 AM UTC, comment #7:
I have given a try to solve this issue, see attached patch.
In order to find if a symbol exist as a variable, we need to have access to the caller variable scope. I rewrote which as a builtin DEFUN (_wich_ in help.cc becomes which) so that the function is run in the caller scope.
I know that the policy is to have as much functions defined in .m files as possible, but I couldn't find another way to have access to the callers workspace (plus most part of the job is already done in _which_).
The patch is not complete as it makes the build process fail whith the following error
(file #30509)
|
Tue 11 Sep 2012 07:51:14 PM UTC, comment #6:
Octave has no professional development staff. If you want something changed the best course is to submit a patch which implements what you are looking for. The patch will be reviewed and, if accepted, entered into the code base.
Attacking me personally will not change that course of events.
|
Tue 11 Sep 2012 07:15:19 PM UTC, comment #5:
"Per your desire" - sorry, it's a blatant lie, and your participation in this bug report is an exercise in hypocrisy.
This is twice a big:
1) documentation contradicts actual behavior;
2) Octave actual behavior contradicts Matlab actual behavior.
I am really sorry I filed this bug report per advice of Octave help mailing list.
Such an attitude to bug reports is the best repellent for those who intend to file bugs - it's really a pity to spend one's energy proving obvious things that a bug is a bug.
|
Tue 11 Sep 2012 02:48:46 PM UTC, comment #4:
Per your desire, this issue has been changed to "Documentation" from "Feature Request".
The function 'which' is implemented as an m-file in which.m. It is therefore easy to modify the help string and submit a patch to resolve this issue. It would probably also be useful, when creating the patch, to put a @seealso reference to the function exist().
|
Tue 11 Sep 2012 10:49:22 AM UTC, comment #3:
This is not a feature request, this is a plain bug.
In my very first post there is an excerpt from 'help which', and it says: "Display the type of each NAME".
I.e. expected behavior is: 'which' is supposed to display types.
Actual behavior is: it doesn't.
It's either a bug in 'which' code or in its documentation, or both.
But it is a bug.
|
Tue 11 Sep 2012 07:06:30 AM UTC, comment #2:
Just for reference, Matlab r2012b prerelease (empty lines in output removed):
...and ML r2007a (> 5 years old)
... so this change hasn't recently been made by TMW.
|
Mon 10 Sep 2012 09:24:49 PM UTC, comment #1:
Yes, apparently Mathworks has extended the functionality of which to report whether NAME is a variable. I have changed the item group to Matlab Compatibility and changed the severity to 1-Wish.
For equivalent functionality try
|
Mon 10 Sep 2012 08:41:54 PM UTC, original submission:
Please see the following ("which foo" produces nothing) :
.
A member of Octave help list claims "which foo" for the 'foo' above works in Matlab.
Thanks,
Sergei.
|