ac-qu-ai-nt is a project I'm working on, using artificial intelligence to break down the user's query, acquire knowledge, and transfer insights to the user('s mind).

This is a placeholder while I take small steps to build out the project.

Installation

Automatically Updatable

You won't find it very useful yet, because it doesn't really do much of anything, but you can install the multibinary with Binstall. This means you don't need to have the same development environment (which will require the Vulkan SDK and CUDA Toolkit in the future) in order to use the program, because you'll just download a precompiled executable.

cargo-binstall -y ac-qu-ai-nt

Install cargo-update and periodically run

cargo install-update --all

in order to keep this program up to date.

I'm not sure if you need a Rust compiler installed for either or if they can work standalone.

Just the Executable

Head to the Releases page and download the asset corresponding to your computer architecture and operating system.

Decompress the archive and place the executable contained within it somewhere useful to you (e.g. in a directory in your PATH variable).

Usage

If it's your preference, you should be able to double click the executable in the folder to be able to run it (defaulting to launching a graphical interface (once I actually make one lol)).

You could also type

ac-qu-ai-nt

on the command line to run it. This is also a way to launch a GUI (once there actually is one) for the application.

Command Line Interface

It's going to be a goal of this project for there to be feature parity between the GUI, CLI, and TUI.

If you want to use its command line interface, start with

ac-qu-ai-nt cli

to see what capabilities are available.

(This is an alias for ac-qu-ai-nt cli-clap to allow the possibility of experimenting with different implementations of the same type of interface.)

Contributing

Issues and Pull Requests

Please create an issue before working on a pull request. It's helpful for you to know if the idea you have in mind will for sure be incorporated into the project, and won't require you to acquaint yourself with the project internals. It even opens the floor for someone else to do the work implementing it for you.

Some existing issues are labeled straightforward and expected to be the easiest to work on, if you'd like to try.

Project Breakdown

This is a summary of the crates in this project and how they are used:

flowchart TD
core --> cli-clap
core --> gui-eframe
core --> tui-ratatui
cli-clap --> multibinary
gui-eframe --> multibinary
tui-ratatui --> multibinary

`core`

The core of the project, where code for large language model and embedding model inference using llama-cpp-2 will be (because it's not started yet at the time of writing), where ingesting data will be done, and where public APIs that the other crates (cli-clap, gui-eframe, and tui-ratatui) use will be.

Each of the interface crates are expected to have feature parity (as in capability, not as in a Cargo feature) where possible, but we'll see how that goes.

`cli-clap`

A command line interface (CLI) for the project written with clap.

`gui-eframe`

A graphical user interface (GUI) for the project written with eframe for egui.

As of right now, it isn't started yet.

`tui-ratatui`

A terminal user interface (TUI) for the project written with ratatui.

As of right now, it isn't started yet.

Versioning

This project aims to adhere to semantic versioning using Conventional Commits, conducted by Release-plz.

To be more specific about what a breaking change could entail:

a previously successful compilation now failing
the program (wrongly) exiting, panicking, reporting an error, etc, where it didn't previously
changing the expected result of an existing integration test (not sure if unit tests would count)

All the crates in this project have a minimum supported Rust version (MSRV) of 1.76, the release succeeding the one that stabilized async fn in traits (which the core crate of this project is expected to make use of). I intend to test this in CI (GitHub Actions) in the future to identify if it ever gets raised by changes but I have not set this up yet. Raising the MSRV will be considered a breaking change --- my justification is that it seems more appropriate for an application like this. This may be reconsidered if Cargo's MSRV-aware resolver is stabilized.