"whos -all" and "who -all" fail

[David Bateman]

The commands "who -all" and "whos -all" fail with the current
repositories symbol table code. The code to do this seems to have been
removed. Was this a deliberate choice? If it was what is the recommended
way of finding out the list of functions that are currently in teh
symbol table?

Regards
David

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[John W. Eaton]

On  5-May-2008, David Bateman wrote:

| The commands "who -all" and "whos -all" fail with the current
| repositories symbol table code. The code to do this seems to have been
| removed. Was this a deliberate choice? If it was what is the recommended
| way of finding out the list of functions that are currently in teh
| symbol table?

I remember removing it because (I think) there was no simple way to
make it work exactly as before with the new symbol table, and also
becaue there is no "all" option for who in Matlab.

Do you need this option for debugging, or something else?

If it is just debugging, would it be OK to have the following

  -- vector_of_scope_ids = __dump_symbol_table__ ("scopes")

    Return a vector of all scope ids currently in use in the symbol
    table.

  __dump_symbol_table__ (scope)

    Print a detailed listing of all information in the symbol table
    for the scope id SCOPE.

  __dump_symbol_table__ ()

    Print a detailed listing of all information in the symbol table
    for all scopes.

?

jwe

[David Bateman]

John W. Eaton wrote:

> On  5-May-2008, David Bateman wrote:
>
> | The commands "who -all" and "whos -all" fail with the current
> | repositories symbol table code. The code to do this seems to have been
> | removed. Was this a deliberate choice? If it was what is the recommended
> | way of finding out the list of functions that are currently in teh
> | symbol table?
>
> I remember removing it because (I think) there was no simple way to
> make it work exactly as before with the new symbol table, and also
> becaue there is no "all" option for who in Matlab.
>
> Do you need this option for debugging, or something else?
>  

No it was just for debugging..

> If it is just debugging, would it be OK to have the following
>
>   -- vector_of_scope_ids = __dump_symbol_table__ ("scopes")
>
>     Return a vector of all scope ids currently in use in the symbol
>     table.
>
>   __dump_symbol_table__ (scope)
>
>     Print a detailed listing of all information in the symbol table
>     for the scope id SCOPE.
>
>   __dump_symbol_table__ ()
>
>     Print a detailed listing of all information in the symbol table
>     for all scopes.
>  

Yes something like that would give all of the information I need :-)

D.



> ?
>
> jwe
>
>
>  


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[Przemek Klosowski]

FWIW, I like the 'who -all' command, because it is the only way to recall a command
that I know exists but I can't spell it. Also, it's useful for exploring around
octave.

[David Bateman]

In fact one of the reasons I wanted this feature was to allow the names
of loaded subfunctions to be  identified so that I could do something like

dbstop ("func:subfunc", 1)

so that the debug stopped in the subfunction. However, this doesn't seem
to work either with the new symbol table code. Note that it would be
nice if  dbstop("func") was equivalent to dbstop("func", 1), but it
doesn't appear to be, as the second returns a breakpoint where the first
returns an empty matrix indicating that no breakpoint was set.

regards
david


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[David Bateman]

David Bateman wrote:

> In fact one of the reasons I wanted this feature was to allow the names
> of loaded subfunctions to be  identified so that I could do something like
>
> dbstop ("func:subfunc", 1)
>
> so that the debug stopped in the subfunction. However, this doesn't seem
> to work either with the new symbol table code. Note that it would be
> nice if  dbstop("func") was equivalent to dbstop("func", 1), but it
> doesn't appear to be, as the second returns a breakpoint where the first
> returns an empty matrix indicating that no breakpoint was set.
>
> regards
> david
>
>
>  

Its even worse than that.. If I have a function for example

function y = testf1 (x)
 y = testf2(x);   ## line 2
endfunction
function y = testf2(x)
 y = x +1;  ## line 5
endfunction

I can do dbstop("testf1",2). However, I can't set the breakpoint dbstop
("testf1:testf2",1) and if I set the breakpoint like dbstop ("testf1",
5), then the breakpoint is never triggered. So there is no way to set a
breakpoint in a subfunction. The first of these syntaxes worked with
3.0.1, but not the second.

D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[John W. Eaton]

On  5-May-2008, David Bateman wrote:

| Its even worse than that.. If I have a function for example
|
| function y = testf1 (x)
|  y = testf2(x);   ## line 2
| endfunction
| function y = testf2(x)
|  y = x +1;  ## line 5
| endfunction
|
| I can do dbstop("testf1",2). However, I can't set the breakpoint dbstop
| ("testf1:testf2",1) and if I set the breakpoint like dbstop ("testf1",
| 5), then the breakpoint is never triggered. So there is no way to set a
| breakpoint in a subfunction. The first of these syntaxes worked with
| 3.0.1, but not the second.

In the old symbol table, subfunctions were stored in the same table
with all other functions using the mangled name (i.e.,
"testf1:testf2").  Now subfunctions are stored in the symbol table
corresponding to the parent function, using just the name of the
subfunction (i.e., there is an entry for "testf2" in the subfunctions
map in the symbol table for "testf1").  The dbstop function has not
yet been updated for this change.  But before we change anything, what
is the syntax for setting a breakpoint in a subfunction in Matlab?  I
think we should use the same syntax if possible since that's what most
users will expect.

jwe

[John W. Eaton]

On  5-May-2008, John W. Eaton wrote:

| Now subfunctions are stored in the symbol table
| corresponding to the parent function, using just the name of the
| subfunction (i.e., there is an entry for "testf2" in the subfunctions
| map in the symbol table for "testf1").

Oops, I answered too quickly and got a (fairly major) detail wrong
here.  The subfunctions are stored using their simple name, but the
map is not separate for each scope.  Instead, there is a static map in
the symbol_table object for function names:

  static std::map<std::string, fcn_info> fcn_table;

This maps names to fcn_info objects.  The fcn_info object contains the
following:

      std::string name;

      // Scope id to function object.
      std::map<scope_id, octave_value> subfunctions;

      // Directory name to function object.
      std::map<std::string, octave_value> private_functions;

      // Class name to function object.
      std::map<std::string, octave_value> class_constructors;

      // Dispatch type to function object.
      std::map<std::string, octave_value> class_methods;

      // Legacy dispatch map (dispatch type name to function name).
      dispatch_map_type dispatch_map;

      octave_value cmdline_function;

      octave_value autoload_function;

      octave_value function_on_path;

      octave_value built_in_function;

This allows more than one function with the same name to be installed.
Then the fcn_info::find method may be used to find the correct one
given dispatch info and scope information.  It only looks in the
current scope for subfunctions (that's all that is needed by the
evaluator, I think) so to look in another scope you would need to
temporarily set the scope to some other value (that is already done
when in debugging mode).  If you want to set a breakoint in a
particular subfunction given a name like "f1:f2" then we should
probably define a find_subfunction method that takes a scope_id as an
argument.  Then you would find the scope id corresponding to f1 and
then look for the subfunction f2 using that scope id.

jwe

[dbateman]

John W. Eaton wrote:

But before we change anything, what
is the syntax for setting a breakpoint in a subfunction in Matlab?  I
think we should use the same syntax if possible since that's what most
users will expect.

Matlab has a function filemarker that on my system returns ">". The dbstop command then uses the character defined by filemarker as the subfunction separator. That is f1>f2. The question I ask myself but can't test is with nested function

function f1
  function f2
    function f3
    end
  end
end

Is f3 defined as f1>f3 or f1>f2>f3. I suspect its f1>f2>f3 but can't check at the moment. Note that the subfunctions in matlab can also have help strings that can be accessed with the filemarker (cf the mathworks website for the filemarker function and the pdede>pdeodes function). I don't know what the values of filemarker are on other platforms

