Tue 24 Jul 2012 05:25:30 PM UTC, comment #13:
I checked in the following change:
http://hg.savannah.gnu.org/hgweb/octave/rev/ff9a638a5555
I changed the variable name, but left the line long. It doesn't bother me too much if arguments to warning and error are not split. Instead of breaking them, I'd rather see them short enough to fit in one line, but I don't see how to express this warning in a shorter way. But either is OK with me, and both are better than inserting newline characters in warning or error messages.
Oops, I just noticed I forgot to put the bug number in teh commit message.
|
Tue 24 Jul 2012 05:00:12 PM UTC, comment #12:
The patch looks good to me. As a matter of aesthetics, shouldn't the variable be "elts_set" not "elts_map"? Also, you don't like to split long strings to adhere to an 80-column limit?
|
Wed 18 Jul 2012 10:12:32 PM UTC, comment #11:
Oops, I uploaded the wrong patch. The correct one is now attached to this comment.
(file #26218)
|
Wed 18 Jul 2012 10:10:35 PM UTC, comment #10:
I think the attached patch will provide the warning and preserve the correct path ordering when using "path (some_new_path)". If sosd, then I can add a commit message and commit the change.
(file #26217)
|
Thu 10 May 2012 12:33:03 AM UTC, comment #9:
Somebody (I forget who) confused path with addpath, so they did path("foo") and deleted their path and broke their Octave session and didn't know how to get it back. I made this change in order to warn when this happened.
|
Thu 10 May 2012 12:13:08 AM UTC, comment #8:
Jordi, I vaguely remember this change. What was the problem that prompted it?
|
Wed 09 May 2012 11:56:39 PM UTC, comment #7:
Would you help me fix this? This is the cset where I modified this behaviour:
http://hg.savannah.gnu.org/hgweb/octave/rev/7dd6ac033e69
Can you read C++? I can explain the situation if you're interested.
|
Wed 09 May 2012 04:49:21 PM UTC, comment #6:
The behavior of path(p) of putting everything on top successively is not intuitive to me; it would be intuitive for addpath(p) though.
ML behaves as mentioned: path(p) assigns p to the full path sequence, which also means that it becomes non-functional if p is bad.
|
Wed 09 May 2012 03:30:07 AM UTC, comment #5:
What does Matlab do about system paths? Can you overwrite those? You can in Octave. When you use path or addpath and you attempt to add a directory already in the path, that directory gets moved to the top of the list. So when you do
the following happens for each x in p:
1) If x is already in the path, it gets moved to the top of the list (and its status as system path or not gets preserved).
2) Else, add x to the top of the list.
So when you do path(p) and p contains system paths, the non-system paths will get moved to the bottom.
Is this a bug only because Matlab doesn't do this? Does this really have to be the same as Matlab?
|
Wed 09 May 2012 03:20:25 AM UTC, comment #4:
isn't it that, whatever is in the path,
puts it in p; and then
restores it to p, whatever was in the path before?
That's how ML works.
|
Wed 09 May 2012 03:12:46 AM UTC, comment #3:
It does. And you changed it with path manipulations.
The situation is that addpath adds paths at the beginning, but plain path will check if the paths you're adding again aren't already there and are system paths. If so, it skips over them and keeps looking for paths to add in the list that you gave it. There can be a fairly intricate interplay between system and non-system paths and the order that you feed to them in path.
I still don't see what the problem is. You expect path and addpath to add paths in the same order?
|
Wed 09 May 2012 03:05:31 AM UTC, comment #2:
I was under the impression that the order of searched directories matters.
|
Wed 09 May 2012 02:37:57 AM UTC, comment #1:
Why is this a bug?
|
Wed 02 May 2012 09:07:01 PM UTC, original submission:
Suppose the present directory has a subdirectory foo. Then issuing the following will show foo in the path, first in the beginning but then at the end.
|