100%

run1:test (OK)

✓ Published0🌍 Public

Last edited Jul 14, 2022

Created on Jul 14, 2022

This example demonstrates the Chomp task runner's behavior with different wildcard patterns in task names, highlighting a discrepancy between `run1:#` and `run2:##` when handling variable substitution. The visualization pairs terminal output from successful `chomp` commands with the corresponding `chompfile.toml` configuration, showing how `$DEP` and `$TARGET` resolve to full filenames in the first case but truncate to shorter names like `st.out` in the second. The rendered output uses monospaced text blocks to juxtapose command execution results, revealing that the `#` wildcard matches a single character while `##` matches multiple, causing the observed path shortening. This comparison effectively exposes a subtle naming convention pitfall in Chomp's task definitions.

AI-generated description

run1:test (OK)

Running run1:test works fine

chomp run1:test
🞂 ./test.out
./test.txt ./test.out
√ ./test.out [4.791791ms]

run1:

Running run1: results in truncated paths

chomp run1:
🞂 ./st.out
./st.txt ./st.out
√ ./st.out [6.474458ms]
√ :run1:#

Similar vizzes

Loading thumbnail…

run1:test (OK)

The example demonstrates how the Chomp build tool handles task targets containing wildcard `#` patterns, showing a working `run1:test` task alongside a truncated-path case for `run1:`. It compares command outputs where `./test.out` and `./st.out` are built, with the latter’s path shortened in the displayed terminal. The visualization uses plain terminal text from `chomp` runs, with validation set to `ok-only` and dependencies/targets defined in a TOML config. The data source is the tool’s own execution log, rendered as static shell snippets.

HHypercubed

89% match

Loading thumbnail…

Gist 578885

This example shows the results of running a Cucumber feature file twice: once with the `require` statement left as-is, and once after replacing it with the file’s contents. The terminal output displays a failing scenario with two skipped steps in the first run, followed by a passing scenario with two passing steps in the second. The visualization highlights the difference in outcome by pairing the two command-line outputs, each labeled with the cucumber command and profile. It demonstrates how a simple code substitution—in this case, inlining a required file—affects test execution, using the Ruby testing framework and its command-line interface.

DDylanFM

52% match

Loading thumbnail…

globby - chuhai

This example compares the performance of two glob-matching libraries—the local `globby` fork and the upstream `globby` master—against `glob-stream`, using the `chuhai` and `ava` benchmarking suites. It shows raw operations per second for three pattern scenarios (negative globs and multiple positive globs) across async and sync APIs, with results from 10 runs each. The code directly invokes `globby.sync()`, `globby()`, and `glob-stream`'s `create()` to measure throughput, while the markdown output lists the fastest implementation per test. Data is generated from a temporary directory containing 500 files per subfolder, and the rendering is plain text from benchmark results.

HHypercubed

51% match

Loading thumbnail…

Stack level too deep

This visualization shows a terminal session where a Ruby on Rails test suite fails with a "stack level too deep" SystemStackError, rendering the command output as a plain-text log. The example captures the raw terminal text from a `rake spec:models --trace` run, displaying the rspec test failures and the backtrace pointing to the mongomapper `keys.rb` library. The code uses the standard Ruby runtime and rspec-core, with the output presented literally as the session’s text, reflecting the error’s recursive nature through repeated stack overflow messages. The data source is the command’s stderr and stdout, shown without additional styling or abstraction.

CCaged

50% match

Loading thumbnail…

Gist 1782460

This visualization shows the result of running Ruby code that attempts to load `rake/compiletask` twice, failing both times with a `LoadError` because the file does not exist. It presents a terminal session where the user first checks the MacRuby version, then tries to require the missing library, and finally verifies that `rake` loads successfully but the specific compile task file remains unavailable. The example uses the Ruby `require` method and the `rake` gem’s API to demonstrate a common error-handling scenario, highlighting the difference between loading a gem and accessing a non-existent sub-file. The data source is the literal command-line output and error messages from the user’s shell.

CCaged

46% match

Loading thumbnail…

Clojure thoughts and tips

The example shows a Clojure gist that clarifies the distinct behaviors of the standard functions `comp` and `juxt` through commented code and live map calls. It first demonstrates `juxt` with `map`, `name`, and `str/capitalize` to produce pairs like `["name" ":name"]`, then examines `comp` to reveal its right-to-left application order, correcting an initial misuse. The code uses Clojure core APIs such as `clojure.core/comp`, `clojure.core/juxt`, `map`, and `str/capitalize` directly in the REPL. The source is a gist authored by Eleonore9, with rendering limited to text output from the function calls.

EEleonore9

46% match

Loading thumbnail…

ava test

This example compares the TAP output of the AVA test runner with that of the `tape` and `tap` libraries, highlighting inconsistencies in console log placement and stream routing. It shows that AVA emits console logs before test titles and writes them to stderr, while `tape` and `tap` place logs after titles on stdout. The visualization uses the `console.log` calls within each test to trace the order and destination of output, contrasting the raw TAP streams side by side. The code relies on the test APIs of `ava`, `tape`, and `tap` to produce the compared outputs.

HHypercubed

46% match

Loading thumbnail…

<title>Testing XPath

This example demonstrates how XPath and the XQuery `typeswitch` expression can be used to selectively process different node types in an XML document. It shows a TEI-encoded text where comments, text nodes, and `<p>` elements are handled distinctly, with element attributes joined into a space-separated string. The code relies on the XQuery 3.0 standard library functions `fn:string` and `fn:string-join`, operating on the TEI namespace declared in the document. The visualization is static, with no graphical rendering; instead, it highlights the programmatic traversal and conditional branching over the XML tree structure.

CCliffordAnderson

45% match