Modifications to error handling for the command suggestion feature

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Modifications to error handling for the command suggestion feature

Sudeepam Pandey
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

Rik, you had been helping me figure out how the feature would integrate itself with Octave and therefore, your help would be particularly appreciated here.

Now here's the thing. From our previous discussions[1] we concluded that some modifications to __unimplemented.m__ would successfully integrate a command suggestion feature with octave. However, I've found a small problem with that.

I'd like to demonstrate the problem with an example. Here I have tried to call the cconv function, a part of the signal package without actually installing the package.

This is what I get...
--------------------------------------------
>> cconv
warning: the 'cconv' function belongs to the signal package from Octave Forge
which seems to not be installed in your system.

Please read <https://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
error: 'cconv' undefined near line 1 column 1
---------------------------------------------

Notice that Octave first tells us something about cconv, this message is generated by the file scripts/help/__unimplemented.m__ after this the actual error message is generated which I have found out is generated by the file libinterp/parse-tree/pt-id.cc

The fault is that, for an effective integration, the preferable thing would be to first print out the 'undefined near line' error message, and then tell us something about the identifier which the parser did not recognize. Here is the reason...

After the suggestion feature presents the corrections to the user, it would provide them with a way to easily execute those commands. If we implement the feature the way it has been discussed, The user would get a suggestion and a prompt to select and execute the command they actually intended to execute... the problem would be that they would receive the error message of their mistake, after they have executed the correct command, and this would definitely be a poor design.

Now I suppose that I have been able to understand the exact file where the call to the missing_function_hook() should be made.Currently it is in the line number 56 of the file pt-id.cc. However, a call from the line number 540 of the file error.cc should do the trick. However, I am not able to understand how to make this call.

If I paste the exact same line 56 from pt-id.cc to line 540 of error.cc I get a name cannot be used as a function error while building. The lack of understanding, obviously is because of not having c++ on my fingertips like Octave so help would be appreciated.

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)


Thankyou,
P Sudeepam
Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

nrjank


On Sat, May 19, 2018, 14:02 Sudeepam Pandey <[hidden email]> wrote:
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

...

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)

Not any help on the code, but I'm trying to think through the under-the-hood decision tree. 

1. Unrecognized function call
2. Check for unloaded possible package function - if so suggest installing/ loading.
3. If not prompt for to-be-implemented suggestions. Since its just text display this can include a version of the error message.
4. Else: error with explanation.

I think you need to leave some error condition as a final fallback to terminate execution. I don't know if you can call the the error message early before terminating execution. Maybe that's what you're suggesting?

This brings up another thought: if I make a typo in a script, do I want command suggestion to occur? I don't think so. If we mess with general error handling, can that be aware of whether the typo happened at the CLI?




Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Rik-4
On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:


On Sat, May 19, 2018, 14:02 Sudeepam Pandey <[hidden email]> wrote:
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

...

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)

Not any help on the code, but I'm trying to think through the under-the-hood decision tree. 

1. Unrecognized function call
2. Check for unloaded possible package function - if so suggest installing/ loading.
3. If not prompt for to-be-implemented suggestions. Since its just text display this can include a version of the error message.
4. Else: error with explanation.

Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    if (l == -1 && c == -1)
      std::cerr << "'" << name () << "' undefined\n";
    else
      std::cerr << "'" << name () << "' undefined near "
                << "line " << l << " column " << c << "\n";

    maybe_missing_function_hook (name ());

    error_with_id ("Octave:undefined-function", "");
  }


I think you need to leave some error condition as a final fallback to terminate execution. I don't know if you can call the the error message early before terminating execution. Maybe that's what you're suggesting?

This brings up another thought: if I make a typo in a script, do I want command suggestion to occur? I don't think so. If we mess with general error handling, can that be aware of whether the typo happened at the CLI?


I agree.  At least in C++ you can check whether you are at the top-level scope, i.e., the command line.  There is probably a way to do so within Octave, jwe might know of a particular variable to check.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey
In reply to this post by nrjank


On Sun, May 20, 2018 at 12:16 AM, Nicholas Jankowski <[hidden email]> wrote:


On Sat, May 19, 2018, 14:02 Sudeepam Pandey <[hidden email]> wrote:
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

...

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)

Not any help on the code, but I'm trying to think through the under-the-hood decision tree. 

1. Unrecognized function call
2. Check for unloaded possible package function - if so suggest installing/ loading.
3. If not prompt for to-be-implemented suggestions. Since its just text display this can include a version of the error message.
4. Else: error with explanation.

I think you need to leave some error condition as a final fallback to terminate execution. I don't know if you can call the the error message early before terminating execution. Maybe that's what you're suggesting?

Yes I was suggesting the exact thing. Can we somehow...generate the error message first and then do a certain thing (such as suggesting possible unloaded package/ unimplemented function etc). Also, I agree with you. An error condition to terminate execution is more suitable. However to use the menu (or similar) function to give a prompt to the user to select and execute the options suggested would require us to make changes to the error handling. If we make the command line suggestion feature in such a way that it does not give the user an option to select the commands suggested no changes to the error handle would be required.

A little thinking gave me another possible idea. Why use the menu or any other function to provide an easy way to select and execute the commands? We simply display the suggestions and the user can just press the upward arrow key, make the small change to the command (note that the change would be small since the word would be a close match) and execute it. Isn't that simple too?



This brings up another thought: if I make a typo in a script, do I want command suggestion to occur? I don't think so. If we mess with general error handling, can that be aware of whether the typo happened at the CLI?


Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey
In reply to this post by Rik-4


On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:


On Sat, May 19, 2018, 14:02 Sudeepam Pandey <[hidden email]> wrote:
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

...

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)

Not any help on the code, but I'm trying to think through the under-the-hood decision tree. 

1. Unrecognized function call
2. Check for unloaded possible package function - if so suggest installing/ loading.
3. If not prompt for to-be-implemented suggestions. Since its just text display this can include a version of the error message.
4. Else: error with explanation.

Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    if (l == -1 && c == -1)
      std::cerr << "'" << name () << "' undefined\n";
    else
      std::cerr << "'" << name () << "' undefined near "
                << "line " << l << " column " << c << "\n";

    maybe_missing_function_hook (name ());

    error_with_id ("Octave:undefined-function", "");
  }


I think you need to leave some error condition as a final fallback to terminate execution. I don't know if you can call the the error message early before terminating execution. Maybe that's what you're suggesting?

This brings up another thought: if I make a typo in a script, do I want command suggestion to occur? I don't think so. If we mess with general error handling, can that be aware of whether the typo happened at the CLI?


I agree.  At least in C++ you can check whether you are at the top-level scope, i.e., the command line.  There is probably a way to do so within Octave, jwe might know of a particular variable to check.

--Rik


If we plan to 'display' the suggestions only, why not include the scripts as well. When the script throws an error at the runtime, the user would look at the command window to see where they have made an error, wouldn't it be nice to have something that tells the user... "you made an error at this line...did you mean to write this?"

Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey
In reply to this post by Rik-4


On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:


On Sat, May 19, 2018, 14:02 Sudeepam Pandey <[hidden email]> wrote:
All,

I'm starting to guess that adding a command suggestion feature would require some changes to the error handling.

...

Could anyone help me understand how that call could be made or maybe, help me figure out a better way to make octave first print out the 'undefined near line' error message and then tell us something about the identifier which parser did not recognize? (perhaps some better place to make the call from?)

Not any help on the code, but I'm trying to think through the under-the-hood decision tree. 

1. Unrecognized function call
2. Check for unloaded possible package function - if so suggest installing/ loading.
3. If not prompt for to-be-implemented suggestions. Since its just text display this can include a version of the error message.
4. Else: error with explanation.

Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command. 

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    if (l == -1 && c == -1)
      std::cerr << "'" << name () << "' undefined\n";
    else
      std::cerr << "'" << name () << "' undefined near "
                << "line " << l << " column " << c << "\n";

    maybe_missing_function_hook (name ());

    error_with_id ("Octave:undefined-function", "");
  }


I think you need to leave some error condition as a final fallback to terminate execution. I don't know if you can call the the error message early before terminating execution. Maybe that's what you're suggesting?

This brings up another thought: if I make a typo in a script, do I want command suggestion to occur? I don't think so. If we mess with general error handling, can that be aware of whether the typo happened at the CLI?


I agree.  At least in C++ you can check whether you are at the top-level scope, i.e., the command line.  There is probably a way to do so within Octave, jwe might know of a particular variable to check.

--Rik




Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

nrjank


On Sat, May 19, 2018, 17:12 Sudeepam Pandey <[hidden email]> wrote:


On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command.  

yes, that makes sense. Don't want to display error message if you've interrupted the process flow and fixed it. 

Regarding display or fix, i think that would make for a useful progression of complexity. Walk before you run, and maybe allow the user an option to just walk. (If we have a suggestion toggle, it could be a 3-way toggle)




Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Rik-4
In reply to this post by Sudeepam Pandey
On 05/19/2018 02:12 PM, Sudeepam Pandey wrote:


Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command. 

If the command is correct, then there is no undefined error.  If the command is not correct, you can offer a suggestion, but there is no way for the user to correct the command and have it execute.  They need to return to the prompt and enter the correct command.  That was my point about not being able to back up the parser and have it re-execute on the suggestion that you supply in the function called by missing_function_hook.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey
In reply to this post by nrjank


On Sun, May 20, 2018 at 4:54 AM, Nicholas Jankowski <[hidden email]> wrote:


On Sat, May 19, 2018, 17:12 Sudeepam Pandey <[hidden email]> wrote:


On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command.  

yes, that makes sense. Don't want to display error message if you've interrupted the process flow and fixed it. 

Regarding display or fix, i think that would make for a useful progression of complexity. Walk before you run, and maybe allow the user an option to just walk. (If we have a suggestion toggle, it could be a 3-way toggle)

I'm sorry Nicholas but can you please explain the last part that you said? I didn't understand.

And just a quick update on the process. I've made a very small (including only a few functions), definitely not very optimized, suggestion feature using the levenshtein algorithm and integrating it like we discussed previously. Its display only at this stage... here are a few test results...

>> clea
Did you mean...
clear

error: 'clea' undefined near line 1 column 1
>>
>>
>> clearr
Did you mean...
clear

error: 'clearr' undefined near line 1 column 1
>>
>> clce
Did you mean...
clc

error: 'clce' undefined near line 1 column 1
>>
>> sine
Did you mean...
sin

error: 'sine' undefined near line 1 column 1
>>
>> sine(5)
Did you mean...
sin

error: 'sine' undefined near line 1 column 1
>>
>> sib (10)
Did you mean...
sin

error: 'sib' undefined near line 1 column 1
>>

Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey
In reply to this post by Rik-4


On Sun, May 20, 2018 at 8:56 AM, Rik <[hidden email]> wrote:
On 05/19/2018 02:12 PM, Sudeepam Pandey wrote:


Providing a list of suggestions and then returning to the CLI is going to be easier then changing the parser--which has already gone down an error path--to accept new input, backup, and re-parse the new command.  The latter can be done, but for the moment I would concentrate on just offering the user some suggestions.

You did correctly find the code in pt-id.cc to modify.  The complete routine is

  void
  tree_identifier::eval_undefined_error (void)
  {
    int l = line ();
    int c = column ();

    maybe_missing_function_hook (name ());

    if (l == -1 && c == -1)
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined", name ().c_str ());
    else
      error_with_id ("Octave:undefined-function",
                     "'%s' undefined near line %d column %d",
                     name ().c_str (), l, c);
  }

What you want to do is print out an error message first, then call maybe_missing_function_hook, and then return to the prompt.  You can't use error_with_id because it is based on exceptions and will return to the prompt as soon as it is done.  However, you can print the warning to stderr, which is what the error() function is doing anyways.  Try this

Our primary need is not to print the error message first, but to make sure that an error message for the mistake made in the last command does not occur after the user has executed the correct command. 

If the command is correct, then there is no undefined error.  If the command is not correct, you can offer a suggestion, but there is no way for the user to correct the command and have it execute.  They need to return to the prompt and enter the correct command.  That was my point about not being able to back up the parser and have it re-execute on the suggestion that you supply in the function called by missing_function_hook.

--Rik

Ohh I understand. So what should we aim for? Display suggestions only or make a pop-up like feature? I've also come across another reason about why providing an execution option wouldn't be the best idea... would like to explain it with an example.

Say a user wants to generate a sine wave in octave with a frequency of 5Hz. They would type something like...

>> x = sin (2*pi*5*t) # t is a previously declared variable that contains time samples.

now if the user misspells and types...say...

>> x = sine (2*pi*5*t)

The suggestion feature would output something like...

----------------------------------------
Did you mean...
sin

error: 'sine' undefined near line 1 column 1
-----------------------------------------

This is because 'sine' is the part that the parser dosen't recognize and so 'sine' is what is corrected to 'sin'

This sin cannot be executed directly without the appropriate arguments and I don't think that we have a way to pass down the entire expression to the pop-up. A better way here to correct the spelling would be to press the upward arrow key and change sine to sin.

So this is another reason why I am starting to believe that displaying a text only suggestion is the best option because octave already provides a reasonably easy way to edit and change commands. Doing this would also save us the task of changing the error handling.
Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

nrjank
In reply to this post by Sudeepam Pandey
On Mon, May 21, 2018 at 9:37 AM, Sudeepam Pandey
<[hidden email]> wrote:

>
>
> On Sun, May 20, 2018 at 4:54 AM, Nicholas Jankowski <[hidden email]>
> wrote:
>>
>>
>>
>> On Sat, May 19, 2018, 17:12 Sudeepam Pandey <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
>>>>
>>>> On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:
>>
>>
>>> Our primary need is not to print the error message first, but to make
>>> sure that an error message for the mistake made in the last command does not
>>> occur after the user has executed the correct command.
>>
>>
>> yes, that makes sense. Don't want to display error message if you've
>> interrupted the process flow and fixed it.
>>
>> Regarding display or fix, i think that would make for a useful progression
>> of complexity. Walk before you run, and maybe allow the user an option to
>> just walk. (If we have a suggestion toggle, it could be a 3-way toggle)
>
>
> I'm sorry Nicholas but can you please explain the last part that you said? I
> didn't understand.

Sorry for the lack of clarity. What I basically meant was that I think
it's appropriate to look at this as a two stage goal:  (1) find the
right way to display a suggested correction (and looks like you're
well on the way for that), and (2) find the right way to let the user
execute the suggested correction. I still don't know if the best
option is CLI-inline or a GUI-pop up. But what I meant was it may be
best to leave the suggestion option as one which lets you pick
off/only-suggest/suggest-and-execute

Reply | Threaded
Open this post in threaded view
|

Re: Modifications to error handling for the command suggestion feature

Sudeepam Pandey


On 21 May 2018 9:34 p.m., "Nicholas Jankowski" <[hidden email]> wrote:
On Mon, May 21, 2018 at 9:37 AM, Sudeepam Pandey
<[hidden email]> wrote:
>
>
> On Sun, May 20, 2018 at 4:54 AM, Nicholas Jankowski <[hidden email]>
> wrote:
>>
>>
>>
>> On Sat, May 19, 2018, 17:12 Sudeepam Pandey <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Sun, May 20, 2018 at 2:05 AM, Rik <[hidden email]> wrote:
>>>>
>>>> On 05/19/2018 11:46 AM, Nicholas Jankowski wrote:
>>
>>
>>> Our primary need is not to print the error message first, but to make
>>> sure that an error message for the mistake made in the last command does not
>>> occur after the user has executed the correct command.
>>
>>
>> yes, that makes sense. Don't want to display error message if you've
>> interrupted the process flow and fixed it.
>>
>> Regarding display or fix, i think that would make for a useful progression
>> of complexity. Walk before you run, and maybe allow the user an option to
>> just walk. (If we have a suggestion toggle, it could be a 3-way toggle)
>
>
> I'm sorry Nicholas but can you please explain the last part that you said? I
> didn't understand.

Sorry for the lack of clarity. What I basically meant was that I think
it's appropriate to look at this as a two stage goal:  (1) find the
right way to display a suggested correction (and looks like you're
well on the way for that), and (2) find the right way to let the user
execute the suggested correction. I still don't know if the best
option is CLI-inline or a GUI-pop up. But what I meant was it may be
best to leave the suggestion option as one which lets you pick
off/only-suggest/suggest-and-execute

Ohh I understand. I'll keep this in mind and update you soon.