D.

[John W. Eaton]

On  5-May-2008, David Bateman wrote:

| > If it is just debugging, would it be OK to have the following
| >
| >   -- vector_of_scope_ids = __dump_symbol_table__ ("scopes")
| >
| >     Return a vector of all scope ids currently in use in the symbol
| >     table.
| >
| >   __dump_symbol_table__ (scope)
| >
| >     Print a detailed listing of all information in the symbol table
| >     for the scope id SCOPE.
| >
| >   __dump_symbol_table__ ()
| >
| >     Print a detailed listing of all information in the symbol table
| >     for all scopes.
| >  
|
| Yes something like that would give all of the information I need :-)

OK, I added the following functions

  SCOPE_ID = __current_scope__ ()

  __dump_symtab_info__ ()
  __dump_symtab_info__ (SCOPE_ID)
  __dump_symtab_info__ ("functions")
  SCOPE_IDS = __dump_symtab_info__ ("scopes")

This took a lot longer than I thought it would (maybe that's why I
punted before).  OTOH, I think I found and fixed a few more bugs in
the symbol table code, so maybe there was some progress.

I'm not sure the interface or format is as useful as it could be.
Feel free to improve it.  I'm done with it for now.

jwe

[John W. Eaton]

On  5-May-2008, Przemek Klosowski wrote:

| FWIW, I like the 'who -all' command, because it is the only way to recall a command
| that I know exists but I can't spell it. Also, it's useful for exploring around
| octave.

What about "help"?  With no arguments it lists all the functions.

jwe

[David Bateman]

John W. Eaton wrote:

> On  5-May-2008, Przemek Klosowski wrote:
>
> | FWIW, I like the 'who -all' command, because it is the only way to recall a command
> | that I know exists but I can't spell it. Also, it's useful for exploring around
> | octave.
>
> What about "help"?  With no arguments it lists all the functions.
>
> jwe
>
>  

But it doesn't return subfunction names..

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[David Bateman]

John W. Eaton wrote:

> OK, I added the following functions
>
>   SCOPE_ID = __current_scope__ ()
>
>   __dump_symtab_info__ ()
>   __dump_symtab_info__ (SCOPE_ID)
>   __dump_symtab_info__ ("functions")
>   SCOPE_IDS = __dump_symtab_info__ ("scopes")
>
> This took a lot longer than I thought it would (maybe that's why I
> punted before).  OTOH, I think I found and fixed a few more bugs in
> the symbol table code, so maybe there was some progress.
>
> I'm not sure the interface or format is as useful as it could be.
> Feel free to improve it.  I'm done with it for now.
>
>  

Ok, this identifies the sub-functions, but we'll need to figure out a
manner to allow "dbstop func:subfunc" to work..

Cheers
D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[John W. Eaton]

On  6-May-2008, David Bateman wrote:

| John W. Eaton wrote:
| > OK, I added the following functions
| >
| >   SCOPE_ID = __current_scope__ ()
| >
| >   __dump_symtab_info__ ()
| >   __dump_symtab_info__ (SCOPE_ID)
| >   __dump_symtab_info__ ("functions")
| >   SCOPE_IDS = __dump_symtab_info__ ("scopes")
| >
| > This took a lot longer than I thought it would (maybe that's why I
| > punted before).  OTOH, I think I found and fixed a few more bugs in
| > the symbol table code, so maybe there was some progress.
| >
| > I'm not sure the interface or format is as useful as it could be.
| > Feel free to improve it.  I'm done with it for now.
| >
| >  
| Ok, this identifies the sub-functions, but we'll need to figure out a
| manner to allow "dbstop func:subfunc" to work..

With the current code, you would need to

  parse the dbstop argument into a list of function names

  find the parent function by name in the symbol table

  get the scope id from the parent function object

  find the subfunction corrsponding to that scope with the given name

  set the breakpoint in the subfunction object

jwe