bugGNU Octave - Bugs: bug #51960, mex or oct function in +package...

 
 

bug #51960: mex or oct function in +package directory that shadows Octave function only works once

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Thu 07 Sep 2017 06:06:19 PM UTC  
 
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  John W. Eaton <jwe>
Originator Name:  Avinoam Open/Closed:  Closed
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.

 

( Jump to the original submission)

Tue 10 Apr 2018 09:18:47 PM UTC, comment #10:

It fixed the problem also for me (checked on Ubuntu).
Thanks!

Closing as fixed.

Avinoam Kalma <avinoam>
Project Member
Tue 10 Apr 2018 01:57:11 PM UTC, comment #9:

I pushed the following changeset to stable and merged with default.

http://hg.savannah.gnu.org/hgweb/octave/rev/6f1fde568e46

It seems to fix the problem for me. Can you confirm?

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Wed 14 Mar 2018 07:05:33 PM UTC, comment #8:

Changing severity to 4-Important.
It does not allow to use external packages like mexopencv.

Avinoam Kalma <avinoam>
Project Member
Tue 02 Jan 2018 05:25:12 AM UTC, comment #7:

Trying to see the origins of this problem, I have found that in 4.2.1, using the script desribed in the first comment, I get

This has been broken in http://hg.savannah.gnu.org/hgweb/octave/rev/551fa3879615

In http://hg.savannah.gnu.org/hgweb/octave/rev/2d4a7ae1f6cd appears difference between first and second call:

This has been reported in bug #51295, and has been fixed in http://hg.savannah.gnu.org/hgweb/octave/rev/ffd27f53fc79, but the fix is good for the first call, the second call finds the wrong function.

I hope this information will help to fix this bug.

Avinoam Kalma <avinoam>
Project Member
Fri 08 Sep 2017 05:56:29 PM UTC, comment #6:

There are several extant bugs on 'which', 'classdef', and 'help' about the path not being worked out properly for classes and packages.

If you try 'which foo' for a package dir +foo you get

This is clearly not right, but probably indicates something about why built-in functions generate a shadowed warning, but m-files don't. I'm guessing that the path lookup is correct before the m-file in +foo has been executed. When you request the function the very first time it has to be parsed, etc., and an entry in the symbol table is constructed. My guess is that the 'file' variable, or whatever it is, in the constructed symbol table entry is incorrect.

Rik <rik5>
Project Administrator
Fri 08 Sep 2017 04:07:01 PM UTC, comment #5:

Changing the Operating System => Any.

Rik <rik5>
Project Administrator
Fri 08 Sep 2017 03:43:50 PM UTC, comment #4:

Hmm, this is a little bit tricky to reproduce. It has to be an oct or mex file in a +package directory that is overriding an m file function in Octave, not a builtin.

With +foo/size.oct there is no bug, because size is a builtin:

With +foo/imread.mex this bug occurs, because imread is an m file function:

And with +foo/which.oct it also occurs, because which is an m file function:

Mike Miller <mtmiller>
Project Administrator
Fri 08 Sep 2017 03:32:00 PM UTC, comment #3:

I observed this on Debian with the current default branch. It does not affect 4.2.1 or the stable branch.

Mike Miller <mtmiller>
Project Administrator
Fri 08 Sep 2017 03:28:15 PM UTC, comment #2:

Is this Windows specific, or are all versions of Octave affected?

Rik <rik5>
Project Administrator
Thu 07 Sep 2017 07:26:23 PM UTC, comment #1:

Confirmed here, both with mex and oct files. M file functions do not have this problem. Confirm also that it used to work in 4.2.1.

Calling "clear -f" allows the functions to work one time again.

Mike Miller <mtmiller>
Project Administrator
Thu 07 Sep 2017 06:06:19 PM UTC, original submission:

An example:

Create the directory c:\data\+temp
And put there the flowing trivial function, called imread.cc

Now:

In the first call, Octave recognizes temp.imread as the file in c:\data\+temp\imread.mex,
but in the second call, Octave calls its own imread.

This is a regression wrt 4.2.1.

Avinoam Kalma <avinoam>
Project Member

 

(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 avinoam
  • -email is unavailable- added by amro_octave
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by avinoam (Submitted the item)
  • -email is unavailable- added by avinoam
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-10 avinoam StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2018-04-10 jwe StatusConfirmed => Ready For Test
    2018-03-29 avinoam Severity3 - Normal => 4 - Important
    2018-01-02 avinoam Assigned toNone => jwe
        Carbon-Copy- => Added jwe
    2017-12-07 amro_octave Carbon-Copy- => Added amro_octave
    2017-09-08 rik5 Operating SystemMicrosoft Windows => Any
    2017-09-07 mtmiller StatusNone => Confirmed
        SummaryProblem with function in +package directory that shadows Octave function => mex or oct function in +package directory that shadows Octave function only works once
    2017-09-07 avinoam Carbon-Copy- => Added -email is unavailable-

    Back to the top


    Powered by Savane 3.3