bugGNU Octave - Bugs: bug #36375, path order after path(p)

 
 

bug #36375: path order after path(p)

Submitted by:  Muhali <muhali>
Submitted on:  Wed 02 May 2012 09:07:01 PM UTC  
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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.

John W. Eaton <jwe>
Project Administrator
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?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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)

John W. Eaton <jwe>
Project Administrator
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)

John W. Eaton <jwe>
Project Administrator
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.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 10 May 2012 12:13:08 AM UTC, comment #8: 

Jordi, I vaguely remember this change.  What was the problem that prompted it?

John W. Eaton <jwe>
Project Administrator
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.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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.

Muhali <muhali>
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

path(p)

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?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 09 May 2012 03:20:25 AM UTC, comment #4: 

isn't it that, whatever is in the path,

p = path ;

puts it in p; and then

path(p) ;

restores it to p, whatever was in the path before?

That's how ML works.

Muhali <muhali>
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?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 09 May 2012 03:05:31 AM UTC, comment #2: 

I was under the impression that the order of searched directories matters.

Muhali <muhali>
Wed 09 May 2012 02:37:57 AM UTC, comment #1: 

Why is this a bug?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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.

addpath foo
path
p = path;
restoredefaultpath;
path(p);
path

Muhali <muhali>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #26218:  diffs.txt added by jwe (6KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by muhali (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-07-24 jwe StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2012-07-18 jwe Attached File- => Added diffs.txt, #26218
    2012-07-18 jwe Attached File#26217 => Removed
    2012-07-18 jwe Attached File- => Added diffs.txt, #26217
        StatusNeed Info => Patch Submitted
    2012-05-09 jordigh StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5