ParetoStackpareto-stackdocshpc-labs

What changed in 0.4.1

Changes in 0.4.1, compared with 0.4.0. The full history of every version is on the all versions page.

0.4.1 (2026-10-25)

Fixes, a clearer start for new users and an AWS Lambda and a Google Cloud Functions example to try the cloud commands on. The engine is the same as 0.4.0.

Added

  • A Google Cloud Functions example, gcf_log_digest (paretostack examples gcf_log_digest, the console's project list, example.sh gcf / example.cmd gcf, step 17 of the tour): an HTTP Cloud Function (main.digest_http) that reports on web access-log lines, with a local harness (harness.py) that times and verifies it offline, byte for byte, through a stand-in for the web request object, and writes recorded requests for the cloud commands. docs/GCF_EXAMPLE.md.
  • paretostack cloud gcf-optimize --zip PACKAGE --events FILE --entry-point NAME: the Google twin of lambda-optimize --zip: the exact optimizers on the function's own Python files, verified offline on the recorded requests on this machine (identical status and body; the timing is indicative); original.zip, optimized.zip, changes.diff, report.json in --out. A licensed command. Not built yet: --port for Cloud Functions and the live verification on deployed copies.
  • An AWS Lambda example, lambda_log_digest (paretostack examples lambda_log_digest, the console's project list, example.sh lambda / example.cmd lambda, step 16 of the tour): a handler (lambda_function.handler) that digests SQS batches of log lines, with a local harness (main.py) that times and verifies it offline, byte for byte, and writes recorded events for the cloud commands. docs/LAMBDA_EXAMPLE.md: offline as a project, offline as a deployment package, live on a sandbox copy. Before this the 0.4.x cloud commands shipped without anything to try them on.
  • paretostack cloud lambda-optimize --zip PACKAGE --events FILE [--handler module.function]: the same optimization as on a deployed function, on a local deployment package, offline: the optimized code is verified against the original on the recorded events on this machine (identical answers; the timing is indicative), nothing is sent anywhere; original.zip, optimized.zip, changes.diff, report.json in --out. The tour's step 16b runs it on the example.
  • The assistant is documented: a new "Assistant (pareto)" page in the documentation (how to start it, that it needs no AI model and no API key, the models and keys, exactly what a cloud model is sent, every command).
  • The Windows installer's Getting started file has a section on pareto (no AI model and no API key needed; a local model, Claude or OpenAI only if you pick one, and then only a short summary, never your code).

Fixed (from the 0.3.10 DGX package installed from hpc-labs.ai as a customer would, and the full example tour, 2026-10-25)

  • update.sh (Linux, DGX) also refreshes what install.sh put under ~/ParetoStack: the example script and the profile are replaced by the package's, sample projects the install lacks are added (existing ones are never overwritten). Before, a customer who updated kept the old tour script and never saw the new steps (16 Lambda, 17 Google Cloud Functions) or the new samples unless they ran example.sh from the package folder. Windows keeps its samples in the package folder, so update.cmd needs nothing.
  • The EC2 probe suggests the current Graviton generations (c8g, m8g or m9g, r8g; t4g for burstable) instead of the 7g families. m9g is Graviton5 (generally available June 2026, some regions only).
  • Windows install.ps1 picks the Python a compiled package needs. With several Pythons installed it took the newest (for example 3.14) and failed with "not a supported wheel"; it now looks for the version in the wheel's name (3.12 for cp312) first, says so clearly if that Python is missing, and starts an earlier environment on another Python again. When only python was found (no py launcher) it crashed on $py[0] (the first letter of the word). Found by running the 0.4.1 zip on a Windows 11 PC with Python 3.11 to 3.14.
  • The license refusal now also names the whitelisted download (curl -fsSL https://hpc-labs.ai/api/license -o license.json), not only the account page.
  • example.sh labels its log after the package's PROFILE file (example-dgx-*.log), which install.sh now copies next to the installed script; before, the label came from the folder name, which is dgx only inside dist/, so a customer's DGX log said linux.
  • install.sh keeps a paretostack-console.service it did not write (ExecStart not the private environment: a source checkout, another python) and says so; --console-overwrite replaces it. update.sh says whether systemctl --user restart paretostack-console will pick the update up or that a hand-written unit is not affected.
  • update.sh found no wheel in a DGX package folder (paretostack-dgx-*, the pattern was paretostack-linux-*) and, with pipefail, ended silently with status 2 when a pattern matched nothing.
  • paretostack doctor has a JDK (javac, java) row (the Java front-end and the java_box_sums example, which the example scripts skipped without a word about where a JDK comes from; the scripts now point to doctor) and a zig (ziglang) row (cloud lambda-optimize --port). Both optional, each with the install command for the system's package manager; --everything still does not pull a JDK onto every machine.
  • The DGX install adds CuPy to the private environment (the wheel of the CUDA toolkit found: cupy-cuda12x / cupy-cuda13x; --no-gpu skips it), so the GPU offload optimizers and the doctor row work out of the box; doctor's hint names the matching wheel instead of always cupy-cuda13x.