internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: gradio-app/gradio

Issue:
When caching the output of a file component in examples, the filename is not respected
### Describe the bug

Run Model3D with cache examples - you can do it with the version hosted on spaces here: https://huggingface.co/spaces/gradio-pr-deploys/pr-2128-all-demos

Click on an example and download the resulting file, you will see that the downloaded file does not have a complete name, e.g. `_home_user_app_gradio_cached_e (2)`

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Reproduction

Stated above^

### Screenshot

![model_3d_download](https://user-images.githubusercontent.com/41651716/187721503-98fad3d1-6551-4491-9e0e-a42e1d08d5d4.gif)


### Logs

```shell
-
```


### System Info

```shell
-
```


### Severity

serious, but I can work around it


Discussion:
Out of curiosity, can you try right clicking "open link in a new tab" when you click on the "Download" link? 
Interesting - then the file is just called `Download`. Just tried it on the space
At first I thought it had to do with the name of the file being too long - but I think it's caused by reading from the example cache. Locally, e.g. no example caching, I modified `zip_two_files` to return a really long file name and the file name (and extension) was respected.
Getting the same behavior, very strange 
Think I figured it out - it's the slashes in the file name when reading from the cache. I think we just need to make the file serializer add the `orig_name` field with the file name as opposed to the full path. Will put up a PR soon.

Resolving patch:
diff --git a/demo/model3D/run.py b/demo/model3D/run.py
--- a/demo/model3D/run.py
+++ b/demo/model3D/run.py
@@ -1,4 +1,3 @@
-import time
 import gradio as gr
 import os
 
diff --git a/gradio/serializing.py b/gradio/serializing.py
--- a/gradio/serializing.py
+++ b/gradio/serializing.py
@@ -2,6 +2,7 @@
 
 import os
 from abc import ABC, abstractmethod
+from pathlib import Path
 from typing import Any, Dict
 
 from gradio import processing_utils
@@ -110,6 +111,7 @@ def serialize(
             "data": processing_utils.encode_url_or_file_to_base64(
                 filename, encryption_key=encryption_key
             ),
+            "orig_name": Path(filename).name,
             "is_file": False,
         }
 


Test patch:
diff --git a/test/test_components.py b/test/test_components.py
--- a/test/test_components.py
+++ b/test/test_components.py
@@ -850,10 +850,12 @@ def test_component_functions(self):
         file_input = gr.File()
         output = file_input.preprocess(x_file)
         self.assertIsInstance(output, tempfile._TemporaryFileWrapper)
+        serialized = file_input.serialize("test/test_files/sample_file.pdf")
         assert filecmp.cmp(
-            file_input.serialize("test/test_files/sample_file.pdf")["name"],
+            serialized["name"],
             "test/test_files/sample_file.pdf",
         )
+        assert serialized["orig_name"] == "sample_file.pdf"
         assert output.orig_name == "test/test_files/sample_file.pdf"
 
         self.assertIsInstance(file_input.generate_sample(), dict)
Repository: gradio-app/gradio

Issue:
Use static config file to configure setuptools as opposed to setup.py
- [x] I have searched to see if a similar issue already exists.


As a gradio developer, I think we should adopt the best practice put forth in [PEP 621](https://peps.python.org/pep-0621/) and declare project metadata statically in a pyproject.toml (setup.cfg would be ok too). 

We should still keep setup.py for editable installs. 

**Describe the solution you'd like**  
Use pyproject.toml (or setup.cfg) to define project metadata

**Additional context**  
[PEP 621](https://peps.python.org/pep-0621/)


Discussion:
Don't think this is high priority - configuring the build via `setup` in `setup.py` will continue to work for a while but may be best to get ahead of this and adopt the best practice. From the setuptools [docs](https://setuptools.pypa.io/en/latest/userguide/quickstart.html#setup-py):

![image](https://user-images.githubusercontent.com/41651716/176479784-13f2c2ee-e5dc-4b21-81ac-db2c58b7b769.png)


Resolving patch:
diff --git a/setup.py b/setup.py
deleted file mode 100644
--- a/setup.py
+++ /dev/null
@@ -1,39 +0,0 @@
-try:
-    from setuptools import setup
-except ImportError:
-    from distutils.core import setup
-from pathlib import Path
-import re
-
-this_directory = Path(__file__).parent
-
-long_description = (this_directory / "README.md").read_text(encoding='utf8')
-# Replace relative paths to images with absolute paths
-long_description = re.sub("website/homepage/", "https://raw.githubusercontent.com/gradio-app/gradio/main/website/homepage/", long_description)
-long_description = re.sub(r"demo/([\S]*.gif)", r"https://raw.githubusercontent.com/gradio-app/gradio/main/demo/\g<1>", long_description)
-
-version = (this_directory / "gradio" / "version.txt").read_text(
-    encoding='utf8').strip()
-
-with open("requirements.txt") as reqs:
-    requirements = reqs.readlines()
-
-setup(
-    name="gradio",
-    version=version,
-    include_package_data=True,
-    description="Python library for easily interacting with trained machine learning models",
-    long_description=long_description,
-    long_description_content_type='text/markdown',
-    author="Abubakar Abid, Ali Abid, Ali Abdalla, Dawood Khan, Ahsen Khaliq, Pete Allen, Ömer Faruk Özdemir",
-    author_email="team@gradio.app",
-    url="https://github.com/gradio-app/gradio",
-    packages=["gradio", "gradio.test_data", "test.test_files"],
-    license="Apache License 2.0",
-    keywords=["machine learning", "visualization", "reproducibility"],
-    install_requires=requirements,
-    entry_points={
-        'console_scripts': ['gradio=gradio.reload:run_in_reload_mode']
-    },
-    python_requires='>=3.7',
-)


Test patch:
Repository: gradio-app/gradio

Issue:
Delete PR Spaces automatically
- [x] I have searched to see if a similar issue already exists.

We should delete the spaces created automatically during PR reviews after the PR is merged or after some given amount of time has passed after the PR has been merged. Keeping around the spaces post merge for a bit may help keep a history of the demos in case we realize something is broken.



Discussion:

Resolving patch:
diff --git a/scripts/delete_old_spaces.py b/scripts/delete_old_spaces.py
new file mode 100644
--- /dev/null
+++ b/scripts/delete_old_spaces.py
@@ -0,0 +1,47 @@
+import argparse
+import datetime
+from typing import Optional
+
+from huggingface_hub import HfApi
+
+
+def delete_space(space_id: str, hf_token: str, api_client: Optional[HfApi] = None):
+    api_client = api_client or HfApi()
+    api_client.delete_repo(repo_id=space_id, token=hf_token, repo_type="space")
+
+
+def get_spaces_to_delete(
+    n_days: int, org_name: str, api_client: Optional[HfApi] = None
+):
+    api_client = api_client or HfApi()
+    spaces = api.list_spaces(author=org_name)
+    spaces_to_delete = []
+    for space in spaces:
+        last_modified = api_client.space_info(space.id).lastModified
+        age = (
+            datetime.datetime.now()
+            - datetime.datetime.fromisoformat(last_modified.rsplit(".", 1)[0])
+        ).days
+        if age > n_days:
+            spaces_to_delete.append(space.id)
+    return spaces_to_delete
+
+
+if __name__ == "__main__":
+    parser = argparse.ArgumentParser(description="Upload a demo to a space")
+    parser.add_argument(
+        "n_days",
+        type=int,
+        help="Spaces older than n_days will be automatically deleted",
+    )
+    parser.add_argument(
+        "org_name", type=str, help="Name of the author/org to search in"
+    )
+    parser.add_argument("hf_token", type=str, help="HF API token")
+    args = parser.parse_args()
+    api = HfApi()
+
+    to_delete = get_spaces_to_delete(args.n_days, args.org_name, api_client=api)
+    for space in to_delete:
+        print(f"Deleting {space}")
+        delete_space(space, args.hf_token, api_client=api)


Test patch:
Repository: gradio-app/gradio

Issue:
`concurrency_count` broke on 3.3	
### Describe the bug

`concurrency_count` is not working on version 3.3. It adds persons to the queue instead of executing the queue in parallel

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Reproduction

Any execution with `concurrency_count` don't run in parallel on 3.3. It works on 3.1.7 and 3.2

### Screenshot

_No response_

### Logs

```shell
No logs
```


### System Info

```shell
3.3+
```


### Severity

blocking upgrade to latest gradio version


Discussion:
Yikes, we'll take a look. Is there code / a Space you can point me to make reproducing faster? 
Because it is broken, I have not let it on any live Spaces, but I think you can reproduce very minimally by setting just taking any demo and adding the `concurrency_count`, the requests still run in sequence

I made a Space with a minimal demo just to exemplify: https://huggingface.co/spaces/multimodalart/saymyname

Resolving patch:
diff --git a/gradio/queue.py b/gradio/queue.py
--- a/gradio/queue.py
+++ b/gradio/queue.py
@@ -36,7 +36,7 @@ def __init__(
         self.max_thread_count = concurrency_count
         self.data_gathering_start = data_gathering_start
         self.update_intervals = update_intervals
-        self.active_jobs: List[None | Event] = [None]
+        self.active_jobs: List[None | Event] = [None] * concurrency_count
         self.delete_lock = asyncio.Lock()
         self.server_path = None
         self.duration_history_total = 0


Test patch:
diff --git a/test/test_queue.py b/test/test_queue.py
--- a/test/test_queue.py
+++ b/test/test_queue.py
@@ -136,6 +136,18 @@ async def test_send_estimation(self, queue: Queue, mock_event: Event):
         assert estimation.rank == 2
         assert estimation.rank_eta == 15
 
+    @pytest.mark.asyncio
+    async def queue_sets_concurrency_count(self):
+        queue_object = Queue(
+            live_updates=True,
+            concurrency_count=5,
+            data_gathering_start=1,
+            update_intervals=1,
+            max_size=None,
+        )
+        assert len(queue_object.active_jobs) == 5
+        queue_object.close()
+
 
 class TestQueueProcessEvents:
     @pytest.mark.asyncio
Repository: gradio-app/gradio

Issue:
Be able to update accordion label from backend
- [x] I have searched to see if a similar issue already exists.


**Is your feature request related to a problem? Please describe.**  
Would be nice if developers could update the accordion label from the backend. 

Example use case,

You have a drop down with dataset names on the left hand side and information about the dataset in different accordion components. You'd like the accordion title to reflect the current dataset selected.

For example, in the UI below, it might be nice if instead of "Dataset Description" it read "<dataset-name> description" or "Label Distribution for <dataset-name>"

![image](https://user-images.githubusercontent.com/41651716/202575495-d494a43b-01ab-4d61-a877-c6552a0b7a82.png)


**Describe the solution you'd like**  
```python
gr.Accordion.update(label=<new-label>)
```

**Additional context**  
Add any other context or screenshots about the feature request here.



Discussion:
Additionally, would be great to also be able to update the status of the accordion (expanded or not) via the backend

Resolving patch:
diff --git a/gradio/layouts.py b/gradio/layouts.py
--- a/gradio/layouts.py
+++ b/gradio/layouts.py
@@ -365,10 +365,12 @@ def get_config(self):
     @staticmethod
     def update(
         open: Optional[bool] = None,
+        label: Optional[str] = None,
         visible: Optional[bool] = None,
     ):
         return {
             "visible": visible,
+            "label": label,
             "open": open,
             "__type__": "update",
         }


Test patch:
diff --git a/test/test_blocks.py b/test/test_blocks.py
--- a/test/test_blocks.py
+++ b/test/test_blocks.py
@@ -759,6 +759,36 @@ def test_with_generic_update(self):
             "__type__": "update",
         }
 
+    @pytest.mark.asyncio
+    async def test_accordion_update(self):
+        with gr.Blocks() as demo:
+            with gr.Accordion(label="Open for greeting", open=False) as accordion:
+                gr.Textbox("Hello!")
+            open_btn = gr.Button(label="Open Accordion")
+            close_btn = gr.Button(label="Close Accordion")
+            open_btn.click(
+                lambda: gr.Accordion.update(open=True, label="Open Accordion"),
+                inputs=None,
+                outputs=[accordion],
+            )
+            close_btn.click(
+                lambda: gr.Accordion.update(open=False, label="Closed Accordion"),
+                inputs=None,
+                outputs=[accordion],
+            )
+        result = await demo.process_api(fn_index=0, inputs=[None], request=None)
+        assert result["data"][0] == {
+            "open": True,
+            "label": "Open Accordion",
+            "__type__": "update",
+        }
+        result = await demo.process_api(fn_index=1, inputs=[None], request=None)
+        assert result["data"][0] == {
+            "open": False,
+            "label": "Closed Accordion",
+            "__type__": "update",
+        }
+
 
 class TestRender:
     def test_duplicate_error(self):
Repository: gradio-app/gradio

Issue:
Plotly plot too zoomed in
### Describe the bug

If you run the live_dashboard demo, the sine curve plot is too zoomed in.

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Reproduction

Run the `live_dashboard` demo in the repo


### Screenshot

![image](https://user-images.githubusercontent.com/41651716/199059495-d9d568a4-724a-47c4-9af1-e8c17ee928aa.png)


### Logs

```shell
-
```


### System Info

```shell
main
```


### Severity

annoying


Discussion:

Resolving patch:
diff --git a/demo/lineplot_component/run.py b/demo/lineplot_component/run.py
new file mode 100644
--- /dev/null
+++ b/demo/lineplot_component/run.py
@@ -0,0 +1,21 @@
+import gradio as gr
+from vega_datasets import data
+
+with gr.Blocks() as demo:
+    gr.LinePlot(
+        data.stocks(),
+        x="date",
+        y="price",
+        color="symbol",
+        color_legend_position="bottom",
+        title="Stock Prices",
+        tooltip=["date", "price", "symbol"],
+        height=300,
+        width=500,
+        show_label=False,
+    ).style(
+        container=False,
+    )
+
+if __name__ == "__main__":
+    demo.launch()
diff --git a/demo/live_dashboard/run.py b/demo/live_dashboard/run.py
--- a/demo/live_dashboard/run.py
+++ b/demo/live_dashboard/run.py
@@ -1,9 +1,10 @@
 import math
+
+import pandas as pd
+
 import gradio as gr
 import datetime
-import plotly.express as px
 import numpy as np
-import time
 
 
 def get_time():
@@ -17,9 +18,18 @@ def get_plot(period=1):
     global plot_end
     x = np.arange(plot_end - 2 * math.pi, plot_end, 0.02)
     y = np.sin(2 * math.pi * period * x)
-    fig = px.line(x=x, y=y)
+    update = gr.LinePlot.update(
+        value=pd.DataFrame({"x": x, "y": y}),
+        x="x",
+        y="y",
+        title="Plot (updates every second)",
+        width=600,
+        height=350,
+    )
     plot_end += 2 * math.pi
-    return fig
+    if plot_end > 1000:
+        plot_end = 2 * math.pi
+    return update
 
 
 with gr.Blocks() as demo:
@@ -33,7 +43,7 @@ def get_plot(period=1):
             period = gr.Slider(
                 label="Period of plot", value=1, minimum=0, maximum=10, step=1
             )
-            plot = gr.Plot(label="Plot (updates every second)")
+            plot = gr.LinePlot(show_label=False)
         with gr.Column():
             name = gr.Textbox(label="Enter your name")
             greeting = gr.Textbox(label="Greeting")
diff --git a/gradio/components.py b/gradio/components.py
--- a/gradio/components.py
+++ b/gradio/components.py
@@ -4081,6 +4081,7 @@ class ScatterPlot(Plot):
     Postprocessing: expects a pandas dataframe with the data to plot.
 
     Demos: native_plots
+    Guides: creating_a_dashboard_from_bigquery_data
     """
 
     def __init__(
@@ -4420,7 +4421,7 @@ class LinePlot(Plot):
     Preprocessing: this component does *not* accept input.
     Postprocessing: expects a pandas dataframe with the data to plot.
 
-    Demos: native_plots
+    Demos: native_plots, live_dashboard
     """
 
     def __init__(


Test patch:
Repository: gradio-app/gradio

Issue:
Replace underscores with dash in slugs (`_` -> `-`).

Review and edit guides to be easily scannable + parsable by readers (and google)
We need to ensure users can quickly find and consume the content they are interested in and to ensure that robots like it too. This means ensuring the purpose of the content is clear, ensuring that the content is concise, and easy to digest. 

- [ ] Add tldr style content at the top
- [ ] Ensure paragraphs are of an optimal length and that guides aren't too long, longer guides could be split into parts.
- [ ] Should we add some kind of CTAs in the content, follow on social media, contribute to the library, etc?

There are many articles like this but buffer talk about content + paragraph length later on. Buffer is a tool for publishing/ managing Social media channels etc so they should be relatively authoritative and the content seems to make sense. https://buffer.com/library/optimal-length-social-media/


Discussion:

Resolving patch:
diff --git a/website/homepage/src/docs/__init__.py b/website/homepage/src/docs/__init__.py
--- a/website/homepage/src/docs/__init__.py
+++ b/website/homepage/src/docs/__init__.py
@@ -148,6 +148,7 @@ def build(output_dir, jinja_env, gradio_wheel_url, gradio_version):
         version="main",
         gradio_version=gradio_version,
         gradio_wheel_url=gradio_wheel_url,
+        canonical_suffix="/main"
     )
     output_folder = os.path.join(output_dir, "docs")
     os.makedirs(output_folder)
@@ -167,7 +168,7 @@ def build_pip_template(version, jinja_env):
     docs_files = os.listdir("src/docs")
     template = jinja_env.get_template("docs/template.html")
     output = template.render(
-        docs=docs, find_cls=find_cls, version="pip", gradio_version=version, ordered_events=ordered_events
+        docs=docs, find_cls=find_cls, version="pip", gradio_version=version, canonical_suffix="", ordered_events=ordered_events
     )
     with open(f"src/docs/v{version}_template.html", "w+") as template_file:
         template_file.write(output)
diff --git a/website/homepage/src/guides/__init__.py b/website/homepage/src/guides/__init__.py
--- a/website/homepage/src/guides/__init__.py
+++ b/website/homepage/src/guides/__init__.py
@@ -32,7 +32,7 @@ def format_name(guide_name):
         guide_name = guide_name[guide_name.index("_") + 1 :]
     if guide_name.lower().endswith(".md"):
         guide_name = guide_name[:-3]
-    pretty_guide_name = " ".join([word[0].upper() + word[1:] for word in guide_name.split("_")])
+    pretty_guide_name = " ".join([word[0].upper() + word[1:] for word in guide_name.split("-")])
     return index, guide_name, pretty_guide_name
 
 


Test patch:
Repository: gradio-app/gradio

Issue:
Create a matrix of that shows which events are valid for each component 
In the discussion of #1892, @FarukOzderim and @pngwn think it would be a good idea to augment one of our guides with a matrix that shows the valid component/event combinations.

Would be cool to create this matrix as a gradio demo. 


Discussion:

Resolving patch:
diff --git a/website/homepage/src/docs/__init__.py b/website/homepage/src/docs/__init__.py
--- a/website/homepage/src/docs/__init__.py
+++ b/website/homepage/src/docs/__init__.py
@@ -53,19 +53,20 @@ def add_demos():
 
 add_demos()
 
+ordered_events = ["Change()", "Click()", "Submit()", "Edit()", "Clear()", "Play()", "Pause()", "Stream()", "Blur()", "Upload()"]
 
 def add_supported_events():
     for component in docs["component"]:
-        component["events"] = []
+        component["events-list"] = []
         event_listener_props = dir(EventListener)
         for listener in EventListener.__subclasses__():
             if not issubclass(component["class"], listener):
                 continue
             for prop in dir(listener):
                 if prop not in event_listener_props:
-                    component["events"].append(prop + "()")
-        if component["events"]:
-            component["events"] = ", ".join(component["events"])
+                    component["events-list"].append(prop + "()")
+        if component["events-list"]:
+            component["events"] = ", ".join(component["events-list"])
 
 
 add_supported_events()
@@ -142,6 +143,7 @@ def build(output_dir, jinja_env, gradio_wheel_url, gradio_version):
     template = jinja_env.get_template("docs/template.html")
     output = template.render(
         docs=docs,
+        ordered_events=ordered_events,
         find_cls=find_cls,
         version="main",
         gradio_version=gradio_version,
@@ -165,7 +167,7 @@ def build_pip_template(version, jinja_env):
     docs_files = os.listdir("src/docs")
     template = jinja_env.get_template("docs/template.html")
     output = template.render(
-        docs=docs, find_cls=find_cls, version="pip", gradio_version=version
+        docs=docs, find_cls=find_cls, version="pip", gradio_version=version, ordered_events=ordered_events
     )
     with open(f"src/docs/v{version}_template.html", "w+") as template_file:
         template_file.write(output)


Test patch: