octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #31815] speed demos no longer work since versi


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #31815] speed demos no longer work since version 3.2.3
Date: Thu, 09 Dec 2010 18:52:26 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101028 Iceweasel/3.5.15 (like Firefox/3.5.15)

Follow-up Comment #1, bug #31815 (project octave):

The demo function creates a string that wraps all of the demo code in a
function called __demo__, evals that string to create a function, then calls
__demo__.  In the olden times, the nested functions weren't treated as nested
or subfunctions, so they were installed globally.  And the type function was a
built-in function that could reconstruct and display functions that were not
defined in files (by reconstructing the program text from the parse tree
information).  Now we have subfunctions and the type function is a .m file
that can't seem to handle anything but files.

Note this simpler examples of failure (save the fucntion to a file and
execute the primary function):


function fun ()
  function subfun ()
    'this is subfun'
  end
  exist ('subfun')
  type subfun
end


For this, I see exist returning 2 (function from a file) but type can't print
it because it doesn't know anything about how to find the subfunction.

I'm not sure what the right behavior is.

What does Matlab do for this function?  Is there a way to find out if a
subfunction exists?  I guess the question doesn't make much sense if you think
of subfunctions as private and that they are statically defined (so there is
really no need to ask).  What about the type function?  Does Matlab have any
way to display the text of a subfunction that is in scope?

What should Octave do, given that it is already different from Matlab in that
it allows functions to be constructed at the command line and by evaluating a
character string?

Should we just rewrite demo instead of trying to fix Octave so that the
current demo code work?

Even if we just avoid the problem by rewriting the demo function, we may
still have some issues to deal with.  I noticed some crashes when I was trying
to debug what was happening.  For example, removing the "type build_orig" and
"type build" lines from the first speed demo, then running "demo speed" caused
a crash for me.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31815>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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