From 6100ca8ffc8c3a93edd6df5f47245a59cda95e5b Mon Sep 17 00:00:00 2001 From: Olivier Cots Date: Tue, 1 Sep 2026 21:40:58 +0200 Subject: [PATCH] docs: convert ordered lists to bullets across src/ and docs/src/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DocumenterVitepress mis-renders ordered lists — valid 1./2./3. source comes out as
    , the first item absorbed as unstyled prose (LuxDL/DocumenterVitepress.jl#150, open, no fix). src/Solutions/build_solution.jl (2 trajectory-data-format items, each with a nested sub-list — outer marker only changes, nested markers and indentation stay, re-anchored under the new "- " width) and src/Building/name_validation.jl (5-point validation check). docs/src/getting-started.md and docs/src/index.md (1 list each, 2 and 4 items) — hand-written prose, never previously swept. Marker-only change, no prose edits. Not build-verified here: this repo's docs build currently fails for an unrelated, pre-existing reason — `UndefVarError: MakieBackend not defined in CTBase.Plotting` on docs/src/serialization/plotting.md:83-85 (`Makie.plot(sol)`), nothing to do with ordered lists. Verified by source grep instead (`grep -rn '^[0-9]+\. ' src/ docs/src/` -> empty) and by the identical pattern holding clean, build-confirmed, on the other four repos in this sweep (CTBase, CTSolvers, CTFlows.jl, OptimalControl). Companion PRs open in parallel on OptimalControl, CTBase, CTSolvers and CTFlows.jl. Full plan: control-toolbox/OptimalControl.jl .reports/campaign/M-ordered-list-sweep.md Co-Authored-By: Claude Opus 5 --- docs/src/getting-started.md | 4 ++-- docs/src/index.md | 8 ++++---- src/Building/name_validation.jl | 10 +++++----- src/Solutions/build_solution.jl | 18 +++++++++--------- 4 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/src/getting-started.md b/docs/src/getting-started.md index 6cda02c4..14be978b 100644 --- a/docs/src/getting-started.md +++ b/docs/src/getting-started.md @@ -29,14 +29,14 @@ It provides: Two things to keep in mind: -1. **No top-level exports.** `using CTModels` loads the package but brings no symbols +- **No top-level exports.** `using CTModels` loads the package but brings no symbols into scope. Every symbol is accessed via its qualified path: ```julia CTModels.Building.state! # ✓ always works CTModels.Solutions.build_solution CTModels.Init.build_initial_guess ``` -2. **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable +- **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable `PreModel`, then frozen into an immutable `Model` by `build`. The `Model` is the object every downstream package (solver, initial-guess builder, serializer) consumes. diff --git a/docs/src/index.md b/docs/src/index.md index 4d72b47b..c5a58942 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -81,10 +81,10 @@ The core **optimal control model** is expressed via: In practice you typically: -1. Specify **time dependence** and **time models** (fixed or free final time, etc.). -2. Describe **state, control, and variable spaces**. -3. Provide **dynamics** and **objective** functions. -4. Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary. +- Specify **time dependence** and **time models** (fixed or free final time, etc.). +- Describe **state, control, and variable spaces**. +- Provide **dynamics** and **objective** functions. +- Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary. The numerical **solution** of an OCP is represented by: diff --git a/src/Building/name_validation.jl b/src/Building/name_validation.jl index 0a69da74..18eb2ca5 100644 --- a/src/Building/name_validation.jl +++ b/src/Building/name_validation.jl @@ -124,11 +124,11 @@ $(TYPEDSIGNATURES) Validate that a name and its components don't conflict with existing names. Performs comprehensive validation: -1. Name is not empty -2. Components are not empty -3. Name not in components (internal conflict) -4. No duplicates in components -5. No conflicts with existing names in other components (global uniqueness) +- Name is not empty +- Components are not empty +- Name not in components (internal conflict) +- No duplicates in components +- No conflicts with existing names in other components (global uniqueness) # Arguments diff --git a/src/Solutions/build_solution.jl b/src/Solutions/build_solution.jl index c2cc7ebe..218e367e 100644 --- a/src/Solutions/build_solution.jl +++ b/src/Solutions/build_solution.jl @@ -38,15 +38,15 @@ for memory efficiency. Otherwise, it uses `MultipleTimeGridModel` to store each Trajectory data (`X`, `U`, `P`, `path_constraints_dual`) can be provided in two formats: -1. **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)` - - Each row corresponds to a time point in the associated grid - - Each column corresponds to a component dimension - - Example: `X` is `(length(T_state), state_dimension(ocp))` - -2. **Function format**: `Function` that takes time `t::Float64` and returns a vector - - Allows analytical or pre-interpolated trajectories - - Function signature: `t -> Vector{Float64}` of appropriate dimension - - Useful for exact solutions or when data is already interpolated +- **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)` + - Each row corresponds to a time point in the associated grid + - Each column corresponds to a component dimension + - Example: `X` is `(length(T_state), state_dimension(ocp))` + +- **Function format**: `Function` that takes time `t::Float64` and returns a vector + - Allows analytical or pre-interpolated trajectories + - Function signature: `t -> Vector{Float64}` of appropriate dimension + - Useful for exact solutions or when data is already interpolated # Arguments