octave-maintainers
[Top][All Lists]
Advanced

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

Re: Changing the way dispatch works for built-in functions


From: Daniel J Sebald
Subject: Re: Changing the way dispatch works for built-in functions
Date: Tue, 13 Dec 2016 19:37:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 12/12/2016 05:40 PM, John W. Eaton wrote:
While looking at this bug report

   https://savannah.gnu.org/bugs/?49794

I started thinking about how to better handle dispatch for built-in
functions.  Currently, built-in functions are found last.  The search is
performed in symbol_table::fcn_info::fcn_info_rep::xfind:


http://hg.savannah.gnu.org/hgweb/octave/file/9b096bffc10d/libinterp/corefcn/symtab.cc#l647


As things are now, if you create a .m file function with the same name
as a built-in function, the .m file function will always override the
built-in function.  But, if we were to install built-in functions in the
map from class name to function (the same one that is currently only
used for user-defined classes) then we could limit the damage someone
could do by installing a plain old function with the same name as a
built-in.  For example, if we installed the current built-in svd
function in the class map for double and single classes, then the
built-in svd function would be found when svd is called with a double or
single argument.  The only way for a user to accidentally override the
built-in version would be to create a function @double/svd @single/svd.

Lookup of built-in functions would also be slightly faster because the
ones that are installed for specific types would be found earlier than
they are now, bypassing some extra logic that is must now be executed
before finding a built-in function.

All that needs to change is to augment the map of types and functions
with built-in functions and the types they handle, and modify the code
that clears that table so that it doesn't remove built-in functions from
the list.  It is not necessary to add all functions at once.  Any
built-in functions that are not associated with specific types will be
found the same as they are now.

I've often wondered if it'd be possible to set up some C/C++ function to place C code and scripts in the function table but maintain a hierarchy then have another C++ function to call a prior function in the hierarchy. Sort of the way virtual functions work in C++. It might then be possible to keep custom command-line GUI behavior as part of the GUI and not need an interface coming from inside the core.

For example, say the Qt GUI wanted to override the behavior of Octave for a couple functions, exit() and editor(), as two examples. In psuedo code, it might be:

qtgui_exit_function (args)
{
    // Do all the GUI shutdown things like saving files here
    // confirming exit and so on
    emit shutdown_or_whatever();

    octave_core_function("exit", args);
}

qtgui_edit_function (octave_val_type args)
{
   // Do all the GUI shutdown things here like saving files,
   // confirming exit and so on
   emit create_new_file_in_editor();

   // No need to call the core default function because
   // this GUI has it's built-in editor.
   // octave_core_function("edit", args);
}

Then in the GUI main startup code:

main_of_qtgui (void)
{
   install_octave_function("exit", &qtgui_exit_function);
   install_octave_function("edit", &qtgui_edit_function);
   ...
}

I'm imagining so many things that have a little GUI element to them. The debug commands for example.

qtgui_dbstop_routine(octave_val_type arg)
{
    octave_val_type retval = octave_core_function("dbstob", args);

    if (retval.success == YES_BREAKPOINT_SET)
        emit addbreakpoint_in_gui_editor(retval.filename, retval.linenumber);
}

The point is that it would be the work of the GUI designers, whatever platform used, to manage all that GUI interactions initiated from the command line.

Dan



reply via email to

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