Merge branch 'develop' into migrate-math-base-ops-divf

Signed-off-by: Athan <[email protected]>

Author: kgryte

.github/workflows/autoclose.yml

@@ -58,7 +58,7 @@ jobs:
           BODY: |
             Thank you for working on this pull request. However, we cannot accept your contribution as this pull request does not follow our [contributing guidelines](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md).
 
-            Per the guidelines outlined in our [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/development.md), you should download and setup [EditorConfig](http://editorconfig.org/) to ensure that files are automatically configured to use expected indentation and line endings.
+            Per the guidelines outlined in our [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md), you should download and setup [EditorConfig](http://editorconfig.org/) to ensure that files are automatically configured to use expected indentation and line endings.
 
             If you would prefer to avoid manual setup, you could also consider using a pre-configured [development container](https://github.com/stdlib-js/stdlib/tree/develop/.devcontainer) for use locally or in GitHub Codespaces.
 
@@ -94,7 +94,7 @@ jobs:
           BODY: |
             Thank you for working on this pull request. However, we cannot accept your contribution as this pull request does not follow our [contributing guidelines](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md).
 
-            Per the guidelines outlined in our [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/development.md), you should have setup your local development environment such that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. We encourage you to refer to that guide **before** continuing to work on this pull request.
+            Per the guidelines outlined in our [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md), you should have setup your local development environment such that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. We encourage you to refer to that guide **before** continuing to work on this pull request.
 
             If you would prefer to avoid manual setup, you could also consider using a pre-configured [development container](https://github.com/stdlib-js/stdlib/tree/develop/.devcontainer) for use locally or in GitHub Codespaces.
 

.github/workflows/good_first_issue.yml

@@ -65,7 +65,7 @@ jobs:
             1.  **You cannot "claim" issues.** People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
             2.  **We have a very high bar for contributions.** We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.
 
-            Before working on this issue and opening a pull request, please read the project's [contributing guidelines](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md). These guidelines and the associated [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/development.md) provide important information, including links to stdlib's [Code of Conduct](https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md), license policy, and steps for setting up your local development environment.
+            Before working on this issue and opening a pull request, please read the project's [contributing guidelines](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md). These guidelines and the associated [development guide](https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md) provide important information, including links to stdlib's [Code of Conduct](https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md), license policy, and steps for setting up your local development environment.
 
             To reiterate, we **strongly** encourage you to refer to our contributing guides **before** beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.
 

.github/workflows/labeler_needs_changes.yml

@@ -199,6 +199,7 @@ jobs:
       - name: 'Lint against EditorConfig'
         id: lint-editorconfig
         run: |
+          set -o pipefail
           files=$(echo "${{ steps.random-files.outputs.files }}" | tr ',' ' ')
           make lint-editorconfig-files FILES="${files}" 2>&1 | tee lint_editorconfig_errors.txt
 
@@ -208,6 +209,10 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.STDLIB_BOT_PAT_REPO_WRITE }}
         run: |
+          strip_ansi() {
+            sed -r 's/\x1B\[[0-9;]*[mK]//g'
+          }
+
           BODY_FILE="$GITHUB_WORKSPACE/lint_issue_body.md"
           cat << EOF > "$BODY_FILE"
           ## EditorConfig Linting Failures
@@ -223,14 +228,15 @@ jobs:
           ### Error Details
 
           \`\`\`
-          $(cat lint_editorconfig_errors.txt)
+          $(cat lint_editorconfig_errors.txt | strip_ansi)
           \`\`\`
           EOF
 
           . "$GITHUB_WORKSPACE/.github/workflows/scripts/create_sub_issue" \
             'Fix EditorConfig lint errors' \
             "$BODY_FILE" \
-            "5156"
+            "5156" \
+            "Good First Issue"
 
           rm "$BODY_FILE"
 

.github/workflows/lint_random_files.yml

@@ -143,7 +143,13 @@ main() {
 
 	# Run C benchmarks:
 	echo "Finding C benchmark files in ${directories}..."
-	c_bench_files=$(find "${directories}" -maxdepth 4 -wholename '**/benchmark/c/benchmark*.c' -exec realpath {} \; | grep -v '/fixtures/' | sort -u | tr '\n' ' ') || true
+	c_bench_files=$(find "${directories}" -maxdepth 5 \( -wholename '**/benchmark/c/benchmark*.c' -or -wholename '**/benchmark/c/**/benchmark*.c' \) -exec realpath {} \; | grep -v '/fixtures/' | sort -u | tr '\n' ' ') || true
+
+	# If benchmarks requiring Cephes are found, install the Cephes library:
+	c_cephes_makefiles=$(find "${directories}" -maxdepth 5 -wholename '**/benchmark/c/**/Makefile' -exec grep -l 'CEPHES' {} + || true)
+	if [ -n "${c_cephes_makefiles}" ]; then
+		make install-deps-cephes
+	fi
 
 	if [ -n "${c_bench_files}" ]; then
 		make benchmark-c-files FILES="${c_bench_files}"

.github/workflows/scripts/run_affected_benchmarks

@@ -151,7 +151,7 @@ main() {
 	done
 
 	# Find all test files in package directories:
-	files=$(find ${directories} -maxdepth 2 -wholename '**/test/test*.js' | grep -v '/fixtures/' | sort -u | tr '\n' ' ') || true
+	files=$(find ${directories} -maxdepth 3 \( -wholename '**/test/test*.js' -or -wholename '**/test/**/test*.js' \) | grep -v '/fixtures/' | sort -u | tr '\n' ' ') || true
 
 	# Exclude files residing in test fixtures directories:
 	files=$(echo "${files}" | grep -v '/fixtures/') || true

.github/workflows/scripts/run_affected_tests

@@ -14,8 +14,8 @@
       "line": 1
     },
     {
-      "file": "docs/development.md",
-      "description": "To setup your development environment, follow the steps in the `docs/development.md` file or use the VSCode development container.",
+      "file": "docs/contributing/development.md",
+      "description": "To setup your development environment, follow the steps in the `docs/contributing/development.md` file or use the VSCode development container.",
       "line": 21
     },
     {

.tours/contributor-overview.tour

@@ -435,15 +435,15 @@ Phew. While the above may be a lot to remember, even for what seem like minor ch
 
 [stdlib-style-guides-git]: https://github.com/stdlib-js/stdlib/blob/develop/docs/style-guides/git
 
-[stdlib-doctest]: https://github.com/stdlib-js/stdlib/blob/develop/docs/doctest.md
+[stdlib-doctest]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/doctest.md
 
-[stdlib-development]: https://github.com/stdlib-js/stdlib/blob/develop/docs/development.md
+[stdlib-development]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md
 
-[stdlib-branching]: https://github.com/stdlib-js/stdlib/blob/develop/docs/branching.md
+[stdlib-branching]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/branching.md
 
-[stdlib-packages]: https://github.com/stdlib-js/stdlib/blob/develop/docs/packages.md
+[stdlib-packages]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/packages.md
 
-[stdlib-repl-text]: https://github.com/stdlib-js/stdlib/blob/develop/docs/repl_text.md
+[stdlib-repl-text]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/repl_text.md
 
 [stdlib-faq]: https://github.com/stdlib-js/stdlib/blob/develop/FAQ.md
 

CONTRIBUTING.md

@@ -766,7 +766,7 @@ Test and build infrastructure is generously provided by the following services:
 
 [stdlib-contributing]: https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md
 
-[stdlib-development]: https://github.com/stdlib-js/stdlib/blob/develop/docs/development.md
+[stdlib-development]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md
 
 [stdlib-authors]: https://github.com/stdlib-js/stdlib/graphs/contributors
 

README.md

@@ -105,7 +105,7 @@ This project follows the branching model articulated in ["A successful Git branc
 
 -   Before merging a hotfix branch into the `master` branch, the changes **must** be peer reviewed and pass continuous integration tests.
 
--   Once merged into `master`, if a release branch currently exists, submit a pull request against the `release` branch. Otherwise, submit a pull request against the `develop` branch. By merging a hotfix into a release branch, the hotfix changes should be propagated to the `develop` branch upon merging the release branch into the `develop` branch. 
+-   Once merged into `master`, if a release branch currently exists, submit a pull request against the `release` branch. Otherwise, submit a pull request against the `develop` branch. By merging a hotfix into a release branch, the hotfix changes should be propagated to the `develop` branch upon merging the release branch into the `develop` branch.
 
 * * *
 

docs/assets/talks/inspiring_computing_2025_athan_reines.png

@@ -254,15 +254,14 @@ workshops  workshops
     ```bash
     $ make TESTS_FILTER=.*/<pattern>/.* test
     ```
-    
+
     with
 
     <!-- run-disable -->
 
     ```bash
     $ make TESTS_FILTER=".*/<pattern>/.*" test
     ```
-    
 
 ## Editors
 

docs/branching.md renamed to docs/contributing/branching.md

@@ -48,7 +48,7 @@ The following guide sets forth doctest conventions for documenting expected beha
 
 A doctest annotation is a syntactically valid language comment consisting of a **marker** and an **expected value**.
 
-> **Note**: most of the following examples will be written in JavaScript which uses C-style comment syntax. While invariably biased toward JavaScript, the doctest annotation convention endeavors to be language agnostic and not limited to any particular comment style. 
+> **Note**: most of the following examples will be written in JavaScript which uses C-style comment syntax. While invariably biased toward JavaScript, the doctest annotation convention endeavors to be language agnostic and not limited to any particular comment style.
 
 Doctest annotations begin with one of three keyword markers (with limited exceptions documented below):
 
@@ -129,7 +129,7 @@ swap( x, 0, 1 );
 // x => [ 2, 1 ]
 ```
 
-indicates that the two-element array to which `x` refers has been mutated after evaluation of the preceding expressions. In this case, as `swap()` returns a `boolean`, the `returns` keyword would not allow us to assert the more salient behavior of array mutation. By using the `{var} =>` convention, we can do so.  
+indicates that the two-element array to which `x` refers has been mutated after evaluation of the preceding expressions. In this case, as `swap()` returns a `boolean`, the `returns` keyword would not allow us to assert the more salient behavior of array mutation. By using the `{var} =>` convention, we can do so.
 
 The `e.g.,` and `{var} =>` prefixes can be used in combination. For example,
 
@@ -602,7 +602,7 @@ var mat = foo();
 
 indicates that `foo()` returns an `NxM` matrix containing a `2x2` sub-matrix beginning with the first row and second column whose contents, when expressed as a linear array, equal `1.14`, `-3.14`, `0.00`, and `0.50`.
 
-Additionally, matrices can include wildcards. For example, 
+Additionally, matrices can include wildcards. For example,
 
 <!-- run-disable -->
 

docs/development.md renamed to docs/contributing/development.md

@@ -114,7 +114,7 @@ double precision function add( x, y )
 end function add
 ```
 
-While `add` may be used in conjunction with other Fortran files, we cannot use `add` directly from C because Fortran expects arguments to be passed by reference rather than by value. Furthermore, while not applicable here, Fortran functions can only return scalar values, not arrays. Thus, the general best practice is to wrap `add` as a subroutine (equivalent of a C function returning `(void)`), where we can pass a pointer for storing the output return value. 
+While `add` may be used in conjunction with other Fortran files, we cannot use `add` directly from C because Fortran expects arguments to be passed by reference rather than by value. In general, for functions accepting and returning scalars, best practice is to wrap `add` as a subroutine (equivalent of a C function returning `(void)`), where we can pass a pointer for storing the output return value.
 
 ```fortran
 !>
@@ -172,7 +172,7 @@ where we prevent name mangling using `extern "C"`. Now that our Fortran code is
 double c_add( const double x, const double y ) {
   double sum;
   addsub( &x, &y, &sum );
-  return sum; 
+  return sum;
 }
 ```
 

docs/doctest.md renamed to docs/contributing/doctest.md

@@ -1,3 +1,23 @@
+<!--
+
+@license Apache-2.0
+
+Copyright (c) 2025 The Stdlib Authors.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+-->
+
 # JavaScript Quirks
 
 > A list of JavaScript quirks which should be kept in mind when writing implementations.
@@ -26,4 +46,4 @@
 
 [java-math-round]: https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#round%28double%29
 
-</section> 
+</section>