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

Issue:
Interpolated charts (Curve, Area, etc) plot data in the provided order, but decimate unsorts data
#### ALL software version info
| Library | Version |
| -- | -- |
| python | 3.9.13 |
| holoviews | 1.15.0 |
| bokeh | 2.4.3 |
| pandas | 1.4.4 |
| numpy | 1.23.3 |

#### Description of expected behavior and the observed behavior
I should be able to decimate Curve/Area charts the same way I can decimate scatter charts.  Decimating interpolated charts currently results in garbled output.

#### Complete, minimal, self-contained example code that reproduces the issue

```python
import numpy as np
import pandas as pd
import holoviews as hv

hv.extension('bokeh')
x = np.linspace(0, 10, 100)
y1 = np.sin(x)
y2 = np.cos(x)

table = hv.Table((x, y1, y2), 'x', ['y1', 'y2'])
hv.Area(table)  # See Figure 1

---------------------------

from holoviews.operation import decimate
decimate(hv.Area(table), max_samples = 50)  # See Figure 2
```

#### Screenshots or screencasts of the bug in action

Figure 1
![image](https://user-images.githubusercontent.com/1297262/191106034-3469033e-742c-4b9f-9c35-9f05e2c57d20.png)

Figure 2
![image](https://user-images.githubusercontent.com/1297262/191106068-39bc8430-cc11-4ece-a41d-f1d0ac00b164.png)



Discussion:
`np.random.RandomState.choice` returns indices in random order.  Adding `np.sort` results in proper operation.
https://github.com/holoviz/holoviews/blob/d8b83d130b0405aa4c4aeef2941bf0698688f328/holoviews/operation/element.py#L912

Resolving patch:
diff --git a/holoviews/operation/element.py b/holoviews/operation/element.py
--- a/holoviews/operation/element.py
+++ b/holoviews/operation/element.py
@@ -909,7 +909,8 @@ def _process_layer(self, element, key=None):
 
         if len(sliced) > self.p.max_samples:
             prng = np.random.RandomState(self.p.random_seed)
-            return sliced.iloc[prng.choice(len(sliced), self.p.max_samples, False)]
+            choice = prng.choice(len(sliced), self.p.max_samples, False)
+            return sliced.iloc[np.sort(choice)]
         return sliced
 
     def _process(self, element, key=None):


Test patch:
Repository: holoviz/holoviews

Issue:
holoviews 1.15.1 doesn't work in Jupyterlite
#### ALL software version info

holoviews: 1.15.1
jupyterlite: Version 0.1.0-beta.13

#### Description of expected behavior and the observed behavior

```python
import piplite
await piplite.install('holoviews==1.15.1')

import holoviews as hv
hv.extension('bokeh')

hv.Curve([1, 2, 3])
```

raise following exception:

```
ImportError: cannot import name 'document' from 'js' (unknown location)
```

Here is the reason:

https://github.com/jupyterlite/pyodide-kernel/issues/94


Discussion:

Resolving patch:
diff --git a/holoviews/__init__.py b/holoviews/__init__.py
--- a/holoviews/__init__.py
+++ b/holoviews/__init__.py
@@ -120,7 +120,12 @@ def __call__(self, *args, **opts): # noqa (dummy signature)
             raise Exception("IPython notebook not available: use hv.extension instead.")
 
 if '_pyodide' in sys.modules:
-    from .pyodide import pyodide_extension as extension # noqa (API import)
+    from .pyodide import pyodide_extension, in_jupyterlite
+    # The notebook_extension is needed inside jupyterlite,
+    # so the override is only done if we are not inside jupyterlite.
+    if not in_jupyterlite():
+        extension = pyodide_extension
+    del pyodide_extension, in_jupyterlite
 
 # A single holoviews.rc file may be executed if found.
 for rcfile in [os.environ.get("HOLOVIEWSRC", ''),
diff --git a/holoviews/pyodide.py b/holoviews/pyodide.py
--- a/holoviews/pyodide.py
+++ b/holoviews/pyodide.py
@@ -74,6 +74,10 @@ def render_png(element):
 def render_svg(element):
     return render_image(element, 'svg')
 
+def in_jupyterlite():
+    import js
+    return hasattr(js, "_JUPYTERLAB")
+
 #-----------------------------------------------------------------------------
 # Public API
 #-----------------------------------------------------------------------------


Test patch:
Repository: holoviz/holoviews

Issue:
Listing colormap records sometimes raises TypeError
Calling `holoviews.plotting.list_cmaps` with `records=True` sometimes raises `TypeError`:

``` python
In [1]: from holoviews.plotting import list_cmaps

In [2]: cmaps = list_cmaps(records=True)
Traceback (most recent call last):
  Cell In [2], line 1
    cmaps = list_cmaps(records=True)
  File ...\holoviews\plotting\util.py:794 in list_cmaps
    return list(unique_iterator(python2sort(matches,
  File ...\holoviews\core\util.py:1128 in unique_iterator
    for item in seq:
  File ...\holoviews\core\util.py:1211 in <genexpr>
    return itertools.chain.from_iterable(sorted(group, key=key) for group in groups)
TypeError: '<' not supported between instances of 'str' and 'NoneType'
```

(I've abbreviated the traceback's paths.)

The error arises when `sorted` tries to order `None` and a `str`, which occurs because the sort key contains `None` from the `bg` or `source` elements of some `CMapInfo` objects.

For some (but few, in my tests) runs of *Python*, the call succeeds, presumably because the lower-level `_list_cmaps` function returns the colormap records in such an order that `sorted` needs to compare only `str` elements of the sort key.

The version of *holoviews* is v1.15.3a2.



Discussion:

Resolving patch:
diff --git a/holoviews/plotting/util.py b/holoviews/plotting/util.py
--- a/holoviews/plotting/util.py
+++ b/holoviews/plotting/util.py
@@ -19,7 +19,7 @@
 from ..core.spaces import get_nested_streams
 from ..core.util import (
     match_spec, wrap_tuple, get_overlay_spec, unique_iterator,
-    closest_match, is_number, isfinite, python2sort, disable_constant,
+    closest_match, is_number, isfinite, disable_constant,
     arraylike_types
 )
 from ..element import Points
@@ -791,8 +791,10 @@ def list_cmaps(provider=None, records=False, name=None, category=None, source=No
 
     # Return results sorted by category if category information is provided
     if records:
-        return list(unique_iterator(python2sort(matches,
-                    key=lambda r: (r.category.split(" ")[-1],r.bg,r.name.lower(),r.provider,r.source))))
+        return sorted(
+            matches,
+            key=lambda r: (r.category.split(" ")[-1], r.bg or "", r.name.lower(), r.provider, r.source or "")
+        )
     else:
         return list(unique_iterator(sorted([rec.name for rec in matches], key=lambda n:n.lower())))
 


Test patch:
Repository: holoviz/holoviews

Issue:
external matplotlib colormaps cannot be found
#### ALL software version info
```
holoviews: 1.15.1
matplotlib: 3.6.0
cmocean: 2.0
```

#### Description of expected behavior and the observed behavior
I've been trying to use the colormaps provided by `cmocean` in a new environment, and got an error stating that the colormap I requested couldn't be found.

It seems that the newest version of `matplotlib` removed `matplotlib.cm._cmap_registry`, which was used here:
https://github.com/holoviz/holoviews/blob/f051576deb8d21ec845a71cfd6f334af5362d64b/holoviews/plotting/util.py#L693-L696

Making `_cmap_registry` an alias of `_colormaps` allows me to use the external colormaps:
```python
import matplotlib.cm as cm

cm._cmap_registry = cm._colormaps
```

However, I don't think that's a long-term solution since both are internal API, so maybe use `list(matplotlib.colormaps)` instead?

cc @tacaswell, @QuLogic

#### Complete, minimal, self-contained example code that reproduces the issue

```python
import cmocean
from holoviews.plotting import list_cmaps

list_cmaps(provider="matplotlib")
```


Discussion:
That is a private attribute so we reserve the right to change it with no warning on the Matplotlib side. 

The suggestion to use `matplotlib.colormaps` is correct (but will need to be version gated depending on how far back holoviews wants to support.

Resolving patch:
diff --git a/holoviews/plotting/util.py b/holoviews/plotting/util.py
--- a/holoviews/plotting/util.py
+++ b/holoviews/plotting/util.py
@@ -699,8 +699,14 @@ def info(provider,names):
 
     if 'matplotlib' in provider:
         try:
+            import matplotlib as mpl
             from matplotlib import cm
-            if hasattr(cm, '_cmap_registry'):
+
+            # matplotlib.colormaps has been introduced in matplotlib 3.5
+            # matplotlib.cm._cmap_registry was removed in matplotlib 3.6
+            if hasattr(mpl, "colormaps"):
+                mpl_cmaps = list(mpl.colormaps)
+            elif hasattr(cm, '_cmap_registry'):
                 mpl_cmaps = list(cm._cmap_registry)
             else:
                 mpl_cmaps = list(cm.cmaps_listed)+list(cm.datad)


Test patch:
Repository: holoviz/holoviews

Issue:
Categorical datashade does not display legend if using GPU
This was originally reported on datashader as https://github.com/holoviz/datashader/issues/1178. There were actually 2 bugs, one in datashader and one in holoviews. The datashader bug is fixed in https://github.com/holoviz/datashader/pull/1179 so that it no longer raises an error. To reproduce the behaviour here it will be necessary to use a datashader branch containing that fix.

Minimal reproducer here:
```python
import datashader as ds
import holoviews as hv
from holoviews.operation.datashader import datashade
import pandas as pd
hv.extension('bokeh')

df = pd.DataFrame(dict(
    x    = [0.0, 1.0, 0.0, 1.0, 0.0],
    y    = [0.0, 1.0, 1.0, 0.0, 0.5],
    cat  = ['a', 'b', 'a', 'b', 'a'],
))
df.cat = df.cat.astype("category")

if 1:
    import cudf
    df = cudf.DataFrame.from_pandas(df)

curve = hv.Curve(df)
datashade(curve, aggregator=ds.by("cat"))
```
If you run this code without the `cupy` block and then with the `cupy` block, these are the 2 outputs you see:
![cpu](https://user-images.githubusercontent.com/580326/218082319-bedffbfd-ca79-4264-bd77-ff06948103f9.png) ![gpu](https://user-images.githubusercontent.com/580326/218082342-9ba2e4ee-2e21-43e0-864a-b8ff2cb3476a.png)

So a legend is displayed if you are using `numpy` but not if using `cupy`. I presume the problem is similar to the datashader problem in the area of `cupy` array conversions which are mostly very similar to `numpy` but not always.


Discussion:

Resolving patch:
diff --git a/holoviews/plotting/util.py b/holoviews/plotting/util.py
--- a/holoviews/plotting/util.py
+++ b/holoviews/plotting/util.py
@@ -1330,7 +1330,11 @@ def _process(self, element, key=None):
             return
         column = agg.column
         if hasattr(hvds.data, 'dtypes'):
-            cats = list(hvds.data.dtypes[column].categories)
+            try:
+                cats = list(hvds.data.dtypes[column].categories)
+            except TypeError:
+                # Issue #5619, cudf.core.index.StringIndex is not iterable.
+                cats = list(hvds.data.dtypes[column].categories.to_pandas())
             if cats == ['__UNKNOWN_CATEGORIES__']:
                 cats = list(hvds.data[column].cat.as_known().categories)
         else:


Test patch:
Repository: holoviz/holoviews

Issue:
Confusing warning for disabled toolbar
For HoloViews 1.15.4 and at least some previous versions, a bogus warning is issued for a disabled toolbar:

```python
import holoviews as hv
hv.extension("bokeh")

color_key = {'w':'aqua',  'b':'lime' }
races     = {'w':'White', 'b':'Black'}

color_points = hv.NdOverlay({races[k]: hv.Points([-80,40]).opts(color=v, size=0) for k, v in color_key.items()})
color_points.opts(clone=True, xaxis=None, yaxis=None, toolbar='disable', height=190, width=135)
```
<img width="1014" alt="image" src="https://user-images.githubusercontent.com/1695496/233612217-7efea4ae-0a24-4786-a228-021d8cdaca72.png">

Here the toolbar is disabled, so HoloVIews shouldn't be trying to make any tools default, or should otherwise be suppressing this warning.


Discussion:

Resolving patch:
diff --git a/holoviews/plotting/bokeh/element.py b/holoviews/plotting/bokeh/element.py
--- a/holoviews/plotting/bokeh/element.py
+++ b/holoviews/plotting/bokeh/element.py
@@ -569,7 +569,7 @@ def _plot_properties(self, key, element):
 
     def _set_active_tools(self, plot):
         "Activates the list of active tools"
-        if plot is None:
+        if plot is None or self.toolbar == "disable":
             return
 
         if self.active_tools is None:


Test patch:
Repository: holoviz/holoviews

Issue:
Reverse order of dash imports
The imports for the dash libraries should be reversed here: https://github.com/holoviz/holoviews/blob/114aff1cf3210dafbfc044262b45be5d74691ecf/holoviews/plotting/plotly/dash.py#L22-L27

If you import the new style first (`from dash import html, dcc`), it won't show the warning message for importing the old libraries (`import dash_html_components`).


Discussion:
A PR to fix this will be greatly appreciated. 

Resolving patch:
diff --git a/holoviews/plotting/plotly/dash.py b/holoviews/plotting/plotly/dash.py
--- a/holoviews/plotting/plotly/dash.py
+++ b/holoviews/plotting/plotly/dash.py
@@ -21,10 +21,10 @@
 
 # Dash imports
 try:
+    from dash import dcc, html
+except ImportError:
     import dash_core_components as dcc
     import dash_html_components as html
-except ImportError:
-    from dash import dcc, html
 from dash import callback_context
 from dash.dependencies import Output, Input, State
 


Test patch:
Repository: holoviz/holoviews

Issue:
Unable to turn off all active tools in the toolbar
#### ALL software version info
(this library, plus any other relevant software, e.g. bokeh, python, notebook, OS, browser, etc)

```
bokeh==3.1.1
holoviews==1.16.2
jupyter==1.0.0
jupyter-console==6.6.3
jupyter-events==0.6.3
jupyter_client==8.2.0
jupyter_core==5.3.0
jupyter_server==2.6.0
jupyter_server_terminals==0.4.4
jupyterlab-pygments==0.2.2
jupyterlab-widgets==3.0.7
panel==1.1.0
```

Python 3.10, Mac OS 12.5.1, Firefox 114.0.1


#### Description of expected behavior and the observed behavior

I'm expecting with `active_tools=[]` opts that when the chart is first rendered, all default tools should be present in the toolbar, but none of them should be selected.

I also tried with `active_tools=None` but to no effect.

Observed behaviour is that "pan" is selected in the toolbar, and "pan" is still activated. That is, I can still pan the chart.

#### Complete, minimal, self-contained example code that reproduces the issue

```python
import holoviews as hv
hv.extension('bokeh')

curve1 = hv.Curve(range(0, 10)).opts(active_tools=[])  # or active_tools=None
curve1
```

#### Stack traceback and/or browser JavaScript console output

NIL

#### Screenshots or screencasts of the bug in action

![image](https://github.com/holoviz/holoviews/assets/30731072/9754a289-d62c-4cea-8a27-58e4d7c5b563)



Discussion:

Resolving patch:
diff --git a/holoviews/plotting/bokeh/element.py b/holoviews/plotting/bokeh/element.py
--- a/holoviews/plotting/bokeh/element.py
+++ b/holoviews/plotting/bokeh/element.py
@@ -578,6 +578,10 @@ def _set_active_tools(self, plot):
         else:
             active_tools = self.active_tools
 
+        if active_tools == []:
+            # Removes Bokeh default behavior of having Pan enabled by default
+            plot.toolbar.active_drag = None
+
         for tool in active_tools:
             if isinstance(tool, str):
                 tool_type = TOOL_TYPES.get(tool, type(None))


Test patch:
Repository: holoviz/holoviews

Issue:
Support new `ImageStack` element in `dynspread` operation
Presumably this needs to be fixed in `spread`.


```python
import pandas as pd
from holoviews.operation.datashader import dynspread
df = pd.DataFrame({'x':[-16.8, 7.3], 'y': [-0.42, 13.6], 'language':['Marathi', 'Luganda']})
points = hv.Points(df, ['x','y'], ['language'])
op = rasterize(points, aggregator=ds.by('language', ds.count()))
dynspread(op)  # Works when dynspread not applied
```


Discussion:

Resolving patch:
diff --git a/holoviews/operation/datashader.py b/holoviews/operation/datashader.py
--- a/holoviews/operation/datashader.py
+++ b/holoviews/operation/datashader.py
@@ -1644,6 +1644,8 @@ def _process(self, element, key=None):
         if isinstance(element, RGB):
             rgb = element.rgb
             data = self._preprocess_rgb(rgb)
+        elif isinstance(element, ImageStack):
+            data = element.data
         elif isinstance(element, Image):
             data = element.clone(datatype=['xarray']).data[element.vdims[0].name]
         else:


Test patch:
diff --git a/holoviews/tests/operation/test_datashader.py b/holoviews/tests/operation/test_datashader.py
--- a/holoviews/tests/operation/test_datashader.py
+++ b/holoviews/tests/operation/test_datashader.py
@@ -48,6 +48,7 @@
         datashade,
         directly_connect_edges,
         ds_version,
+        dynspread,
         inspect,
         inspect_points,
         inspect_polygons,
@@ -1563,3 +1564,10 @@ def test_imagestack_datashade_count_cat():
     df = pd.DataFrame({"x": range(3), "y": range(3), "c": range(3)})
     op = datashade(Points(df), aggregator=ds.count_cat("c"))
     render(op)  # should not error out
+
+
+def test_imagestack_dynspread():
+    df = pd.DataFrame({'x':[-16.8, 7.3], 'y': [-0.42, 13.6], 'language':['Marathi', 'Luganda']})
+    points = Points(df, ['x','y'], ['language'])
+    op = dynspread(rasterize(points, aggregator=ds.by('language', ds.count())))
+    render(op)  # should not error out
Repository: holoviz/holoviews

Issue:
Disable Datashader count aggregator `self-intersect` by default for curves
#### Describe the solution you'd like

The self-intersect option for a Datashader count aggregator controls whether pixel-crossings of the **same** line contribute toward a pixel's count.

It was decided that a more reasonable default behavior would be to disable self-intersect by default.

This only makes sense for curves, not paths; self-intersections of paths are usually valuable information. 

#### Additional context

```

import pandas as pd
import numpy as np
import holoviews as hv
from holoviews.operation.datashader import rasterize
import datashader as ds

hv.extension('bokeh')

self_intersect = True
n_samples = 1000
data = np.random.randn(n_samples)
df = pd.DataFrame({'time': np.arange(len(data)), 'value': data})

hv_curve = rasterize(hv.Curve(df, 'time', 'value'), aggregator=ds.count(self_intersect=self_intersect)).opts(width=600)

hvplot_curve = df.hvplot.line('time', 'value', rasterize=True, aggregator=ds.count(self_intersect=self_intersect))

hv_curve + hvplot_curve

```


https://github.com/holoviz/holoviews/assets/6613202/aab0305a-b5aa-4600-9bd1-e92e10f623f6




Discussion:
Also, in the video in the description, it appears that there remains some gradient in the line even when `self-intersect = False`. Is that right? If self-intersections are not counted and there is only one line, then all the counts should be the same and therefore I would expect only a single hue

Resolving patch:
diff --git a/holoviews/operation/datashader.py b/holoviews/operation/datashader.py
--- a/holoviews/operation/datashader.py
+++ b/holoviews/operation/datashader.py
@@ -444,6 +444,18 @@ def _apply_datashader(self, dfdata, cvs_fn, agg_fn, agg_kwargs, x, y):
                 agg[col] = ((y.name, x.name), val)
         return agg
 
+class curve_aggregate(aggregate):
+    """
+    Optimized aggregation for Curve objects by setting the default
+    of the aggregator to self_intersect=False to be more consistent
+    with the appearance of non-aggregated curves.
+    """
+    aggregator = param.ClassSelector(class_=(rd.Reduction, rd.summary, str),
+                                     default=rd.count(self_intersect=False), doc="""
+        Datashader reduction function used for aggregating the data.
+        The aggregator may also define a column to aggregate; if
+        no column is defined the first value dimension of the element
+        will be used. May also be defined as a string.""")
 
 class overlay_aggregate(aggregate):
     """
@@ -1457,7 +1469,7 @@ class rasterize(AggregationOperation):
                    (Graph, aggregate),
                    (Scatter, aggregate),
                    (Points, aggregate),
-                   (Curve, aggregate),
+                   (Curve, curve_aggregate),
                    (Path, aggregate),
                    (type(None), shade) # To handle parameters of datashade
     ]


Test patch:
Repository: holoviz/holoviews

Issue:
rasterize=True no longer works with any geoviews parameters in hvplot (e.g. geo=True, crs=ccrs.PlateCarree())
Hey everyone,

I created a new environment with the latest packages from conda (hvplot 0.9.2, datashader 0.16.0, geoviews 1.11.0, spatialpandas 0.4.10, **holoviews 1.18.2**) and have started encountering an error when using rasterize=True with geo=True (or similar argument such as specifying crs=some_crs).
```
import xarray as xr
import hvplot.xarray
xr.tutorial.open_dataset("air_temperature").isel(time=0).hvplot.quadmesh(rasterize=True,geo=True)
```
raises
```
AttributeError: unexpected attribute 'lower' to CustomJSHover, possible attributes are args, code, js_event_callbacks, js_property_callbacks, name, subscribed_events, syncable or tags
```
Meanwhile, using datashade=True still works perfectly fine. 
```
import xarray as xr
import hvplot.xarray
xr.tutorial.open_dataset("air_temperature").isel(time=0).hvplot.quadmesh(datashade=True,geo=True)
```

I rolled back all of the mentioned packages one-by-one and determined the problem is with holoviews 1.18.2; holoviews 1.18.1 doesn't see this issue. 

[Traceback.txt](https://github.com/holoviz/holoviews/files/14181835/Traceback.txt)



Discussion:

Resolving patch:
diff --git a/holoviews/plotting/bokeh/raster.py b/holoviews/plotting/bokeh/raster.py
--- a/holoviews/plotting/bokeh/raster.py
+++ b/holoviews/plotting/bokeh/raster.py
@@ -82,7 +82,8 @@ def _postprocess_hover(self, renderer, source):
             }
             """
             for key in formatters:
-                if formatters[key].lower() == "datetime":
+                formatter = formatters[key]
+                if isinstance(formatter, str) and formatter.lower() == "datetime":
                     formatters[key] = CustomJSHover(code=datetime_code)
 
         hover.tooltips = tooltips


Test patch:
diff --git a/holoviews/tests/plotting/bokeh/test_rasterplot.py b/holoviews/tests/plotting/bokeh/test_rasterplot.py
--- a/holoviews/tests/plotting/bokeh/test_rasterplot.py
+++ b/holoviews/tests/plotting/bokeh/test_rasterplot.py
@@ -3,7 +3,7 @@
 import numpy as np
 import pandas as pd
 import pytest
-from bokeh.models import CustomJSHover
+from bokeh.models import CustomJSHover, HoverTool
 
 from holoviews.element import RGB, Image, ImageStack, Raster
 from holoviews.plotting.bokeh.raster import ImageStackPlot
@@ -155,6 +155,17 @@ def test_image_datetime_hover(self):
         else:
             assert isinstance(hover.formatters["@{Timestamp}"], CustomJSHover)
 
+    def test_image_hover_with_custom_js(self):
+        # Regression for https://github.com/holoviz/holoviews/issues/6101
+        hover_tool = HoverTool(
+            tooltips=[("x", "$x{custom}")], formatters={"x": CustomJSHover(code="return value + '2'")}
+        )
+        img = Image(np.ones(100).reshape(10, 10)).opts(tools=[hover_tool])
+        plot = bokeh_renderer.get_plot(img)
+
+        hover = plot.handles["hover"]
+        assert hover.formatters == hover_tool.formatters
+
 class _ImageStackBase(TestRasterPlot):
     __test__ = False