From 875b8a49fd70022582b307cfd076f2660d838c66 Mon Sep 17 00:00:00 2001 From: jan0ski Date: Sun, 14 Jan 2024 08:47:01 -0500 Subject: [PATCH 1/2] chore(docs): fix 404s on rustdocs for auraed, remove unused paths --- Makefile | 2 +- docs/stdlib/index.md | 6 +++--- mkdocs.yml | 7 ++++--- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 0bc723f3c..84546030d 100644 --- a/Makefile +++ b/Makefile @@ -315,7 +315,7 @@ endif .PHONY: docs-crates docs-crates: musl $(GEN_TS) $(GEN_RS) ## Build the crate (documentation) - $(cargo) doc --target $(uname_m)-unknown-linux-musl --no-deps --package auraed + $(cargo) doc --no-deps --package auraed $(cargo) doc --no-deps --package auraescript $(cargo) doc --no-deps --package client $(cargo) doc --no-deps --package aer diff --git a/docs/stdlib/index.md b/docs/stdlib/index.md index 746079feb..c351d6480 100644 --- a/docs/stdlib/index.md +++ b/docs/stdlib/index.md @@ -37,7 +37,7 @@ For example the service that mutates a `Cell` should be called `CellService`. ### What are functions? -A function is a discreet piece of functionality designed to execute on the "backend," or directly by an Aurae Daemon server. +A function is a discreet piece of functionality designed to execute on the "backend", or directly by an Aurae Daemon server. The library is designed to be executed procedurally and quickly. Many function calls per second is a reasonable expectation for any client. @@ -67,7 +67,7 @@ import "path/to/other.proto"; // everything else -``` +``` Generally follow these rules: @@ -87,7 +87,7 @@ enum FooBar { FOO_BAR_FIRST_VALUE = 1; FOO_BAR_SECOND_VALUE = 2; } -``` +``` A notable exception to the public specification above is the Aurae project's preference for standardizing the objects that are used as the request and response messages. diff --git a/mkdocs.yml b/mkdocs.yml index cd9c26066..855d82716 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -25,12 +25,13 @@ nav: - Reference: - auraed: /crate/auraed - auraescript: /crate/auraescript - - implementors: /crate/implementors - - macros: /crate/macros + - client: /crate/client + - aer: /crate/aer - src: - auraed: /crate/src/auraed/lib.rs.html - auraescript: /crate/src/auraescript/lib.rs.html - - macros: /crate/src/macros/lib.rs.html + - client: /crate/src/client/lib.rs.html + - aer: /crate/src/aer/lib.rs.html - Blog: - Isolation with Aurae Cells: /blog/2022-10-24-aurae-cells - Cgroups in Aurae: /blog/2022-12-11-cgroups From 7f7dc40163e4b19628dca795ff54a4e4ad08eb31 Mon Sep 17 00:00:00 2001 From: jan0ski Date: Sun, 14 Jan 2024 08:55:13 -0500 Subject: [PATCH 2/2] chore(doc): correct a few typos --- api/README.md | 6 +++--- docs/stdlib/index.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/api/README.md b/api/README.md index 660335ba4..c5f891f09 100644 --- a/api/README.md +++ b/api/README.md @@ -20,7 +20,7 @@ For example, Aurae has the concept of an `Executable` resource which represents The core resources are intended to be fundamental and composable, similar to the objects and structures found in modern programming languages. -Resources are defined directly in the corresponding protobuf definition and later generated into code for various languages. A resource's corresponding message should never be passed to directly to, or received directly from an RPC. +Resources are defined directly in the corresponding protobuf definition and later generated into code for various languages. A resource's corresponding message should never be passed directly to, or received directly from an RPC. In protobuf terms a resource is a [message](https://protobuf.dev/programming-guides/proto3/#simple). @@ -31,7 +31,7 @@ Services are a section of the API designed to be a way of grouping functionality A service should be discreet in the terms of how it mutates the system. For example if a service starts, it should stop. If a service allocates, it should free. And so on. Services should be named after a resource or set of functionality around common resources. -Services should follow the `service NameService` paradigm as defined in the [style guide](https://protobuf.dev/programming-guides/style/) +Services should follow the `service NameService` paradigm as defined in the [style guide](https://protobuf.dev/programming-guides/style/). For example the service that mutates a `Cell` should be called `CellService`. @@ -89,7 +89,7 @@ enum FooBar { } ``` -A notable exception to the public specification above is the Aurae projects preference for standardizing the objects that are used as the request and response messages. +A notable exception to the public specification above is the Aurae project's preference for standardizing the objects that are used as the request and response messages. The traditional convention that is meant to reduce the likelihood of future breaking changes and ease the creation of macros for generating code: diff --git a/docs/stdlib/index.md b/docs/stdlib/index.md index c351d6480..c5f891f09 100644 --- a/docs/stdlib/index.md +++ b/docs/stdlib/index.md @@ -20,7 +20,7 @@ For example, Aurae has the concept of an `Executable` resource which represents The core resources are intended to be fundamental and composable, similar to the objects and structures found in modern programming languages. -Resources are defined directly in the corresponding protobuf definition and later generated into code for various languages. A resource's corresponding message should never be passed directly to or received directly from an RPC. +Resources are defined directly in the corresponding protobuf definition and later generated into code for various languages. A resource's corresponding message should never be passed directly to, or received directly from an RPC. In protobuf terms a resource is a [message](https://protobuf.dev/programming-guides/proto3/#simple). @@ -67,7 +67,7 @@ import "path/to/other.proto"; // everything else -``` +``` Generally follow these rules: @@ -87,7 +87,7 @@ enum FooBar { FOO_BAR_FIRST_VALUE = 1; FOO_BAR_SECOND_VALUE = 2; } -``` +``` A notable exception to the public specification above is the Aurae project's preference for standardizing the objects that are used as the request and response messages.