Google Git
Sign in
apache/magpie/HEAD/./tools/probe-templates
tree: b815f7a7c786cea2c156789942056bf769af8213
  1. groovy/
  2. README.md
tools/probe-templates/README.md

Table of Contents generated with DocToc

Probe templates

Capability: substrate:sandbox

Harness: agnostic

Runnable cross-family probe scripts that the issue-reproducer skill copies from when its Step 9 (optional cross-family probe) runs against an issue.

The probe pattern, contract, and recording schema are in the skill's probe-templates.md companion. This directory holds runtime-specific reference implementations.

Prerequisites

  • Runtime: None of its own — this directory holds per-runtime probe template files (today groovy/). Running a probe needs the matching language runtime (e.g. a Groovy interpreter for the groovy/ templates).
  • CLIs: Whatever runs the target runtime's scripts; nothing else.
  • Credentials / auth: None.
  • Network: Runs fully offline/local.

Layout

tools/probe-templates/
├── README.md                        (this file)
└── <runtime>/                       (one subdirectory per supported runtime)
    └── *.template                   (probe template files with placeholders)

Adopters with JVM-language projects copy from <runtime>/ where <runtime> matches their language. Adopters whose runtime is not covered contribute their own per-runtime templates back via PR.

What a probe template looks like

A probe template is a small runnable script that exercises the same expression across every member of a type or operator family and emits a comparison table. The structure is universal across runtimes:

# Pseudocode (each runtime renders this in its own syntax):
probes = {
    "Member A": () => { construct backend A, exercise the expression }
    "Member B": () => { same expression on backend B }
    # ... one entry per family member
}
for name, body in probes:
    try:
        outcome = body()
    catch e:
        outcome = "THREW: " + type(e) + ": " + message(e)
    print(name + " | " + outcome)

The expression under test is a placeholder; users substitute it when running against a specific issue.

Contributing a runtime

The framework treats every per-runtime subdirectory as first-class. Today the groovy/ subdirectory ships in the framework; python/, kotlin/, java/, rust/, and other-language subdirectories are welcome and awaiting contribution. None of them require framework-side support beyond adding the subdirectory — the per-runtime probe scripts are runnable standalone.

Adopters with a new runtime should:

  1. Add a subdirectory tools/probe-templates/<runtime>/ matching the runtime's conventional short name (lowercase, hyphenated).
  2. Add at least one template file per supported family type:
    • range-index-cross-type.<ext>.template
    • gpath-cross-backend.<ext>.template
    • operator-variants-safe-nav.<ext>.template
  3. Each template file has a header comment naming the family being probed, the placeholders the user substitutes, and an example invocation.
  4. Open a PR against apache/magpie.

Note: not every language has every family. A typed compiled language without an operator-overloading subsystem may have no operator-variants-* templates; that's fine — the framework only loads templates that exist.

Cross-references