This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch gh-pages
in repository https://gitbox.apache.org/repos/asf/burr.git
The following commit(s) were added to refs/heads/gh-pages by this push:
new 72ada1bd deploy: 65943a4be3da752b482c7c80db066c808fe3358a
72ada1bd is described below
commit 72ada1bdb563a3cd4cebed0098e86f3f7a500b65
Author: skrawcz <[email protected]>
AuthorDate: Mon Sep 8 05:46:25 2025 +0000
deploy: 65943a4be3da752b482c7c80db066c808fe3358a
---
pull/577/.doctrees/concepts/parallelism.doctree | Bin 116823 -> 114115 bytes
pull/577/.doctrees/concepts/sync-vs-async.doctree | Bin 31667 -> 30713 bytes
pull/577/.doctrees/environment.pickle | Bin 432542 -> 432542 bytes
pull/577/_sources/concepts/parallelism.rst.txt | 18 ++++++++----------
pull/577/_sources/concepts/sync-vs-async.rst.txt | 2 +-
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/pull/577/.doctrees/concepts/parallelism.doctree
b/pull/577/.doctrees/concepts/parallelism.doctree
index f1392eb4..9dedb3bf 100644
Binary files a/pull/577/.doctrees/concepts/parallelism.doctree and
b/pull/577/.doctrees/concepts/parallelism.doctree differ
diff --git a/pull/577/.doctrees/concepts/sync-vs-async.doctree
b/pull/577/.doctrees/concepts/sync-vs-async.doctree
index 0fbeecb2..c292d822 100644
Binary files a/pull/577/.doctrees/concepts/sync-vs-async.doctree and
b/pull/577/.doctrees/concepts/sync-vs-async.doctree differ
diff --git a/pull/577/.doctrees/environment.pickle
b/pull/577/.doctrees/environment.pickle
index 9b4a1032..a2a7c3aa 100644
Binary files a/pull/577/.doctrees/environment.pickle and
b/pull/577/.doctrees/environment.pickle differ
diff --git a/pull/577/_sources/concepts/parallelism.rst.txt
b/pull/577/_sources/concepts/parallelism.rst.txt
index b878921f..1cb55272 100644
--- a/pull/577/_sources/concepts/parallelism.rst.txt
+++ b/pull/577/_sources/concepts/parallelism.rst.txt
@@ -1,8 +1,8 @@
.. _parallelism:
-===========
+=================
Parallelism
-===========
+=================
Burr can run multiple actions in parallel. Each parallel branch can contain
one or more actions, and different branches can have different actions. This is
useful when:
@@ -33,7 +33,6 @@ With the low-level API, you can manually determine how
parallel actions or subgr
Overview
========
-
Burr allows you to define parallel actions by expanding a single action into
multiple individual actions or subgraphs which
will execute them all and joining the results. This is a simple `map-reduce
<https://en.wikipedia.org/wiki/MapReduce>`_ pattern.
@@ -131,7 +130,6 @@ Then, to run the application:
Run different actions over the same state
-----------------------------------------
-
For case (2) (mapping actions over the same state) you implement the
``MapActions`` class, doing the following:
- We define a regular action ``query_llm()`` using the ``@action`` decorator.
This takes in a model parameter (which we're going to bind later)
@@ -602,7 +600,7 @@ The basics (code not present now):
Inter-action communication
---------------------------
+---------------------------
Say you have two LLMs answering the same question -- one that gives immediate
results back to the user
as they come in, and another that thinks for a while to give more
sophisticated results. The user then has the option to say they're happy
@@ -619,12 +617,12 @@ To do this, you would:
Async Parallelism
-================
+==================
Burr also supports asynchronous parallelism. When working in an async context,
you need to make a few adjustments to your parallel actions:
1. Make your methods async
---------------------------
+---------------------------
The `action`, `states`, `reduce`, and other methods should be defined as async:
@@ -657,7 +655,7 @@ The `action`, `states`, `reduce`, and other methods should
be defined as async:
return state.update(ensemble_responses=all_responses)
2. Implement the is_async method
--------------------------------
+--------------------------------
You must override the `is_async` method to return `True`:
@@ -672,7 +670,7 @@ You must override the `is_async` method to return `True`:
# ... other methods ...
3. Use async persisters with connection pools
---------------------------------------------
+----------------------------------------------
When using state persistence with async parallelism, make sure to use the
async version of persisters and initialize them with a connection pool:
@@ -731,4 +729,4 @@ Things that may change:
1. We will likely alter the executor API to be more flexible, although we will
probably allow for use of the current executor API
2. We will be adding guard-rails for generator-types (sync versus async)
3. The UI is a WIP -- we have more sophisticated capabilities but are still
polishing them
-4. Support for action-level executors
\ No newline at end of file
+4. Support for action-level executors
diff --git a/pull/577/_sources/concepts/sync-vs-async.rst.txt
b/pull/577/_sources/concepts/sync-vs-async.rst.txt
index 4058eb4f..c0e3ad24 100644
--- a/pull/577/_sources/concepts/sync-vs-async.rst.txt
+++ b/pull/577/_sources/concepts/sync-vs-async.rst.txt
@@ -22,7 +22,7 @@ Burr gives you the ability to write synchronous (standard
python) and asynchrono
* :py:meth:`.stream_result() <.Application.stream_result()>`
Checklist for Async Applications
--------------------------------
+-----------------------------------
When building asynchronous applications with Burr, ensure you:
