Currently CD only builds for macOS and publishes to the Homebrew tap. Support to publish a release of Windows, Linux and macOS binaries would be good.

pipes.sh has this, so we should too.

This could result in invalid colours; I’ve come up with two possible solutions:

• before drawing anything on the screen you go through all possible hues, ensuring that they are all valid
• if the colour you generate is invalid, you then try again with a different random hue. This means you won’t definitely get an even mix of colours (you’ll only get those possible at the current chroma/lightness combination), and also would lead to an infinite loop if there aren’t any valid colours at that chroma and lightness

For now we’ll want these to include an x86_64 slice and an arm64 slice. See the rust-analyzer CD for how we can build for both architectures. It’s trivial to then merge the two resulting binaries with lipo(1).

I wonder if macOS 14 will stabilize the arm64e ABI (which IIUC has been in preview since Big Sur) so we can turn on pointer authentication. (This is all irrelevant for pipes-rs’s purposes, but hey overengineering is the name of the game.)

Hmmm, it would be trivial to come up with a little one-liner that `curl`s the latest release, untars, and then runs `cargo install --path pipes-rs-v1.6.0/` or something.

Originally posted by @arzg in #111 (comment)

Since each character cell in the terminal is roughly two times as tall as it is wide, pipes traveling vertically appear to move twice as fast as pipes which are traveling horizontally. Of course, this doesn’t apply to pipes whose unicode width isn’t 1.

This project is super fun! Any chance of publishing it to crates.io?

The build failed when I attempted to test this app.

Compiling nanorand v0.5.2
error[E0277]: arrays only have std trait implementations for lengths 0..=32

PS C:\Users\username\Projects\rust\testing> cargo install --git https://github.com/CookieCoder15/pipes-rs
    Updating git repository `https://github.com/CookieCoder15/pipes-rs`
  Installing pipes-rs v1.4.0 (https://github.com/CookieCoder15/pipes-rs#7acb8fd4)
    Updating crates.io index
  Downloaded anyhow v1.0.38
  Downloaded structopt v0.3.21
  Downloaded crossterm v0.19.0
  Downloaded tincture v0.5.0
  Downloaded oorandom v11.1.3
  Downloaded serde v1.0.124
  Downloaded flume v0.10.2
  Downloaded getrandom v0.2.2
  Downloaded mimalloc v0.1.25
  Downloaded crossterm_winapi v0.7.0
  Downloaded serde_derive v1.0.124
  Downloaded pin-project v1.0.5
  Downloaded spinning_top v0.2.2
  Downloaded structopt-derive v0.4.14
  Downloaded futures-sink v0.3.13
  Downloaded nanorand v0.5.2
  Downloaded futures-core v0.3.13
  Downloaded parking_lot v0.11.1
  Downloaded toml v0.5.8
  Downloaded cfg-if v1.0.0
  Downloaded etcetera v0.3.2
  Downloaded libmimalloc-sys v0.1.21
  Downloaded quote v1.0.9
  Downloaded pin-project-internal v1.0.5
  Downloaded heck v0.3.2
  Downloaded proc-macro-error v1.0.4
  Downloaded thiserror v1.0.24
  Downloaded instant v0.1.9
  Downloaded parking_lot_core v0.8.3
  Downloaded cc v1.0.67
  Downloaded dirs-next v2.0.0
  Downloaded thiserror-impl v1.0.24
  Downloaded smallvec v1.6.1
  Downloaded unicode-segmentation v1.7.1
  Downloaded proc-macro-error-attr v1.0.4
  Downloaded dirs-sys-next v0.1.2
  Downloaded lock_api v0.4.2
  Downloaded syn v1.0.62
  Downloaded scopeguard v1.1.0
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.62
   Compiling winapi v0.3.9
   Compiling cfg-if v1.0.0
   Compiling version_check v0.9.2
   Compiling bitflags v1.2.1
   Compiling getrandom v0.2.2
   Compiling scopeguard v1.1.0
   Compiling unicode-width v0.1.8
   Compiling serde_derive v1.0.124
   Compiling smallvec v1.6.1
   Compiling cc v1.0.67
   Compiling lazy_static v1.4.0
   Compiling serde v1.0.124
   Compiling anyhow v1.0.38
   Compiling unicode-segmentation v1.7.1
   Compiling futures-sink v0.3.13
   Compiling futures-core v0.3.13
   Compiling vec_map v0.8.2
   Compiling oorandom v11.1.3
   Compiling strsim v0.8.0
   Compiling tincture v0.5.0
   Compiling instant v0.1.9
   Compiling lock_api v0.4.2
   Compiling textwrap v0.11.0
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling heck v0.3.2
   Compiling spinning_top v0.2.2
   Compiling nanorand v0.5.2
error[E0277]: arrays only have std trait implementations for lengths 0..=32
  --> C:\Users\username\.cargo\registry\src\github.com-1ecc6299db9ec823\nanorand-0.5.2\src\rand\chacha.rs:47:2
   |
46 | impl RNG for ChaCha {
   | ------------------- in this `impl` item
47 |     type Output = [u8; 64];
   |     ^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[u8; 64]`
   |
  ::: C:\Users\username\.cargo\registry\src\github.com-1ecc6299db9ec823\nanorand-0.5.2\src\rand\mod.rs:28:10
   |
28 |     type Output: AsRef<[u8]>;
   |          ------ associated type defined here
   |
   = note: required because of the requirements on the impl of `std::convert::AsRef<[u8]>` for `[u8; 64]`
error: aborting due to previous error
For more information about this error, try rustc --explain E0277.

error: could not compile nanorand.

warning: build failed, waiting for other jobs to finish...

error: failed to compile pipes-rs v1.4.0 (https://github.com/CookieCoder15/pipes-rs#7acb8fd4), intermediate artifacts can be found at C:\Users\username\AppData\Local\Temp\cargo-installgXe2RB
Caused by:

build failed

PS C:\Users\username\Projects\rust\testing>

System info

cargo 1.40.0 (bc8e4c8be 2019-11-22)
Windows Terminal Version 1.6.10571.0
Windows 10 Version 2004

jemalloc and mimalloc are both worth a try.

Migrated from this comment.

It might also be worth adding panic = "abort" to the release profile, as this eliminates code needed to show backtraces and catch panics, which can be expensive. The downside is that debugging is more difficult, as when a panic is encountered in release mode there will be no way of knowing where it came from. Perhaps this could be alleviated by saving the random seed used to a temporary file somewhere (maybe ~/.cache/pipes-rs/last_seed) so that the run that caused the panic can be reproduced.

https://gfycat.com/heftyparallelannelid
it keeps resetting! Am I doing something wrong? or this is a bug?
using this command
pipes-rs.exe -b true -c rgb -i true -k curved -p 100

Seems like I don't have the required Character set to view the heavy, curved, knobby, emojis pipe faces on my system!

Edit: *curved instead of dots
Edit: I forgot to set the reset threshold! it was my fault! forgive me guys!

Before we implement some sort of scaling of the pipes on resize, we should first make sure it doesn’t ‘break’ like it does currently.

s/Installlation/Installation

Can’t be bothered to fix atm.

By default, the compiler splits each crate into sixteen ‘codegen units’, which can all be compiled in parallel. This improves compile times, but can lead to worse performance as IIUC some optimisations cannot be performed across codegen unit boundaries. Compile times do not matter for release builds, so I suggest we add codegen_units = 1 to Cargo.toml so that crates aren’t split.

On NixOS I get this error either if I use the system wide installed cargo or in a nix-shell.

error[E0277]: arrays only have std trait implementations for lengths 0..=32
  --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/nanorand-0.5.2/src/rand/chacha.rs:47:16
   |
47 |     type Output = [u8; 64];
   |                   ^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[u8; 64]`
   | 
  ::: /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/nanorand-0.5.2/src/rand/mod.rs:26:11
   |
26 | pub trait RNG: Clone {
   |           --- required by a bound in this
27 |     /// The byte output that this RNG emits.
28 |     type Output: AsRef<[u8]>;
   |                  ----------- required by this bound in `rand::RNG`
   |
   = note: required because of the requirements on the impl of `std::convert::AsRef<[u8]>` for `[u8; 64]`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `nanorand`.

We should verify that reset_threshold and turn_chance are in the range 0.0..1.0.

Brief Description of the issue

After attempting to install pipes-rs through cargo build fails with error.

Expected Behavior

Build succeeds and pipes-rs is installed in the system.

Actual Behavior

Errors,

Updating git repository `https://github.com/lhvy/pipes-rs.git`
  Installing pipes-rs v1.4.1 (https://github.com/lhvy/pipes-rs.git#889d5e7f)
    Updating crates.io index
  Downloaded structopt v0.3.21
  Downloaded oorandom v11.1.3
  Downloaded unicode-segmentation v1.7.1
  Downloaded dirs-next v2.0.0
  Downloaded heck v0.3.2
  Downloaded mio v0.7.11
  Downloaded pin-project-internal v1.0.6
  Downloaded mimalloc v0.1.25
  Downloaded dirs-sys-next v0.1.2
  Downloaded thiserror v1.0.24
  Downloaded thiserror-impl v1.0.24
  Downloaded toml v0.5.8
  Downloaded anyhow v1.0.40
  Downloaded futures-sink v0.3.13
  Downloaded futures-core v0.3.13
  Downloaded crossterm v0.19.0
  Downloaded pin-project v1.0.6
  Downloaded nanorand v0.5.2
  Downloaded structopt-derive v0.4.14
  Downloaded proc-macro-error v1.0.4
  Downloaded proc-macro-error-attr v1.0.4
  Downloaded serde v1.0.125
  Downloaded syn v1.0.67
  Downloaded version_check v0.9.3
  Downloaded spinning_top v0.2.2
  Downloaded flume v0.10.2
  Downloaded getrandom v0.2.2
  Downloaded serde_derive v1.0.125
  Downloaded libc v0.2.91
  Downloaded tincture v0.5.0
  Downloaded etcetera v0.3.2
  Downloaded libmimalloc-sys v0.1.21
  Downloaded 32 crates (2.7 MB) in 18.16s
   Compiling libc v0.2.91
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.67
   Compiling cfg-if v1.0.0
   Compiling version_check v0.9.3
   Compiling getrandom v0.2.2
   Compiling scopeguard v1.1.0
   Compiling bitflags v1.2.1
   Compiling log v0.4.14
   Compiling serde_derive v1.0.125
   Compiling unicode-width v0.1.8
   Compiling smallvec v1.6.1
   Compiling anyhow v1.0.40
   Compiling lazy_static v1.4.0
   Compiling cc v1.0.67
   Compiling serde v1.0.125
   Compiling futures-core v0.3.13
   Compiling unicode-segmentation v1.7.1
   Compiling futures-sink v0.3.13
   Compiling strsim v0.8.0
   Compiling ansi_term v0.11.0
   Compiling vec_map v0.8.2
   Compiling oorandom v11.1.3
   Compiling tincture v0.5.0
   Compiling instant v0.1.9
   Compiling lock_api v0.4.2
   Compiling textwrap v0.11.0
   Compiling heck v0.3.2
   Compiling spinning_top v0.2.2
   Compiling quote v1.0.9
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling signal-hook-registry v1.3.0
   Compiling parking_lot_core v0.8.3
   Compiling mio v0.7.11
   Compiling atty v0.2.14
   Compiling dirs-sys-next v0.1.2
   Compiling clap v2.33.3
   Compiling dirs-next v2.0.0
   Compiling nanorand v0.5.2
   Compiling rng v0.1.0 (/home/sebas/.cargo/git/checkouts/pipes-rs-a78de783e7e290ef/889d5e7/crates/rng)
   Compiling parking_lot v0.11.1
   Compiling signal-hook v0.1.17
   Compiling crossterm v0.19.0
   Compiling libmimalloc-sys v0.1.21
   Compiling mimalloc v0.1.25
   Compiling pin-project-internal v1.0.6
   Compiling thiserror-impl v1.0.24
   Compiling structopt-derive v0.4.14
   Compiling thiserror v1.0.24
   Compiling etcetera v0.3.2
   Compiling pin-project v1.0.6
   Compiling flume v0.10.2
   Compiling terminal v0.1.0 (/home/sebas/.cargo/git/checkouts/pipes-rs-a78de783e7e290ef/889d5e7/crates/terminal)
   Compiling structopt v0.3.21
   Compiling model v0.1.0 (/home/sebas/.cargo/git/checkouts/pipes-rs-a78de783e7e290ef/889d5e7/crates/model)
   Compiling toml v0.5.8
error[E0658]: use of unstable library feature 'array_value_iter'
   --> crates/model/src/pipe/kind.rs:191:30
    |
191 |             .flat_map(|kind| array::IntoIter::new(kind.chars()))
    |                              ^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #65798 <https://github.com/rust-lang/rust/issues/65798> for more information

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `model`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `pipes-rs v1.4.1 (https://github.com/lhvy/pipes-rs.git#889d5e7f)`, intermediate artifacts can be found at `/tmp/cargo-installRYbLqA`

Caused by:
  build failed

System info

OS: PopOS 20.10
Kernel: 5.8.0-7642-generic

Rather than measuring the coverage of the screen, all we do is measure the number of times the screen has refreshed. Ideally we should instead store the contents of the screen, and measure what portion of the screen’s cells have something on them.

Terminal emulators such as Alacritty take as much data as possible from the program and only update the window at a certain refresh rate. If we limit pipes-rs to output at the same rate as the window, then we’ll save a lot of unnecessary stepping of the world when the window isn’t even updating. I guess the pipes are still moving during this time between window updates, which means this change would slow down pipe movement, but thereby make pipe movement speed consistent regardless of the terminal’s speed.

spin_sleep is perfect for both implementing this and an FPS meter.

If you leave pipes-rs --reset-threshold 0 --delay 0 running for long enough, ticks will repeatedly be incremented until it overflows, resulting in a panic.

From #36.

When I try running with a large number of pipes, pipes-rs starts to hog the CPU and eat up memory. For instance, running pipes-rs -p 929292 -r 0 in a standard 80×24 terminal window leads to a consistent saturation of one CPU core (95%), as well as memory usage hovering around 90MB.

Possible ways to improve performance:

• Lock STDOUT at program start to avoid locking onto it on every single write call. Completed by #61.
• Explicitly buffer STDOUT writing using a BufWriter. On second thought, this won’t do anything as std::io::Stdout already contains a BufWriter that flushes when a newline is written, which never happens.
• Consolidate Vecs of multiple instances of a type into a single global Vec (e.g. turn dirs field on Pipe into a std::ops::Range<usize> that indexes into a global Vec of pipe direction history) Obviated by #57.
• Enable #[inline(always)] on Terminal::move_cursor_to as this is an extremely hot function that, when compiled with optimisations, doesn’t do much apart from forwarding to std’s write machinery. Completed by #60.

To measure changes in actual runtime performance we should add an FPS meter. I realised in #59 that this isn’t possible.

Alternativley

It might be helpful to list the available key bindings in the readme.

• r resets
• q exits

From #36.

Hi,

First of all, I love this, thank you for making it. We all deserve nice things in Rust and what better than pipes.sh!

That having been said, I recently saw a screenshot of a particular wayland compositor that features pipes with rainbow colors.

This is the link to that screenshot: https://camo.githubusercontent.com/7481081d2b3d79ed59007f1978b7364da1c503c0c767f0131344da7728428fb6/68747470733a2f2f692e696d6775722e636f6d2f427058784d38482e706e67

tl;dr: -c rgb is sweet, but can we have a -c rainbow too?!

We can make these independent of the terminal by passing an implementor of std::io::Write into terminal::Terminal and extracting the logical core of App into another type that can be constructed from a Config, std::io::Write instance and terminal::Terminal. In the benchmarks the std::io::Write instance can be a type that simply swallows all writes and drops them.

Criterion can be used a benchmarking harness.

Once benchmarks are in place, future optimisations (e.g. data-oriented design’s struct of arrays) will have a sound basis.

Rust 1.55 stabilised std::ops::ControlFlow, which we defined manually. We should switch to using the definition from the standard library.

• improves performance because you don’t need to keep asking the terminal what its size is
• allows Terminal::size to not return a Result, which means a ton of other functions that were only returning Results because of this now don’t have to return a Result
• paves the way for #2 because that also needs infrastructure to do something on each resize

When running pipes-rs with settings set in a config file at ~/.config/pipes-rs/config.toml, omitting the license field causes a parser error.

With a config like:

color_mode = "rgb"
delay_ms = 42
inherit_style = true
kinds = ["heavy"]
num_pipes = 16
palette = "default"
reset_threshold = 0.0
turn_chance = 0.1

Running

$ pipes-rs

yields:

Error: failed to read config

Caused by:
    TOML parse error at line 1, column 1
      |
    1 | color_mode = "rgb"
      | ^^^^^^^^^^^^^^^^^^
    missing field `license`

Even an empty config file will yield this error.

Adding license = false resolves the issue, but seems a little silly to have that field be required in the first place.