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

Issue:
restore BdbQuit_excepthook
It is used by ipdb


Discussion:

Resolving patch:
diff --git a/IPython/core/debugger.py b/IPython/core/debugger.py
--- a/IPython/core/debugger.py
+++ b/IPython/core/debugger.py
@@ -149,6 +149,17 @@ def make_arrow(pad):
     return ''
 
 
+def BdbQuit_excepthook(et, ev, tb, excepthook=None):
+    """Exception hook which handles `BdbQuit` exceptions.
+
+    All other exceptions are processed using the `excepthook`
+    parameter.
+    """
+    raise ValueError(
+        "`BdbQuit_excepthook` is deprecated since version 5.1. It is still arround only because it is still imported by ipdb.",
+    )
+
+
 RGX_EXTRA_INDENT = re.compile(r'(?<=\n)\s+')
 
 


Test patch:
Repository: ipython/ipython

Issue:
matplotlib plots not showing when using "ipython --pylab"
In versions of ipython up to 8.21.0, when invoked with `ipython --pylab`, matplotlib plots are displayed to the screen automatically, and without blocking. In later versions (8.22.* and 8.23.0), they are not, and can only be displayed using `plt.show(block=True)`.

Here are steps to reproduce. This uses `pip` installation on Ubuntu for a simple example (where `/usr/bin/python3` is python 3.10.12), although I have also observed the issue in conda environments on both Ubuntu and CentOS, based on python 3.11 and 3.12.

----

**1) Working example -- with ipython 8.21.0:**
```
$  python3 -m venv /tmp/myenv
$  . /tmp/myenv/bin/activate
(myenv) $  pip install pyqt5 numpy matplotlib ipython==8.21.0
(myenv) $  ipython --pylab
In [1]:  plt.plot(np.arange(10)**2)
```
A plot appears on the screen automatically (without needing to call `plt.show` explicitly) -- and in non-blocking mode, so you can continue to type at the ipython `In [2]:` prompt.

<details>
   <summary>Screenshot of plot window</summary>
   <img src="https://github.com/ipython/ipython/assets/5577313/7447e9b0-fad1-4392-9ee5-419967454eb7">
</details>

----

**2) Broken example with ipython 8.23.0:**
- use the same commands as above, except `ipython==8.23.0`

In this case, a matplotlib window is opened, but it is black (with no plot). 

<details>
   <summary>Screenshot of plot window</summary>
   <img src="https://github.com/ipython/ipython/assets/5577313/0a5f3603-3663-4a67-9fb6-37362ed66458">
</details>

If `plt.show()` or `plt.show(block=False)` is typed, neither of these succeed in displaying the plot -- and if `plt.show(block=False)` is typed then not long afterwards a message from GNOME appears saying "matplotlib is not responding".  The plot is only shown if `plt.show(block=True)` is typed, in which case, it blocks as requested (so no futher prompt is issued until the plot is closed).

----

In these examples, matplotlib was version 3.8.4, although further experimentation shows that it does not seem to depend on the matplotlib version.

Please can you restore the behaviour that is obtained in earlier versions.


Discussion:
This might be due to #14330. I will investigate.

Resolving patch:
diff --git a/IPython/core/interactiveshell.py b/IPython/core/interactiveshell.py
--- a/IPython/core/interactiveshell.py
+++ b/IPython/core/interactiveshell.py
@@ -3654,6 +3654,13 @@ def enable_matplotlib(self, gui=None):
             make sense in all contexts, for example a terminal ipython can't
             display figures inline.
         """
+        from .pylabtools import _matplotlib_manages_backends
+
+        if not _matplotlib_manages_backends() and gui in (None, "auto"):
+            # Early import of backend_inline required for its side effect of
+            # calling _enable_matplotlib_integration()
+            import matplotlib_inline.backend_inline
+
         from IPython.core import pylabtools as pt
         gui, backend = pt.find_gui_and_backend(gui, self.pylab_gui_select)
 


Test patch:
Repository: ipython/ipython

Issue:
Default value in docs for TerminalInteractiveShell.simple_prompt is incorrect
The default value for `TerminalInteractiveShell.simple_prompt` per the [docs](https://ipython.readthedocs.io/en/stable/config/options/terminal.html#configtrait-TerminalInteractiveShell.simple_prompt) is `True` yet when one produces the default profile `ipython_config.py` the comments imply the default value is `False`.

In addition, the statement "and emacs inferior-shell integration through elpy." should be re-worded to "and emacs inferior-python integration." as "inferior" here in Emacs parlance just means the process is a subprocess but the process here is the ipython/python interpreter and it is also *not just* applicable through Elpy as it can be used ~~within~~ without Elpy. The 'inferior-shell' refers to the subprocess when using the Emacs built-in shell (M-x shell).

I would submit a PR but it is unclear to me if I would have to make changes in [all these places](https://github.com/search?q=repo%3Aipython%2Fipython%20TerminalInteractiveShell.simple_prompt&type=code).

Edit: changed within for without


Discussion:

Resolving patch:
diff --git a/IPython/terminal/interactiveshell.py b/IPython/terminal/interactiveshell.py
--- a/IPython/terminal/interactiveshell.py
+++ b/IPython/terminal/interactiveshell.py
@@ -225,11 +225,14 @@ class TerminalInteractiveShell(InteractiveShell):
         help="""Use `raw_input` for the REPL, without completion and prompt colors.
 
             Useful when controlling IPython as a subprocess, and piping STDIN/OUT/ERR. Known usage are:
-            IPython own testing machinery, and emacs inferior-shell integration through elpy.
+            IPython own testing machinery, and emacs inferior-python integration through elpy.
 
             This mode default to `True` if the `IPY_TEST_SIMPLE_PROMPT`
-            environment variable is set, or the current terminal is not a tty."""
-            ).tag(config=True)
+            environment variable is set, or the current terminal is not a tty.
+            Thus the Default value reported in --help-all, or config will often
+            be incorrectly reported.
+            """,
+    ).tag(config=True)
 
     @property
     def debugger_cls(self):


Test patch:
Repository: Princeton-CDH/geniza

Issue:
set up js & css builds
- [x] set up minification
- [x] set up sourcemaps

set up compression
 handle via nginx; see #262 


Discussion:

Resolving patch:
diff --git a/geniza/apps.py b/geniza/apps.py
--- a/geniza/apps.py
+++ b/geniza/apps.py
@@ -1,5 +1,10 @@
 from django.contrib.admin.apps import AdminConfig
+from django.contrib.staticfiles.apps import StaticFilesConfig
 
 
 class GenizaAdminConfig(AdminConfig):
     default_site = "geniza.admin.GenizaAdminSite"
+
+class GenizaStaticFilesConfig(StaticFilesConfig):
+    # don't collect frontend source files when running collectstatic
+    ignore_patterns = StaticFilesConfig.ignore_patterns + ["*.esm.js", "*.scss"]
\ No newline at end of file
diff --git a/geniza/settings/components/base.py b/geniza/settings/components/base.py
--- a/geniza/settings/components/base.py
+++ b/geniza/settings/components/base.py
@@ -33,7 +33,7 @@
     "django.contrib.humanize",
     "django.contrib.sessions",
     "django.contrib.messages",
-    "django.contrib.staticfiles",
+    "geniza.apps.GenizaStaticFilesConfig",
     "django.contrib.postgres",
     "django.contrib.sites",
     "django_cas_ng",
@@ -44,6 +44,7 @@
     "adminsortable2",
     "admin_log_entries",
     "parasolr",
+    "webpack_loader",
     "geniza.common",
     "geniza.corpus.apps.CorpusAppConfig",
     "geniza.footnotes.apps.FootnotesConfig",
@@ -167,11 +168,22 @@
 
 STATIC_URL = "/static/"
 
-# disable until this exists, since otherwise collectstatic fails
 STATICFILES_DIRS = [
     BASE_DIR / "sitemedia",
 ]
 
+# Production webpack config: cache immediately upon loading the manifest
+WEBPACK_LOADER = {
+    "DEFAULT": {
+        "CACHE": True,
+        "BUNDLE_DIR_NAME": "sitemedia/bundles/",  # must end with slash
+        "STATS_FILE": BASE_DIR / "sitemedia" / "webpack-stats.json",
+        "POLL_INTERVAL": 0.1,
+        "TIMEOUT": None,
+        "IGNORE": [r".+\.hot-update.js", r".+\.map"],
+    }
+}
+
 # pucas configuration that is not expected to change across deploys
 # and does not reference local server configurations or fields
 PUCAS_LDAP = {


Test patch:
diff --git a/.github/workflows/unit_tests.yml b/.github/workflows/unit_tests.yml
--- a/.github/workflows/unit_tests.yml
+++ b/.github/workflows/unit_tests.yml
@@ -73,6 +73,9 @@ jobs:
       - name: Setup local_settings.py
         run: python -c "import uuid; print('SECRET_KEY = \'%s\'' % uuid.uuid4())" >> geniza/settings/local_settings.py
 
+      - name: Setup dummy webpack manifest
+        run: cp sitemedia/webpack-stats-ci.json sitemedia/webpack-stats.json
+
       - name: Run pytest
         run: py.test --cov=./ --cov-report=xml
Repository: Princeton-CDH/geniza

Issue:
As a front-end user I want to see the PGP logo on the site
here are links to the temporary logo approved till we finish revising the permanent one: 

- [for desktop light mode](https://www.figma.com/file/HpGBOZi9lO8B3nCAx3d4Fj/Princeton-Geniza-(Project-team)?node-id=2300%3A16460)
- [for mobile light mode](https://www.figma.com/file/HpGBOZi9lO8B3nCAx3d4Fj/Princeton-Geniza-(Project-team)?node-id=2300%3A16461)
- [for desktop dark mode](https://www.figma.com/file/HpGBOZi9lO8B3nCAx3d4Fj/Princeton-Geniza-(Project-team)?node-id=2300%3A16466)
- [for mobile dark mode](https://www.figma.com/file/HpGBOZi9lO8B3nCAx3d4Fj/Princeton-Geniza-(Project-team)?node-id=2301%3A16480)



Discussion:

Resolving patch:
diff --git a/geniza/pages/management/commands/bootstrap_content.py b/geniza/pages/management/commands/bootstrap_content.py
--- a/geniza/pages/management/commands/bootstrap_content.py
+++ b/geniza/pages/management/commands/bootstrap_content.py
@@ -136,7 +136,11 @@ def generate_test_content_page(self):
             description="Example page",
             slug="content",
             body=content.replace(  # get static URLs for test images
-                "test-image-fragment.jpg", static("test-image-fragment.jpg")
-            ).replace("test-image-tagnetwork.png", static("test-image-tagnetwork.png")),
+                "test-image-fragment.jpg",
+                static("img/fixtures/test-image-fragment.jpg"),
+            ).replace(
+                "test-image-tagnetwork.png",
+                static("img/fixtures/test-image-tagnetwork.png"),
+            ),
             live=True,
         )
diff --git a/geniza/pages/models.py b/geniza/pages/models.py
--- a/geniza/pages/models.py
+++ b/geniza/pages/models.py
@@ -39,6 +39,11 @@ class HomePage(Page):
     class Meta:
         verbose_name = "homepage"
 
+    def get_context(self, request):
+        context = super(HomePage, self).get_context(request)
+        context["page_type"] = "homepage"
+        return context
+
 
 class ContainerPage(Page):
     """An empty :class:`Page` type that has :class:`ContentPage` instances


Test patch:
diff --git a/geniza/pages/tests/test_pages_models.py b/geniza/pages/tests/test_pages_models.py
--- a/geniza/pages/tests/test_pages_models.py
+++ b/geniza/pages/tests/test_pages_models.py
@@ -7,6 +7,13 @@
 from geniza.pages.models import ContainerPage, ContentPage, HomePage
 
 
+class TestHomePage:
+    @pytest.mark.django_db
+    def test_get_context(self):
+        home_page = HomePage()
+        assert home_page.get_context(HttpRequest())["page_type"] == "homepage"
+
+
 class TestContentPage:
     @pytest.mark.django_db
     def test_get_context(self):
Repository: Princeton-CDH/geniza

Issue:
documents without images can't be edited in django admin (v4.8)
**Describe the bug**
Documents without images can't be edited in django admin. Django complains about an error, but no field is highlighted.

**Additional information**
 - Site version v4.8



Discussion:

Resolving patch:
diff --git a/geniza/corpus/migrations/0035_document_image_order_override.py b/geniza/corpus/migrations/0035_document_image_order_override.py
--- a/geniza/corpus/migrations/0035_document_image_order_override.py
+++ b/geniza/corpus/migrations/0035_document_image_order_override.py
@@ -19,6 +19,7 @@ class Migration(migrations.Migration):
                 null=True,
                 size=None,
                 verbose_name="Image Order",
+                blank=True,
             ),
         ),
     ]
diff --git a/geniza/corpus/models.py b/geniza/corpus/models.py
--- a/geniza/corpus/models.py
+++ b/geniza/corpus/models.py
@@ -458,7 +458,7 @@ class Document(ModelIndexable, DocumentDateMixin):
         Fragment, through="TextBlock", related_name="documents"
     )
     image_order_override = ArrayField(
-        models.URLField(), null=True, verbose_name="Image Order"
+        models.URLField(), null=True, verbose_name="Image Order", blank=True
     )
     shelfmark_override = models.CharField(
         "Shelfmark Override",


Test patch:
Repository: librosa/librosa

Issue:
Update show_versions to match current dependencies
**Describe the bug**

Looks like we forgot to revise the list of modules checked by `show_versions()` in the 0.9.0 release.
This isn't a major problem, but we should fix it for 0.9.2 and keep it as part of the release audit sequence going forward.

In general, `show_versions()` should track the dependencies listed in setup.cfg: https://github.com/librosa/librosa/blob/ef482b824c609222abb265357f7a79b11d174dd2/setup.cfg#L45-L84
Update show_versions to match current dependencies
**Describe the bug**

Looks like we forgot to revise the list of modules checked by `show_versions()` in the 0.9.0 release.
This isn't a major problem, but we should fix it for 0.9.2 and keep it as part of the release audit sequence going forward.

In general, `show_versions()` should track the dependencies listed in setup.cfg: https://github.com/librosa/librosa/blob/ef482b824c609222abb265357f7a79b11d174dd2/setup.cfg#L45-L84


Discussion:
Relatedly, once our minimum python version bumps to 3.8, we should pull version data from importlib metadata intead of `__version__` attributes.
Relatedly, once our minimum python version bumps to 3.8, we should pull version data from importlib metadata intead of `__version__` attributes.

Resolving patch:
diff --git a/librosa/version.py b/librosa/version.py
--- a/librosa/version.py
+++ b/librosa/version.py
@@ -38,18 +38,26 @@ def show_versions():
         "soundfile",
         "resampy",
         "numba",
+        "pooch",
+        "packaging"
     ]
 
     extra_deps = [
         "numpydoc",
         "sphinx",
         "sphinx_rtd_theme",
-        "sphinxcontrib.versioning",
-        "sphinx-gallery",
+        "sphinx_multiversion",
+        "sphinx_gallery",
+        "mir_eval",
+        "ipython",
+        "sphinxcontrib-svg2pdfconverter",
         "pytest",
         "pytest-mpl",
         "pytest-cov",
         "matplotlib",
+        "samplerate",
+        "soxr",
+        "contextlib2",
         "presets",
     ]
 


Test patch:
Repository: librosa/librosa

Issue:
note_to_midi docstring is confusing
**Describe the bug**

The `note_to_midi` function has a parameter `round_midi` which is documented as follows:


> round_midi : bool
>        If True, allow for fractional midi notes
>        Otherwise, round cent deviations to the nearest note


The relevant source code is:
https://github.com/librosa/librosa/blob/1b076bbfb27e69587e3fb55fc587beec60f28c7b/librosa/core/convert.py#L566-L567

The documentation should be corrected:

> If `True`, then midi numbers are rounded to the nearest integer.
> If `False, then midi numbers may be fractional.


Discussion:

Resolving patch:
diff --git a/librosa/core/convert.py b/librosa/core/convert.py
--- a/librosa/core/convert.py
+++ b/librosa/core/convert.py
@@ -475,8 +475,8 @@ def note_to_midi(note, *, round_midi=True):
     note : str or iterable of str
         One or more note names.
     round_midi : bool
-        - If ``True``, allow for fractional midi notes
-        - Otherwise, round cent deviations to the nearest note
+        - If ``True``, midi numbers are rounded to the nearest integer.
+        - If ``False``, allow fractional midi numbers.
 
     Returns
     -------


Test patch:
Repository: librosa/librosa

Issue:
remove "hanning" window
**Describe the bug**

scipy 1.9 removed the `hanning` window function.  We never use this directly, but do support it as an option in a few places.

I think it's fine to leave support in, but we'll need to remove hanning from the tests to keep things passing cleanly.


Discussion:

Resolving patch:
diff --git a/librosa/filters.py b/librosa/filters.py
--- a/librosa/filters.py
+++ b/librosa/filters.py
@@ -105,7 +105,6 @@
     "hamming": 1.3629455320350348,
     "han": 1.50018310546875,
     "hann": 1.50018310546875,
-    "hanning": 1.50018310546875,
     "nut": 1.9763500280946082,
     "nutl": 1.9763500280946082,
     "nuttall": 1.9763500280946082,


Test patch:
diff --git a/tests/test_filters.py b/tests/test_filters.py
--- a/tests/test_filters.py
+++ b/tests/test_filters.py
@@ -226,7 +226,6 @@ def test_chroma_issue1295(freq):
         "flattop",
         "hamming",
         "hann",
-        "hanning",
         "nuttall",
         "parzen",
         "triang",
Repository: librosa/librosa

Issue:
Bypass automatic colormap selection
**Is your feature request related to a problem? Please describe.**

`librosa.display.specshow` allows the user to set the colormap for the rendered image in the usual way, eg `cmap='magma'`.  If no colormap is supplied, the helper function `librosa.display.cmap` tries to guess an appropriate colormap based on the contents of the data to be drawn (eg, sequential, binary, or diverging).

As noted in #738 , it would sometimes be helpful to be able to disable this behavior and fall back on whatever the default colormap of the matplotlib environment is.  This is especially handy when using a style / context manager to handle these decisions, where it may not be explicit or obvious to the user what colormap is being chosen.

At present, the best workaround here is to explicitly set the cmap, but that leads to inflexible code that does not adapt to the matplotlib environment.


**Describe the solution you'd like**

The current logic for cmap inference is here:
https://github.com/librosa/librosa/blob/9f46e987488a98ad383aef2875e95ae970c057e5/librosa/display.py#L868

I propose to replace this by the following:

```python
if 'cmap' in kwargs and kwargs['cmap'] is None:
    # Remove cmap from the pcolormesh kwargs
    kwargs.pop('cmap')
else:
    # No cmap is specified, so guess one from the data properties
    kwargs.setdefault("cmap", cmap(data))
```

This would allow for `librosa.display.specshow(..., cmap=None)` to always use the "default" colormap.  If `cmap` is not provided as a kwarg, it is inferred from `data` just as before.  If `cmap` is otherwise not None (e.g., a string or color map object), it is passed through as is to `pcolormesh`.



**Describe alternatives you've considered**

@lostanlen and I discussed various options offline, including adding a new parameter to disable cmap selection, or using a token value for `cmap` to indicate the intended behavior.  At the end of the discussion, we agreed that `None` does the job well here with minimal added complexity.





Discussion:
Update from the scipy2022 sprint: it turns out this already works with no code modification necessary!  Passing `cmap=None` selects the default colormap from the style already.  All we need to do here is document the functionality.
~~I'll probably roll this doc update in with a PR for #1422.~~ **EDIT**: scratch that - since #1422 is blocked, we can just handle this directly.

Resolving patch:
diff --git a/librosa/display.py b/librosa/display.py
--- a/librosa/display.py
+++ b/librosa/display.py
@@ -909,6 +909,9 @@ def specshow(
             - ``shading='auto'``
             - ``edgecolors='None'``
 
+        The ``cmap`` option if not provided, is inferred from data automatically.
+        Set ``cmap=None`` to use matplotlib's default colormap.
+
     Returns
     -------
     colormesh : `matplotlib.collections.QuadMesh`


Test patch:
Repository: librosa/librosa

Issue:
Running changelog, updated contributor guidelines
**Is your feature request related to a problem? Please describe.**

Historically, I've always managed release notes / changelog updates as one of the last steps in a release.  This was basically fine when the documentation site was also only updated on release.  However, now that we have automatic doc builds for every merge to main, I think we should try to keep this up to date at all times.

**Describe the solution you'd like**

1. We should revise the contributing guidelines to include instructions for updating the release notes.
2. We should fill in the changelog to date for the 0.10 cycle.

Retire the repet-sim example?
Our doc site has a [reimplementation](https://librosa.org/doc/latest/auto_examples/plot_vocal_separation.html#sphx-glr-auto-examples-plot-vocal-separation-py) of the repet-sim method for foreground/background separation, which gives a nice demo of a few features:

- audio source separation and resynthesis
- non-local means
- soft masking

Repet-sim is a pretty old method at this point, but its foreground (vocals) estimates are quite glitchy in general and very far from what's possible via more modern methods (open-umx, spleeter, demucs, etc).  So while it's fine for demonstrative purposes, I worry that it misleads novice users about how to do vocal separation generally.  As a result, I think we should retire this example from the gallery in the next major release (0.10).

If we do this, should we consider replacing it with something else to demonstrate some kind of source separation (eg nmf)?  The docstring examples go pretty far with this, but I think there's added value to having a self-contained notebook with playable audio.


Discussion:

It turns out that people actually do use this example (!) - so i'm not sure if we can remove it entirely.

At the very least, we can update the example to provide links to more modern source separators.

Resolving patch:
diff --git a/docs/examples/plot_vocal_separation.py b/docs/examples/plot_vocal_separation.py
--- a/docs/examples/plot_vocal_separation.py
+++ b/docs/examples/plot_vocal_separation.py
@@ -7,6 +7,13 @@
 This notebook demonstrates a simple technique for separating vocals (and
 other sporadic foreground signals) from accompanying instrumentation.
 
+.. warning::
+    This example is primarily of historical interest, and we do not recommend
+    this as a competitive method for vocal source separation.
+    For a more recent treatment of vocal and music source separation, please
+    refer to `Open Source Tools & Data for Music Source Separation <https://source-separation.github.io/tutorial/landing.html>`_
+    (Manilow, Seetharaman, and Salamon 2020).
+
 This is based on the "REPET-SIM" method of `Rafii and Pardo, 2012
 <http://www.cs.northwestern.edu/~zra446/doc/Rafii-Pardo%20-%20Music-Voice%20Separation%20using%20the%20Similarity%20Matrix%20-%20ISMIR%202012.pdf>`_, but includes a couple of modifications and extensions:
 


Test patch: