From 2803bed21fc123632ca4ed81e49baba2b321c8c6 Mon Sep 17 00:00:00 2001 From: Thomas Walker Lynch Date: Sun, 10 May 2026 12:47:24 +0000 Subject: [PATCH] intermediate, names updated for v3.0, but references still outdated --- ...Release_howto.html => how-to_release.html} | 0 developer/document/RT-code-format-Lisp.html | 392 ++++++++++++++++++ ...T_code_format.html => RT-code-format.html} | 116 ++++-- ...ng.html => naming_file-and-directory.html} | 0 ...> single-file_C-module-and-namespace.html} | 0 developer/tool/{do_all => do-all} | 0 ...Harmony.html => introduction_Harmony.html} | 0 ...ole-and-workflow_product-development.html} | 0 ...ole-and-workflow_product-maintenance.html} | 0 document/todo.txt | 4 + next-generation-name.py | 65 +++ ..._dict.js => dictionary_style-directory.js} | 0 ...all_Python.org => installation_Python.org} | 0 ...l_generic.org => installation_generic.org} | 0 shared/linked-project/.git-holder | 0 shared/linked-project/RT-style-JS_public | 1 + shared/third_party/.gitignore | 8 - shared/tool/{RTfmt => RT-formatter} | 0 shared/tool/{RTfmt.el => RT-formatter.el} | 0 ...target_kmod.mk => target_kernel-module.mk} | 0 shared/tool/version | 2 +- shared/{third_party => }/upstream/.gitignore | 0 .../RTfmt => RT-formatter/RT-formatter} | 0 .../RT-formatter.el} | 0 .../RT-formatter_alt.el} | 0 .../RT-formatter_script.el} | 0 .../RT-formatter_with-compare} | 0 .../RT-formatter_with-compare.el} | 0 .../data_test-0.c} | 0 .../data_test-1.py} | 0 30 files changed, 549 insertions(+), 39 deletions(-) rename administrator/document/{Release_howto.html => how-to_release.html} (100%) create mode 100644 developer/document/RT-code-format-Lisp.html rename developer/document/{RT_code_format.html => RT-code-format.html} (51%) rename developer/document/{File_directory_naming.html => naming_file-and-directory.html} (100%) rename developer/document/{Single-file_C_modules_and_namespaces.html => single-file_C-module-and-namespace.html} (100%) rename developer/tool/{do_all => do-all} (100%) rename document/{Introduction_to_Harmony.html => introduction_Harmony.html} (100%) rename document/{Product-development_roles-and-workflow.html => role-and-workflow_product-development.html} (100%) rename document/{Product-maintenance_roles-and-workflow.html => role-and-workflow_product-maintenance.html} (100%) create mode 100644 document/todo.txt create mode 100755 next-generation-name.py rename shared/{style_directory_dict.js => dictionary_style-directory.js} (100%) rename shared/document/{install_Python.org => installation_Python.org} (100%) rename shared/document/{install_generic.org => installation_generic.org} (100%) create mode 100644 shared/linked-project/.git-holder create mode 120000 shared/linked-project/RT-style-JS_public delete mode 100644 shared/third_party/.gitignore rename shared/tool/{RTfmt => RT-formatter} (100%) rename shared/tool/{RTfmt.el => RT-formatter.el} (100%) rename shared/tool/makefile/{target_kmod.mk => target_kernel-module.mk} (100%) rename shared/{third_party => }/upstream/.gitignore (100%) rename tester/{RT_format/RTfmt => RT-formatter/RT-formatter} (100%) rename tester/{RT_format/RT_Format.el => RT-formatter/RT-formatter.el} (100%) rename tester/{RT_format/RT_format.el => RT-formatter/RT-formatter_alt.el} (100%) rename tester/{RT_format/RTfmt.el => RT-formatter/RT-formatter_script.el} (100%) rename tester/{RT_format/RTfmt_with_compare => RT-formatter/RT-formatter_with-compare} (100%) rename tester/{RT_format/RTfmt_with_compare.el => RT-formatter/RT-formatter_with-compare.el} (100%) rename tester/{RT_format/test_0_data.c => RT-formatter/data_test-0.c} (100%) rename tester/{RT_format/test_1_data.py => RT-formatter/data_test-1.py} (100%) diff --git a/administrator/document/Release_howto.html b/administrator/document/how-to_release.html similarity index 100% rename from administrator/document/Release_howto.html rename to administrator/document/how-to_release.html diff --git a/developer/document/RT-code-format-Lisp.html b/developer/document/RT-code-format-Lisp.html new file mode 100644 index 0000000..edbed6b --- /dev/null +++ b/developer/document/RT-code-format-Lisp.html @@ -0,0 +1,392 @@ + + + + + RT Code Format: Lisp Addendum + + + + + + + + + + +

+ This document serves as the authoritative addendum for applying the RT code format conventions to Lisp dialects, specifically Emacs Lisp. It integrates micro-syntax rules with macro-structural organization to ensure consistency across the software ecosystem. +

+ +

File Architecture and Section Banners

+

+ To maintain a predictable progression from static data to external hooks, a Lisp file is divided into standard architectural sections. Each section is introduced by an Architectural Banner. +

+ + + +

Comment Ontology

+

+ The commenting style in Lisp is highly structured, using semicolon counts and indentation to create a clear visual hierarchy. A programmer should assume the reader can understand Lisp syntax; avoid comments that merely translate the code below them into English prose. +

+ + + +

Header case, for all RT documents and code, is an initial capital letter, and no trailing period. Acronyms and tagged code or terms keep their original capitalization or lack thereof.

+ +

Identifier Naming and Namespaces

+ +

Primary and Secondary Separators

+

+ Because Emacs Lisp and Common Lisp support the hyphen character in identifiers, Lisp code utilizes snake-kebab_case. The hyphen acts as the primary word separator. The underscore is reserved strictly as a secondary separator to group logically related portions of an identifier or to denote semantic boundaries, acting as a structural namespace within the symbol (e.g., city-scape_building-height). +

+ +

Ad Hoc Namespaces

+

+ Emacs Lisp shares a global environment. To prevent global environment pollution, functions and global variables use the center dot (·) to separate namespace hierarchies. Spaces are omitted around the dot to ensure the symbol evaluates contiguously. +

+ + (defconst RT·first-order-list·control·continue 0) + + +

Code Structure Attributes

+

+ The code structure heavily applies the RT Code Format conventions to a Lisp environment, resulting in a distinct visual footprint. +

+ +

Global Two Space Offset

+

+ Unlike standard Emacs Lisp where top level forms like defun or setq are flush left, the entire programmatic contents of the file are indented by two spaces. +

+ +

Function Call Enclosures

+

+ Lisp function calls are exempt from the multi-level enclosure padding rule. The outer parentheses forming a function call receive no padding, even when they contain nested data lists. +

+ + (cat 'a 'b '( 2 (4 5))) + + +

Vertical Branching

+

+ The if and while statements are expanded vertically. The operator, the condition, the true branch, and the false branch each occupy their own isolated lines. +

+ +

Isolated Binding Blocks

+

+ In let and let* forms, the variable declaration list is pushed to its own level. The opening parenthesis sits alone on a new line. Each binding sits on its own line. The closing parenthesis sits alone, vertically aligned with the opening parenthesis. The body of the form follows on the subsequent line. +

+ +

Using let to destructure a list

+

+ Don't destructure a list and then use the parts in a single `let*`, instead destructure the list in a first list, then use the parts in a second nested `let`. +

+ +

Cascading Closures

+

+ When the items of a list appear one per line, i.e. for a vertical list, the closing parenthesis, and all cascading closures, appear on a line of their own at the same indention level as though an element of the list. In a sense, the innermost vertical list wins, as it will close all the vertical lists it is nested in. +

+ + (let + ( + (example_list + (list + '(4 [0]) + '(5 [1]) + '(6 []) + ))) + ... + + + +

A comment subsection

+

+ When a comment under a triple semicolon section forms a subsection, the + comment starts at the indention level of the code, has two semicolons. After the comment there is a line at the indent level with only two semicolons. Then there is a blank line. The subsection contents follow. +

+ + ;; Color logic + ;; + + (defun RT-literal·highlight-none () + nil + ) + + (defun RT-literal·highlight-default () + 'region + ) + + +

one line specific comment

+

+ A single semicolon occurs after the code on the line, followed by a comment. +

+ + + + + +

Contiguous Form Cluster

+

+ When the comment adds insight into the code, the comment typically appears with two semicolons at the same indentation level above said code. There is no following blank line. All code the comment applies to then follows without intervening blank lines. +

+ + ;; By contract: only called when overlay is in quoted form, and null string case already handled + ;; Everything from content_leftmost to content_rightmost is data, inclusive. + (setq RT-literal·describe-new-form_status (list 'new-good)) + (defun RT-literal·describe-new-form_message (status) + nil + ) + (defun RT-literal·describe-new-form (overlay_leftmost content_rightmost_right-neighbor) + (let* + ( ... ) + ... + ))) + + +

API Design Conventions

+ +

Parameter Ordering

+

+ When defining function signatures, static configuration parameters (such as sizes, limits, or modes) must precede data payloads or instances that are actively manipulated. This facilitates partial application and logical readability. +

+ +

TTCA Theory Terminology

+

+ The following definitions bridge the gap between abstract TTCA theory and practical implementation conventions. +

+ + + +

+ The TTCA ontology is a topological description. It speaks of left, and right, of leftmost and rightmost. Time dependent terms such as first or last imply scanning/traversal. The first cell scanned could be anywhere on the tape, depending on the algorithm used for the scan or traversal. Careful, the term rightmost refers to a cell that is included on the tape. It is an inclusive bound. Today exclusive bounds are more common. Inclusive found loops often exit from the middle. +

+ + +

The First/Rest Loop Technique

+ +

The first/rest loop is an iterative control flow pattern designed for sequence traversal and state machine evaluation. The pattern explicitly separates the evaluation of the initial state (the "first") from the continuous cycle of advancing and re-evaluating (the "rest").

+ +

This technique eliminates the need for mid-loop escape clauses, such as break or throw/catch, and avoids evaluating out-of-bounds memory by ensuring the tape head is always validated before stepping.

+ +

The Structural Form

+ +

The structure requires performing the initial work on the first valid cell and evaluating the boundary condition simultaneously. Because a freshly cued tape machine always rests on valid data, the first cell is processed immediately within the initial variable bindings. The loop condition then evaluates both the result of that work and whether the machine has a right neighbor. Inside the loop, the machine steps, and both the work and boundary conditions are explicitly re-evaluated and updated at the absolute bottom.

+ +

If the work performed on the cell is extensive, a programmer should extract that logic into a helper function. This helper function is called once in the initial bindings for the "first" phase, and once inside the loop for the "rest" phase.

+ +

Here is the canonical RT code format for the first/rest loop:

+ + + (let + ( + ;; 1. The "First" Work & Boundary Evaluation + (work-successful (evaluate-current-cell machine)) + (has_right-neighbor (RT·TM·has-right-neighbor machine)) + ) + ;; 2. The rest loop + (while (and work-successful has_right-neighbor) + (progn + ;; 3. The "Step" phase + (RT·TM·step machine) + + ;; 4. The "Rest" Work & Boundary Evaluation + (setq work-successful (evaluate-current-cell machine)) + (setq has_right-neighbor (RT·TM·has-right-neighbor machine)) + )) + ;; Return the final state of the work + work-successful + ) + + +

+ Elisp does not have a middle-of-loop exit, but if it did, the logic would look like this: +

+ + + (let + ( + (work-successful nil) + (has_right-neighbor nil) + ) + (loop + (setq work-successful (evaluate-current-cell machine)) + (setq has_right-neighbor (RT·TM·has-right-neighbor machine)) + + (if + (not (and work-successful has_right-neighbor)) + (break) + (RT·TM·step machine) + )) + work-successful + ) + + +

Which eliminates the need for two calls to evaluate-current-cell and has-right-neighbor. This can be done in other languages that have a loop break. (Donald Knuth argued in his 1974 paper, Structured Programming with go to Statements, that forcing programmers to duplicate code simply to satisfy a rigid while or repeat/until pre/post-test constraint was a failure of the language's expressiveness. Also discussed in the Art of Computer Programming.) +

+ +

If we are willing to us catch and throw in normal control flow, this can be done in elisp as: +

+ + + (catch 'loop-exit + (while t + (let + ( + (work-successful (evaluate-current-cell machine)) + (has_right-neighbor (RT·TM·has-right-neighbor machine)) + ) + (if + (not (and work-successful has_right-neighbor)) + (throw 'loop-exit work-successful) + (RT·TM·step machine) + )))) + + +

So defining:

+ + (defmacro RT·loop (&rest body) + "An infinite loop construct designed to be exited via RT·break." + `(catch 'loop-exit + (while t + ,@body + ))) + + (defmacro RT·break (&optional return_val) + "Break out of an RT·loop, optionally returning RETURN_VAL." + `(throw 'loop-exit ,return_val) + ) + + +

Our example becomes:

+ + + (let + ( + (work-successful nil) + (has_right-neighbor nil) + ) + (RT·loop + ;; 1. The Work & Boundary Evaluation + (setq work-successful (evaluate-current-cell machine)) + (setq has_right-neighbor (RT·TM·has-right-neighbor machine)) + + ;; 2. The Mid-Loop Condition Check + (if + (not (and work-successful has_right-neighbor)) + (RT·break work-successful) + ;; 3. The "Step" phase + (RT·TM·step machine) + )) + ) + + +

+ Production code first/rest loop example without a middle loop break. +

+ + + (defun RT·TM·sequence·eq (TM_substrate TM_target) + (let + ( + (TM-substrate-copy (RT·TM·entangled-copy TM_substrate)) + (TM-target-copy (RT·TM·entangled-copy TM_target)) + ) + (let + ( + (are-eq (= (RT·TM·read TM-substrate-copy) (RT·TM·read TM-target-copy))) + (target-has-right-neighbor (RT·TM·has-right-neighbor TM-target-copy)) + (substrate-has-right-neighbor (RT·TM·has-right-neighbor TM-substrate-copy)) + ) + (while + (and are-eq target-has-right-neighbor substrate-has-right-neighbor) + (progn + (RT·TM·step TM-substrate-copy) + (RT·TM·step TM-target-copy) + (setq are-eq (= (RT·TM·read TM-substrate-copy) (RT·TM·read TM-target-copy))) + (setq target-has-right-neighbor (RT·TM·has-right-neighbor TM-target-copy)) + (setq substrate-has-right-neighbor (RT·TM·has-right-neighbor TM-substrate-copy)) + )) + (and are-eq (not target-has-right-neighbor)) + ))) + + +

If the double call code is substantial, and we do not want to use a middle break, it can be put in a helper function, and then this reduces to two calls to the helper. the helper function is called in the first part and the rest loop. If the programmer tries to trick the loop by giving the variables fake values in the first part, the first/rest pattern will be broken. +

+ +

Relationship between first/rest and Tail Recursion

+ +

The first/rest loop is the exact iterative equivalent of a tail-recursive function.

+ +

In a functional paradigm, a sequence is algebraically defined as a head (first) and a tail (rest). A tail-recursive function evaluates the head, performs the necessary work, and then returns the result of calling itself on the tail.

+ +

Environments lacking Tail Call Optimization (TCO), such as Emacs Lisp, will throw a stack overflow error if a recursive function traverses a long sequence. The first/rest loop flattens this recursive mathematical model into memory-safe iteration by mapping the recursive phases directly to iterative steps:

+ +

The Initial Function Call: The initial work and the let block bindings in the first/rest loop mirror the initial execution and argument evaluation of the recursive function.

+ +

The Base Case Check: The while loop condition mirrors the recursive base case. If the condition fails, the loop terminates, mimicking the recursive function returning its final value.

+ +

The Tail Call: The step and setq updates at the bottom of the loop body mirror the argument passing of the tail-recursive call. Updating the variables and allowing the while loop to jump back to the top is functionally identical to the function invoking itself with a new set of parameters for the "rest" of the sequence.

+ +

By adhering to this pattern, a programmer retains the strict, predictable state management of functional recursion while satisfying the physical memory constraints of an iterative runtime environment.

+ +

To illustrate the mathematical equivalence, here is the exact same logic written as a tail-recursive function. Note that while this form is theoretically pure, the first/rest iterative loop is strictly preferred in Emacs Lisp. Because Elisp lacks Tail Call Optimization (TCO), this recursive form would eventually exhaust the call stack and crash when traversing massive sequences.

+ + + (defun process-sequence-recursively (machine) + (let + ( + ;; 1. The "First" Work & Boundary Evaluation + (work-successful (evaluate-current-cell machine)) + (active (RT·TM·has-right-neighbor machine)) + ) + ;; 2. The Condition check + (if (and work-successful active) + (progn + ;; 3. The "Step" phase + (RT·TM·step machine) + + ;; 4. The Tail Call (The "Rest") + ;; This directly replaces the setq updates and loop jump + (process-sequence-recursively machine) + ) + ;; Base case: loop terminates, return final state + work-successful + ))) + + +

Exercise

+

Show the 'production code' with a first/rest pattern using the RT macros and a middle break loop.

+ + + + diff --git a/developer/document/RT_code_format.html b/developer/document/RT-code-format.html similarity index 51% rename from developer/document/RT_code_format.html rename to developer/document/RT-code-format.html index 7f2de0c..43069bc 100644 --- a/developer/document/RT_code_format.html +++ b/developer/document/RT-code-format.html @@ -20,29 +20,32 @@

- We are not big on revising inherited or legacy code for naming conventions, though no one will hold you back. However, new code should follow these conventions. + This document has been evolving. Consequently there is a body of non-conforming code. Whenever we run up against it, it is nice to update it.

Object vs. instance nomenclature

- We reserve the word 'object' for its general English meaning. When discussing data that is manipulated solely through a defined interface, use the term instance. It is too much of an ask to remove the word object from the language, and this is reflected in the fact that few people use the term precisely. + It is too much of an ask to remove the word 'object' from the English language, and then set it aside and give it a esoteric technical meaning. This is why the term is often misused. So we instead talk about an interface as being a set of functions that share one or more state variables. The term instance is then a collection of such state variables and their values sitting in memory. Interface functions are usually grouped within a named container, and state variables are often grouped into a single named data structure.

- Hence, a programmer can talk about math objects, as things found in mathematics, and C objects, as things found in the C language, even though they are not instantiated from classes, or might not even be data. For example, the for loop is a C object. + In some languages the instance occurs to the left of a lower dot (period) operator and is referred to as this from inside the interface functions. In other languages there is a convention where the instance is passed in as the first parameter to interface functions. There can also be interface functions that accept multiple instances of the same type. Bridge interfaces can be created that accept two instances potentially of different types. +

+

+ Since we have released object from captivity, a programmer can talk about math objects, as things found in mathematics, and C objects, as things found in the C language, even though they are not instantiated from classes, or might not even be data. For example, the for loop is a C object.

-

Identifier Names

+

Identifier names

Case

Proper nouns and acronyms

- Even in PascalCase and snake_case, proper nouns and acronyms remain capitalized, as per standard English language conventions (e.g., IEEE_publication_count). + Even in PascalCase and snake-kebab_case, proper nouns and acronyms remain capitalized, as per standard English language conventions (e.g., IEEE_publication-count).

Abbreviations

@@ -53,44 +56,85 @@ For long words, inner scope identifiers, temporary variables, and conventional suffixes, abbreviations become more common. By the time we get to inner loops variable names, such as loop counters are typically 1 letter long.

-

Primary and secondary separators (snake-kebab_case)

+

Primary and secondary separator use

+

+ When a language supports the dash, -, dash connected components are given precedence and of choice, and bind semantically higher than under score separated components. E.g. rounded_x-coordinate. +

+

+ Otherwise, if the language does not support hyphens in identifiers (such as C, Python, and Java), we conventionally drop the nicety of multiple semantic bindings, e.g. rounded_x_coordinate. However if the distinction has high value, a double underscore and be used, rounded__x_coordinate. +

+ +

Ad hoc namespacing

- If a language supports the hyphen (-) in identifiers (such as Common Lisp and Emacs Lisp), the identifier is written in snake-kebab_case. The hyphen is used as the primary word separator. The underscore (_) is then reserved strictly as a secondary separator to group logically related portions of an identifier or to denote semantic boundaries, acting as a structural namespace within the symbol (e.g., city-scape_building-height). + Most parsers now a allow a center dot (·) in identifiers. In languages were namespaces are not explicitly available, we use the cdot to represent a namespace. Namespaces are closely related to module names, class names, interface names, and to type names,so all are written in PascalCase. So for example, Math·rounded__x_coordinate, might be variable in the Math namespace, a function on the Math interface, etc. + +

Component order

+

+ As long as it is sensible, and doesn't break parallel constructions, place the least changing component, or the broadest category, to the left of the identifer. For example, a conditional write functions would be called, `write-conditional`, not `conditional-write` because it is a refinement on the general category or write functions.

+ +

Copy,read, write

- Otherwise, if the language does not support hyphens in identifiers (such as C, Python, and Java), the identifier falls back to standard snake_case and only the underscore (_) is used for all separation. In C specifically, a center dot (·) is used for ad hoc namespaces. + 'read' and 'write', are the two ends of a copy. When 'this instance' is understood as being one end of the copy, then using 'read' or 'write' makes sense. However, it is generally better to provide an external copy command. The order of arguments in a copy command are `read from source value --> write to destination value` i.e. data flows from left to write. (This is contrary to an assignment operator, which has data flowing from right to left during a copy.)

-

Suffixes

+

The term make

+

+ When allowed by the langauge, factory functions are called 'make'. They are not called 'create', nor 'new'. +

+ +

Function terminology

+

+ Parameters are what give a function its characteristics. They are typically static. They are one step away from values that are curried into a function. Parameter variables are given with the function definition, and parameter values are given to the function at run time when it is called. +

+

+ Given argument values can be said to be bound to arguments variables upon call. +

+

+ Arguments drive the function computation. Conceptually they might change on every separate call, so they are highly dynamic. Argument variables are specified when the function is defined. Argument values are given to the function at call time. +

+

+ Values are said to be given to a function. We don't say a function takes arguments, as though a call stack could reach into memory and grab values. We use terms accept and reject of values for guard code. For a function to accept an argument value is to mean that argument value was tested and passed. As an example, we can say that a square root function only accepts values greater than or equal to zero, or that it rejects negative values. +

+

+ Operators are logically functions by another name. Syntactically infix notation is often used. Operands are arguments given to an operator. +

+ +

Plural identifiers

+ +

+ Do not make the names of containers plural, instead prefix the container abstract type, or actual type before the identifier. Recall that types are PascalCase. +

-

Add a container type suffix instead of making variable names plural.

-

Add a type suffix when it adds clarity.

+

Add a type prefix when it adds clarity.

+

Identifiers for directory/file names

- -

Comma separated lists

Horizontal comma list

@@ -220,6 +264,18 @@
  • A variable holding multiple absolute file paths for images: imageFiles
    • +

    Exercise 4: Identifier naming with hyphens

    +

    + Rename the same poorly named variables from Exercise 3, but this time assume they are written in a language that supports the hyphen (-) in identifiers. Apply the rules for primary and secondary separators, keeping in mind the structural boundary of suffixes. +

    + + diff --git a/developer/document/File_directory_naming.html b/developer/document/naming_file-and-directory.html similarity index 100% rename from developer/document/File_directory_naming.html rename to developer/document/naming_file-and-directory.html diff --git a/developer/document/Single-file_C_modules_and_namespaces.html b/developer/document/single-file_C-module-and-namespace.html similarity index 100% rename from developer/document/Single-file_C_modules_and_namespaces.html rename to developer/document/single-file_C-module-and-namespace.html diff --git a/developer/tool/do_all b/developer/tool/do-all similarity index 100% rename from developer/tool/do_all rename to developer/tool/do-all diff --git a/document/Introduction_to_Harmony.html b/document/introduction_Harmony.html similarity index 100% rename from document/Introduction_to_Harmony.html rename to document/introduction_Harmony.html diff --git a/document/Product-development_roles-and-workflow.html b/document/role-and-workflow_product-development.html similarity index 100% rename from document/Product-development_roles-and-workflow.html rename to document/role-and-workflow_product-development.html diff --git a/document/Product-maintenance_roles-and-workflow.html b/document/role-and-workflow_product-maintenance.html similarity index 100% rename from document/Product-maintenance_roles-and-workflow.html rename to document/role-and-workflow_product-maintenance.html diff --git a/document/todo.txt b/document/todo.txt new file mode 100644 index 0000000..5e09e0e --- /dev/null +++ b/document/todo.txt @@ -0,0 +1,4 @@ +2026-03-26 03:41:44 + +when making a skeleton from Harmony, set skeleton docs and other files not to be edited to read only + diff --git a/next-generation-name.py b/next-generation-name.py new file mode 100755 index 0000000..7aa8c84 --- /dev/null +++ b/next-generation-name.py @@ -0,0 +1,65 @@ +#!/usr/bin/env -S python3 -B +# -*- mode: python; coding: utf-8; python-indent-offset: 2; indent-tabs-mode: nil -*- + +import os ,sys + +def CLI(argv=None) -> int: + # Ordered list of renames: files first, then directories to preserve paths + substitutions = [ + # Administrator + ("administrator/document/Release_howto.html" ,"administrator/document/how-to_release.html") + + # Developer + ,("developer/document/File_directory_naming.html" ,"developer/document/naming_file-and-directory.html") + ,("developer/document/RT_code_format.html" ,"developer/document/format_RT-code.html") + ,("developer/document/Single-file_C_modules_and_namespaces.html" ,"developer/document/single-file_C-module-and-namespace.html") + ,("developer/tool/do_all" ,"developer/tool/do-all") + + # Top-level documents + ,("document/Introduction_to_Harmony.html" ,"document/introduction_Harmony.html") + ,("document/Product-development_roles-and-workflow.html" ,"document/role-and-workflow_product-development.html") + ,("document/Product-maintenance_roles-and-workflow.html" ,"document/role-and-workflow_product-maintenance.html") + + # Shared tools and documents + ,("shared/document/install_Python.org" ,"shared/document/installation_Python.org") + ,("shared/document/install_generic.org" ,"shared/document/installation_generic.org") + ,("shared/style_directory_dict.js" ,"shared/dictionary_style-directory.js") + ,("shared/tool/RTfmt" ,"shared/tool/RT-formatter") + ,("shared/tool/RTfmt.el" ,"shared/tool/RT-formatter.el") + ,("shared/tool/makefile/target_kmod.mk" ,"shared/tool/makefile/target_kernel-module.mk") + + # Tester files (referenced by the old directory name before it is renamed) + ,("tester/RT_format/RT_Format.el" ,"tester/RT_format/RT-formatter.el") + ,("tester/RT_format/RT_format.el" ,"tester/RT_format/RT-formatter_alt.el") + ,("tester/RT_format/RTfmt" ,"tester/RT_format/RT-formatter") + ,("tester/RT_format/RTfmt.el" ,"tester/RT_format/RT-formatter_script.el") + ,("tester/RT_format/RTfmt_with_compare" ,"tester/RT_format/RT-formatter_with-compare") + ,("tester/RT_format/RTfmt_with_compare.el" ,"tester/RT_format/RT-formatter_with-compare.el") + ,("tester/RT_format/test_0_data.c" ,"tester/RT_format/data_test-0.c") + ,("tester/RT_format/test_1_data.py" ,"tester/RT_format/data_test-1.py") + + # Directories + ,("shared/third_party" ,"shared/linked-project") + ,("tester/RT_format" ,"tester/RT-formatter") + ] + + for src ,dst in substitutions: + if not os.path.exists(src): + print(f"Skipping (not found): {src}") + continue + + if os.path.exists(dst): + print(f"Warning: Destination {dst} already exists. Skipping rename for {src}.") + continue + + try: + os.rename(src ,dst) + print(f"Renamed: {src} -> {dst}") + except Exception as e: + print(f"Error renaming {src} to {dst}: {e}") + + return 0 + +if __name__ == "__main__": + sys.exit(CLI()) + diff --git a/shared/style_directory_dict.js b/shared/dictionary_style-directory.js similarity index 100% rename from shared/style_directory_dict.js rename to shared/dictionary_style-directory.js diff --git a/shared/document/install_Python.org b/shared/document/installation_Python.org similarity index 100% rename from shared/document/install_Python.org rename to shared/document/installation_Python.org diff --git a/shared/document/install_generic.org b/shared/document/installation_generic.org similarity index 100% rename from shared/document/install_generic.org rename to shared/document/installation_generic.org diff --git a/shared/linked-project/.git-holder b/shared/linked-project/.git-holder new file mode 100644 index 0000000..e69de29 diff --git a/shared/linked-project/RT-style-JS_public b/shared/linked-project/RT-style-JS_public new file mode 120000 index 0000000..9600bc6 --- /dev/null +++ b/shared/linked-project/RT-style-JS_public @@ -0,0 +1 @@ +../../../RT-style-JS_public/ \ No newline at end of file diff --git a/shared/third_party/.gitignore b/shared/third_party/.gitignore deleted file mode 100644 index 0de97f0..0000000 --- a/shared/third_party/.gitignore +++ /dev/null @@ -1,8 +0,0 @@ -# Ignore all files -* - -# But don't ignore the .gitignore file itself -!/.gitignore - -# keep the upstream directory -!/upstream diff --git a/shared/tool/RTfmt b/shared/tool/RT-formatter similarity index 100% rename from shared/tool/RTfmt rename to shared/tool/RT-formatter diff --git a/shared/tool/RTfmt.el b/shared/tool/RT-formatter.el similarity index 100% rename from shared/tool/RTfmt.el rename to shared/tool/RT-formatter.el diff --git a/shared/tool/makefile/target_kmod.mk b/shared/tool/makefile/target_kernel-module.mk similarity index 100% rename from shared/tool/makefile/target_kmod.mk rename to shared/tool/makefile/target_kernel-module.mk diff --git a/shared/tool/version b/shared/tool/version index a132902..aced6ba 100755 --- a/shared/tool/version +++ b/shared/tool/version @@ -1,4 +1,4 @@ -echo "Harmony v2.5 2026-03-09" +echo "Harmony v3.0 2026-05-10" diff --git a/shared/third_party/upstream/.gitignore b/shared/upstream/.gitignore similarity index 100% rename from shared/third_party/upstream/.gitignore rename to shared/upstream/.gitignore diff --git a/tester/RT_format/RTfmt b/tester/RT-formatter/RT-formatter similarity index 100% rename from tester/RT_format/RTfmt rename to tester/RT-formatter/RT-formatter diff --git a/tester/RT_format/RT_Format.el b/tester/RT-formatter/RT-formatter.el similarity index 100% rename from tester/RT_format/RT_Format.el rename to tester/RT-formatter/RT-formatter.el diff --git a/tester/RT_format/RT_format.el b/tester/RT-formatter/RT-formatter_alt.el similarity index 100% rename from tester/RT_format/RT_format.el rename to tester/RT-formatter/RT-formatter_alt.el diff --git a/tester/RT_format/RTfmt.el b/tester/RT-formatter/RT-formatter_script.el similarity index 100% rename from tester/RT_format/RTfmt.el rename to tester/RT-formatter/RT-formatter_script.el diff --git a/tester/RT_format/RTfmt_with_compare b/tester/RT-formatter/RT-formatter_with-compare similarity index 100% rename from tester/RT_format/RTfmt_with_compare rename to tester/RT-formatter/RT-formatter_with-compare diff --git a/tester/RT_format/RTfmt_with_compare.el b/tester/RT-formatter/RT-formatter_with-compare.el similarity index 100% rename from tester/RT_format/RTfmt_with_compare.el rename to tester/RT-formatter/RT-formatter_with-compare.el diff --git a/tester/RT_format/test_0_data.c b/tester/RT-formatter/data_test-0.c similarity index 100% rename from tester/RT_format/test_0_data.c rename to tester/RT-formatter/data_test-0.c diff --git a/tester/RT_format/test_1_data.py b/tester/RT-formatter/data_test-1.py similarity index 100% rename from tester/RT_format/test_1_data.py rename to tester/RT-formatter/data_test-1.py -- 2.20.1