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

Add initial support for variable resolution from user input #108

Merged
merged 7 commits into from
Jul 30, 2024

Conversation

martin-fleck-at
Copy link

@martin-fleck-at martin-fleck-at commented Jul 29, 2024

What it does

  • Ensure we always create a variable part even for undefined variables
    -- Prompt text will then default to user text (including '#')

  • Allow adopters to register variable resolution contributions
    -- Given a particular variable name, argument and location

  • Automatically resolve all variable parts in a chat request
    -- Ensure parts always provide a matching prompt text

Relates to https://github.com/eclipsesource/osweek-2024/issues/46

How to test

  • Test that normal chat still works as before
  • Use variable '#today' in your prompt and try different arguments such as 'inUnixSeconds' or 'inIso8601' combined as '#today:inIso8601' to see different results.

ai-variables

Follow-ups

Review checklist

Reminder for reviewers

@@ -26,16 +26,17 @@ export interface ChatMessage {
export const getMessages = (model: ChatModel, includeResponseInProgress = false): ChatMessage[] =>
model.getRequests().flatMap(request => {
const messages: ChatMessage[] = [];
const query = request.message.parts.map(part => part.promptText).join('');
Copy link
Author

Choose a reason for hiding this comment

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

👀

- Ensure we always create a variable part even for undefined variables
-- Prompt text will then default to user text (including '#')

- Allow adopters to register variable resolution contributions
-- Given a particular variable name, argument and location

- Automatically resolve all variable parts in a chat request
-- Ensure parts always provide a matching prompt text

Relates to eclipsesource/osweek-2024#46

Co-authored-by: Christian W. Damus <[email protected]>"
- Allow adopters to register resolvers with priority
- Ensure we use a dedicated frontend service to init contributions
- Push variable service into core
-- Generic variable handling for all agents and UI layers
-- Chat-specific variable handling only in the chat layer
Copy link
Member

@eneufeld eneufeld left a comment

Choose a reason for hiding this comment

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

Some questions

@@ -40,8 +39,7 @@ export default new ContainerModule(bind => {
bind(ChatRequestParserImpl).toSelf().inSingletonScope();
bind(ChatRequestParser).toService(ChatRequestParserImpl);

bind(DummyChatVariablesService).toSelf().inSingletonScope();
bind(ChatVariablesService).toService(DummyChatVariablesService);
bind(AIVariableContribution).to(TodayVariableContribution).inSingletonScope();
Copy link
Member

Choose a reason for hiding this comment

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

why is the todayvariable in chat only?

Copy link
Collaborator

Choose a reason for hiding this comment

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

To demonstrate the chat-specific variables context information (which just happens not to be used). Ideally it will be moved into a sample extension.

Copy link
Member

Choose a reason for hiding this comment

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

let's move to ai-core then

}

return;
return new ChatRequestVariablePart(varRange, name, variableArg);
Copy link
Member

Choose a reason for hiding this comment

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

what happens if the variable cannot be resolved? we still show the chatpart?

Copy link
Author

Choose a reason for hiding this comment

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

What exactly do you mean by 'show'? The part remains unresolved and in the textual part (promptText) it will simply keep the original syntax. On resolution the prompt text is changed. You can also check if a part is resolved.

Copy link
Member

Choose a reason for hiding this comment

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

so we keep the variable in the prompt even if we can't resolve it, something vscode doesn't do, but this can be changed in a follow up

export interface IChatVariableData {
id: string;
name: string;
export interface VsCodeChatRequestVariableValueData {
Copy link
Member

Choose a reason for hiding this comment

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

why is it called vsCode... now?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The intention is that this is to support the interface with VSCode chat extensions. Perhaps it could have a more generic name.

Copy link
Author

Choose a reason for hiding this comment

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

We could call it Extension but it is a specific format for the extension API that VS Code expects. For now it is not really used and could be removed as well.

Copy link
Member

Choose a reason for hiding this comment

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

if it is not used I would tend to remove it

bind(ChatVariablesService).toService(DummyChatVariablesService);
bind(DefaultAIVariableService).toSelf().inSingletonScope();
bindContributionProvider(bind, AIVariableContribution);
bind(AIVariableService).toService(DefaultAIVariableService);
Copy link
Member

Choose a reason for hiding this comment

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

why is this registered in the chat module?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Right. This should be registered in core.

}

protected initContributions(): void {
this.contributionProvider.getContributions().forEach(contribution => contribution.registerVariables(this));
Copy link
Member

Choose a reason for hiding this comment

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

why not retrieve the necessary information from the contribution and register the resolver here directly? we now go to the contribution give it the service and it calls the service to provide data, this is a bit confusing

Copy link
Author

Choose a reason for hiding this comment

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

I think this is the more common Theia way to do this, cf. CommandService and CommandContribution. I think we should not confuse AIVariableResolver with AIVariableContribution. A contribution may register variables and resolvers but it may also unregister a variable or use other parts of the service.

Copy link
Member

Choose a reason for hiding this comment

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

fine by me

cdamus and others added 2 commits July 30, 2024 13:26
- Move today variable contribution to core package as it is generic
- Remove VS code extension-specific interfaces
- Do not register variable service in backend
@martin-fleck-at martin-fleck-at merged commit ba3bf65 into feat/ai-chat Jul 30, 2024
1 check passed
@sdirix sdirix deleted the feat/46-variables branch August 12, 2024 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants