[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #57872] newly compiled function (.mex/.oct) wi

From: Rik
Subject: [Octave-bug-tracker] [bug #57872] newly compiled function (.mex/.oct) with same name as m-file does not immediately override function file
Date: Mon, 24 Feb 2020 11:30:39 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

Update of bug #57872 (project octave):

                Category:                    None => Interpreter            
                Priority:                 3 - Low => 1 - Later              
              Item Group:                    None => Matlab Compatibility   
                 Release:                   5.2.0 => dev                    
                 Summary: newly compiled mex function with same name does not
immediately override function file => newly compiled function (.mex/.oct) with
same name as m-file does not immediately override function file


Follow-up Comment #10:

This behavior exists with any compiled file (.mex or .oct) so I have re-titled
the issue report.

The issue only exists for a compiled file with exactly the same name as the
executing m-file.  Presumably this is because Octave uses the function name as
the key in its internal cache and the name doesn't change so no update of the
symbol table occurs.

This is a very odd code pattern, and there are several workarounds, so I have
lowered the priority to 1.  If someone wants to code a patch for this they
can, but there are other bugs that would be more useful to fix first.

Workaround number one is simply to compile to a different file name and have
the m-file dispatch to the differently named mex/oct file.  Octave uses this
pattern internally all the time where the help string and input validation are
done in an m-file, and the actual hard work is done in a compiled file.  See,
for example, mkdir.m which uses an internal function written in C++ to do the

    [status, msg, msgid] = __mkdir__ (parent, dirname);

Workaround number two is to force an update of Octave's symbol table from
within the m-file.  For performance, Octave normally only updates the symbol
table upon returning to a command prompt.  See test code below (also attached
as testme.m)

function retval = testme ()

  disp ("Entering m-file testme.m");

  if (! exist ("testme.mex", "file"))
    mex ("-v", "testme.cpp", "-output", "testme.mex");

  which ("testme")
  which ("testme")
  disp ("Calling testme() from within m-file testme.m");
  testme (); 

  disp ("Leaving m-file testme.m");


When executed, results are

octave:1> testme
Entering m-file testme.m
g++ -c  -fPIC -I/home/rik/local/include/octave-7.0.0/octave/..
-I/home/rik/local/include/octave-7.0.0/octave -I/home/rik/local/include 
-pthread -fopenmp -O2 -pipe   -I.  testme.cpp -o /tmp/oct-fqahp6.o
g++ -I/home/rik/local/include/octave-7.0.0/octave/..
-I/home/rik/local/include/octave-7.0.0/octave -I/home/rik/local/include 
-pthread -fopenmp -O2 -pipe -shared -Wl,-Bsymbolic   -o testme.mex 
/tmp/oct-fqahp6.o    -L/home/rik/local/lib   
'testme' is a function from the file
'testme' is a function from the file
Calling testme() from within m-file testme.m
Executing mex file testme.cpp.
Leaving m-file testme.m

You can see that the call to 'rehash' forces Octave to recognize testme.mex.

(file #48493)

Additional Item Attachment:

File name: testme.m                       Size:0 KB


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]