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

.Net: Semantic Kernel Exception when running TextMemory Plugin Sample #4418

Closed
AshD opened this issue Dec 24, 2023 · 2 comments · Fixed by #4471
Closed

.Net: Semantic Kernel Exception when running TextMemory Plugin Sample #4418

AshD opened this issue Dec 24, 2023 · 2 comments · Fixed by #4471
Assignees
Labels
.NET Issue or Pull requests regarding .NET code

Comments

@AshD
Copy link

AshD commented Dec 24, 2023

Describe the bug
Running TextMemory Plugin Sample
https://github.com/microsoft/semantic-kernel/blob/main/dotnet/samples/KernelSyntaxExamples/Example15_TextMemoryPlugin.cs

in PART 4: TextMemoryPlugin Recall in a Prompt Function throws
Microsoft.SemanticKernel.KernelException: 'A function named argument must contain a name and value separated by a '=' character.'

In line
var aboutMeOracle = kernel.CreateFunctionFromPrompt(RecallFunctionDefinition, new OpenAIPromptExecutionSettings() { MaxTokens = 100 });

Has the syntax for defining the Recall function changed? The below is the one from the sample.

            const string RecallFunctionDefinition = @"
Consider only the facts below when answering questions:

BEGIN FACTS
About me: {{recall='where did I grow up?'}}
About me: {{recall='where do I live now?'}}
END FACTS

Question: {{$input}}

Answer:
";

I am on dotnet 1.01 release and Kernel memory 1.0.1-alpha

Thanks,
Ash

@shawncal shawncal added .NET Issue or Pull requests regarding .NET code triage labels Dec 24, 2023
@github-actions github-actions bot changed the title Semantic Kernel Exception when running TextMemory Plugin Sample .Net: Semantic Kernel Exception when running TextMemory Plugin Sample Dec 24, 2023
@glahaye
Copy link
Contributor

glahaye commented Jan 3, 2024

Looking at this...

@glahaye
Copy link
Contributor

glahaye commented Jan 3, 2024

It turns out the CodeTokenizer routinely causes first-chance (caught) exceptions to determine whether tokens belong to function names of named argument blocks. This is inefficient but also can be startling depending on how one has set one's configuration for breaking on exceptions.

See PR #4471 for fix

github-merge-queue bot pushed a commit that referenced this issue Jan 5, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
### Motivation and Context
The CodeTokenizer routinely causes first-chance (caught) exceptions to
determine whether tokens belong to function names of named argument
blocks. This is inefficient but also can be startling depending on how
one has set one's configuration for breaking on exceptions.

See #4418 

### Description
CodeTokenizer now uses a new method from NamedArgBlock to determine
whether a string could result in a NamedArgBlock instead of resorting to
causing exceptions to gather the same information.

### Contribution Checklist
- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
@github-project-automation github-project-automation bot moved this to Sprint: Done in Semantic Kernel Jan 5, 2024
Bryan-Roe pushed a commit to Bryan-Roe-ai/semantic-kernel that referenced this issue Oct 6, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…ft#4471)

### Motivation and Context
The CodeTokenizer routinely causes first-chance (caught) exceptions to
determine whether tokens belong to function names of named argument
blocks. This is inefficient but also can be startling depending on how
one has set one's configuration for breaking on exceptions.

See microsoft#4418 

### Description
CodeTokenizer now uses a new method from NamedArgBlock to determine
whether a string could result in a NamedArgBlock instead of resorting to
causing exceptions to gather the same information.

### Contribution Checklist
- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
.NET Issue or Pull requests regarding .NET code
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants