Updates for new OpenAI release post dev day

[transitive-bullshit]

• adds support for tools
• changes some other types required by openai updates

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dexter	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 9, 2023 2:23am

[rileytomasek]

I'm not sure this is the best way to think about the relationship between the legacy functions and the new tools.

It seems like the legacy functions have the same structure and function, but are now nested under tools. I think all of the schema/spec/parser/implementation parts of AIFunction should stay the same (without tools) and should be used by a new higher level tools abstraction that is just wraps a function for now, and presumably other things in the future.

Also, can you please start writing real commit messages :)

[transitive-bullshit]

It seems like the legacy functions have the same structure and function, but are now nested under tools. I think all of the schema/spec/parser/implementation parts of AIFunction should stay the same (without tools) and should be used by a new higher level tools abstraction that is just wraps a function for now, and presumably other things in the future.

Sounds good & agreed. I haven't actually used createAIFunction yet, so that would be a good first step haha

Also, can you please start writing real commit messages :)

Yep; sorry about that. I try to use real git-flow commit messages for substantive stuff and commit-emoji for minor things. Will work on breaking that habit for dexa stuff. :)

[transitive-bullshit]

This PR is now dependent on dexaai/openai-fetch#38

[transitive-bullshit]

@rileytomasek I changed the tools and function assistant types and utility functions to have an explicit assistant prefix.

I also fixed all the lingering TS issues, mainly due to the message stuff. Such a PITA.

Not 100% sure I incorporated the assistant prefix feedback you gave as you were expecting. Happy to adjust.

[rileytomasek]

This looks good other than the name changes. Can we hold off removing the Message.name stuff until everything settles from the new releases and it's clear what the status of name is? We're using it internally and I'd rather not change until we know it's definitely gone.

Edit: these changes are also going to require a major version bump, right?

[rileytomasek]

Do we need this now that you fixed the types for openai-fetch?

[transitive-bullshit]

Good question && yes, unfortunately TS complains without it.

One thing I've noticed is that the new openai types seem to have gotten a lot stricter in terms of inputs/outputs used in different places. I could be wrong since I've only just started getting back into things.

[transitive-bullshit]

[rileytomasek]

i think this is just from their jank types so we can leave as is for now

[rileytomasek]

Why this change? We are using this internally and I'd rather not change the existing code unless there is a reason for this.

[transitive-bullshit]

hmmm was just a part of my removing name, and I thought it made more sense to have a util to format the name identifier directly than an object which at the time I was thinking would no longer have a name property.

all good && will revert

[transitive-bullshit]

This looks good other than the name changes. Can we hold off removing the Message.name stuff until everything settles from the new releases and it's clear what the status of name is? We're using it internally and I'd rather not change until we know it's definitely gone.

Done.

Edit: these changes are also going to require a major version bump, right?

Yes, though it's a brand new package, so we could just do a minor? I'm fine either way.

[transitive-bullshit]

Fixes #8 as well

[rileytomasek]

You missed these names when reverting

[transitive-bullshit]

ahhh good catch :) will revert

[rileytomasek]

Everything looks good, except for the names I suggested 😂

What do you think of:

System
User
Assistant
FuncCall
FuncResult
ToolCall
ToolResult

And then mirror to Msg methods like:

Msg.system()
Msg.user()
Msg.assistant()
Msg.funcCall()
Msg.funcResult()
Msg.toolCall()
Msg.toolResult()

Msg.isSystem()
Msg.isUser()
Msg.isAssistant()
Msg.isFuncCall()
Msg.isFuncResult()
Msg.isToolCall()
Msg.isToolResult()

[transitive-bullshit]

Everything looks good, except for the names I suggested 😂

What do you think of:

System
User
Assistant
FuncCall
FuncResult
ToolCall
ToolResult

And then mirror to Msg methods like:

Msg.system()
Msg.user()
Msg.assistant()
Msg.funcCall()
Msg.funcResult()
Msg.toolCall()
Msg.toolResult()

Msg.isSystem()
Msg.isUser()
Msg.isAssistant()
Msg.isFuncCall()
Msg.isFuncResult()
Msg.isToolCall()
Msg.isToolResult()

I'm not opinionated when it comes to naming; the only problem I see w/ this is that ToolCall type represents both the individual tool call { id: string, type: string, function: FunctionCall } as well as the tool call message type, which represents an array of tool calls.

It's the same issue w/ FunctionCall type except you got around that by shortening the message function call type to FuncCall to avoid the naming collision.

I don't have a strong feeling either way.

[transitive-bullshit]

If we call the tool calls message ToolCalls or ToolsCall, that would get around it. ToolsCall sounds better, but it's weird for the underlying field to be tool_calls and then refer to it as a ToolsCall...

[rileytomasek]

🚢