Upload 23 files

sources/00_the-interface-class.md

@@ -0,0 +1,110 @@
+
+# The `Interface` class
+
+As mentioned in the [Quickstart](/main/guides/quickstart), the `gr.Interface` class is a high-level abstraction in Gradio that allows you to quickly create a demo for any Python function simply by specifying the input types and the output types. Revisiting our first demo:
+
+$code_hello_world_4
+
+
+We see that the `Interface` class is initialized with three required parameters:
+
+- `fn`: the function to wrap a user interface (UI) around
+- `inputs`: which Gradio component(s) to use for the input. The number of components should match the number of arguments in your function.
+- `outputs`: which Gradio component(s) to use for the output. The number of components should match the number of return values from your function.
+
+In this Guide, we'll dive into `gr.Interface` and the various ways it can be customized, but before we do that, let's get a better understanding of Gradio components.
+
+## Gradio Components
+
+Gradio includes more than 30 pre-built components (as well as many [community-built _custom components_](https://www.gradio.app/custom-components/gallery)) that can be used as inputs or outputs in your demo. These components correspond to common data types in machine learning and data science, e.g. the `gr.Image` component is designed to handle input or output images, the `gr.Label` component displays classification labels and probabilities, the `gr.Plot` component displays various kinds of plots, and so on. 
+
+**Static and Interactive Components**
+
+Every component has a _static_ version that is designed to *display* data, and most components also have an _interactive_ version designed to let users input or modify the data. Typically, you don't need to think about this distinction, because when you build a Gradio demo, Gradio automatically figures out whether the component should be static or interactive based on whether it is being used as an input or output. However, you can set this manually using the `interactive` argument that every component supports.
+
+**Preprocessing and Postprocessing**
+
+When a component is used as an input, Gradio automatically handles the _preprocessing_ needed to convert the data from a type sent by the user's browser (such as an uploaded image) to a form that can be accepted by your function (such as a `numpy` array).
+
+
+Similarly, when a component is used as an output, Gradio automatically handles the _postprocessing_ needed to convert the data from what is returned by your function (such as a list of image paths) to a form that can be displayed in the user's browser (a gallery of images).
+
+## Components Attributes
+
+We used the default versions of the `gr.Textbox` and `gr.Slider`, but what if you want to change how the UI components look or behave?
+
+Let's say you want to customize the slider to have values from 1 to 10, with a default of 2. And you wanted to customize the output text field — you want it to be larger and have a label.
+
+If you use the actual classes for `gr.Textbox` and `gr.Slider` instead of the string shortcuts, you have access to much more customizability through component attributes.
+
+$code_hello_world_2
+$demo_hello_world_2
+
+## Multiple Input and Output Components
+
+Suppose you had a more complex function, with multiple outputs as well. In the example below, we define a function that takes a string, boolean, and number, and returns a string and number. 
+
+$code_hello_world_3
+$demo_hello_world_3
+
+Just as each component in the `inputs` list corresponds to one of the parameters of the function, in order, each component in the `outputs` list corresponds to one of the values returned by the function, in order.
+
+## An Image Example
+
+Gradio supports many types of components, such as `Image`, `DataFrame`, `Video`, or `Label`. Let's try an image-to-image function to get a feel for these!
+
+$code_sepia_filter
+$demo_sepia_filter
+
+When using the `Image` component as input, your function will receive a NumPy array with the shape `(height, width, 3)`, where the last dimension represents the RGB values. We'll return an image as well in the form of a NumPy array. 
+
+As mentioned above, Gradio handles the preprocessing and postprocessing to convert images to NumPy arrays and vice versa. You can also control the preprocessing performed with the `type=` keyword argument. For example, if you wanted your function to take a file path to an image instead of a NumPy array, the input `Image` component could be written as:
+
+```python
+gr.Image(type="filepath", shape=...)
+```
+
+You can read more about the built-in Gradio components and how to customize them in the [Gradio docs](https://gradio.app/docs).
+
+## Example Inputs
+
+You can provide example data that a user can easily load into `Interface`. This can be helpful to demonstrate the types of inputs the model expects, as well as to provide a way to explore your dataset in conjunction with your model. To load example data, you can provide a **nested list** to the `examples=` keyword argument of the Interface constructor. Each sublist within the outer list represents a data sample, and each element within the sublist represents an input for each input component. The format of example data for each component is specified in the [Docs](https://gradio.app/docs#components).
+
+$code_calculator
+$demo_calculator
+
+You can load a large dataset into the examples to browse and interact with the dataset through Gradio. The examples will be automatically paginated (you can configure this through the `examples_per_page` argument of `Interface`).
+
+Continue learning about examples in the [More On Examples](https://gradio.app/guides/more-on-examples) guide.
+
+## Descriptive Content
+
+In the previous example, you may have noticed the `title=` and `description=` keyword arguments in the `Interface` constructor that helps users understand your app.
+
+There are three arguments in the `Interface` constructor to specify where this content should go:
+
+- `title`: which accepts text and can display it at the very top of interface, and also becomes the page title.
+- `description`: which accepts text, markdown or HTML and places it right under the title.
+- `article`: which also accepts text, markdown or HTML and places it below the interface.
+
+![annotated](https://github.com/gradio-app/gradio/blob/main/guides/assets/annotated.png?raw=true)
+
+Note: if you're using the `Blocks` class, you can insert text, markdown, or HTML anywhere in your application using the `gr.Markdown(...)` or `gr.HTML(...)` components.
+
+Another useful keyword argument is `label=`, which is present in every `Component`. This modifies the label text at the top of each `Component`. You can also add the `info=` keyword argument to form elements like `Textbox` or `Radio` to provide further information on their usage.
+
+```python
+gr.Number(label='Age', info='In years, must be greater than 0')
+```
+
+## Additional Inputs within an Accordion
+
+If your prediction function takes many inputs, you may want to hide some of them within a collapsed accordion to avoid cluttering the UI. The `Interface` class takes an `additional_inputs` argument which is similar to `inputs` but any input components included here are not visible by default. The user must click on the accordion to show these components. The additional inputs are passed into the prediction function, in order, after the standard inputs.
+
+You can customize the appearance of the accordion by using the optional `additional_inputs_accordion` argument, which accepts a string (in which case, it becomes the label of the accordion), or an instance of the `gr.Accordion()` class (e.g. this lets you control whether the accordion is open or closed by default).
+
+Here's an example:
+
+$code_interface_with_additional_inputs
+$demo_interface_with_additional_inputs
+

sources/01_blocks-and-event-listeners.md

@@ -0,0 +1,244 @@
+
+# Blocks and Event Listeners
+
+We briefly descirbed the Blocks class in the [Quickstart](/main/guides/quickstart#custom-demos-with-gr-blocks) as a way to build custom demos. Let's dive deeper. 
+
+
+## Blocks Structure
+
+Take a look at the demo below.
+
+$code_hello_blocks
+$demo_hello_blocks
+
+- First, note the `with gr.Blocks() as demo:` clause. The Blocks app code will be contained within this clause.
+- Next come the Components. These are the same Components used in `Interface`. However, instead of being passed to some constructor, Components are automatically added to the Blocks as they are created within the `with` clause.
+- Finally, the `click()` event listener. Event listeners define the data flow within the app. In the example above, the listener ties the two Textboxes together. The Textbox `name` acts as the input and Textbox `output` acts as the output to the `greet` method. This dataflow is triggered when the Button `greet_btn` is clicked. Like an Interface, an event listener can take multiple inputs or outputs.
+
+You can also attach event listeners using decorators - skip the `fn` argument and assign `inputs` and `outputs` directly:
+
+$code_hello_blocks_decorator
+
+## Event Listeners and Interactivity
+
+In the example above, you'll notice that you are able to edit Textbox `name`, but not Textbox `output`. This is because any Component that acts as an input to an event listener is made interactive. However, since Textbox `output` acts only as an output, Gradio determines that it should not be made interactive. You can override the default behavior and directly configure the interactivity of a Component with the boolean `interactive` keyword argument.
+
+```python
+output = gr.Textbox(label="Output", interactive=True)
+```
+
+_Note_: What happens if a Gradio component is neither an input nor an output? If a component is constructed with a default value, then it is presumed to be displaying content and is rendered non-interactive. Otherwise, it is rendered interactive. Again, this behavior can be overridden by specifying a value for the `interactive` argument.
+
+## Types of Event Listeners
+
+Take a look at the demo below:
+
+$code_blocks_hello
+$demo_blocks_hello
+
+Instead of being triggered by a click, the `welcome` function is triggered by typing in the Textbox `inp`. This is due to the `change()` event listener. Different Components support different event listeners. For example, the `Video` Component supports a `play()` event listener, triggered when a user presses play. See the [Docs](http://gradio.app/docs#components) for the event listeners for each Component.
+
+## Multiple Data Flows
+
+A Blocks app is not limited to a single data flow the way Interfaces are. Take a look at the demo below:
+
+$code_reversible_flow
+$demo_reversible_flow
+
+Note that `num1` can act as input to `num2`, and also vice-versa! As your apps get more complex, you will have many data flows connecting various Components.
+
+Here's an example of a "multi-step" demo, where the output of one model (a speech-to-text model) gets fed into the next model (a sentiment classifier).
+
+$code_blocks_speech_text_sentiment
+$demo_blocks_speech_text_sentiment
+
+## Function Input List vs Dict
+
+The event listeners you've seen so far have a single input component. If you'd like to have multiple input components pass data to the function, you have two options on how the function can accept input component values:
+
+1. as a list of arguments, or
+2. as a single dictionary of values, keyed by the component
+
+Let's see an example of each:
+$code_calculator_list_and_dict
+
+Both `add()` and `sub()` take `a` and `b` as inputs. However, the syntax is different between these listeners.
+
+1. To the `add_btn` listener, we pass the inputs as a list. The function `add()` takes each of these inputs as arguments. The value of `a` maps to the argument `num1`, and the value of `b` maps to the argument `num2`.
+2. To the `sub_btn` listener, we pass the inputs as a set (note the curly brackets!). The function `sub()` takes a single dictionary argument `data`, where the keys are the input components, and the values are the values of those components.
+
+It is a matter of preference which syntax you prefer! For functions with many input components, option 2 may be easier to manage.
+
+$demo_calculator_list_and_dict
+
+## Function Return List vs Dict
+
+Similarly, you may return values for multiple output components either as:
+
+1. a list of values, or
+2. a dictionary keyed by the component
+
+Let's first see an example of (1), where we set the values of two output components by returning two values:
+
+```python
+with gr.Blocks() as demo:
+    food_box = gr.Number(value=10, label="Food Count")
+    status_box = gr.Textbox()
+    def eat(food):
+        if food > 0:
+            return food - 1, "full"
+        else:
+            return 0, "hungry"
+    gr.Button("EAT").click(
+        fn=eat,
+        inputs=food_box,
+        outputs=[food_box, status_box]
+    )
+```
+
+Above, each return statement returns two values corresponding to `food_box` and `status_box`, respectively.
+
+Instead of returning a list of values corresponding to each output component in order, you can also return a dictionary, with the key corresponding to the output component and the value as the new value. This also allows you to skip updating some output components.
+
+```python
+with gr.Blocks() as demo:
+    food_box = gr.Number(value=10, label="Food Count")
+    status_box = gr.Textbox()
+    def eat(food):
+        if food > 0:
+            return {food_box: food - 1, status_box: "full"}
+        else:
+            return {status_box: "hungry"}
+    gr.Button("EAT").click(
+        fn=eat,
+        inputs=food_box,
+        outputs=[food_box, status_box]
+    )
+```
+
+Notice how when there is no food, we only update the `status_box` element. We skipped updating the `food_box` component.
+
+Dictionary returns are helpful when an event listener affects many components on return, or conditionally affects outputs and not others.
+
+Keep in mind that with dictionary returns, we still need to specify the possible outputs in the event listener.
+
+## Updating Component Configurations
+
+The return value of an event listener function is usually the updated value of the corresponding output Component. Sometimes we want to update the configuration of the Component as well, such as the visibility. In this case, we return a new Component, setting the properties we want to change.
+
+$code_blocks_essay_simple
+$demo_blocks_essay_simple
+
+See how we can configure the Textbox itself through a new `gr.Textbox()` method. The `value=` argument can still be used to update the value along with Component configuration. Any arguments we do not set will use their previous values.
+
+## Examples
+
+Just like with `gr.Interface`, you can also add examples for your functions when you are working with `gr.Blocks`. In this case, instantiate a `gr.Examples` similar to how you would instantiate any other component. The constructor of `gr.Examples` takes two required arguments:
+
+* `examples`: a nested list of examples, in which the outer list consists of examples and each inner list consists of an input corresponding to each input component
+* `inputs`: the component or list of components that should be populated when the examples are clicked
+
+You can also set `cache_examples=True` similar to `gr.Interface`, in which case two additional arguments must be provided:
+
+* `outputs`: the component or list of components corresponding to the output of the examples
+* `fn`: the function to run to generate the outputs corresponding to the examples
+
+Here's an example showing how to use `gr.Examples` in a `gr.Blocks` app:
+
+$code_calculator_blocks
+
+**Note**: In Gradio 4.0 or later, when you click on examples, not only does the value of the input component update to the example value, but the component's configuration also reverts to the properties with which you constructed the component. This ensures that the examples are compatible with the component even if its configuration has been changed. 
+
+
+
+## Running Events Consecutively
+
+You can also run events consecutively by using the `then` method of an event listener. This will run an event after the previous event has finished running. This is useful for running events that update components in multiple steps.
+
+For example, in the chatbot example below, we first update the chatbot with the user message immediately, and then update the chatbot with the computer response after a simulated delay.
+
+$code_chatbot_consecutive
+$demo_chatbot_consecutive
+
+The `.then()` method of an event listener executes the subsequent event regardless of whether the previous event raised any errors. If you'd like to only run subsequent events if the previous event executed successfully, use the `.success()` method, which takes the same arguments as `.then()`.
+
+## Running Events Continuously
+
+You can run events on a fixed schedule using `gr.Timer()` object. This will run the event when the timer's `tick` event fires. See the code below:
+
+```python
+with gr.Blocks as demo:
+    timer = gr.Timer(5)
+    textbox = gr.Textbox()
+    textbox2 = gr.Textbox()
+    timer.tick(set_textbox_fn, textbox, textbox2)
+```
+
+This can also be used directly with a Component's `every=` parameter as such:
+
+```python
+with gr.Blocks as demo:
+    timer = gr.Timer(5)
+    textbox = gr.Textbox()
+    textbox2 = gr.Textbox(set_textbox_fn, inputs=[textbox], every=timer)
+```
+
+Here is an example of a demo that print the current timestamp, and also prints random numbers regularly!
+
+$code_timer
+$demo_timer
+
+## Gathering Event Data
+
+You can gather specific data about an event by adding the associated event data class as a type hint to an argument in the event listener function.
+
+For example, event data for `.select()` can be type hinted by a `gradio.SelectData` argument. This event is triggered when a user selects some part of the triggering component, and the event data includes information about what the user specifically selected. If a user selected a specific word in a `Textbox`, a specific image in a `Gallery`, or a specific cell in a `DataFrame`, the event data argument would contain information about the specific selection.
+
+In the 2 player tic-tac-toe demo below, a user can select a cell in the `DataFrame` to make a move. The event data argument contains information about the specific cell that was selected. We can first check to see if the cell is empty, and then update the cell with the user's move.
+
+$code_tictactoe
+$demo_tictactoe
+
+## Binding Multiple Triggers to a Function
+
+Often times, you may want to bind multiple triggers to the same function. For example, you may want to allow a user to click a submit button, or press enter to submit a form. You can do this using the `gr.on` method and passing a list of triggers to the `trigger`.
+
+$code_on_listener_basic
+$demo_on_listener_basic
+
+You can use decorator syntax as well:
+
+$code_on_listener_decorator
+
+You can use `gr.on` to create "live" events by binding to the `change` event of components that implement it. If you do not specify any triggers, the function will automatically bind to all `change` event of all input components that include a `change` event (for example `gr.Textbox` has a `change` event whereas `gr.Button` does not).
+
+$code_on_listener_live
+$demo_on_listener_live
+
+You can follow `gr.on` with `.then`, just like any regular event listener. This handy method should save you from having to write a lot of repetitive code!
+
+## Binding a Component Value Directly to a Function of Other Components
+
+If you want to set a Component's value to always be a function of the value of other Components, you can use the following shorthand:
+
+```python
+with gr.Blocks() as demo:
+  num1 = gr.Number()
+  num2 = gr.Number()
+  product = gr.Number(lambda a, b: a * b, inputs=[num1, num2])
+```
+
+This functionally the same as:
+```python
+with gr.Blocks() as demo:
+  num1 = gr.Number()
+  num2 = gr.Number()
+  product = gr.Number()
+
+  gr.on(
+    [num1.change, num2.change, demo.load], 
+    lambda a, b: a * b, 
+    inputs=[num1, num2], 
+    outputs=product
+  )
+```

sources/01_more-on-examples.md

@@ -0,0 +1,44 @@
+
+# More on Examples
+
+In the [previous Guide](/main/guides/the-interface-class), we discussed how to provide example inputs for your demo to make it easier for users to try it out. Here, we dive into more details.
+
+## Providing Examples
+
+Adding examples to an Interface is as easy as providing a list of lists to the `examples`
+keyword argument.
+Each sublist is a data sample, where each element corresponds to an input of the prediction function.
+The inputs must be ordered in the same order as the prediction function expects them.
+
+If your interface only has one input component, then you can provide your examples as a regular list instead of a list of lists.
+
+### Loading Examples from a Directory
+
+You can also specify a path to a directory containing your examples. If your Interface takes only a single file-type input, e.g. an image classifier, you can simply pass a directory filepath to the `examples=` argument, and the `Interface` will load the images in the directory as examples.
+In the case of multiple inputs, this directory must
+contain a log.csv file with the example values.
+In the context of the calculator demo, we can set `examples='/demo/calculator/examples'` and in that directory we include the following `log.csv` file:
+
+```csv
+num,operation,num2
+5,"add",3
+4,"divide",2
+5,"multiply",3
+```
+
+This can be helpful when browsing flagged data. Simply point to the flagged directory and the `Interface` will load the examples from the flagged data.
+
+### Providing Partial Examples
+
+Sometimes your app has many input components, but you would only like to provide examples for a subset of them. In order to exclude some inputs from the examples, pass `None` for all data samples corresponding to those particular components.
+
+## Caching examples
+
+You may wish to provide some cached examples of your model for users to quickly try out, in case your model takes a while to run normally.
+If `cache_examples=True`, your Gradio app will run all of the examples and save the outputs when you call the `launch()` method. This data will be saved in a directory called `gradio_cached_examples` in your working directory by default. You can also set this directory with the `GRADIO_EXAMPLES_CACHE` environment variable, which can be either an absolute path or a relative path to your working directory.
+
+Whenever a user clicks on an example, the output will automatically be populated in the app now, using data from this cached directory instead of actually running the function. This is useful so users can quickly try out your model without adding any load!
+
+Alternatively, you can set `cache_examples="lazy"`. This means that each particular example will only get cached after it is first used (by any user) in the Gradio app. This is helpful if your prediction function is long-running and you do not want to wait a long time for your Gradio app to start.
+
+Keep in mind once the cache is generated, it will not be updated automatically in future launches. If the examples or function logic change, delete the cache folder to clear the cache and rebuild it with another `launch()`.

sources/01_queuing.md

@@ -0,0 +1,17 @@
+
+# Queuing
+
+Every Gradio app comes with a built-in queuing system that can scale to thousands of concurrent users. You can configure the queue by using `queue()` method which is supported by the `gr.Interface`, `gr.Blocks`, and `gr.ChatInterface` classes. 
+
+For example, you can control the number of requests processed at a single time by setting the `default_concurrency_limit` parameter of `queue()`, e.g.
+
+```python
+demo = gr.Interface(...).queue(default_concurrency_limit=5)
+demo.launch()
+```
+
+This limits the number of requests processed for this event listener at a single time to 5. By default, the `default_concurrency_limit` is actually set to `1`, which means that when many users are using your app, only a single user's request will be processed at a time. This is because many machine learning functions consume a significant amount of memory and so it is only suitable to have a single user using the demo at a time. However, you can change this parameter in your demo easily.
+
+See the [docs on queueing](/docs/gradio/interface#interface-queue) for more details on configuring the queuing parameters.
+
+You can see analytics on the number and status of all requests processed by the queue by visiting the `/monitoring` endpoint of your app. This endpoint will print a secret URL to your console that links to the full analytics dashboard.

sources/01_quickstart.md

@@ -0,0 +1,119 @@
+
+# Quickstart
+
+Gradio is an open-source Python package that allows you to quickly **build** a demo or web application for your machine learning model, API, or any arbitary Python function. You can then **share** a link to your demo or web application in just a few seconds using Gradio's built-in sharing features. *No JavaScript, CSS, or web hosting experience needed!*
+
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/gradio-guides/lcm-screenshot-3.gif" style="padding-bottom: 10px">
+
+It just takes a few lines of Python to create a demo like the one above, so let's get started 💫
+
+## Installation
+
+**Prerequisite**: Gradio requires [Python 3.8 or higher](https://www.python.org/downloads/)
+
+
+We recommend installing Gradio using `pip`, which is included by default in Python. Run this in your terminal or command prompt:
+
+```bash
+pip install gradio
+```
+
+
+Tip: it is best to install Gradio in a virtual environment. Detailed installation instructions for all common operating systems <a href="https://www.gradio.app/main/guides/installing-gradio-in-a-virtual-environment">are provided here</a>. 
+
+## Building Your First Demo
+
+You can run Gradio in your favorite code editor, Jupyter notebook, Google Colab, or anywhere else you write Python. Let's write your first Gradio app:
+
+
+$code_hello_world_4
+
+
+Tip: We shorten the imported name from <code>gradio</code> to <code>gr</code> for better readability of code. This is a widely adopted convention that you should follow so that anyone working with your code can easily understand it. 
+
+Now, run your code. If you've written the Python code in a file named, for example, `app.py`, then you would run `python app.py` from the terminal.
+
+The demo below will open in a browser on [http://localhost:7860](http://localhost:7860) if running from a file. If you are running within a notebook, the demo will appear embedded within the notebook.
+
+$demo_hello_world_4
+
+Type your name in the textbox on the left, drag the slider, and then press the Submit button. You should see a friendly greeting on the right.
+
+Tip: When developing locally, you can run your Gradio app in <strong>hot reload mode</strong>, which automatically reloads the Gradio app whenever you make changes to the file. To do this, simply type in <code>gradio</code> before the name of the file instead of <code>python</code>. In the example above, you would type: `gradio app.py` in your terminal. Learn more about hot reloading in the <a href="https://www.gradio.app/guides/developing-faster-with-reload-mode">Hot Reloading Guide</a>.
+
+
+**Understanding the `Interface` Class**
+
+You'll notice that in order to make your first demo, you created an instance of the `gr.Interface` class. The `Interface` class is designed to create demos for machine learning models which accept one or more inputs, and return one or more outputs. 
+
+The `Interface` class has three core arguments:
+
+- `fn`: the function to wrap a user interface (UI) around
+- `inputs`: the Gradio component(s) to use for the input. The number of components should match the number of arguments in your function.
+- `outputs`: the Gradio component(s) to use for the output. The number of components should match the number of return values from your function.
+
+The `fn` argument is very flexible -- you can pass *any* Python function that you want to wrap with a UI. In the example above, we saw a relatively simple function, but the function could be anything from a music generator to a tax calculator to the prediction function of a pretrained machine learning model.
+
+The `inputs` and `outputs` arguments take one or more Gradio components. As we'll see, Gradio includes more than [30 built-in components](https://www.gradio.app/docs/gradio/components) (such as the `gr.Textbox()`, `gr.Image()`, and `gr.HTML()` components) that are designed for machine learning applications. 
+
+Tip: For the `inputs` and `outputs` arguments, you can pass in the name of these components as a string (`"textbox"`) or an instance of the class (`gr.Textbox()`).
+
+If your function accepts more than one argument, as is the case above, pass a list of input components to `inputs`, with each input component corresponding to one of the arguments of the function, in order. The same holds true if your function returns more than one value: simply pass in a list of components to `outputs`. This flexibility makes the `Interface` class a very powerful way to create demos.
+
+We'll dive deeper into the `gr.Interface` on our series on [building Interfaces](https://www.gradio.app/main/guides/the-interface-class).
+
+## Sharing Your Demo
+
+What good is a beautiful demo if you can't share it? Gradio lets you easily share a machine learning demo without having to worry about the hassle of hosting on a web server. Simply set `share=True` in `launch()`, and a publicly accessible URL will be created for your demo. Let's revisit our example demo,  but change the last line as follows:
+
+```python
+import gradio as gr
+
+def greet(name):
+    return "Hello " + name + "!"
+
+demo = gr.Interface(fn=greet, inputs="textbox", outputs="textbox")
+    
+demo.launch(share=True)  # Share your demo with just 1 extra parameter 🚀
+```
+
+When you run this code, a public URL will be generated for your demo in a matter of seconds, something like:
+
+👉 &nbsp; `https://a23dsf231adb.gradio.live`
+
+Now, anyone around the world can try your Gradio demo from their browser, while the machine learning model and all computation continues to run locally on your computer.
+
+To learn more about sharing your demo, read our dedicated guide on [sharing your Gradio application](https://www.gradio.app/guides/sharing-your-app).
+
+
+## Core Gradio Classes
+
+So far, we've been discussing the `Interface` class, which is a high-level class that lets to build demos quickly with Gradio. But what else does Gradio include?aaa
+
+### Chatbots with `gr.ChatInterface`
+
+Gradio includes another high-level class, `gr.ChatInterface`, which is specifically designed to create Chatbot UIs. Similar to `Interface`, you supply a function and Gradio creates a fully working Chatbot UI. If you're interested in creating a chatbot, you can jump straight to [our dedicated guide on `gr.ChatInterface`](https://www.gradio.app/guides/creating-a-chatbot-fast).
+
+### Custom Demos with `gr.Blocks`
+
+Gradio also offers a low-level approach for designing web apps with more flexible layouts and data flows with the `gr.Blocks` class. Blocks allows you to do things like control where components appear on the page, handle complex data flows (e.g. outputs can serve as inputs to other functions), and update properties/visibility of components based on user interaction — still all in Python. 
+
+You can build very custom and complex applications using `gr.Blocks()`. For example, the popular image generation [Automatic1111 Web UI](https://github.com/AUTOMATIC1111/stable-diffusion-webui) is built using Gradio Blocks. We dive deeper into the `gr.Blocks` on our series on [building with Blocks](https://www.gradio.app/guides/blocks-and-event-listeners).
+
+
+### The Gradio Python & JavaScript Ecosystem
+
+That's the gist of the core `gradio` Python library, but Gradio is actually so much more! Its an entire ecosystem of Python and JavaScript libraries that let you build machine learning applications, or query them programmatically, in Python or JavaScript. Here are other related parts of the Gradio ecosystem:
+
+* [Gradio Python Client](https://www.gradio.app/guides/getting-started-with-the-python-client) (`gradio_client`): query any Gradio app programmatically in Python.
+* [Gradio JavaScript Client](https://www.gradio.app/guides/getting-started-with-the-js-client) (`@gradio/client`): query any Gradio app programmatically in JavaScript.
+* [Gradio-Lite](https://www.gradio.app/guides/gradio-lite) (`@gradio/lite`): write Gradio apps in Python that run entirely in the browser (no server needed!), thanks to Pyodide. 
+* [Hugging Face Spaces](https://huggingface.co/spaces): the most popular place to host Gradio applications — for free!
+
+## What's Next?
+
+Keep learning about Gradio sequentially using the Gradio Guides, which include explanations as well as example code and embedded interactive demos. Next up: [let's dive deeper into the Interface class](https://www.gradio.app/guides/the-interface-class).
+
+Or, if you already know the basics and are looking for something specific, you can search the more [technical API documentation](https://www.gradio.app/docs/).
+
+

sources/02_controlling-layout.md

@@ -0,0 +1,138 @@
+
+# Controlling Layout
+
+By default, Components in Blocks are arranged vertically. Let's take a look at how we can rearrange Components. Under the hood, this layout structure uses the [flexbox model of web development](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexbox).
+
+## Rows
+
+Elements within a `with gr.Row` clause will all be displayed horizontally. For example, to display two Buttons side by side:
+
+```python
+with gr.Blocks() as demo:
+    with gr.Row():
+        btn1 = gr.Button("Button 1")
+        btn2 = gr.Button("Button 2")
+```
+
+To make every element in a Row have the same height, use the `equal_height` argument of the `style` method.
+
+```python
+with gr.Blocks() as demo:
+    with gr.Row(equal_height=True):
+        textbox = gr.Textbox()
+        btn2 = gr.Button("Button 2")
+```
+
+The widths of elements in a Row can be controlled via a combination of `scale` and `min_width` arguments that are present in every Component.
+
+- `scale` is an integer that defines how an element will take up space in a Row. If scale is set to `0`, the element will not expand to take up space. If scale is set to `1` or greater, the element will expand. Multiple elements in a row will expand proportional to their scale. Below, `btn2` will expand twice as much as `btn1`, while `btn0` will not expand at all:
+
+```python
+with gr.Blocks() as demo:
+    with gr.Row():
+        btn0 = gr.Button("Button 0", scale=0)
+        btn1 = gr.Button("Button 1", scale=1)
+        btn2 = gr.Button("Button 2", scale=2)
+```
+
+- `min_width` will set the minimum width the element will take. The Row will wrap if there isn't sufficient space to satisfy all `min_width` values.
+
+Learn more about Rows in the [docs](https://gradio.app/docs/row).
+
+## Columns and Nesting
+
+Components within a Column will be placed vertically atop each other. Since the vertical layout is the default layout for Blocks apps anyway, to be useful, Columns are usually nested within Rows. For example:
+
+$code_rows_and_columns
+$demo_rows_and_columns
+
+See how the first column has two Textboxes arranged vertically. The second column has an Image and Button arranged vertically. Notice how the relative widths of the two columns is set by the `scale` parameter. The column with twice the `scale` value takes up twice the width.
+
+Learn more about Columns in the [docs](https://gradio.app/docs/column).
+
+# Dimensions
+
+You can control the height and width of various components, where the parameters are available. These parameters accept either a number (interpreted as pixels) or a string. Using a string allows the direct application of any CSS unit to the encapsulating Block element, catering to more specific design requirements. When omitted, Gradio uses default dimensions suited for most use cases.
+
+Below is an example illustrating the use of viewport width (vw):
+
+```python
+import gradio as gr
+
+with gr.Blocks() as demo:
+    im = gr.ImageEditor(
+        width="50vw",
+    )
+
+demo.launch()
+```
+
+When using percentage values for dimensions, you may want to define a parent component with an absolute unit (e.g. `px` or `vw`). This approach ensures that child components with relative dimensions are sized appropriately:
+
+
+```python
+import gradio as gr
+
+css = """
+.container {
+    height: 100vh;
+}
+"""
+
+with gr.Blocks(css=css) as demo:
+    with gr.Column(elem_classes=["container"]):
+        name = gr.Chatbot(value=[["1", "2"]], height="70%")
+
+demo.launch()
+```
+
+In this example, the Column layout component is given a height of 100% of the viewport height (100vh), and the Chatbot component inside it takes up 70% of the Column's height.
+
+You can apply any valid CSS unit for these parameters. For a comprehensive list of CSS units, refer to [this guide](https://www.w3schools.com/cssref/css_units.php). We recommend you always consider responsiveness and test your interfaces on various screen sizes to ensure a consistent user experience.
+
+
+
+## Tabs and Accordions
+
+You can also create Tabs using the `with gr.Tab('tab_name'):` clause. Any component created inside of a `with gr.Tab('tab_name'):` context appears in that tab. Consecutive Tab clauses are grouped together so that a single tab can be selected at one time, and only the components within that Tab's context are shown.
+
+For example:
+
+$code_blocks_flipper
+$demo_blocks_flipper
+
+Also note the `gr.Accordion('label')` in this example. The Accordion is a layout that can be toggled open or closed. Like `Tabs`, it is a layout element that can selectively hide or show content. Any components that are defined inside of a `with gr.Accordion('label'):` will be hidden or shown when the accordion's toggle icon is clicked.
+
+Learn more about [Tabs](https://gradio.app/docs/tab) and [Accordions](https://gradio.app/docs/accordion) in the docs.
+
+## Visibility
+
+Both Components and Layout elements have a `visible` argument that can set initially and also updated. Setting `gr.Column(visible=...)` on a Column can be used to show or hide a set of Components.
+
+$code_blocks_form
+$demo_blocks_form
+
+## Variable Number of Outputs
+
+By adjusting the visibility of components in a dynamic way, it is possible to create
+demos with Gradio that support a _variable numbers of outputs_. Here's a very simple example
+where the number of output textboxes is controlled by an input slider:
+
+$code_variable_outputs
+$demo_variable_outputs
+
+## Defining and Rendering Components Separately
+
+In some cases, you might want to define components before you actually render them in your UI. For instance, you might want to show an examples section using `gr.Examples` above the corresponding `gr.Textbox` input. Since `gr.Examples` requires as a parameter the input component object, you will need to first define the input component, but then render it later, after you have defined the `gr.Examples` object.
+
+The solution to this is to define the `gr.Textbox` outside of the `gr.Blocks()` scope and use the component's `.render()` method wherever you'd like it placed in the UI.
+
+Here's a full code example:
+
+```python
+input_textbox = gr.Textbox()
+
+with gr.Blocks() as demo:
+    gr.Examples(["hello", "bonjour", "merhaba"], input_textbox)
+    input_textbox.render()
+```

sources/02_flagging.md

@@ -0,0 +1,46 @@
+
+# Flagging
+
+You may have noticed the "Flag" button that appears by default in your `Interface`. When a user using your demo sees input with interesting output, such as erroneous or unexpected model behaviour, they can flag the input for you to review. Within the directory provided by the `flagging_dir=` argument to the `Interface` constructor, a CSV file will log the flagged inputs. If the interface involves file data, such as for Image and Audio components, folders will be created to store those flagged data as well.
+
+For example, with the calculator interface shown above, we would have the flagged data stored in the flagged directory shown below:
+
+```directory
++-- calculator.py
++-- flagged/
+|   +-- logs.csv
+```
+
+_flagged/logs.csv_
+
+```csv
+num1,operation,num2,Output
+5,add,7,12
+6,subtract,1.5,4.5
+```
+
+With the sepia interface shown earlier, we would have the flagged data stored in the flagged directory shown below:
+
+```directory
++-- sepia.py
++-- flagged/
+|   +-- logs.csv
+|   +-- im/
+|   |   +-- 0.png
+|   |   +-- 1.png
+|   +-- Output/
+|   |   +-- 0.png
+|   |   +-- 1.png
+```
+
+_flagged/logs.csv_
+
+```csv
+im,Output
+im/0.png,Output/0.png
+im/1.png,Output/1.png
+```
+
+If you wish for the user to provide a reason for flagging, you can pass a list of strings to the `flagging_options` argument of Interface. Users will have to select one of the strings when flagging, which will be saved as an additional column to the CSV.
+
+

sources/02_key-features.md

@@ -0,0 +1,194 @@
+
+# Key Features
+
+Let's go through some of the key features of Gradio. This guide is intended to be a high-level overview of various things that you should be aware of as you build your demo. Where appropriate, we link to more detailed guides on specific topics.
+
+1. [Components](#components)
+2. [Queuing](#queuing)
+3. [Streaming outputs](#streaming-outputs)
+4. [Streaming inputs](#streaming-inputs)
+5. [Alert modals](#alert-modals)
+6. [Styling](#styling)
+7. [Progress bars](#progress-bars)
+8. [Batch functions](#batch-functions)
+
+## Components
+
+Gradio includes more than 30 pre-built components (as well as many user-built _custom components_) that can be used as inputs or outputs in your demo with a single line of code. These components correspond to common data types in machine learning and data science, e.g. the `gr.Image` component is designed to handle input or output images, the `gr.Label` component displays classification labels and probabilities, the `gr.Plot` component displays various kinds of plots, and so on.
+
+Each component includes various constructor attributes that control the properties of the component. For example, you can control the number of lines in a `gr.Textbox` using the `lines` argument (which takes a positive integer) in its constructor. Or you can control the way that a user can provide an image in the `gr.Image` component using the `sources` parameter (which takes a list like `["webcam", "upload"]`).
+
+**Static and Interactive Components**
+
+Every component has a _static_ version that is designed to *display* data, and most components also have an _interactive_ version designed to let users input or modify the data. Typically, you don't need to think about this distinction, because when you build a Gradio demo, Gradio automatically figures out whether the component should be static or interactive based on whether it is being used as an input or output. However, you can set this manually using the `interactive` argument that every component supports.
+
+**Preprocessing and Postprocessing**
+
+When a component is used as an input, Gradio automatically handles the _preprocessing_ needed to convert the data from a type sent by the user's browser (such as an uploaded image) to a form that can be accepted by your function (such as a `numpy` array).
+
+
+Similarly, when a component is used as an output, Gradio automatically handles the _postprocessing_ needed to convert the data from what is returned by your function (such as a list of image paths) to a form that can be displayed in the user's browser (a gallery of images).
+
+Consider an example demo with three input components (`gr.Textbox`, `gr.Number`, and `gr.Image`) and two outputs (`gr.Number` and `gr.Gallery`) that serve as a UI for your image-to-image generation model. Below is a diagram of what our preprocessing will send to the model and what our postprocessing will require from it.
+
+![](https://github.com/gradio-app/gradio/blob/main/guides/assets/dataflow.svg?raw=true)
+
+In this image, the following preprocessing steps happen to send the data from the browser to your function:
+
+* The text in the textbox is converted to a Python `str` (essentially no preprocessing)
+* The number in the number input is converted to a Python `int` (essentially no preprocessing)
+* Most importantly, ihe image supplied by the user is converted to a `numpy.array` representation of the RGB values in the image
+
+Images are converted to NumPy arrays because they are a common format for machine learning workflows. You can control the _preprocessing_ using the component's parameters when constructing the component. For example, if you instantiate the `Image` component with the following parameters, it will preprocess the image to the `PIL` format instead:
+
+```py
+img = gr.Image(type="pil")
+```
+
+Postprocessing is even simpler! Gradio automatically recognizes the format of the returned data (e.g. does the user's function return a `numpy` array or a `str` filepath for the `gr.Image` component?) and postprocesses it appropriately into a format that can be displayed by the browser.
+
+So in the image above, the following postprocessing steps happen to send the data returned from a user's function to the browser:
+
+* The `float` is displayed as a number and displayed directly to the user
+* The list of string filepaths (`list[str]`) is interpreted as a list of image filepaths and displayed as a gallery in the browser
+
+Take a look at the [Docs](https://gradio.app/docs) to see all the parameters for each Gradio component.
+
+## Queuing
+
+Every Gradio app comes with a built-in queuing system that can scale to thousands of concurrent users. You can configure the queue by using `queue()` method which is supported by the `gr.Interface`, `gr.Blocks`, and `gr.ChatInterface` classes. 
+
+For example, you can control the number of requests processed at a single time by setting the `default_concurrency_limit` parameter of `queue()`, e.g.
+
+```python
+demo = gr.Interface(...).queue(default_concurrency_limit=5)
+demo.launch()
+```
+
+This limits the number of requests processed for this event listener at a single time to 5. By default, the `default_concurrency_limit` is actually set to `1`, which means that when many users are using your app, only a single user's request will be processed at a time. This is because many machine learning functions consume a significant amount of memory and so it is only suitable to have a single user using the demo at a time. However, you can change this parameter in your demo easily.
+
+See the [docs on queueing](https://gradio.app/docs/gradio/interface#interface-queue) for more details on configuring the queuing parameters.
+
+## Streaming outputs
+
+In some cases, you may want to stream a sequence of outputs rather than show a single output at once. For example, you might have an image generation model and you want to show the image that is generated at each step, leading up to the final image. Or you might have a chatbot which streams its response one token at a time instead of returning it all at once.
+
+In such cases, you can supply a **generator** function into Gradio instead of a regular function. Creating generators in Python is very simple: instead of a single `return` value, a function should `yield` a series of values instead. Usually the `yield` statement is put in some kind of loop. Here's an example of an generator that simply counts up to a given number:
+
+```python
+def my_generator(x):
+    for i in range(x):
+        yield i
+```
+
+You supply a generator into Gradio the same way as you would a regular function. For example, here's a a (fake) image generation model that generates noise for several steps before outputting an image using the `gr.Interface` class:
+
+$code_fake_diffusion
+$demo_fake_diffusion
+
+Note that we've added a `time.sleep(1)` in the iterator to create an artificial pause between steps so that you are able to observe the steps of the iterator (in a real image generation model, this probably wouldn't be necessary).
+
+## Streaming inputs
+
+Similarly, Gradio can handle streaming inputs, e.g. a live audio stream that can gets transcribed to text in real time, or an image generation model that reruns every time a user types a letter in a textbox. This is covered in more details in our guide on building [reactive Interfaces](/guides/reactive-interfaces). 
+
+## Alert modals
+
+You may wish to raise alerts to the user. To do so, raise a `gr.Error("custom message")` to display an error message. You can also issue `gr.Warning("message")` and `gr.Info("message")` by having them as standalone lines in your function, which will immediately display modals while continuing the execution of your function. Queueing needs to be enabled for this to work.
+
+Note below how the `gr.Error` has to be raised, while the `gr.Warning` and `gr.Info` are single lines.
+
+```python
+def start_process(name):
+    gr.Info("Starting process")
+    if name is None:
+        gr.Warning("Name is empty")
+    ...
+    if success == False:
+        raise gr.Error("Process failed")
+```
+
+
+
+## Styling
+
+Gradio themes are the easiest way to customize the look and feel of your app. You can choose from a variety of themes, or create your own. To do so, pass the `theme=` kwarg to the `Interface` constructor. For example:
+
+```python
+demo = gr.Interface(..., theme=gr.themes.Monochrome())
+```
+
+Gradio comes with a set of prebuilt themes which you can load from `gr.themes.*`. You can extend these themes or create your own themes from scratch - see the [theming guide](https://gradio.app/guides/theming-guide) for more details.
+
+For additional styling ability, you can pass any CSS (as well as custom JavaScript) to your Gradio application. This is discussed in more detail in our [custom JS and CSS guide](/guides/custom-CSS-and-JS).
+
+
+## Progress bars
+
+Gradio supports the ability to create custom Progress Bars so that you have customizability and control over the progress update that you show to the user. In order to enable this, simply add an argument to your method that has a default value of a `gr.Progress` instance. Then you can update the progress levels by calling this instance directly with a float between 0 and 1, or using the `tqdm()` method of the `Progress` instance to track progress over an iterable, as shown below.
+
+$code_progress_simple
+$demo_progress_simple
+
+If you use the `tqdm` library, you can even report progress updates automatically from any `tqdm.tqdm` that already exists within your function by setting the default argument as `gr.Progress(track_tqdm=True)`!
+
+## Batch functions
+
+Gradio supports the ability to pass _batch_ functions. Batch functions are just
+functions which take in a list of inputs and return a list of predictions.
+
+For example, here is a batched function that takes in two lists of inputs (a list of
+words and a list of ints), and returns a list of trimmed words as output:
+
+```py
+import time
+
+def trim_words(words, lens):
+    trimmed_words = []
+    time.sleep(5)
+    for w, l in zip(words, lens):
+        trimmed_words.append(w[:int(l)])
+    return [trimmed_words]
+```
+
+The advantage of using batched functions is that if you enable queuing, the Gradio server can automatically _batch_ incoming requests and process them in parallel,
+potentially speeding up your demo. Here's what the Gradio code looks like (notice the `batch=True` and `max_batch_size=16`)
+
+With the `gr.Interface` class:
+
+```python
+demo = gr.Interface(
+    fn=trim_words, 
+    inputs=["textbox", "number"], 
+    outputs=["output"],
+    batch=True, 
+    max_batch_size=16
+)
+
+demo.launch()
+```
+
+With the `gr.Blocks` class:
+
+```py
+import gradio as gr
+
+with gr.Blocks() as demo:
+    with gr.Row():
+        word = gr.Textbox(label="word")
+        leng = gr.Number(label="leng")
+        output = gr.Textbox(label="Output")
+    with gr.Row():
+        run = gr.Button()
+
+    event = run.click(trim_words, [word, leng], output, batch=True, max_batch_size=16)
+
+demo.launch()
+```
+
+In the example above, 16 requests could be processed in parallel (for a total inference time of 5 seconds), instead of each request being processed separately (for a total
+inference time of 80 seconds). Many Hugging Face `transformers` and `diffusers` models work very naturally with Gradio's batch mode: here's [an example demo using diffusers to
+generate images in batches](https://github.com/gradio-app/gradio/blob/main/demo/diffusers_with_batching/run.py)
+
+
+

sources/02_streaming-outputs.md

@@ -0,0 +1,21 @@
+
+# Streaming outputs
+
+In some cases, you may want to stream a sequence of outputs rather than show a single output at once. For example, you might have an image generation model and you want to show the image that is generated at each step, leading up to the final image. Or you might have a chatbot which streams its response one token at a time instead of returning it all at once.
+
+In such cases, you can supply a **generator** function into Gradio instead of a regular function. Creating generators in Python is very simple: instead of a single `return` value, a function should `yield` a series of values instead. Usually the `yield` statement is put in some kind of loop. Here's an example of an generator that simply counts up to a given number:
+
+```python
+def my_generator(x):
+    for i in range(x):
+        yield i
+```
+
+You supply a generator into Gradio the same way as you would a regular function. For example, here's a a (fake) image generation model that generates noise for several steps before outputting an image using the `gr.Interface` class:
+
+$code_fake_diffusion
+$demo_fake_diffusion
+
+Note that we've added a `time.sleep(1)` in the iterator to create an artificial pause between steps so that you are able to observe the steps of the iterator (in a real image generation model, this probably wouldn't be necessary).
+
+Similarly, Gradio can handle streaming inputs, e.g. an image generation model that reruns every time a user types a letter in a textbox. This is covered in more details in our guide on building [reactive Interfaces](/guides/reactive-interfaces). 

sources/03_alerts.md

@@ -0,0 +1,19 @@
+
+# Alerts
+
+You may wish to display alerts to the user. To do so, raise a `gr.Error("custom message")` in your function to halt the execution of your function and display an error message to the user.
+
+Alternatively, can issue `gr.Warning("custom message")` or `gr.Info("custom message")` by having them as standalone lines in your function, which will immediately display modals while continuing the execution of your function. The only difference between `gr.Info()` and `gr.Warning()` is the color of the alert. 
+
+```python
+def start_process(name):
+    gr.Info("Starting process")
+    if name is None:
+        gr.Warning("Name is empty")
+    ...
+    if success == False:
+        raise gr.Error("Process failed")
+```
+
+Tip: Note that `gr.Error()` is an exception that has to be raised, while `gr.Warning()` and `gr.Info()` are functions that are called directly.
+

sources/03_interface-state.md

@@ -0,0 +1,33 @@
+
+# Interface State
+
+So far, we've assumed that your demos are *stateless*: that they do not persist information beyond a single function call. What if you want to modify the behavior of your demo based on previous interactions with the demo? There are two approaches in Gradio: *global state* and *session state*.
+
+## Global State
+
+If the state is something that should be accessible to all function calls and all users, you can create a variable outside the function call and access it inside the function. For example, you may load a large model outside the function and use it inside the function so that every function call does not need to reload the model.
+
+$code_score_tracker
+
+In the code above, the `scores` array is shared between all users. If multiple users are accessing this demo, their scores will all be added to the same list, and the returned top 3 scores will be collected from this shared reference.
+
+## Session State
+
+Another type of data persistence Gradio supports is session state, where data persists across multiple submits within a page session. However, data is _not_ shared between different users of your model. To store data in a session state, you need to do three things:
+
+1. Pass in an extra parameter into your function, which represents the state of the interface.
+2. At the end of the function, return the updated value of the state as an extra return value.
+3. Add the `'state'` input and `'state'` output components when creating your `Interface`
+
+Here's a simple app to illustrate session state - this app simply stores users previous submissions and displays them back to the user:
+
+
+$code_interface_state
+$demo_interface_state
+
+
+Notice how the state persists across submits within each page, but if you load this demo in another tab (or refresh the page), the demos will not share chat history. Here, we could not store the submission history in a global variable, otherwise the submission history would then get jumbled between different users.
+
+The initial value of the `State` is `None` by default. If you pass a parameter to the `value` argument of `gr.State()`, it is used as the default value of the state instead. 
+
+Note: the `Interface` class only supports a single session state variable (though it can be a list with multiple elements). For more complex use cases, you can use Blocks, [which supports multiple `State` variables](/guides/state-in-blocks/). Alternatively, if you are building a chatbot that maintains user state, consider using the `ChatInterface` abstraction, [which manages state automatically](/guides/creating-a-chatbot-fast).

sources/03_state-in-blocks.md

@@ -0,0 +1,31 @@
+
+# State in Blocks
+
+We covered [State in Interfaces](https://gradio.app/interface-state), this guide takes a look at state in Blocks, which works mostly the same.
+
+## Global State
+
+Global state in Blocks works the same as in Interface. Any variable created outside a function call is a reference shared between all users.
+
+## Session State
+
+Gradio supports session **state**, where data persists across multiple submits within a page session, in Blocks apps as well. To reiterate, session data is _not_ shared between different users of your model. To store data in a session state, you need to do three things:
+
+1. Create a `gr.State()` object. If there is a default value to this stateful object, pass that into the constructor.
+2. In the event listener, put the `State` object as an input and output.
+3. In the event listener function, add the variable to the input parameters and the return value.
+
+Let's take a look at a game of hangman.
+
+$code_hangman
+$demo_hangman
+
+Let's see how we do each of the 3 steps listed above in this game:
+
+1. We store the used letters in `used_letters_var`. In the constructor of `State`, we set the initial value of this to `[]`, an empty list.
+2. In `btn.click()`, we have a reference to `used_letters_var` in both the inputs and outputs.
+3. In `guess_letter`, we pass the value of this `State` to `used_letters`, and then return an updated value of this `State` in the return statement.
+
+With more complex apps, you will likely have many State variables storing session state in a single Blocks app.
+
+Learn more about `State` in the [docs](https://gradio.app/docs/state).

sources/04_dynamic-apps-with-render-decorator.md

@@ -0,0 +1,67 @@
+
+# Dynamic Apps with the Render Decorator
+
+The components and event listeners you define in a Blocks so far have been fixed - once the demo was launched, new components and listeners could not be added, and existing one could not be removed. 
+
+The `@gr.render` decorator introduces the ability to dynamically change this. Let's take a look. 
+
+## Dynamic Number of Components
+
+In the example below, we will create a variable number of Textboxes. When the user edits the input Textbox, we create a Textbox for each letter in the input. Try it out below:
+
+$code_render_split_simple
+$demo_render_split_simple
+
+See how we can now create a variable number of Textboxes using our custom logic - in this case, a simple `for` loop. The `@gr.render` decorator enables this with the following steps:
+
+1. Create a function and attach the @gr.render decorator to it.
+2. Add the input components to the `inputs=` argument of @gr.render, and create a corresponding argument in your function for each component. This function will automatically re-run on any change to a component.
+3. Add all components inside the function that you want to render based on the inputs.
+
+Now whenever the inputs change, the function re-runs, and replaces the components created from the previous function run with the latest run. Pretty straightforward! Let's add a little more complexity to this app:
+
+$code_render_split
+$demo_render_split
+
+By default, `@gr.render` re-runs are triggered by the `.load` listener to the app and the `.change` listener to any input component provided. We can override this by explicitly setting the triggers in the decorator, as we have in this app to only trigger on `input_text.submit` instead. 
+If you are setting custom triggers, and you also want an automatic render at the start of the app, make sure to add `demo.load` to your list of triggers.
+
+## Dynamic Event Listeners
+
+If you're creating components, you probably want to attach event listeners to them as well. Let's take a look at an example that takes in a variable number of Textbox as input, and merges all the text into a single box.
+
+$code_render_merge_simple
+$demo_render_merge_simple
+
+Let's take a look at what's happening here:
+
+1. The state variable `text_count` is keeping track of the number of Textboxes to create. By clicking on the Add button, we increase `text_count` which triggers the render decorator.
+2. Note that in every single Textbox we create in the render function, we explicitly set a `key=` argument. This key allows us to preserve the value of this Component between re-renders. If you type in a value in a textbox, and then click the Add button, all the Textboxes re-render, but their values aren't cleared because the `key=` maintains the the value of a Component across a render.
+3. We've stored the Textboxes created in a list, and provide this list as input to the merge button event listener. Note that **all event listeners that use Components created inside a render function must also be defined inside that render function**. The event listener can still reference Components outside the render function, as we do here by referencing `merge_btn` and `output` which are both defined outside the render function.
+
+Just as with Components, whenever a function re-renders, the event listeners created from the previous render are cleared and the new event listeners from the latest run are attached. 
+
+This allows us to create highly customizable and complex interactions! 
+
+## Putting it Together
+
+Let's look at two examples that use all the features above. First, try out the to-do list app below: 
+
+$code_todo_list
+$demo_todo_list
+
+Note that almost the entire app is inside a single `gr.render` that reacts to the tasks `gr.State` variable. This variable is a nested list, which presents some complexity. If you design a `gr.render` to react to a list or dict structure, ensure you do the following:
+
+1. Any event listener that modifies a state variable in a manner that should trigger a re-render must set the state variable as an output. This lets Gradio know to check if the variable has changed behind the scenes. 
+2. In a `gr.render`, if a variable in a loop is used inside an event listener function, that variable should be "frozen" via setting it to itself as a default argument in the function header. See how we have `task=task` in both `mark_done` and `delete`. This freezes the variable to its "loop-time" value.
+
+Let's take a look at one last example that uses everything we learned. Below is an audio mixer. Provide multiple audio tracks and mix them together.
+
+$code_audio_mixer
+$demo_audio_mixer
+
+Two things to not in this app:
+1. Here we provide `key=` to all the components! We need to do this so that if we add another track after setting the values for an existing track, our input values to the existing track do not get reset on re-render.
+2. When there are lots of components of different types and arbitrary counts passed to an event listener, it is easier to use the set and dictionary notation for inputs rather than list notation. Above, we make one large set of all the input `gr.Audio` and `gr.Slider` components when we pass the inputs to the `merge` function. In the function body we query the component values as a dict.
+
+The `gr.render` expands gradio capabilities extensively - see what you can make out of it! 

sources/04_reactive-interfaces.md

@@ -0,0 +1,29 @@
+
+# Reactive Interfaces
+
+Finally, we cover how to get Gradio demos to refresh automatically or continuously stream data.
+
+## Live Interfaces
+
+You can make interfaces automatically refresh by setting `live=True` in the interface. Now the interface will recalculate as soon as the user input changes.
+
+$code_calculator_live
+$demo_calculator_live
+
+Note there is no submit button, because the interface resubmits automatically on change.
+
+## Streaming Components
+
+Some components have a "streaming" mode, such as `Audio` component in microphone mode, or the `Image` component in webcam mode. Streaming means data is sent continuously to the backend and the `Interface` function is continuously being rerun.
+
+The difference between `gr.Audio(source='microphone')` and `gr.Audio(source='microphone', streaming=True)`, when both are used in `gr.Interface(live=True)`, is that the first `Component` will automatically submit data and run the `Interface` function when the user stops recording, whereas the second `Component` will continuously send data and run the `Interface` function _during_ recording.
+
+Here is example code of streaming images from the webcam.
+
+$code_stream_frames
+
+Streaming can also be done in an output component. A `gr.Audio(streaming=True)` output component can take a stream of audio data yielded piece-wise by a generator function and combines them into a single audio file.
+
+$code_stream_audio_out
+
+For a more detailed example, see our guide on performing [automatic speech recognition](/guides/real-time-speech-recognition) with Gradio.

sources/04_styling.md

@@ -0,0 +1,13 @@
+
+# Styling
+
+Gradio themes are the easiest way to customize the look and feel of your app. You can choose from a variety of themes, or create your own. To do so, pass the `theme=` kwarg to the `Interface` constructor. For example:
+
+```python
+demo = gr.Interface(..., theme=gr.themes.Monochrome())
+```
+
+Gradio comes with a set of prebuilt themes which you can load from `gr.themes.*`. You can extend these themes or create your own themes from scratch - see the [theming guide](https://gradio.app/guides/theming-guide) for more details.
+
+For additional styling ability, you can pass any CSS (as well as custom JavaScript) to your Gradio application. This is discussed in more detail in our [custom JS and CSS guide](/guides/custom-CSS-and-JS).
+

sources/05_custom-CSS-and-JS.md

@@ -0,0 +1,123 @@
+
+# Customizing your demo with CSS and Javascript
+
+Gradio allows you to customize your demo in several ways. You can customize the layout of your demo, add custom HTML, and add custom theming as well. This tutorial will go beyond that and walk you through how to add custom CSS and JavaScript code to your demo in order to add custom styling, animations, custom UI functionality, analytics, and more.
+
+## Adding custom CSS to your demo
+
+Gradio themes are the easiest way to customize the look and feel of your app. You can choose from a variety of themes, or create your own. To do so, pass the `theme=` kwarg to the `Blocks` constructor. For example:
+
+```python
+with gr.Blocks(theme=gr.themes.Glass()):
+    ...
+```
+
+Gradio comes with a set of prebuilt themes which you can load from `gr.themes.*`. You can extend these themes or create your own themes from scratch - see the [Theming guide](/guides/theming-guide) for more details.
+
+For additional styling ability, you can pass any CSS to your app using the `css=` kwarg. You can either the filepath to a CSS file, or a string of CSS code.
+
+**Warning**: The use of query selectors in custom JS and CSS is _not_ guaranteed to work across Gradio versions as the Gradio HTML DOM may change. We recommend using query selectors sparingly.
+
+The base class for the Gradio app is `gradio-container`, so here's an example that changes the background color of the Gradio app:
+
+```python
+with gr.Blocks(css=".gradio-container {background-color: red}") as demo:
+    ...
+```
+
+If you'd like to reference external files in your css, preface the file path (which can be a relative or absolute path) with `"file="`, for example:
+
+```python
+with gr.Blocks(css=".gradio-container {background: url('file=clouds.jpg')}") as demo:
+    ...
+```
+
+Note: By default, files in the host machine are not accessible to users running the Gradio app. As a result, you should make sure that any referenced files (such as `clouds.jpg` here) are either URLs or allowed via the `allow_list` parameter in `launch()`. Read more in our [section on Security and File Access](/guides/sharing-your-app#security-and-file-access).
+
+
+## The `elem_id` and `elem_classes` Arguments
+
+You can `elem_id` to add an HTML element `id` to any component, and `elem_classes` to add a class or list of classes. This will allow you to select elements more easily with CSS. This approach is also more likely to be stable across Gradio versions as built-in class names or ids may change (however, as mentioned in the warning above, we cannot guarantee complete compatibility between Gradio versions if you use custom CSS as the DOM elements may themselves change).
+
+```python
+css = """
+#warning {background-color: #FFCCCB}
+.feedback textarea {font-size: 24px !important}
+"""
+
+with gr.Blocks(css=css) as demo:
+    box1 = gr.Textbox(value="Good Job", elem_classes="feedback")
+    box2 = gr.Textbox(value="Failure", elem_id="warning", elem_classes="feedback")
+```
+
+The CSS `#warning` ruleset will only target the second Textbox, while the `.feedback` ruleset will target both. Note that when targeting classes, you might need to put the `!important` selector to override the default Gradio styles.
+
+## Adding custom JavaScript to your demo
+
+There are 3 ways to add javascript code to your Gradio demo:
+
+1. You can add JavaScript code as a string or as a filepath to the `js` parameter of the `Blocks` or `Interface` initializer. This will run the JavaScript code when the demo is first loaded.
+
+Below is an example of adding custom js to show an animated welcome message when the demo first loads.
+
+$code_blocks_js_load
+$demo_blocks_js_load
+
+Note: You can also supply your custom js code as a file path. For example, if you have a file called `custom.js` in the same directory as your Python script, you can add it to your demo like so: `with gr.Blocks(js="custom.js") as demo:`. Same goes for `Interface` (ex: `gr.Interface(..., js="custom.js")`).
+
+2. When using `Blocks` and event listeners, events have a `js` argument that can take a JavaScript function as a string and treat it just like a Python event listener function. You can pass both a JavaScript function and a Python function (in which case the JavaScript function is run first) or only Javascript (and set the Python `fn` to `None`). Take a look at the code below:
+   
+$code_blocks_js_methods
+$demo_blocks_js_methods
+
+3. Lastly, you can add JavaScript code to the `head` param of the `Blocks` initializer. This will add the code to the head of the HTML document. For example, you can add Google Analytics to your demo like so:
+
+
+```python
+head = f"""
+<script async src="https://www.googletagmanager.com/gtag/js?id={google_analytics_tracking_id}"></script>
+<script>
+  window.dataLayer = window.dataLayer || [];
+  function gtag(){{dataLayer.push(arguments);}}
+  gtag('js', new Date());
+  gtag('config', '{google_analytics_tracking_id}');
+</script>
+"""
+
+with gr.Blocks(head=head) as demo:
+    ...demo code...
+```
+
+The `head` parameter accepts any HTML tags you would normally insert into the `<head>` of a page. For example, you can also include `<meta>` tags to `head`.
+
+Note that injecting custom HTML can affect browser behavior and compatibility (e.g. keyboard shortcuts). You should test your interface across different browsers and be mindful of how scripts may interact with browser defaults.
+Here's an example where pressing `Shift + s` triggers the `click` event of a specific `Button` component if the browser focus is _not_ on an input component (e.g. `Textbox` component):
+
+```python
+import gradio as gr
+
+shortcut_js = """
+<script>
+function shortcuts(e) {
+    var event = document.all ? window.event : e;
+    switch (e.target.tagName.toLowerCase()) {
+        case "input":
+        case "textarea":
+        break;
+        default:
+        if (e.key.toLowerCase() == "s" && e.shiftKey) {
+            document.getElementById("my_btn").click();
+        }
+    }
+}
+document.addEventListener('keypress', shortcuts, false);
+</script>
+"""
+
+with gr.Blocks(head=shortcut_js) as demo:
+    action_button = gr.Button(value="Name", elem_id="my_btn")
+    textbox = gr.Textbox()
+    action_button.click(lambda : "button pressed", None, textbox)
+    
+demo.launch()
+```

sources/05_four-kinds-of-interfaces.md

@@ -0,0 +1,45 @@
+
+# The 4 Kinds of Gradio Interfaces
+
+So far, we've always assumed that in order to build an Gradio demo, you need both inputs and outputs. But this isn't always the case for machine learning demos: for example, _unconditional image generation models_ don't take any input but produce an image as the output.
+
+It turns out that the `gradio.Interface` class can actually handle 4 different kinds of demos:
+
+1. **Standard demos**: which have both separate inputs and outputs (e.g. an image classifier or speech-to-text model)
+2. **Output-only demos**: which don't take any input but produce on output (e.g. an unconditional image generation model)
+3. **Input-only demos**: which don't produce any output but do take in some sort of input (e.g. a demo that saves images that you upload to a persistent external database)
+4. **Unified demos**: which have both input and output components, but the input and output components _are the same_. This means that the output produced overrides the input (e.g. a text autocomplete model)
+
+Depending on the kind of demo, the user interface (UI) looks slightly different:
+
+![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/gradio-guides/interfaces4.png)
+
+Let's see how to build each kind of demo using the `Interface` class, along with examples:
+
+## Standard demos
+
+To create a demo that has both the input and the output components, you simply need to set the values of the `inputs` and `outputs` parameter in `Interface()`. Here's an example demo of a simple image filter:
+
+$code_sepia_filter
+$demo_sepia_filter
+
+## Output-only demos
+
+What about demos that only contain outputs? In order to build such a demo, you simply set the value of the `inputs` parameter in `Interface()` to `None`. Here's an example demo of a mock image generation model:
+
+$code_fake_gan_no_input
+$demo_fake_gan_no_input
+
+## Input-only demos
+
+Similarly, to create a demo that only contains inputs, set the value of `outputs` parameter in `Interface()` to be `None`. Here's an example demo that saves any uploaded image to disk:
+
+$code_save_file_no_output
+$demo_save_file_no_output
+
+## Unified demos
+
+A demo that has a single component as both the input and the output. It can simply be created by setting the values of the `inputs` and `outputs` parameter as the same component. Here's an example demo of a text generation model:
+
+$code_unified_demo_text_generation
+$demo_unified_demo_text_generation

sources/05_progress-bars.md

@@ -0,0 +1,9 @@
+
+# Progress Bars
+
+Gradio supports the ability to create custom Progress Bars so that you have customizability and control over the progress update that you show to the user. In order to enable this, simply add an argument to your method that has a default value of a `gr.Progress` instance. Then you can update the progress levels by calling this instance directly with a float between 0 and 1, or using the `tqdm()` method of the `Progress` instance to track progress over an iterable, as shown below.
+
+$code_progress_simple
+$demo_progress_simple
+
+If you use the `tqdm` library, you can even report progress updates automatically from any `tqdm.tqdm` that already exists within your function by setting the default argument as `gr.Progress(track_tqdm=True)`!

sources/06_batch-functions.md

@@ -0,0 +1,60 @@
+
+# Batch functions
+
+Gradio supports the ability to pass _batch_ functions. Batch functions are just
+functions which take in a list of inputs and return a list of predictions.
+
+For example, here is a batched function that takes in two lists of inputs (a list of
+words and a list of ints), and returns a list of trimmed words as output:
+
+```py
+import time
+
+def trim_words(words, lens):
+    trimmed_words = []
+    time.sleep(5)
+    for w, l in zip(words, lens):
+        trimmed_words.append(w[:int(l)])
+    return [trimmed_words]
+```
+
+The advantage of using batched functions is that if you enable queuing, the Gradio server can automatically _batch_ incoming requests and process them in parallel,
+potentially speeding up your demo. Here's what the Gradio code looks like (notice the `batch=True` and `max_batch_size=16`)
+
+With the `gr.Interface` class:
+
+```python
+demo = gr.Interface(
+    fn=trim_words, 
+    inputs=["textbox", "number"], 
+    outputs=["output"],
+    batch=True, 
+    max_batch_size=16
+)
+
+demo.launch()
+```
+
+With the `gr.Blocks` class:
+
+```py
+import gradio as gr
+
+with gr.Blocks() as demo:
+    with gr.Row():
+        word = gr.Textbox(label="word")
+        leng = gr.Number(label="leng")
+        output = gr.Textbox(label="Output")
+    with gr.Row():
+        run = gr.Button()
+
+    event = run.click(trim_words, [word, leng], output, batch=True, max_batch_size=16)
+
+demo.launch()
+```
+
+In the example above, 16 requests could be processed in parallel (for a total inference time of 5 seconds), instead of each request being processed separately (for a total
+inference time of 80 seconds). Many Hugging Face `transformers` and `diffusers` models work very naturally with Gradio's batch mode: here's [an example demo using diffusers to
+generate images in batches](https://github.com/gradio-app/gradio/blob/main/demo/diffusers_with_batching/run.py)
+
+

sources/06_using-blocks-like-functions.md

@@ -0,0 +1,91 @@
+
+# Using Gradio Blocks Like Functions
+
+Tags: TRANSLATION, HUB, SPACES
+
+**Prerequisite**: This Guide builds on the Blocks Introduction. Make sure to [read that guide first](https://gradio.app/blocks-and-event-listeners).
+
+## Introduction
+
+Did you know that apart from being a full-stack machine learning demo, a Gradio Blocks app is also a regular-old python function!?
+
+This means that if you have a gradio Blocks (or Interface) app called `demo`, you can use `demo` like you would any python function.
+
+So doing something like `output = demo("Hello", "friend")` will run the first event defined in `demo` on the inputs "Hello" and "friend" and store it
+in the variable `output`.
+
+If I put you to sleep 🥱, please bear with me! By using apps like functions, you can seamlessly compose Gradio apps.
+The following section will show how.
+
+## Treating Blocks like functions
+
+Let's say we have the following demo that translates english text to german text.
+
+$code_english_translator
+
+I already went ahead and hosted it in Hugging Face spaces at [gradio/english_translator](https://huggingface.co/spaces/gradio/english_translator).
+
+You can see the demo below as well:
+
+$demo_english_translator
+
+Now, let's say you have an app that generates english text, but you wanted to additionally generate german text.
+
+You could either:
+
+1. Copy the source code of my english-to-german translation and paste it in your app.
+
+2. Load my english-to-german translation in your app and treat it like a normal python function.
+
+Option 1 technically always works, but it often introduces unwanted complexity.
+
+Option 2 lets you borrow the functionality you want without tightly coupling our apps.
+
+All you have to do is call the `Blocks.load` class method in your source file.
+After that, you can use my translation app like a regular python function!
+
+The following code snippet and demo shows how to use `Blocks.load`.
+
+Note that the variable `english_translator` is my english to german app, but its used in `generate_text` like a regular function.
+
+$code_generate_english_german
+
+$demo_generate_english_german
+
+## How to control which function in the app to use
+
+If the app you are loading defines more than one function, you can specify which function to use
+with the `fn_index` and `api_name` parameters.
+
+In the code for our english to german demo, you'll see the following line:
+
+```python
+translate_btn.click(translate, inputs=english, outputs=german, api_name="translate-to-german")
+```
+
+The `api_name` gives this function a unique name in our app. You can use this name to tell gradio which
+function in the upstream space you want to use:
+
+```python
+english_generator(text, api_name="translate-to-german")[0]["generated_text"]
+```
+
+You can also use the `fn_index` parameter.
+Imagine my app also defined an english to spanish translation function.
+In order to use it in our text generation app, we would use the following code:
+
+```python
+english_generator(text, fn_index=1)[0]["generated_text"]
+```
+
+Functions in gradio spaces are zero-indexed, so since the spanish translator would be the second function in my space,
+you would use index 1.
+
+## Parting Remarks
+
+We showed how treating a Blocks app like a regular python helps you compose functionality across different apps.
+Any Blocks app can be treated like a function, but a powerful pattern is to `load` an app hosted on
+[Hugging Face Spaces](https://huggingface.co/spaces) prior to treating it like a function in your own app.
+You can also load models hosted on the [Hugging Face Model Hub](https://huggingface.co/models) - see the [Using Hugging Face Integrations](/using_hugging_face_integrations) guide for an example.
+
+### Happy building! ⚒️

sources/07_resource-cleanup.md

@@ -0,0 +1,49 @@
+
+# Resource Cleanup
+
+Your Gradio application may create resources during its lifetime.
+Examples of resources are `gr.State` variables, any variables you create and explicitly hold in memory, or files you save to disk. 
+Over time, these resources can use up all of your server's RAM or disk space and crash your application.
+
+Gradio provides some tools for you to clean up the resources created by your app:
+
+1. Automatic deletion of `gr.State` variables.
+2. Automatic cache cleanup with the `delete_cache` parameter.
+2. The `Blocks.unload` event.
+
+Let's take a look at each of them individually.
+
+## Automatic deletion of `gr.State`
+
+When a user closes their browser tab, Gradio will automatically delete any `gr.State` variables associated with that user session after 60 minutes. If the user connects again within those 60 minutes, no state will be deleted.
+
+You can control the deletion behavior further with the following two parameters of `gr.State`:
+
+1. `delete_callback` - An arbitrary function that will be called when the variable is deleted. This function must take the state value as input. This function is useful for deleting variables from GPU memory.
+2. `time_to_live` - The number of seconds the state should be stored for after it is created or updated. This will delete variables before the session is closed, so it's useful for clearing state for potentially long running sessions.
+
+## Automatic cache cleanup via `delete_cache`
+
+Your Gradio application will save uploaded and generated files to a special directory called the cache directory. Gradio uses a hashing scheme to ensure that duplicate files are not saved to the cache but over time the size of the cache will grow (especially if your app goes viral 😉).
+
+Gradio can periodically clean up the cache for you if you specify the `delete_cache` parameter of `gr.Blocks()`, `gr.Interface()`, or `gr.ChatInterface()`. 
+This parameter is a tuple of the form `[frequency, age]` both expressed in number of seconds.
+Every `frequency` seconds, the temporary files created by this Blocks instance will be deleted if more than `age` seconds have passed since the file was created. 
+For example, setting this to (86400, 86400) will delete temporary files every day if they are older than a day old.
+Additionally, the cache will be deleted entirely when the server restarts.
+
+## The `unload` event
+
+Additionally, Gradio now includes a `Blocks.unload()` event, allowing you to run arbitrary cleanup functions when users disconnect (this does not have a 60 minute delay).
+Unlike other gradio events, this event does not accept inputs or outptus.
+You can think of the `unload` event as the opposite of the `load` event.
+
+## Putting it all together
+
+The following demo uses all of these features. When a user visits the page, a special unique directory is created for that user.
+As the user interacts with the app, images are saved to disk in that special directory.
+When the user closes the page, the images created in that session are deleted via the `unload` event.
+The state and files in the cache are cleaned up automatically as well.
+
+$code_state_cleanup
+$demo_state_cleanup

sources/08_environment-variables.md

@@ -0,0 +1,118 @@
+
+# Environment Variables
+
+Environment variables in Gradio provide a way to customize your applications and launch settings without changing the codebase. In this guide, we'll explore the key environment variables supported in Gradio and how to set them.
+
+## Key Environment Variables
+
+### 1. `GRADIO_SERVER_PORT`
+
+- **Description**: Specifies the port on which the Gradio app will run.
+- **Default**: `7860`
+- **Example**:
+  ```bash
+  export GRADIO_SERVER_PORT=8000
+  ```
+
+### 2. `GRADIO_SERVER_NAME`
+
+- **Description**: Defines the host name for the Gradio server. To make Gradio accessible from any IP address, set this to `"0.0.0.0"`
+- **Default**: `"127.0.0.1"` 
+- **Example**:
+  ```bash
+  export GRADIO_SERVER_NAME="0.0.0.0"
+  ```
+
+### 3. `GRADIO_ANALYTICS_ENABLED`
+
+- **Description**: Whether Gradio should provide 
+- **Default**: `"True"`
+- **Options**: `"True"`, `"False"`
+- **Example**:
+  ```sh
+  export GRADIO_ANALYTICS_ENABLED="True"
+  ```
+
+### 4. `GRADIO_DEBUG`
+
+- **Description**: Enables or disables debug mode in Gradio. If debug mode is enabled, the main thread does not terminate allowing error messages to be printed in environments such as Google Colab.
+- **Default**: `0`
+- **Example**:
+  ```sh
+  export GRADIO_DEBUG=1
+  ```
+
+### 5. `GRADIO_ALLOW_FLAGGING`
+
+- **Description**: Controls whether users can flag inputs/outputs in the Gradio interface. See [the Guide on flagging](/guides/using-flagging) for more details.
+- **Default**: `"manual"`
+- **Options**: `"never"`, `"manual"`, `"auto"`
+- **Example**:
+  ```sh
+  export GRADIO_ALLOW_FLAGGING="never"
+  ```
+
+### 6. `GRADIO_TEMP_DIR`
+
+- **Description**: Specifies the directory where temporary files created by Gradio are stored.
+- **Default**: System default temporary directory
+- **Example**:
+  ```sh
+  export GRADIO_TEMP_DIR="/path/to/temp"
+  ```
+
+### 7. `GRADIO_ROOT_PATH`
+
+- **Description**: Sets the root path for the Gradio application. Useful if running Gradio [behind a reverse proxy](/guides/running-gradio-on-your-web-server-with-nginx).
+- **Default**: `""`
+- **Example**:
+  ```sh
+  export GRADIO_ROOT_PATH="/myapp"
+  ```
+
+### 8. `GRADIO_SHARE`
+
+- **Description**: Enables or disables sharing the Gradio app.
+- **Default**: `"False"`
+- **Options**: `"True"`, `"False"`
+- **Example**:
+  ```sh
+  export GRADIO_SHARE="True"
+  ```
+
+### 9. `GRADIO_ALLOWED_PATHS`
+
+- **Description**: Sets a list of complete filepaths or parent directories that gradio is allowed to serve. Must be absolute paths. Warning: if you provide directories, any files in these directories or their subdirectories are accessible to all users of your app. Multiple items can be specified by separating items with commas.
+- **Default**: `""`
+- **Example**:
+  ```sh
+  export GRADIO_ALLOWED_PATHS="/mnt/sda1,/mnt/sda2"
+  ```
+
+### 10. `GRADIO_BLOCKED_PATHS`
+
+- **Description**: Sets a list of complete filepaths or parent directories that gradio is not allowed to serve (i.e. users of your app are not allowed to access). Must be absolute paths. Warning: takes precedence over `allowed_paths` and all other directories exposed by Gradio by default. Multiple items can be specified by separating items with commas.
+- **Default**: `""`
+- **Example**:
+  ```sh
+  export GRADIO_BLOCKED_PATHS="/users/x/gradio_app/admin,/users/x/gradio_app/keys"
+  ```
+
+
+## How to Set Environment Variables
+
+To set environment variables in your terminal, use the `export` command followed by the variable name and its value. For example:
+
+```sh
+export GRADIO_SERVER_PORT=8000
+```
+
+If you're using a `.env` file to manage your environment variables, you can add them like this:
+
+```sh
+GRADIO_SERVER_PORT=8000
+GRADIO_SERVER_NAME="localhost"
+```
+
+Then, use a tool like `dotenv` to load these variables when running your application.
+

sources/09_sharing-your-app.md

@@ -0,0 +1,482 @@
+
+# Sharing Your App
+
+In this Guide, we dive more deeply into the various aspects of sharing a Gradio app with others. We will cover:
+
+1. [Sharing demos with the share parameter](#sharing-demos)
+2. [Hosting on HF Spaces](#hosting-on-hf-spaces)
+3. [Embedding hosted spaces](#embedding-hosted-spaces)
+4. [Using the API page](#api-page)
+5. [Accessing network requests](#accessing-the-network-request-directly)
+6. [Mounting within FastAPI](#mounting-within-another-fast-api-app)
+7. [Authentication](#authentication)
+8. [Security and file access](#security-and-file-access)
+9. [Analytics](#analytics)
+
+## Sharing Demos
+
+Gradio demos can be easily shared publicly by setting `share=True` in the `launch()` method. Like this:
+
+```python
+import gradio as gr
+
+def greet(name):
+    return "Hello " + name + "!"
+
+demo = gr.Interface(fn=greet, inputs="textbox", outputs="textbox")
+    
+demo.launch(share=True)  # Share your demo with just 1 extra parameter 🚀
+```
+
+This generates a public, shareable link that you can send to anybody! When you send this link, the user on the other side can try out the model in their browser. Because the processing happens on your device (as long as your device stays on), you don't have to worry about any packaging any dependencies. 
+
+![sharing](https://github.com/gradio-app/gradio/blob/main/guides/assets/sharing.svg?raw=true)
+
+
+A share link usually looks something like this: **https://07ff8706ab.gradio.live**. Although the link is served through the Gradio Share Servers, these servers are only a proxy for your local server, and do not store any data sent through your app. Share links expire after 72 hours. (it is [also possible to set up your own Share Server](https://github.com/huggingface/frp/) on your own cloud server to overcome this restriction.)
+
+Tip: Keep in mind that share links are publicly accessible, meaning that anyone can use your model for prediction! Therefore, make sure not to expose any sensitive information through the functions you write, or allow any critical changes to occur on your device. Or you can [add authentication to your Gradio app](#authentication) as discussed below.
+
+Note that by default, `share=False`, which means that your server is only running locally. (This is the default, except in Google Colab notebooks, where share links are automatically created). As an alternative to using share links, you can use use [SSH port-forwarding](https://www.ssh.com/ssh/tunneling/example) to share your local server with specific users.
+
+
+## Hosting on HF Spaces
+
+If you'd like to have a permanent link to your Gradio demo on the internet, use Hugging Face Spaces. [Hugging Face Spaces](http://huggingface.co/spaces/) provides the infrastructure to permanently host your machine learning model for free!
+
+After you have [created a free Hugging Face account](https://huggingface.co/join), you have two methods to deploy your Gradio app to Hugging Face Spaces:
+
+1. From terminal: run `gradio deploy` in your app directory. The CLI will gather some basic metadata and then launch your app. To update your space, you can re-run this command or enable the Github Actions option to automatically update the Spaces on `git push`.
+
+2. From your browser: Drag and drop a folder containing your Gradio model and all related files [here](https://huggingface.co/new-space). See [this guide how to host on Hugging Face Spaces](https://huggingface.co/blog/gradio-spaces) for more information, or watch the embedded video:
+
+<video autoplay muted loop>
+  <source src="https://github.com/gradio-app/gradio/blob/main/guides/assets/hf_demo.mp4?raw=true" type="video/mp4" />
+</video>
+
+
+## Embedding Hosted Spaces
+
+Once you have hosted your app on Hugging Face Spaces (or on your own server), you may want to embed the demo on a different website, such as your blog or your portfolio. Embedding an interactive demo allows people to try out the machine learning model that you have built, without needing to download or install anything — right in their browser! The best part is that you can embed interactive demos even in static websites, such as GitHub pages.
+
+There are two ways to embed your Gradio demos. You can find quick links to both options directly on the Hugging Face Space page, in the "Embed this Space" dropdown option:
+
+![Embed this Space dropdown option](https://github.com/gradio-app/gradio/blob/main/guides/assets/embed_this_space.png?raw=true)
+
+### Embedding with Web Components
+
+Web components typically offer a better experience to users than IFrames. Web components load lazily, meaning that they won't slow down the loading time of your website, and they automatically adjust their height based on the size of the Gradio app.
+
+To embed with Web Components:
+
+1. Import the gradio JS library into into your site by adding the script below in your site (replace {GRADIO_VERSION} in the URL with the library version of Gradio you are using).
+
+```html
+<script
+	type="module"
+	src="https://gradio.s3-us-west-2.amazonaws.com/{GRADIO_VERSION}/gradio.js"
+></script>
+```
+
+2. Add
+
+```html
+<gradio-app src="https://$your_space_host.hf.space"></gradio-app>
+```
+
+element where you want to place the app. Set the `src=` attribute to your Space's embed URL, which you can find in the "Embed this Space" button. For example:
+
+```html
+<gradio-app
+	src="https://abidlabs-pytorch-image-classifier.hf.space"
+></gradio-app>
+```
+
+<script>
+fetch("https://pypi.org/pypi/gradio/json"
+).then(r => r.json()
+).then(obj => {
+    let v = obj.info.version;
+    content = document.querySelector('.prose');
+    content.innerHTML = content.innerHTML.replaceAll("{GRADIO_VERSION}", v);
+});
+</script>
+
+You can see examples of how web components look <a href="https://www.gradio.app">on the Gradio landing page</a>.
+
+You can also customize the appearance and behavior of your web component with attributes that you pass into the `<gradio-app>` tag:
+
+- `src`: as we've seen, the `src` attributes links to the URL of the hosted Gradio demo that you would like to embed
+- `space`: an optional shorthand if your Gradio demo is hosted on Hugging Face Space. Accepts a `username/space_name` instead of a full URL. Example: `gradio/Echocardiogram-Segmentation`. If this attribute attribute is provided, then `src` does not need to be provided.
+- `control_page_title`: a boolean designating whether the html title of the page should be set to the title of the Gradio app (by default `"false"`)
+- `initial_height`: the initial height of the web component while it is loading the Gradio app, (by default `"300px"`). Note that the final height is set based on the size of the Gradio app.
+- `container`: whether to show the border frame and information about where the Space is hosted (by default `"true"`)
+- `info`: whether to show just the information about where the Space is hosted underneath the embedded app (by default `"true"`)
+- `autoscroll`: whether to autoscroll to the output when prediction has finished (by default `"false"`)
+- `eager`: whether to load the Gradio app as soon as the page loads (by default `"false"`)
+- `theme_mode`: whether to use the `dark`, `light`, or default `system` theme mode (by default `"system"`)
+- `render`: an event that is triggered once the embedded space has finished rendering.
+
+Here's an example of how to use these attributes to create a Gradio app that does not lazy load and has an initial height of 0px.
+
+```html
+<gradio-app
+	space="gradio/Echocardiogram-Segmentation"
+	eager="true"
+	initial_height="0px"
+></gradio-app>
+```
+
+Here's another example of how to use the `render` event. An event listener is used to capture the `render` event and will call the `handleLoadComplete()` function once rendering is complete. 
+
+```html
+<script>
+	function handleLoadComplete() {
+		console.log("Embedded space has finished rendering");
+	}
+
+	const gradioApp = document.querySelector("gradio-app");
+	gradioApp.addEventListener("render", handleLoadComplete);
+</script>
+```
+
+_Note: While Gradio's CSS will never impact the embedding page, the embedding page can affect the style of the embedded Gradio app. Make sure that any CSS in the parent page isn't so general that it could also apply to the embedded Gradio app and cause the styling to break. Element selectors such as `header { ... }` and `footer { ... }` will be the most likely to cause issues._
+
+### Embedding with IFrames
+
+To embed with IFrames instead (if you cannot add javascript to your website, for example), add this element:
+
+```html
+<iframe src="https://$your_space_host.hf.space"></iframe>
+```
+
+Again, you can find the `src=` attribute to your Space's embed URL, which you can find in the "Embed this Space" button.
+
+Note: if you use IFrames, you'll probably want to add a fixed `height` attribute and set `style="border:0;"` to remove the boreder. In addition, if your app requires permissions such as access to the webcam or the microphone, you'll need to provide that as well using the `allow` attribute.
+
+## API Page
+
+You can use almost any Gradio app as an API! In the footer of a Gradio app [like this one](https://huggingface.co/spaces/gradio/hello_world), you'll see a "Use via API" link.
+
+![Use via API](https://github.com/gradio-app/gradio/blob/main/guides/assets/use_via_api.png?raw=true)
+
+This is a page that lists the endpoints that can be used to query the Gradio app, via our supported clients: either [the Python client](https://gradio.app/guides/getting-started-with-the-python-client/), or [the JavaScript client](https://gradio.app/guides/getting-started-with-the-js-client/). For each endpoint, Gradio automatically generates the parameters and their types, as well as example inputs, like this.
+
+![](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/gradio-guides/view-api.png)
+
+The endpoints are automatically created when you launch a Gradio `Interface`. If you are using Gradio `Blocks`, you can also set up a Gradio API page, though we recommend that you explicitly name each event listener, such as
+
+```python
+btn.click(add, [num1, num2], output, api_name="addition")
+```
+
+This will add and document the endpoint `/api/addition/` to the automatically generated API page. Otherwise, your API endpoints will appear as "unnamed" endpoints.
+
+## Accessing the Network Request Directly
+
+When a user makes a prediction to your app, you may need the underlying network request, in order to get the request headers (e.g. for advanced authentication), log the client's IP address, getting the query parameters, or for other reasons. Gradio supports this in a similar manner to FastAPI: simply add a function parameter whose type hint is `gr.Request` and Gradio will pass in the network request as that parameter. Here is an example:
+
+```python
+import gradio as gr
+
+def echo(text, request: gr.Request):
+    if request:
+        print("Request headers dictionary:", request.headers)
+        print("IP address:", request.client.host)
+        print("Query parameters:", dict(request.query_params))
+    return text
+
+io = gr.Interface(echo, "textbox", "textbox").launch()
+```
+
+Note: if your function is called directly instead of through the UI (this happens, for
+example, when examples are cached, or when the Gradio app is called via API), then `request` will be `None`. 
+You should handle this case explicitly to ensure that your app does not throw any errors. That is why
+we have the explicit check `if request`.
+
+## Mounting Within Another FastAPI App
+
+In some cases, you might have an existing FastAPI app, and you'd like to add a path for a Gradio demo.
+You can easily do this with `gradio.mount_gradio_app()`.
+
+Here's a complete example:
+
+$code_custom_path
+
+Note that this approach also allows you run your Gradio apps on custom paths (`http://localhost:8000/gradio` in the example above).
+
+
+## Authentication
+
+### Password-protected app
+
+You may wish to put an authentication page in front of your app to limit who can open your app. With the `auth=` keyword argument in the `launch()` method, you can provide a tuple with a username and password, or a list of acceptable username/password tuples; Here's an example that provides password-based authentication for a single user named "admin":
+
+```python
+demo.launch(auth=("admin", "pass1234"))
+```
+
+For more complex authentication handling, you can even pass a function that takes a username and password as arguments, and returns `True` to allow access, `False` otherwise.
+
+Here's an example of a function that accepts any login where the username and password are the same:
+
+```python
+def same_auth(username, password):
+    return username == password
+demo.launch(auth=same_auth)
+```
+
+If you have multiple users, you may wish to customize the content that is shown depending on the user that is logged in. You can retrieve the logged in user by [accessing the network request directly](#accessing-the-network-request-directly) as discussed above, and then reading the `.username` attribute of the request. Here's an example:
+
+
+```python
+import gradio as gr
+
+def update_message(request: gr.Request):
+    return f"Welcome, {request.username}"
+
+with gr.Blocks() as demo:
+    m = gr.Markdown()
+    demo.load(update_message, None, m)
+    
+demo.launch(auth=[("Abubakar", "Abubakar"), ("Ali", "Ali")])
+```
+
+Note: For authentication to work properly, third party cookies must be enabled in your browser. This is not the case by default for Safari or for Chrome Incognito Mode. 
+
+If users visit the `/logout` page of your Gradio app, they will automatically be logged out and session cookies deleted. This allows you to add logout functionality to your Gradio app as well. Let's update the previous example to include a log out button:
+
+```python
+import gradio as gr
+
+def update_message(request: gr.Request):
+    return f"Welcome, {request.username}"
+
+with gr.Blocks() as demo:
+    m = gr.Markdown()
+    logout_button = gr.Button("Logout", link="/logout")
+    demo.load(update_message, None, m)
+    
+demo.launch(auth=[("Pete", "Pete"), ("Dawood", "Dawood")])
+```
+
+Note: Gradio's built-in authentication provides a straightforward and basic layer of access control but does not offer robust security features for applications that require stringent access controls (e.g.  multi-factor authentication, rate limiting, or automatic lockout policies).
+
+### OAuth (Login via Hugging Face)
+
+Gradio natively supports OAuth login via Hugging Face. In other words, you can easily add a _"Sign in with Hugging Face"_ button to your demo, which allows you to get a user's HF username as well as other information from their HF profile. Check out [this Space](https://huggingface.co/spaces/Wauplin/gradio-oauth-demo) for a live demo.
+
+To enable OAuth, you must set `hf_oauth: true` as a Space metadata in your README.md file. This will register your Space
+as an OAuth application on Hugging Face. Next, you can use `gr.LoginButton` to add a login button to
+your Gradio app. Once a user is logged in with their HF account, you can retrieve their profile by adding a parameter of type
+`gr.OAuthProfile` to any Gradio function. The user profile will be automatically injected as a parameter value. If you want
+to perform actions on behalf of the user (e.g. list user's private repos, create repo, etc.), you can retrieve the user
+token by adding a parameter of type `gr.OAuthToken`. You must define which scopes you will use in your Space metadata
+(see [documentation](https://huggingface.co/docs/hub/spaces-oauth#scopes) for more details).
+
+Here is a short example:
+
+```py
+import gradio as gr
+from huggingface_hub import whoami
+
+def hello(profile: gr.OAuthProfile | None) -> str:
+    if profile is None:
+        return "I don't know you."
+    return f"Hello {profile.name}"
+
+def list_organizations(oauth_token: gr.OAuthToken | None) -> str:
+    if oauth_token is None:
+        return "Please log in to list organizations."
+    org_names = [org["name"] for org in whoami(oauth_token.token)["orgs"]]
+    return f"You belong to {', '.join(org_names)}."
+
+with gr.Blocks() as demo:
+    gr.LoginButton()
+    m1 = gr.Markdown()
+    m2 = gr.Markdown()
+    demo.load(hello, inputs=None, outputs=m1)
+    demo.load(list_organizations, inputs=None, outputs=m2)
+
+demo.launch()
+```
+
+When the user clicks on the login button, they get redirected in a new page to authorize your Space.
+
+<center>
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/gradio-guides/oauth_sign_in.png" style="width:300px; max-width:80%">
+</center>
+
+Users can revoke access to their profile at any time in their [settings](https://huggingface.co/settings/connected-applications).
+
+As seen above, OAuth features are available only when your app runs in a Space. However, you often need to test your app
+locally before deploying it. To test OAuth features locally, your machine must be logged in to Hugging Face. Please run `huggingface-cli login` or set `HF_TOKEN` as environment variable with one of your access token. You can generate a new token in your settings page (https://huggingface.co/settings/tokens). Then, clicking on the `gr.LoginButton` will login your local Hugging Face profile, allowing you to debug your app with your Hugging Face account before deploying it to a Space.
+
+
+### OAuth (with external providers)
+
+It is also possible to authenticate with external OAuth providers (e.g. Google OAuth) in your Gradio apps. To do this, first mount your Gradio app within a FastAPI app ([as discussed above](#mounting-within-another-fast-api-app)). Then, you must write an *authentication function*, which gets the user's username from the OAuth provider and returns it. This function should be passed to the `auth_dependency` parameter in `gr.mount_gradio_app`. 
+
+Similar to [FastAPI dependency functions](https://fastapi.tiangolo.com/tutorial/dependencies/), the function specified by `auth_dependency` will run before any Gradio-related route in your FastAPI app. The function should accept a single parameter: the FastAPI `Request` and return either a string (representing a user's username) or `None`. If a string is returned, the user will be able to access the Gradio-related routes in your FastAPI app. 
+
+First, let's show a simplistic example to illustrate the `auth_dependency` parameter:
+
+```python
+from fastapi import FastAPI, Request
+import gradio as gr
+
+app = FastAPI()
+
+def get_user(request: Request):
+    return request.headers.get("user")
+
+demo = gr.Interface(lambda s: f"Hello {s}!", "textbox", "textbox")
+
+app = gr.mount_gradio_app(app, demo, path="/demo", auth_dependency=get_user)
+
+if __name__ == '__main__':
+    uvicorn.run(app)
+```
+
+In this example, only requests that include a "user" header will be allowed to access the Gradio app. Of course, this does not add much security, since any user can add this header in their request.
+
+Here's a more complete example showing how to add Google OAuth to a Gradio app (assuming you've already created OAuth Credentials on the [Google Developer Console](https://console.cloud.google.com/project)):
+
+```python
+import os
+from authlib.integrations.starlette_client import OAuth, OAuthError
+from fastapi import FastAPI, Depends, Request
+from starlette.config import Config
+from starlette.responses import RedirectResponse
+from starlette.middleware.sessions import SessionMiddleware
+import uvicorn
+import gradio as gr
+
+app = FastAPI()
+
+# Replace these with your own OAuth settings
+GOOGLE_CLIENT_ID = "..."
+GOOGLE_CLIENT_SECRET = "..."
+SECRET_KEY = "..."
+
+config_data = {'GOOGLE_CLIENT_ID': GOOGLE_CLIENT_ID, 'GOOGLE_CLIENT_SECRET': GOOGLE_CLIENT_SECRET}
+starlette_config = Config(environ=config_data)
+oauth = OAuth(starlette_config)
+oauth.register(
+    name='google',
+    server_metadata_url='https://accounts.google.com/.well-known/openid-configuration',
+    client_kwargs={'scope': 'openid email profile'},
+)
+
+SECRET_KEY = os.environ.get('SECRET_KEY') or "a_very_secret_key"
+app.add_middleware(SessionMiddleware, secret_key=SECRET_KEY)
+
+# Dependency to get the current user
+def get_user(request: Request):
+    user = request.session.get('user')
+    if user:
+        return user['name']
+    return None
+
+@app.get('/')
+def public(user: dict = Depends(get_user)):
+    if user:
+        return RedirectResponse(url='/gradio')
+    else:
+        return RedirectResponse(url='/login-demo')
+
+@app.route('/logout')
+async def logout(request: Request):
+    request.session.pop('user', None)
+    return RedirectResponse(url='/')
+
+@app.route('/login')
+async def login(request: Request):
+    redirect_uri = request.url_for('auth')
+    # If your app is running on https, you should ensure that the
+    # `redirect_uri` is https, e.g. uncomment the following lines:
+    # 
+    # from urllib.parse import urlparse, urlunparse
+    # redirect_uri = urlunparse(urlparse(str(redirect_uri))._replace(scheme='https'))
+    return await oauth.google.authorize_redirect(request, redirect_uri)
+
+@app.route('/auth')
+async def auth(request: Request):
+    try:
+        access_token = await oauth.google.authorize_access_token(request)
+    except OAuthError:
+        return RedirectResponse(url='/')
+    request.session['user'] = dict(access_token)["userinfo"]
+    return RedirectResponse(url='/')
+
+with gr.Blocks() as login_demo:
+    gr.Button("Login", link="/login")
+
+app = gr.mount_gradio_app(app, login_demo, path="/login-demo")
+
+def greet(request: gr.Request):
+    return f"Welcome to Gradio, {request.username}"
+
+with gr.Blocks() as main_demo:
+    m = gr.Markdown("Welcome to Gradio!")
+    gr.Button("Logout", link="/logout")
+    main_demo.load(greet, None, m)
+
+app = gr.mount_gradio_app(app, main_demo, path="/gradio", auth_dependency=get_user)
+
+if __name__ == '__main__':
+    uvicorn.run(app)
+```
+
+There are actually two separate Gradio apps in this example! One that simply displays a log in button (this demo is accessible to any user), while the other main demo is only accessible to users that are logged in. You can try this example out on [this Space](https://huggingface.co/spaces/gradio/oauth-example).
+
+
+
+## Security and File Access
+
+Sharing your Gradio app with others (by hosting it on Spaces, on your own server, or through temporary share links) **exposes** certain files on the host machine to users of your Gradio app.
+
+In particular, Gradio apps ALLOW users to access to four kinds of files:
+
+- **Temporary files created by Gradio.** These are files that are created by Gradio as part of running your prediction function. For example, if your prediction function returns a video file, then Gradio will save that video to a temporary cache on your device and then send the path to the file to the front end. You can customize the location of temporary cache files created by Gradio by setting the environment variable `GRADIO_TEMP_DIR` to an absolute path, such as `/home/usr/scripts/project/temp/`. You can delete the files created by your app when it shuts down with the `delete_cache` parameter of `gradio.Blocks`, `gradio.Interface`, and `gradio.ChatInterface`. This parameter is a tuple of integers of the form `[frequency, age]` where `frequency` is how often to delete files and `age` is the time in seconds since the file was last modified.
+
+
+- **Cached examples created by Gradio.** These are files that are created by Gradio as part of caching examples for faster runtimes, if you set `cache_examples=True` or `cache_examples="lazy"` in `gr.Interface()`, `gr.ChatInterface()` or in `gr.Examples()`. By default, these files are saved in the `gradio_cached_examples/` subdirectory within your app's working directory. You can customize the location of cached example files created by Gradio by setting the environment variable `GRADIO_EXAMPLES_CACHE` to an absolute path or a path relative to your working directory.
+
+- **Files that you explicitly allow via the `allowed_paths` parameter in `launch()`**. This parameter allows you to pass in a list of additional directories or exact filepaths you'd like to allow users to have access to. (By default, this parameter is an empty list).
+
+- **Static files that you explicitly set via the `gr.set_static_paths` function**. This parameter allows you to pass in a list of directories or filenames that will be considered static. This means that they will not be copied to the cache and will be served directly from your computer. This can help save disk space and reduce the time your app takes to launch but be mindful of possible security implications.
+
+Gradio DOES NOT ALLOW access to:
+
+- **Files that you explicitly block via the `blocked_paths` parameter in `launch()`**. You can pass in a list of additional directories or exact filepaths to the `blocked_paths` parameter in `launch()`. This parameter takes precedence over the files that Gradio exposes by default or by the `allowed_paths`.
+
+- **Any other paths on the host machine**. Users should NOT be able to access other arbitrary paths on the host.
+
+Sharing your Gradio application will also allow users to upload files to your computer or server. You can set a maximum file size for uploads to prevent abuse and to preserve disk space. You can do this with the `max_file_size` parameter of `.launch`. For example, the following two code snippets limit file uploads to 5 megabytes per file.
+
+```python
+import gradio as gr
+
+demo = gr.Interface(lambda x: x, "image", "image")
+
+demo.launch(max_file_size="5mb")
+# or
+demo.launch(max_file_size=5 * gr.FileSize.MB)
+```
+
+Please make sure you are running the latest version of `gradio` for these security settings to apply.
+
+## Analytics
+
+By default, Gradio collects certain analytics to help us better understand the usage of the `gradio` library. This includes the following information:
+
+* What environment the Gradio app is running on (e.g. Colab Notebook, Hugging Face Spaces)
+* What input/output components are being used in the Gradio app
+* Whether the Gradio app is utilizing certain advanced features, such as `auth` or `show_error` 
+* The IP address which is used solely to measure the number of unique developers using Gradio 
+* The version of Gradio that is running 
+
+No information is collected from _users_ of your Gradio app. If you'd like to diable analytics altogether, you can do so by setting the `analytics_enabled` parameter to `False` in `gr.Blocks`, `gr.Interface`, or `gr.ChatInterface`. Or, you can set the GRADIO_ANALYTICS_ENABLED environment variable to `"False"` to apply this to all Gradio apps created across your system.
+
+*Note*: this reflects the analytics policy as of `gradio>=4.32.0`.