woxi 0.1.0__tar.gz

woxi-0.1.0/.config/nextest.toml

@@ -0,0 +1,63 @@
+[profile.default]
+# Fail any individual test that takes longer than 20 seconds.
+slow-timeout = { period = "20s", terminate-after = 1 }
+
+# NOTE: nextest applies the FIRST matching override for a given setting.
+# The most specific overrides must therefore come BEFORE the broad
+# `/^script_/` rule below, or they will be shadowed by it.
+
+# `D[x^x, {x, 10}]` is intentionally a heavy regression test for the Plus
+# comparator panic — order 10 matches the originally panicking input. It
+# takes ~10s standalone in debug builds and can brush against the default
+# 20s timeout under full parallel load. Give it a wider window.
+[[profile.default.overrides]]
+filter = 'test(high_order_derivative_of_x_x_does_not_panic)'
+slow-timeout = { period = "60s", terminate-after = 1 }
+
+# `fourier_matrix_boundary_materializes` materializes a large matrix and is
+# allocation-heavy: ~10s solo, but it exceeds the 20s default timeout under the
+# parallel contention of a full CI run (the job otherwise fails here). Give it
+# a wider window.
+[[profile.default.overrides]]
+filter = 'test(fourier_matrix_boundary_materializes)'
+slow-timeout = { period = "90s", terminate-after = 1 }
+
+# The remaining (non-`#[ignore]`d) RosettaCode script snapshots run a few
+# seconds in debug builds; under full parallel load they can brush past the
+# default 20s timeout. Give them a safety ceiling. The genuinely heavy
+# scripts (tens of seconds each in debug) are marked `#[ignore]` via the
+# `slow_script_test!` macro and run only via `make test-slow` under the
+# `slow` profile below — they never run during `make test`.
+[[profile.default.overrides]]
+filter = 'test(/^script_/)'
+slow-timeout = { period = "120s", terminate-after = 1 }
+
+# Profile for `make test-slow` (`cargo nextest run --features slow-tests
+# --profile slow --run-ignored only`). The heavy `#[ignore]`d scripts run with heavy
+# mutual CPU contention and are ~270s+ standalone in debug builds, so give
+# every test a very wide window.
+#
+# NOTE: a custom profile inherits `[[profile.default.overrides]]`, and the
+# active profile's own overrides are evaluated *before* the inherited ones.
+# Without the explicit `script_` override below, the default profile's
+# 120s `/^script_/` rule would shadow this profile's 900s base and the
+# heavy scripts would (wrongly) time out at 120s.
+[profile.slow]
+slow-timeout = { period = "900s", terminate-after = 1 }
+
+# `script_egyptian_fractions` is allocation-throughput-bound (~330s standalone
+# in debug). Run concurrently with the other ~23 heavy scripts, the shared
+# allocator / memory-bandwidth contention on a CI runner pushes it past the
+# 900s ceiling and the job fails. Reserve all test threads so it runs in
+# isolation — its wall time then stays close to standalone — and give it a wide
+# timeout for the slower-than-local CI hardware. This override must precede the
+# broad `/^script_/` rule below, since nextest applies the FIRST matching
+# override for a given setting.
+[[profile.slow.overrides]]
+filter = 'test(script_egyptian_fractions)'
+threads-required = 'num-cpus'
+slow-timeout = { period = "1800s", terminate-after = 1 }
+
+[[profile.slow.overrides]]
+filter = 'test(/^script_/)'
+slow-timeout = { period = "900s", terminate-after = 1 }

woxi-0.1.0/.dockerignore

@@ -0,0 +1,30 @@
+# Keep the build context small and reproducible. Anything not needed
+# to compile + test the Rust code is excluded.
+
+.git
+.direnv
+.env
+.DS_Store
+target
+node_modules
+tests/book
+tests/jupyterlite
+tests/playground/pkg
+tests/_*
+tests/scripts/_*
+
+# Generated artefacts and scratch files
+factorials
+mathics
+examples
+*-checkpoint.ipynb
+.jupyterlite.doit.db
+sample.txt
+
+# Editor / IDE state
+.idea
+.vscode
+
+# Don't ship the Dockerfile itself into the build context
+Dockerfile
+.dockerignore

woxi-0.1.0/.envrc

@@ -0,0 +1 @@
+use flake

woxi-0.1.0/.gitignore

@@ -0,0 +1,17 @@
+.DS_Store
+/.claude
+/*-checkpoint.ipynb
+/.direnv
+/.env
+/.jupyterlite.doit.db
+/examples
+/mathics
+/node_modules
+/target
+/tests/_*
+/tests/book
+/tests/jupyterlite
+/tests/playground/pkg
+/tests/playground/vendor
+/tests/scripts/_*
+/todos.md

woxi-0.1.0/.pre-commit-config.yaml

@@ -0,0 +1,14 @@
+repos:
+  - repo: local
+    hooks:
+      - id: clippy-fix
+        name: Clippy Fix
+        language: unsupported
+        entry: cargo clippy --fix --allow-dirty
+        pass_filenames: false
+
+      - id: cargo-fmt
+        name: Cargo Format
+        language: unsupported
+        entry: cargo fmt
+        pass_filenames: false

woxi-0.1.0/AGENTS.md

@@ -0,0 +1,57 @@
+## Scope
+
+This repo contains several related sub-projects:
+
+- Woxi
+    - Interpreter for a subset of the Wolfram Language
+    - Is a computer algebra system (CAS) and therefore all computations must be solved symbolically
+- Woxi Playground
+    - A simple playground to try out Woxi in the browser (tests/playground)
+- Woxi JupyterLite
+    - JupyterLite instance with an integrated Woxi kernel (tests/jupyterlite)
+- Woxi Studio
+    - A native notebook editor for Wolfram Language `.nb` files, built with `iced` (woxi-studio)
+- Woxi for Python
+    - PyO3/maturin-based Python package wrapping the interpreter,
+      published to PyPI as `woxi` (woxi-py)
+
+
+## Environment
+
+Nix Flake is used to manage system dependencies.
+Therefore, some tools in the path are the GNU versions.
+E.g. GNU sed, GNU make, GNU coreutils, and GNU bash.
+
+
+## Development
+
+There is 3 levels of tests:
+
+1. Unit tests in ./tests/*.rs files.
+    They are the fastest to execute and
+    there should be a unit test for every feature / language construct here.
+2. Snapshots tests in ./tests/scripts/*.wls files
+    They ensure the code also works in files and
+    has exactly the same output when run with `wolframscript`.
+3. Documentation tests in ./tests/cli/*.md files.
+    Serves as documentation and also ensures `woxi` and `wolframscript`
+    have the same output for shorter and more diverse code snippets.
+    Those tests should be less comprehensive than the unit tests and
+    focus on illustrative examples.
+
+**Follow those rules:**
+
+- Whenever you change something, add unit tests for it.
+- When fixing a bug, always add a regression test so the bug wont't occur again.
+- Always run `make test` after any changes to rule out any regressions.
+- Never implement features or tests only for special cases like e.g. one specific number.
+    Make sure to implement it for all possible cases!
+- Use `wolframscript -code 'Plus[1, 2]'` to verify the output of Wolfram Language code.
+    The output of Woxi must 100% match the output of wolframscript.
+- Do not write code to temporary files. Simply use `cargo run -- eval '<code>'`.
+- If you stumble upon a pre-existing issue, do not try to ignore it or work around it,
+    but rather fix it right away.
+- After implementing a new function, make sure to update functions.csv
+    including a description and an effect_level.
+- To see the graphical output of expressions wrap them with:
+    `ExportString[<expression>, "SVG"]`

woxi-0.1.0/CLAUDE.md

@@ -0,0 +1,57 @@
+## Scope
+
+This repo contains several related sub-projects:
+
+- Woxi
+    - Interpreter for a subset of the Wolfram Language
+    - Is a computer algebra system (CAS) and therefore all computations must be solved symbolically
+- Woxi Playground
+    - A simple playground to try out Woxi in the browser (tests/playground)
+- Woxi JupyterLite
+    - JupyterLite instance with an integrated Woxi kernel (tests/jupyterlite)
+- Woxi Studio
+    - A native notebook editor for Wolfram Language `.nb` files, built with `iced` (woxi-studio)
+- Woxi for Python
+    - PyO3/maturin-based Python package wrapping the interpreter,
+      published to PyPI as `woxi` (woxi-py)
+
+
+## Environment
+
+Nix Flake is used to manage system dependencies.
+Therefore, some tools in the path are the GNU versions.
+E.g. GNU sed, GNU make, GNU coreutils, and GNU bash.
+
+
+## Development
+
+There is 3 levels of tests:
+
+1. Unit tests in ./tests/*.rs files.
+    They are the fastest to execute and
+    there should be a unit test for every feature / language construct here.
+2. Snapshots tests in ./tests/scripts/*.wls files
+    They ensure the code also works in files and
+    has exactly the same output when run with `wolframscript`.
+3. Documentation tests in ./tests/cli/*.md files.
+    Serves as documentation and also ensures `woxi` and `wolframscript`
+    have the same output for shorter and more diverse code snippets.
+    Those tests should be less comprehensive than the unit tests and
+    focus on illustrative examples.
+
+**Follow those rules:**
+
+- Whenever you change something, add unit tests for it.
+- When fixing a bug, always add a regression test so the bug wont't occur again.
+- Always run `make test` after any changes to rule out any regressions.
+- Never implement features or tests only for special cases like e.g. one specific number.
+    Make sure to implement it for all possible cases!
+- Use `wolframscript -code 'Plus[1, 2]'` to verify the output of Wolfram Language code.
+    The output of Woxi must 100% match the output of wolframscript.
+- Do not write code to temporary files. Simply use `cargo run -- eval '<code>'`.
+- If you stumble upon a pre-existing issue, do not try to ignore it or work around it,
+    but rather fix it right away.
+- After implementing a new function, make sure to update functions.csv
+    including a description and an effect_level.
+- To see the graphical output of expressions wrap them with:
+    `ExportString[<expression>, "SVG"]`