tristan/gptel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gptel/gptel-ollama.el

168 lines
5.7 KiB
EmacsLisp
Raw Normal View History

gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; gptel-ollama.el --- Ollama support for gptel -*- lexical-binding: t; -*-
;; Copyright (C) 2023 Karthik Chikmagalur
;; Author: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
;; Keywords: hypermedia
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
;; This file adds support for the Ollama LLM API to gptel
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; Code:
(require 'gptel)
(require 'cl-generic)
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(declare-function json-read "json" ())
(defvar json-object-type)
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;; Ollama
(cl-defstruct (gptel-ollama (:constructor gptel--make-ollama)
(:copier nil)
(:include gptel-backend)))
gptel: Appease the byte compiler.
2023-11-07 20:20:54 -08:00
(defvar-local gptel--ollama-context nil
"Context for ollama conversations.
This variable holds the context array for conversations with
Ollama models.")
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(cl-defmethod gptel-curl--parse-stream ((_backend gptel-ollama) info)
";TODO: "
(when (bobp)
(re-search-forward "^{")
(forward-line 0))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(let* ((content-strs) (content) (pt (point)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(condition-case nil
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(while (setq content (gptel--json-read))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(setq pt (point))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((done (map-elt content :done))
(response (map-elt content :response)))
(push response content-strs)
gptel: Use libjansson support if available Using the libjansson JSON parser gives us a modest boost in speed. It's not as significant a speedup as it is for LSP clients since our jSON payloads are smaller and less frequent -- but we might as well use it. * gptel.el (gptel--json-read, gptel--json-encode, gptel--url-get-response, gptel--parse-response): Define macros to use the libjansson-supported `json-parse-buffer` and `json-serialize`. Replace use of `json-encode` and `json-read` appropriately. * gptel-openai.el: (gptel-curl--parse-stream) : Use `gptel--json-read` instead of `json-read`. * gptel-ollama.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-gemini.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * gptel-curl.el (gptel-curl--get-args, gptel-curl--get-response, gptel-curl--log-response, gptel-curl--stream-cleanup, gptel-curl--parse-response): Use `gptel--json-read` and `gptel--json-encode` in place of the json.el versions. * gptel-anthropic.el (gptel-curl--parse-stream): Use `gptel--json-read` instead of `json-read`. * test/gptel-org-test.el: Use `gptel--json-read`.
2024-03-13 01:53:06 -07:00
(unless (eq done :json-false)
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(with-current-buffer (plist-get info :buffer)
(setq gptel--ollama-context (map-elt content :context)))
gptel: Appease the byte compiler.
2023-11-07 20:20:54 -08:00
(goto-char (point-max)))))
gptel-ollama: Adjust Ollama stream parser for libjansson * gptel-ollama.el (gptel-curl--parse-stream): libjansson and json.el behave differently w.r.t moving point when there is a parsing error. Fix by explicitly handling point when there is an error. (#255)
2024-03-15 22:27:10 -07:00
(error (goto-char pt)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(apply #'concat (nreverse content-strs))))
(cl-defmethod gptel--parse-response ((_backend gptel-ollama) response info)
(when-let ((context (map-elt response :context)))
(with-current-buffer (plist-get info :buffer)
(setq gptel--ollama-context context)))
(map-elt response :response))
(cl-defmethod gptel--request-data ((_backend gptel-ollama) prompts)
gptel: docstrings for multi-LLM support, bump version * gptel.el (gptel, gptel--insert-response, gptel-temperature, gptel-pre-response-hook, gptel-response-filter-functions, gptel-stream, gptel--convert-org, gptel-pre-response-hook, gptel-max-tokens, gptel-mode, gptel-request, gptel--insert-response, gptel-set-topic, gptel--convert-org): Replace mentions of "ChatGPT" with "LLM" or equivalent. Update package description and remove commented out obsolete code. Bump version to 0.6.5. * gptel-transient.el (gptel--crowdsourced-prompts-url, gptel--crowdsourced-prompts, gptel-menu, gptel-system-prompt, gptel-rewrite-menu, gptel--infix-max-tokens, gptel--suffix-system-message): Ditto. * gptel-ollama.el (gptel--request-data): Ditto * gptel-kagi.el (gptel--request-data): Ditto * gptel-curl.el (gptel-curl--stream-insert-response, gptel-curl--stream-cleanup, gptel-curl--stream-filter): Ditto
2024-02-03 14:20:41 -08:00
"JSON encode PROMPTS for Ollama."
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((prompts-plist
`(:model ,gptel-model
,@prompts
:stream ,(or (and gptel-stream gptel-use-curl
(gptel-backend-stream gptel-backend))
:json-false))))
(when gptel--ollama-context
(plist-put prompts-plist :context gptel--ollama-context))
prompts-plist))
(cl-defmethod gptel--parse-buffer ((_backend gptel-ollama) &optional _max-entries)
gptel-ollama: Fix buffer parsing * gptel-ollama.el (gptel--parse-buffer): The prompt construction for Ollama fails when starting from (point-min). Fix by checking if a valid text-property match object is found in the parsing.
2023-11-07 22:37:59 -08:00
(let ((prompts)
(prop (text-property-search-backward
'gptel 'response
(when (get-char-property (max (point-min) (1- (point)))
'gptel)
t))))
(if (and (prop-match-p prop)
(prop-match-value prop))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(user-error "No user prompt found!")
(setq prompts (list
:system gptel--system-message
:prompt
gptel-ollama: Fix buffer parsing * gptel-ollama.el (gptel--parse-buffer): The prompt construction for Ollama fails when starting from (point-min). Fix by checking if a valid text-property match object is found in the parsing.
2023-11-07 22:37:59 -08:00
(if (prop-match-p prop)
Add multiline prefixes & AI response prefixes (#142) gptel: Add customizable prompt/response prefixes gptel.el (gptel-prompt-prefix-alist, gptel-response-prefix-alist, gptel-prompt-prefix-string, gptel-response-prefix-string, gptel--url-get-response): Add customizable response prefixes (per major-mode) in `gptel-response-prefix-alist`. Rename `gptel-prompt-string` -> `gptel-prompt-prefix-string` The function `gptel-response-prefix-string` returns the prefix string for the response in the current major-mode. gptel-openai.el, gptel-ollama.el (gptel--parse-buffer): Remove the prompt and response prefixes when creating prompt strings to send to the LLM API. gptel-curl.el (gptel-curl--stream-cleanup, gptel-curl--stream-insert-response): Insert the response prefix for the current major-mode before inserting the LLM API response.
2023-12-15 19:30:16 +02:00
(string-trim
(buffer-substring-no-properties (prop-match-beginning prop)
(prop-match-end prop))
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
(regexp-quote (gptel-prompt-prefix-string)))
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
(regexp-quote (gptel-response-prefix-string))))
"")))
prompts)))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
;;;###autoload
(cl-defun gptel-make-ollama
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
(name &key curl-args header key models stream
gptel-ollama: Use default host in gptel-make-ollama
2024-01-10 09:22:34 -08:00
(host "localhost:11434")
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(protocol "http")
(endpoint "/api/generate"))
"Register an Ollama backend for gptel with NAME.
Keyword arguments:
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
CURL-ARGS (optional) is a list of additional Curl arguments.
gptel-ollama: Use default host in gptel-make-ollama
2024-01-10 09:22:34 -08:00
HOST is where Ollama runs (with port), defaults to localhost:11434
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
MODELS is a list of available model names.
STREAM is a boolean to toggle streaming responses, defaults to
false.
PROTOCOL (optional) specifies the protocol, http by default.
ENDPOINT (optional) is the API endpoint for completions, defaults to
\"/api/generate\".
HEADER (optional) is for additional headers to send with each
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
request. It should be an alist or a function that retuns an
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
alist, like:
((\"Content-Type\" . \"application/json\"))
KEY (optional) is a variable whose value is the API key, or
gptel: Fix prompt collection bug + linting * gptel.el: Update package description. * gptel-gemini.el(gptel--request-data, gptel--parse-buffer): Add model temperature to request correctly. * gptel-ollama.el(gptel--parse-buffer): Ensure that newlines are trimmed correctly even when `gptel-prompt-prefix-string` and `gptel-response-prefix-string` are absent. Fix formatting and linter warnings. * gptel-openai.el(gptel--parse-buffer): Ditto.
2023-12-20 14:23:45 -08:00
function that returns the key. This is typically not required
for local models like Ollama.
gptel-ollama, gptel-openai: Add example of backend creation README: Fix error with Ollama backend instructions
2023-10-29 00:31:56 -07:00
Example:
-------
(gptel-make-ollama
\"Ollama\"
:host \"localhost:11434\"
gptel: address byte-compile and checkdoc warnings * gptel.el, gptel-transient.el, gptel-openai.el, gptel-ollama.el
2023-10-31 20:18:00 -07:00
:models \\='(\"mistral:latest\")
gptel-ollama, gptel-openai: Add example of backend creation README: Fix error with Ollama backend instructions
2023-10-29 00:31:56 -07:00
:stream t)"
gptel: checkdoc linting and indentation rules * gptel.el (gptel-use-header-line, gptel--parse-buffer): Docstrings. * gptel-transient.el (gptel--transient-read-variable): Docstring. * gptel-openai.el (gptel-make-openai, gptel-make-azure): Add indent declaration. * gptel-ollama.el (gptel-make-ollama): Add indent declaration. * gptel-kagi.el (gptel-make-kagi): Add indent declaration. * gptel-gemini.el (gptel-make-gemini): Add indent declaration.
2024-01-19 14:19:22 -08:00
(declare (indent 1))
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
(let ((backend (gptel--make-ollama
gptel-openai: curl-args slot in gptel-backend (#221) gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure): Add a curl-args slot to the backend struct for additional Curl arguments. Usage example: This can be used to set the `--cert` and `--key` options in a custom backend that uses mutal TLS to communicate with an OpenAI proxy/gateway. gptel-curl.el (gptel-curl--get-args): Add backend-specific curl-args when creating HTTP requests. gptel-gemini.el (gptel-make-gemini): Add a curl-args slot to the constructor. gptel-kagi.el (gptel-make-kagi): Ditto. gptel-ollama.el (gptel-make-ollama): Ditto.
2024-02-21 00:21:46 +01:00
:curl-args curl-args
gptel: Add multi-llm support README.org: Update README with new information and a multi-llm demo. gptel.el (gptel-host, gptel--known-backends, gptel--api-key, gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request, gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state, gptel, gptel-backend): Integrate multiple LLMs through the introcution of gptel-backends. Each backend is composed of two pieces: 1. An instance of a cl-struct, containing connection, authentication and model information. See the cl-struct `gptel-backend` for details. A separate cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and Ollama) that inherits from the generic gptel-backend type. 2. cl-generic implementations of specific tasks, like gathering up and formatting context (previous user queries and LLM responses), parsing responses or responses streams etc. The four tasks currently specialized this way are carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for parsing the response). See their implementations for details. Some effort has been made to limit the number of times dispatching is done when reading streaming responses. When a backend is created, it is registered in the collection `gptel--known-backends` and can be accessed by name later, such as from the transient menu. Only one of these backends is active at any time in a buffer, stored in the buffer-local variable `gptel-backend`. Most messaging, authentication etc accounts for the active backend, although there might be some leftovers. When using `gptel-request` or `gptel-send`, the active backend can be changed or let-bound. - Obsolete `gptel-host` - Fix the rear-sticky property when restoring sessions from files. - Document some variables (not user options), like `gptel--debug` gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure, gptel-make-gpt4all): This file (currently always loaded) sets up the generic backend struct and includes constructors for creating OpenAI, GPT4All and Azure backends. They all use the same API so a single set of defgeneric implemenations suffices for all of them. gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct, constructor and requisite defgeneric implementations for Ollama support. gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider, gptel-suffix-send): - Provide access to all available LLM backends and models from `gptel-menu`. - Adjust keybindings in gptel-menu: setting the model and query parameters is now bound to two char keybinds, while redirecting input and output is bound to single keys.
2023-10-23 23:40:52 -07:00
:name name
:host host
:header header
:key key
:models models
:protocol protocol
:endpoint endpoint
:stream stream
:url (if protocol
(concat protocol "://" host endpoint)
(concat host endpoint)))))
(prog1 backend
(setf (alist-get name gptel--known-backends
nil nil #'equal)
backend))))
(provide 'gptel-ollama)
;;; gptel-ollama.el ends here
Reference in a new issue Copy permalink