Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the ICommandPredictor to provide more feedback and also make feedback easier to be corelated #14649

Merged
merged 9 commits into from Feb 4, 2021

Conversation

daxian-dbw
Copy link
Member

@daxian-dbw daxian-dbw commented Jan 21, 2021

PR Summary

Update the ICommandPredictor interface APIs to allow a predictor to get feedback about what suggestions from it were displayed to the user, and also make it easier for a predictor to corelate feedback events.

  1. Add ICommandPredictor.OnSuggestionDisplayed, to let a predictor know what results were displayed to the user when rendering the results: void OnSuggestionDisplayed(uint session, int countOrIndex);

    • The countOrIndex parameter can help a predictor to tell if the display was in ListView or InlineView:
      • When the value is > 0, it's the number of displayed suggestions from the list returned in , starting from the index 0. This indicates the ListView is in use.
      • When the value is <= 0, it means a single suggestion from the list got displayed, and the index is the absolute value. This indicates the InlineView is in use.
  2. Add clientId and session parameters to the existing interface APIs. The clientId parameter helps a predictor to know what host client is calling it (PSReadLine only today, but it could be the PS VSCode extension some day in future); the session parameter helps a predictor to corelate feedback events.

    • GetSuggestion and StartEarlyProcessing both take a string parameter clientId, so it knows the client that makes the call
    • GetSuggestion returns a uint type session value, along with the list of suggestion entries it provides.
    • OnSuggestionDisplayed and OnSuggestionAccepted both take a uint parameter session, which indicates where the displayed or accepted suggestions were from.

/cc @kceiw

This PR also includes a few changes to the scripts that generate PowerShell SDK NuGet packages, to make it works properly with the other changes from this PR, and also make NuGet packages include the XML document files.

PR Checklist

@ghost ghost assigned anmenaga Jan 21, 2021
@daxian-dbw daxian-dbw changed the title Predict Update the ICommandPredictor to provide more feedback and also make feedback easier to be corelated Jan 22, 2021
Comment on lines 64 to 71
void OnSuggestionDisplayed(uint session, int countOrIndex);

/// <summary>
/// The suggestion provided by the predictor was accepted.
/// </summary>
/// <param name="session">Represents the mini-session where the accepted suggestion came from.</param>
/// <param name="acceptedSuggestion">The accepted suggestion text.</param>
void OnSuggestionAccepted(uint session, string acceptedSuggestion);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could merge both methods if they are always used together.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are not used together. OnSuggestionDisplayed will be fired way more than OnSuggestionAccepted.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thoughts are if we get 100 suggestions we could weight all 100 (including displayed and accepted ones) and return the result to the prediction service so that it could make more better analyze. So users could prefer a case-sensitive selection or use other sources for selection (local configs, history or other prediction services) to inform the prediction service.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thoughts are if we get 100 suggestions we could weight all 100 (including displayed and accepted ones) and return the result to the prediction service so that it could make more better analyze.

It's pretty common that we get suggestions from a predictor but user doesn't accept anything, so it's not clear to me how to always include "displayed and accepted ones" in a feedback.

After this change, "OnSuggestionDisplayed" event will be fired very often. I very much want to reduce it ..., so any ideas are very welcome. Can you maybe elaborate your thoughts more?

So users could prefer a case-sensitive selection or use other sources for selection (local configs, history or other prediction services) to inform the prediction service.

Not sure I understand what you mean, it would be nice if you can clarify more. Basically, we try to avoid sending more user local infor to a predictor than really needed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've heard more than once that users want to restore a PowerShell session after a restart. For this service it might be useful too.

My thoughts may be vague, but I believe that if a service does not store permanently the (session) state, then this state should be stored locally.

What is a session data? (1) Personal sensitive user data (stored only locally), (2) service data. Service data may be (1) complex data structure (like subset of ML model), (2) simple tips (references on internal service models)

I think that if user data should not be stored on the service, then there might be the following options:

  1. No data is stored locally between sessions
  2. All session data is stored locally (including model)
  3. All sensitive data is stored locally (including service tips).

Also I think there are many claims about sensing user data to Cloud. The service could be data agnostic and gets encrypted data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like a design proposal for a separate feature "restore a PowerShell session after a restart" :)

/// <summary>
/// Gets the mini-session id that represents a specific invocation to the <see cref="ICommandPredictor.GetSuggestion"/> API of the predictor.
/// </summary>
public uint Session { get; }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why uint? Maybe Guid to be globally independent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The session is always under a context, for example, a period of time when a predictor module is loaded and used, a Runspace instance id where the module is loaded. That context can be uniquely identified, so I think there is no need for the mini-session to be globally unique.

I use uint only because it provides a large space and easy to increment to get a new mini-session id. Azure PowerShell team is using this prediction API for the Az Predictor. I'm waiting on the their feedback on this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Az.Predictor team has confirmed that uint works fine, becuase they already have other context information that is uniquely identifiable. /cc @kceiw

@daxian-dbw daxian-dbw marked this pull request as ready for review February 1, 2021 19:13
@daxian-dbw
Copy link
Member Author

@rjmholt and @anmenaga this PR is ready, please help review it, thank!
@kceiw I will appreciate it if you can review this PR as well.

@@ -2312,6 +2312,14 @@ internal static void NotNullOrEmpty(string value, string paramName)
}
}

internal static void NotNullOrEmpty(ICollection value, string paramName)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps use [CallerArgumentExpression("value")] ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not implemented yet, right? See the proposal doc and the open issue: dotnet/csharplang#287

Copy link
Collaborator

@powercode powercode Feb 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're correct! I was misled by the docs. I have used CallerMemberName and read the documentation for CAE and just assumed it worked as well.

@anmenaga anmenaga added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Feb 4, 2021
Copy link
Contributor

@anmenaga anmenaga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine.
Please file a doc issue and link it in "Documentation needed"/"Issue filed:" in PR Checklist; thank you.

@@ -2268,6 +2276,9 @@ function New-ReferenceAssembly
Copy-Item $refBinPath $RefAssemblyDestinationPath -Force
Write-Log "Reference assembly '$assemblyName.dll' built and copied to $RefAssemblyDestinationPath"

Copy-Item $dllXmlDoc $RefAssemblyDestinationPath -Force
Write-Log "Xml document '$assemblyName.xml' copied to $RefAssemblyDestinationPath"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... make NuGet packages include the XML document files.
This is not really related to prediction APIs. Could have been a separate PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly related, but sort of. The script needs to be updated after the changes in API because new attributes are used which need to be scrubbed when generating the reference assembly, so I have to update the packaging scripts. While doing so, I found the XML docs are missing when using our NuGet packages in VS Code or Visual Studio, and thus I fix that too.
Since we need to include part of the fixes in packaging.psm1 anyways, I prefer to keep all changes in this PR.

@{
ApplyTo = @("System.Management.Automation")
Pattern = "[System.Runtime.CompilerServices.CompilerGeneratedAttribute, System.Runtime.CompilerServices.IsReadOnlyAttribute]"
Replacement = "/* [System.Runtime.CompilerServices.CompilerGeneratedAttribute, System.Runtime.CompilerServices.IsReadOnlyAttribute] */ "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please explain why this is needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CompilerGeneratedAttribute and IsReadOnlyAttribute are added by the C# compiler to the readonly members of a struct in the generated IL. Those attributes can only be used by the C# compiler and thus will result in complication error when they are in the source code. Therefore, we need to scrub them out before compiling to get our reference assembly.

@daxian-dbw
Copy link
Member Author

daxian-dbw commented Feb 4, 2021

@anmenaga Thanks for the review!
There is no need to update PowerShell docs. The PSSubsystemPluginModel experimental feature is only mentioned here: https://docs.microsoft.com/en-us/powershell/scripting/learn/experimental-features?view=powershell-7.1#pssubsystempluginmodel, and it doesn't talk about specific APIs. We only need to update the XML document for the APIs, which is done by the updates to packaging.psm1.

Lists the currently available experimental features and how to use them.

@anmenaga anmenaga merged commit e803d3b into PowerShell:master Feb 4, 2021
@daxian-dbw daxian-dbw deleted the predict branch February 5, 2021 01:13
@iSazonov iSazonov added this to the 7.2.0-preview.3 milestone Feb 5, 2021
@ghost
Copy link

ghost commented Feb 12, 2021

🎉v7.2.0-preview.3 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants