misc: fix typos

burr/integrations/ray.py

@@ -47,7 +47,7 @@ def submit(self, fn, *args, **kwargs):
     def shutdown(self, wait=True, **kwargs):
         """Shuts down the executor by shutting down ray
 
-        :param wait: Whether to wait -- required for hte API but not respected (yet)
+        :param wait: Whether to wait -- required for the API but not respected (yet)
         :param kwargs: Keyword arguments -- not used yet
         """
         if self.shutdown_on_end:

docs/concepts/additional-visibility.rst

@@ -106,7 +106,7 @@ This would create the following traces:
 #. ``call_llm`` as a causal dependent of ``create_prompt``
 
 Dependencies are used to express [dag](-style structures of spans within actions. This is useful for gaining visibility into the internal structure
-of an action, but is likely best used with integrations with micro-orchestration systems for implementating actions, such as Hamilton or Lanchain.
+of an action, but is likely best used with integrations with micro-orchestration systems for implementing actions, such as Hamilton or Lanchain.
 This maps to the `span link <https://opentelemetry.io/docs/concepts/signals/traces/#span-links>`_ concept in OpenTelemetry.
 
 Note that, on the surface, this doesn't actually *do* anything. It has to be paired with the appropriate hooks.
@@ -166,7 +166,7 @@ Tracing Functions
 
 You can observe non-burr functions, which will show up as part of your traces. To do this, you simply need to decorate the
 function with the :py:func:`@trace <burr.visibility.tracing.trace>` decorator. This will automatically create a span
-for the function (within the approprite context), and log as attributes the parameters + return value.
+for the function (within the appropriate context), and log as attributes the parameters + return value.
 
 For instance:
 
@@ -196,7 +196,7 @@ For instance:
         return state.update({'response': response})
 
 
-This will create spans for the ``_modify_prompt``, ``_fix``, and ``_query`` functions, and log the parameters and return values. You can opt out of logging paramers or return values and adding a filter to the decorator to exclude certain parameters.
+This will create spans for the ``_modify_prompt``, ``_fix``, and ``_query`` functions, and log the parameters and return values. You can opt out of logging parameters or return values and adding a filter to the decorator to exclude certain parameters.
 To contrast what you can instrument manually, the ``@trace`` decorator allows you to get more visibility and replace manual code such as the following (though you can happily combine the two approaches):
 
 .. code-block:: python
@@ -216,7 +216,7 @@ To contrast what you can instrument manually, the ``@trace`` decorator allows yo
 
 
 This will create spans for the ``_modify_prompt``, ``_fix``, and ``_query`` functions, and log the parameters and return values.
-You can opt out of logging paramers or return values and adding a filter to the decorator to exclude certain parameters.
+You can opt out of logging parameters or return values and adding a filter to the decorator to exclude certain parameters.
 
 .. _opentelref:
 

docs/concepts/parallelism.rst

@@ -511,7 +511,7 @@ Persistence/Tracking
 By default, the trackers/persisters will be passed from the parent application to the child application. The application IDs
 will be created as a a stable hash of the parent ID + the index of the child ID, requiring the order to be constant to ensure that the same application ID is used for the same task every time.
 
-Note that we will be adding hte ability to create a unique key, per application, but that is not implemented yet.
+Note that we will be adding the ability to create a unique key, per application, but that is not implemented yet.
 
 It will also utilize the same persister to load from the prior state, if that is used on the application level (see :ref:`state persistence <state-persistence>`).
 
@@ -526,7 +526,7 @@ The default behavior is to cascade all the following constructs through to the p
 2. State saving/persistence (given by the :py:meth:`burr.core.application.ApplicationBuilder.with_state_persister` function in :py:class:`burr.core.application.ApplicationBuilder`)
 3. State loading (given by the :py:meth:`burr.core.application.ApplicationBuilder.initialize_from` function in :py:class:`burr.core.application.ApplicationBuilder`)
 
-These will then be passed ot the corresponding sub-application tasks. If any of these objects implement a `.copy()` method, that will be called. Otherwise the same instance will be created. Not the tracker/persister/loader must be serializable
+These will then be passed to the corresponding sub-application tasks. If any of these objects implement a `.copy()` method, that will be called. Otherwise the same instance will be created. Not the tracker/persister/loader must be serializable
 to work in non-multithreaded executors, and thread-safe to work in multithreaded instances.
 
 In mst cases, (2) and (3) above will be the same, however there all valid use-cases where you might want to use different persisters/loaders for the sub-application.

docs/concepts/streaming-actions.rst

@@ -32,7 +32,7 @@ Actions can be implemented as streaming results. This enables a lower time-to-fi
 interface in the case of AI applications or streaming in of metrics in a model-training application. Broadly,
 this is a tool to enable quicker user interaction in longer running actions that require user focus.
 
-Like other actions, these can be implemented both as functions and as classes, and can use synchronous or asynchrounous APIs.
+Like other actions, these can be implemented both as functions and as classes, and can use synchronous or asynchronous APIs.
 
 They are used differently from regular actions -- the application wraps their result in a
 :py:class:`StreamingResultContainer <burr.core.action.StreamingResultContainer>`, or a

docs/concepts/sync-vs-async.rst

@@ -83,7 +83,7 @@ applications.
 
 In general, Burr gives you the constructs for synchronous and asynchronous execution. We usually do that by
 providing both methods (see specific references for more detail and reach out if you feel like we
-are missing a specific implementation). Furthermore, Burr suports the following APIs for both synchronous/asynchronous interfaces:
+are missing a specific implementation). Furthermore, Burr supports the following APIs for both synchronous/asynchronous interfaces:
 
 - :ref:`hooks <hooksref>`
 - :ref:`persisters <persistersref>`
@@ -93,7 +93,7 @@ Nuances of Sync + Async together
 
 We encourage to make a decision to either commit fully to sync or async. That said,
 there are cases where a hybrid situation may be desirable or unavoidable (testing, prototyping,
-legacy code, ...) and we give some options to handle that. The table bellow shows the
+legacy code, ...) and we give some options to handle that. The table below shows the
 possibilities Burr now supports -- combining the set of synchronous/asynchronous.
 
 

docs/examples/deployment/web-server.rst

@@ -40,4 +40,4 @@ To connect Burr to a database, you can use one of the provided persisters, or bu
 
 - :ref:`Documentation on persistence <state-persistence>`
 - :ref:`Set of available persisters <persistersref>`
-- `Simple chatbot intro with persistence to SQLLite <https://github.com/apache/burr/blob/main/examples/simple-chatbot-intro/notebook.ipynb>`_
+- `Simple chatbot intro with persistence to SQLite <https://github.com/apache/burr/blob/main/examples/simple-chatbot-intro/notebook.ipynb>`_