bugGNU Octave - Bugs: bug #42500, Matlab loadpath includes private...

 
 

bug #42500: Matlab loadpath includes private directories (II)

Submitter:  Muhali <muhali>
Submitted:  Tue 03 Jun 2014 05:54:53 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 25 Apr 2015 05:57:23 AM UTC, comment #5: 

This didn't work before, but now does with the latest development tip.  Closing report.

Rik <rik5>
Group administrator
Mon 09 Jun 2014 03:23:42 AM UTC, comment #4: 

The committed changeset doesn't work for me.  This is on the development branch at 18813:bc52657a7d29.

Rik <rik5>
Group administrator
Wed 04 Jun 2014 09:34:02 PM UTC, comment #3: 

I checked in the following changeset.  I think this fixes the problem and doesn't cause any new problems.  If you agree, then please close this bug report.

http://hg.savannah.gnu.org/hgweb/octave/rev/ebf6a1e5ff59

John W. Eaton <jwe>
Group administrator
Wed 04 Jun 2014 07:39:59 AM UTC, comment #2: 


> Does the mat file being loaded have to be in the same private directory as the m-file function?


No. But ML behavior is weird. It finds the file in any directory that is added via addpath, plus in the private directory of the calling function, but NOT in other directories of the search path (e.g. toolbox dirs).

> Does a load work if the mat file is under private but the function calling load is not?


Yes.

> Can it be in a different private directory that is also on the path?


See above.

> I guess the question is how far beyond the real path does the search have to go? And how important is this and do we really want to fix this? See Rik's comment on bug #35697.


For me the question is always will it break existing ML scripts, as it was the case in this report.

Muhali <muhali>
Wed 04 Jun 2014 01:13:20 AM UTC, comment #1: 

Does the mat file being loaded have to be in the same private directory as the m-file function? Does a load work if the mat file is under private but the function calling load is not? Can it be in a different private directory that is also on the path?

I guess the question is how far beyond the real path does the search have to go? And how important is this and do we really want to fix this? See Rik's comment on bug #35697.

Mike Miller <mtmiller>
Group Member
Tue 03 Jun 2014 05:54:53 PM UTC, original submission:  

Private directories are treated differently in matlab and octave. If in a function a function is called wherein a file from the private directory is loaded, this is recognized by matlab but not by octave, as in the following example where foo.mat resides in private:


% fun.m
function y = fun()
   foo;
end

% private/foo.m
function y = foo()
   load foo.mat
end


See also bug#35697.

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-25 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-06-05 rik5 StatusNeed Info Ready For Test
    2014-06-04 mtmiller Item GroupNone Incorrect Result
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code