bugGNU Octave - Bugs: bug #57535, PKG_DEL is not sourced when path()...

 
 

bug #57535: PKG_DEL is not sourced when path() removes a directory from the load path

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Fri 03 Jan 2020 10:52:50 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Mon 06 Jan 2020 05:45:20 PM UTC, comment #4: 

The load-path code probably needs some rethinking, including deciding whether we should be automatically executing code from PKG_ADD and PKG_DEL files (see bug #48880).

John W. Eaton <jwe>
Project Administrator
Mon 06 Jan 2020 04:22:53 PM UTC, comment #3: 

I looked very briefly at the load-path.cc code, and there is actually already some code in there breaking the new path argument into a std::set<std::string>, so it may not be that hard to do the same with the current path and get the set differences. This bug is the kind of asymmetry that annoys me, so I may work on it time permitting. If it's not done in time for 6.1, no big deal, been working the same way for many releases now.

Mike Miller <mtmiller>
Project Administrator
Mon 06 Jan 2020 12:32:15 AM UTC, comment #2: 

I agree with your assessment of the situation.

path, rmpath, and addpath are C++ rather than m-files which is a bit sad.  If they were merely m-files then we could call setdiff to determine the differences.  It is possible to call m-files from C++ using octave::feval, and this still might be the fastest way to get to a solution.

Rik <rik5>
Project Administrator
Fri 03 Jan 2020 11:04:00 PM UTC, comment #1: 

And while we're at it, setting the same path() twice in a row should not source the PKG_ADD of a directory since it was already in the previous load path. In other words, to handle PKG_ADD and PKG_DEL properly, how I think users expect them to work, we need to compute a difference of directories each time a new load path is set, and only call PKG_ADD or PKG_DEL for directories that have been added to the set or removed from the set.

Mike Miller <mtmiller>
Project Administrator
Fri 03 Jan 2020 10:52:50 PM UTC, original submission:  

For symmetry, the PKG_DEL file in a directory should be sourced when a directory is removed from the load path as a side effect of calling path().

Here is an example that expresses the problem and the asymmetry:

>> orig_path = path ();
>> addpath /tmp/mypath
Adding /tmp/mypath to the load path
>> with_path = path ();
>> rmpath /tmp/mypath
Removing /tmp/mypath from the load path
>> path (orig_path);
>> path (with_path);
Adding /tmp/mypath to the load path
>> path (orig_path);
>> path (orig_path);
>> path (with_path);
Adding /tmp/mypath to the load path
>> path (with_path);
Adding /tmp/mypath to the load path
>> path (orig_path);
>> path (orig_path);

The PKG_ADD and PKG_DEL files (each containing just a disp) are each executed when the user calls addpath() and rmpath() on the directory in question. The PKG_ADD file is also sourced when the user calls path() to set an entire path string and the new path contains /tmp/mypath. However, the PKG_DEL file is not sourced when the user sets a new path() that does not contain /tmp/mypath  and the previous path did contain it. I believe path() needs to check for directories removed by assigning a new full load path for full symmetry and reliability of the PKG_ADD and PKG_DEL features.

Mike Miller <mtmiller>
Project Administrator

 

(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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-06 rik5 StatusNone => Confirmed
    2020-01-03 mtmiller Carbon-CopyRemoved 80942 => -

    Back to the top


    Powered by Savane 3.5