.rs # service definition for role B (e.g. client)
-```
-In the default example, the roles we use are `Client` and `Server`, but you can imagine different roles depending on the structure of your service or application.
-
### `main.rs`
We start with a `main` function that parses command-line options, and invokes the appropriate
role-specific service.
@@ -61,7 +47,7 @@ Following that, we use Rust's [`clap`](https://docs.rs/clap/latest/clap/) (Comma
This sets up 3 command-line flags: `role`, `addr`, and `server_addr`. Note how the `addr` and `server_addr` flags are made optional via wrapping in a Rust `Option`; by contrast, the `role` option is required. The `clap` crate will parse the command-line options and populate the `Opts` struct with the values. `clap` handles parsing the command line strings into the associated Rust types -- the `value_parser` attribute tells `clap` to use Hydroflow's `ipv4_resolve` helper function to parse a string like "127.0.0.1:6552" into a `SocketAddr`.
-This brings us to the `main` function itself. It is prefaced by a `#[hydroflow::main]` attribute, which is a macro that sets up the tokio runtime for Hydroflow. This is necessary because Hydroflow uses the tokio runtime for asynchronous execution as a service.
+This brings us to the `main` function itself. It is prefaced by a `#[hydroflow::main]` attribute, which is a macro that sets up the tokio runtime for Hydroflow. It is also an async function. This is necessary because Hydroflow uses the tokio runtime for asynchronous execution as a service.
{getLines(main, 29, 40)}
diff --git a/docs/docs/hydroflow/quickstart/example_8_chat_server.mdx b/docs/docs/hydroflow/quickstart/example_8_chat_server.mdx
index 06d3c8c6c52..90dec2b370b 100644
--- a/docs/docs/hydroflow/quickstart/example_8_chat_server.mdx
+++ b/docs/docs/hydroflow/quickstart/example_8_chat_server.mdx
@@ -13,7 +13,7 @@ import { getLines } from '../../../src/util';
> * Multiple message types and the [`demux`](../syntax/surface_ops_gen.md#demux) operator.
> * A broadcast pattern via the [`cross_join`](../syntax/surface_ops_gen.md#cross_join) operator.
> * One-time bootstrapping pipelines
-> * A "gated buffer" pattern via `cross_join` with a single-object input.
+> * A "gated buffer" using [`defer_signal`](../syntax/surface_ops_gen.md#defer_signal) and [`persist`](../syntax/surface_ops_gen.md#persist) operators
Our previous [echo server](./example_7_echo_server) example was admittedly simplistic. In this example, we'll build something a bit more useful: a simple chat server. We will again have two roles: a `Client` and a `Server`. `Clients` will register their presence with the `Server`, which maintains a list of clients. Each `Client` sends messages to the `Server`, which will then broadcast those messages to all other clients.
@@ -53,18 +53,21 @@ To follow along, replace the contents of `src/server.rs` with the code below:
{getLines(server, 1, 24)}
-After a short prelude, we have the Hydroflow code near the top of `run_server()`. It begins by defining `outbound_chan` as a `union`d destination sink for network messages. Then we get to the
+After a short prelude, we have the Hydroflow code near the top of `run_server()`. It begins by defining `outbound_chan` as a `union`ed destination sink for network messages. Then we get to the
more interesting `inbound_chan` definition.
The `inbound` channel is a source stream that will carry many
-types of `Message`s. We use the [`demux`](../syntax/surface_ops_gen.md#demux) operator to partition the stream objects into three channels. The `clients` channel
+types of `Message`s.
+We first use a `map` operator to `unwrap` the Rust `Result` type that comes from deserializing the input
+from `source_stream_serde`.
+Then we use the [`demux`](../syntax/surface_ops_gen.md#demux) operator to partition the stream objects into three channels. The `clients` channel
will carry the addresses of clients that have connected to the server. The `msgs` channel will carry the `ChatMsg` messages that clients send to the server.
The `errs` channel will carry any other messages that clients send to the server.
Note the structure of the `demux` operator: it takes a closure on
-`(Message, SocketAddr)` pairs, and a variadic tuple (`var_args!`) of output channel names—in this case `clients`, `msgs`, and `errs`. The closure is basically a big
+`(Message, SocketAddr)` pairs, and a variadic tuple (`var_args!`) of the output channel names—in this case `clients`, `msgs`, and `errs`. The closure is basically a big
Rust pattern [`match`](https://doc.rust-lang.org/book/ch06-02-match.html), with one arm for each output channel name given in the variadic tuple. Note
-that the different output channels can have different-typed messages! Note also that we destructure the incoming `Message` types into tuples of fields. (If we didn't we'd either have to write boilerplate code for each message type in every downstream pipeline, or face Rust's dreaded [refutable pattern](https://doc.rust-lang.org/book/ch18-02-refutability.html) error!)
+that each output channel can have its own message type! Note also that we destructure the incoming `Message` types into component fields. (If we didn't we'd have to write boilerplate code to handle every possible `Message` type in every downstream pipeline!)
The remainder of the server consists of two independent pipelines, the code to print out the flow graph,
and the code to run the flow graph. To follow along, paste the following into the bottom of your `src/server.rs` file:
@@ -139,9 +142,8 @@ end
### `client.rs`
The chat client is not very different from the echo server client, with two new design patterns:
- 1. a degenerate `source_iter` pipeline that runs once
-as a "bootstrap" in the first tick
- 2. the use of `cross_join` as a "gated buffer" to postpone sending messages.
+ 1. a `initialize` operator that runs once to "bootstrap" action in the first tick
+ 2. the use of `defer_signal` and `persist` as a "gated buffer" to postpone sending messages.
We also include a Rust helper routine `pretty_print_msg` for formatting output.
@@ -152,7 +154,7 @@ To follow along, start by replacing the contents of `src/client.rs` with the fol
{getLines(client, 1, 27)}
This brings us to the `run_client` function. As in `run_server` we begin by ensuring the server address
-is supplied. We then have the hydroflow code starting with a standard pattern of a `union`d `outbound_chan`,
+is supplied. We then have the hydroflow code starting with a standard pattern of a `union`ed `outbound_chan`,
and a `demux`ed `inbound_chan`. The client handles only two inbound `Message` types: `Message::ConnectResponse` and `Message::ChatMsg`.
Paste the following to the bottom of `src/client.rs`:
@@ -165,15 +167,15 @@ bottom of your `src/client.rs` file.
{getLines(client, 47, 64)}
1. The first pipeline is the "bootstrap" alluded to above.
-It starts with `source_iter` operator that emits a single, opaque "unit" (`()`) value. This value is available when the client begins, which means
+It starts with the `initialize` operator that emits a single, opaque "unit" (`()`) value. This value is emitted when the client begins, which means
this pipeline runs once, immediately on startup, and generates a single `ConnectRequest` message which is sent to the server.
-2. The second pipeline reads from `source_stdin` and sends messages to the server. It differs from our echo-server example in the use of a `cross_join`
-with `inbound_chan[acks]`. This cross-join is similar to that of the server: it forms pairs between all messages and all servers that send a `ConnectResponse` ack.
-In principle this means that the client is broadcasting each message to all servers.
-In practice, however, the client establishes at most one connection to a server. Hence over time, this pipeline starts with zero `ConnectResponse`s and is sending no messages;
-subsequently it receives a single `ConnectResponse` and starts sending messages. The `cross_join` is thus effectively a buffer for messages, and a "gate" on that buffer that opens
-when the client receives its sole `ConnectResponse`.
+2. The second pipeline reads from `source_stdin` and sends messages to the server. It differs from our echo-server example in the use of the [`defer_signal`](../syntax/surface_ops_gen.md#defer_signal) operator, which buffers up messages until a `ConnectResponse` is received. The flow assigned to the `lines`
+variable takes chat messages from stdin and passes them to the `[input]` channel of the `defer_signal`.
+The `defer_signal` operator buffers these messages until it gets an input on its `[signal]` channel. Then all `[input]` data buffered from previous ticks is passed along to the output, along with any data that streams in during the current tick.
+In our chat example, we want messages to be sent to the server in *all subsequent ticks* after `ConnectResponse` is received! To enforce this, we need to send something on the `[signal]` channel of `defer_signal` every subsequent tick. We achieve this by interposing a `persist` between `inbound_chan[acks]` and `[signal]msg_send`. The [`persist`](../syntax/surface_ops_gen.md#persist) operator stores its input data in order across time, and replays its current contents
+each tick. In this case it is storing `ConnectResponse` messages, of which we expect only one. The
+`persist` op will replay this signal every tick after it is received, so the client will always send its messages to the server once connected.
3. The final pipeline simply pretty-prints the messages received from the server.
@@ -275,7 +277,7 @@ May 31, 5:12:40 alice: Is there anyone home?
Now start client "bob" in terminal 3, and notice how he instantly receives the backlog of Alice's messages from the server's `cross_join`.
(The messages may not be printed in the same order as they were timestamped! The `cross_join` operator is not guaranteed to preserve order, nor
-is the udp network. Fixing these issues requires extra client logic that we leave as an exercise to the reader.)
+is the udp network. Fixing these issues requires extra client logic (perhaps using the [`sort()`](../syntax/surface_ops_gen#sort) operator) that we leave as an exercise to the reader.)
```console
#shell-command-next-line
cargo run -- --name "bob" --role client --server-addr 127.0.0.1:12347
diff --git a/docs/docs/hydroflow/quickstart/setup.md b/docs/docs/hydroflow/quickstart/setup.md
index 08b76be74e0..f3a2c477688 100644
--- a/docs/docs/hydroflow/quickstart/setup.md
+++ b/docs/docs/hydroflow/quickstart/setup.md
@@ -47,9 +47,7 @@ cargo install cargo-generate
## VS Code Setup
We recommend using VS Code with the `rust-analyzer` extension (and NOT the
-`Rust` extension). To enable the pre-release version of `rust-analyzer`
-(required by some new nightly syntax we use, at least until 2022-03-14), click
-the "Switch to Pre-Release Version" button next to the uninstall button.
+`Rust` extension).
## Setting up a Hydroflow Project
The easiest way to get started with Hydroflow is to begin with a template project.
@@ -122,9 +120,10 @@ will provide inline type and error messages, code completion, etc.
To work with the repository, it's best to start with an "example", found in the
[`hydroflow/examples` folder](https://github.com/hydro-project/hydroflow/tree/main/hydroflow/examples).
-These examples are included via the [`hydroflow/Cargo.toml` file](https://github.com/hydro-project/hydroflow/blob/main/hydroflow/Cargo.toml),
-so make sure to add your example there if you create a new one. The simplest
-example is the [`echo server`](https://github.com/hydro-project/hydroflow/blob/main/hydroflow/examples/echoserver/main.rs).
+The simplest example is the
+['hello world'](https://github.com/hydro-project/hydroflow/blob/main/hydroflow/examples/hello_world/main.rs) example;
+the simplest example with networking is the
+[`echo server`](https://github.com/hydro-project/hydroflow/blob/main/hydroflow/examples/echoserver/main.rs).
The Hydroflow repository is set up as a [workspace](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html),
i.e. a repo containing a bunch of separate packages, `hydroflow` is just the
diff --git a/docs/docs/hydroflow/syntax/index.mdx b/docs/docs/hydroflow/syntax/index.mdx
index bbaf37cc0e8..458a2800ff3 100644
--- a/docs/docs/hydroflow/syntax/index.mdx
+++ b/docs/docs/hydroflow/syntax/index.mdx
@@ -4,7 +4,7 @@ import exampleCode from '!!raw-loader!../../../../hydroflow/examples/example_syn
# Hydroflow Surface Syntax
The natural way to write a Hydroflow program is using the _Surface Syntax_ documented here.
It is a chained `Iterator`-style syntax of operators built into Hydroflow that should be sufficient
-for most uses. If you want lower-level access you can work with the `Core API` documented in the [Architecture](../architecture/index) section.
+for most uses. If you want lower-level access you can work with the `Core API` documented in the [Architecture](../architecture/) section.
In this chapter we go over the syntax piece by piece: how to [embed surface syntax in Rust](./surface_embedding) and how to specify [_flows_](./surface_flows), which consist of [_data sources_](./surface_data) flowing through [_operators_](./surface_ops_gen).
diff --git a/docs/docs/hydroflow/syntax/surface_data.mdx b/docs/docs/hydroflow/syntax/surface_data.mdx
index 6e6d3a18e42..66a27b4c99d 100644
--- a/docs/docs/hydroflow/syntax/surface_data.mdx
+++ b/docs/docs/hydroflow/syntax/surface_data.mdx
@@ -6,20 +6,27 @@ import exampleCode from '!!raw-loader!../../../../hydroflow/examples/example_syn
# Data Sources and Sinks in Rust
Any useful flow requires us to define sources of data, either generated computationally or received from
-and outside environment via I/O.
+an outside environment via I/O.
-## `source_iter`
-A flow can receive data from a Rust collection object via the `source_iter` operator, which takes the
+## One-time Iterator Sources
+A flow can receive data from a Rust collection object via the [`source_iter()`](./surface_ops_gen.md#source_iter) operator, which takes the
iterable collection as an argument and passes the items down the flow.
For example, here we iterate through a vector of `usize` items and push them down the flow:
```rust,ignore
source_iter(vec![0, 1]) -> ...
```
-The Hello, World example above uses this construct.
+The Hello, World example above uses this construct.
-## `source_stream`
+The [`source_file()`](./surface_ops_gen.md#source_file) and [`source_json()`](./surface_ops_gen.md#source_json) operators are similar, but read from a specified file.
+
+All of these operators output the contents of their collection only once, during the first tick.
+To output every tick, consider feeding results into a [`persist()`](./surface_ops_gen.md#persist)
+operator.
+
+## Streaming Sources
More commonly, a flow should handle external data coming in asynchronously from a [_Tokio_ runtime](https://tokio.rs/tokio/tutorial).
-One way to do this is with _channels_ that allow Rust code to send data into the Hydroflow inputs.
+
+One way to do this is with _channels_ that allow Rust code to send data into Hydroflow via the [`source_stream()`](./surface_ops_gen.md#source_stream) operator.
The code below creates a channel for data of (Rust) type `(usize, usize)`:
```rust,ignore
let (input_send, input_recv) = hydroflow::util::unbounded_channel::<(usize, usize)>();
@@ -30,7 +37,7 @@ it explicitly as follows:
```rust,ignore
input_send.send((0, 1)).unwrap()
```
-And in our Hydroflow syntax we can receive the data from the channel using the `source_stream` syntax and
+And in our Hydroflow syntax we can receive the data from the channel using the [`source_stream()`](./surface_ops_gen.md#source_stream) operator and
pass it along a flow:
```rust,ignore
source_stream(input_recv) -> ...
@@ -41,4 +48,19 @@ in from outside the flow:
{exampleCode}
-TODO: add the remaining sources.
\ No newline at end of file
+Sometimes we want to trigger activity based on timing, not data. To achieve this, we can use the [`source_interval()`](./surface_ops_gen.md#source_interval) operator, which takes a `Duration` `d` as an argument, and outputs a Tokio time Instant after every `d` units of time pass.
+
+## Destinations
+As duals to our data source operators, we also have data destination operators. The dest operators you'll likely use
+most often are [`dest_sink()`](./surface_ops_gen.md#dest_sink) and [`dest_file()`](./surface_ops_gen.md#dest_file). They are fairly
+straightforward, so the best source for further information is the documentation you can find by following the links on the operator names above.
+
+## SerDe: Network Serialization and Deserialization
+One of the mechanical annoyances of networked systems is the need to convert data to wire format ("serialization") and convert it back from wire format to data ("deserialization"),
+also known as "SerDe".
+This can be done with `map` functions, but we provide a convenience source/sink pair that does serde and networking for you.
+The source side, [`source_serde()`](./surface_ops_gen.md#source_serde) generates tuples of the type `(T, SocketAddr)`,
+where the first field is a deserialized item of type `T`, and the second field is the address of the sender of the item.
+The dest side, [`source_serde()`](./surface_ops_gen.md#source_serde), takes in tuples of type `(T, SocketAddr)`,
+where the first field is an item of type `T` to be serialized, and the second field is a destination address.
+
diff --git a/docs/docs/hydroflow/syntax/surface_flows.md b/docs/docs/hydroflow/syntax/surface_flows.md
index 2f56d55a970..1d55b2c756d 100644
--- a/docs/docs/hydroflow/syntax/surface_flows.md
+++ b/docs/docs/hydroflow/syntax/surface_flows.md
@@ -23,15 +23,15 @@ data, making the program more understandable.
## Operators with Multiple Ports
Some operators have more than one input _port_ that can be referenced by `->`. For example [`union`](./surface_ops_gen.md#union)
-unions the contents of many flows, so it can have an abitrary number of input ports. Some operators have multiple outputs, notably [`tee`](./surface_ops_gen.md#tee),
-which has an arbitrary number of outputs.
+unions the contents of many flows, so it can have an abitrary number of input ports. Some operators have multiple outputs; [`tee`](./surface_ops_gen.md#tee) and [`demux`](./surface_ops_gen.md#demux)
+have an arbitrary number of outputs.
In the syntax, we optionally distinguish input ports via an _indexing prefix_ string
-in square brackets before the name (e.g. `[0]my_union` and `[1]my_union`). Binary operators ---
-those with two distinct input ports --- require indexing prefixes, and require them to be `0` and `1`.
-Operators with arbitrary numbers of inputs ([`union`](./surface_ops_gen.md#union)) and outputs
+in square brackets before the name (e.g. `[0]my_union` and `[1]my_union`). Most operators with a fixed number of input ports\ require specific indexing prefixes to
+distinguish the inputs. For example, the inputs to [`join`](./surface_ops_gen.md#join) must be `[0]` and `[1]`; the inputs to [`difference`](./surface_ops_gen.md#difference) must be `[pos]` and `[neg]`.
+Operators with an arbitrary number of inputs ([`union`](./surface_ops_gen.md#union)) and outputs
([`demux`](./surface_ops_gen.md#demux), [`tee`](./surface_ops_gen.md#tee))
-allow for arbitrary strings, which can make code and dataflow graphs more readable and understandable
+allow you to choose arbitrary strings, which help you make your code and dataflow graphs more readable and understandable
(e.g. `my_tee[print]` and `my_tee[continue]`).
Here is an example that tees one flow into two, handles each separately, and then unions them to print out the contents in both lowercase and uppercase:
diff --git a/docs/docs/hydroflow/todo.md b/docs/docs/hydroflow/todo.md
index ddac14b7fed..b10714f83fd 100644
--- a/docs/docs/hydroflow/todo.md
+++ b/docs/docs/hydroflow/todo.md
@@ -56,21 +56,23 @@ sidebar_position: 8
- cargo generate for templating
- Hydroflow program specs embedded in Rust
- Tokio Channels and how to use them in Hydroflow
- - Network sources and sinks (source_stream)
- - Built-in serde (source_stream_serde, dest_sink_serde)
+ - Network sources and sinks (`source_stream`)
+ - Built-in serde (`source_stream_serde`, `dest_sink_serde`)
- Hydroflow syntax: operators, ->, variables, indexing multi-input/output operators
- running Hydroflow via `run_available` and `run_async`
- Recursion via cyclic dataflow
- Fixpoints and Strata
- - Template structure: clap, message types
- - source_stdin
+ - Template structure: `clap`, message types
+ - `source_stdin`
- Messages and `demux`
- broadcast pattern
- - gated buffer pattern
- - bootstrapping pipelines
+ - the `persist` operator to store and replay dataflow
+ - the `defer_signal` operator to gate a dataflow
+ - bootstrapping pipelines: `initialize`
- Operators covered
- cross_join
+ - defer_signal
- demux
- dest_sink_serde
- difference
@@ -79,12 +81,15 @@ sidebar_position: 8
- flatten
- flat_map
- for_each
+ - initialize
- join
- map
+ - persist
- union
- source_iter
- source_stdin
- source_stream
- source_stream_serde
- tee
+ - union
- unique
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index 1a1e5be7845..2b37bfc6e5d 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -27,6 +27,10 @@ const config = {
onBrokenLinks: 'throw',
onBrokenMarkdownLinks: 'throw',
+ customFields: {
+ 'LOAD_PLAYGROUND': process.env.LOAD_PLAYGROUND || false,
+ },
+
markdown: {
mermaid: true
},
diff --git a/docs/src/pages/playground.js b/docs/src/pages/playground.js
index e519d3e24ac..684181f3b46 100644
--- a/docs/src/pages/playground.js
+++ b/docs/src/pages/playground.js
@@ -5,27 +5,37 @@ import Editor from "@monaco-editor/react";
import ExecutionEnvironment from '@docusaurus/ExecutionEnvironment';
+import siteConfig from '@generated/docusaurus.config';
+
import * as wasm from "website_playground/website_playground_bg.wasm";
-import { __wbg_set_wasm, init, compile_hydroflow, compile_datalog } from "website_playground/website_playground_bg.js";
+import * as playgroundJS from "website_playground/website_playground_bg.js";
+
+let compile_hydroflow = null;
+let compile_datalog = null;
-if (ExecutionEnvironment.canUseDOM) {
- __wbg_set_wasm(wasm);
-} else {
- const wasmUri = require("website_playground/website_playground_bg.wasm");
- const wasmBuffer = Buffer.from(wasmUri.split(",")[1], 'base64');
- const wasm = new WebAssembly.Module(wasmBuffer);
- const instance = new WebAssembly.Instance(wasm, {
- "./website_playground_bg.js": require("website_playground/website_playground_bg.js")
- });
- __wbg_set_wasm(instance.exports);
+if (siteConfig.customFields.LOAD_PLAYGROUND === '1') {
+ compile_hydroflow = playgroundJS.compile_hydroflow;
+ compile_datalog = playgroundJS.compile_datalog;
+
+ if (ExecutionEnvironment.canUseDOM) {
+ playgroundJS.__wbg_set_wasm(wasm);
+ } else {
+ const wasmUri = require("website_playground/website_playground_bg.wasm");
+ const wasmBuffer = Buffer.from(wasmUri.split(",")[1], 'base64');
+ const wasm = new WebAssembly.Module(wasmBuffer);
+ const instance = new WebAssembly.Instance(wasm, {
+ "./website_playground_bg.js": require("website_playground/website_playground_bg.js")
+ });
+ playgroundJS.__wbg_set_wasm(instance.exports);
+ }
+
+ playgroundJS.init();
}
import mermaid from "mermaid";
import styles from "./playground.module.css";
-init();
-
function MermaidGraph({ id, source }) {
const [svg, setSvg] = useState({ __html: 'Loading Mermaid graph...' });
useEffect(() => {
@@ -50,7 +60,7 @@ source_iter(0..10) -> for_each(|n| println!("Hello {}", n));`,
// https://hydro.run/docs/hydroflow/quickstart/example_2_simple
source_iter(0..10)
-> map(|n| n * n)
- -> filter(|&n| n > 10)
+ -> filter(|n| *n > 10)
-> map(|n| (n..=n+1))
-> flatten()
-> for_each(|n| println!("Howdy {}", n));`,
@@ -179,6 +189,10 @@ export function EditorDemo({ compileFn, examples, mermaidId }) {
const [showingMermaid, setShowingMermaid] = useState(true);
const [editorAndMonaco, setEditorAndMonaco] = useState(null);
+ if (siteConfig.customFields.LOAD_PLAYGROUND !== '1') {
+ return Please set LOAD_PLAYGROUND environment variable to 1 to enable the playground.
;
+ }
+
const { output, diagnostics } = (compileFn)(program);
const numberOfLines = program.split("\n").length;
diff --git a/docs/wasm-plugin.js b/docs/wasm-plugin.js
index a3dd8c8b945..16181e5850e 100644
--- a/docs/wasm-plugin.js
+++ b/docs/wasm-plugin.js
@@ -14,7 +14,15 @@ module.exports = function (context, options) {
type: "asset/inline",
},
] : []
- }
+ },
+ ...(process.env.LOAD_PLAYGROUND !== "1" ? {
+ resolve: {
+ alias: {
+ "website_playground/website_playground_bg.wasm": false,
+ "website_playground/website_playground_bg.js": false
+ }
+ }
+ } : {})
};
},
};
diff --git a/hydro_cli/CHANGELOG.md b/hydro_cli/CHANGELOG.md
index 387ff162005..750b836ec7f 100644
--- a/hydro_cli/CHANGELOG.md
+++ b/hydro_cli/CHANGELOG.md
@@ -1,7 +1,69 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## 0.4.0 (2023-08-15)
+
+### Chore
+
+ - fix lints for latest nightly
+
+### Commit Statistics
+
+
+
+ - 1 commit contributed to the release over the course of 27 calendar days.
+ - 42 days passed between releases.
+ - 1 commit was understood as [conventional](https://www.conventionalcommits.org).
+ - 1 unique issue was worked on: [#844](https://github.com/hydro-project/hydroflow/issues/844)
+
+### Commit Details
+
+
+
+view details
+
+ * **[#844](https://github.com/hydro-project/hydroflow/issues/844)**
+ - Fix lints for latest nightly ([`949db02`](https://github.com/hydro-project/hydroflow/commit/949db02e9fa9878e1a7176c180d6f44c5cddf052))
+view details
+
+ * **Uncategorized**
+ - Release hydroflow_cli_integration v0.3.0, hydroflow_lang v0.3.0, hydroflow_datalog_core v0.3.0, hydroflow_datalog v0.3.0, hydroflow_macro v0.3.0, lattices v0.3.0, pusherator v0.0.2, hydroflow v0.3.0, hydro_cli v0.3.0, safety bump 5 crates ([`ec9633e`](https://github.com/hydro-project/hydroflow/commit/ec9633e2e393c2bf106223abeb0b680200fbdf84))
+ - Mark hydro_cli as unchanged for 0.3 release ([`4c2cf81`](https://github.com/hydro-project/hydroflow/commit/4c2cf81411835529b5d7daa35717834e46e28b9b))
+