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

Issue:
[BUG] Undocumented API removals in 2.0
Currently trying to update the HoloViz stack to bokeh 2.0 compatibility and running into some undocumented deprecations:

* `bokeh.io.create_webdriver` removed (see https://github.com/bokeh/bokeh/pull/9331#discussion_r376234181)
* `bokeh.plotting.helpers` removed
* `AbstractButton` clicks property removed

I'll keep adding to these as I encounter these.

Reference: https://docs.bokeh.org/en/dev/docs/releases.html#api-removals


Discussion:
Also need to mention `app_hooks.py` as preferred new server hooks file location (and update docs)

Resolving patch:
diff --git a/examples/app/spectrogram/server_lifecycle.py b/examples/app/spectrogram/app_hooks.py
similarity index 100%
rename from examples/app/spectrogram/server_lifecycle.py
rename to examples/app/spectrogram/app_hooks.py
diff --git a/examples/app/stocks/server_lifecycle.py b/examples/app/stocks/app_hooks.py
similarity index 100%
rename from examples/app/stocks/server_lifecycle.py
rename to examples/app/stocks/app_hooks.py


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] Always setting asyncio event loop policy
Currently, for Python 3.8+ on Windows we're always setting the event loop policy to ensure that the policy used is compatible with tornado (xref https://github.com/tornadoweb/tornado/issues/2608):

https://github.com/bokeh/bokeh/blob/dea6ca42135c0402fa4f24fa502b58fce288e067/bokeh/server/tornado.py#L689-L692

However, this can interact poorly with other applications that use `bokeh` but also need to use custom event loop policies other than `asyncio.WindowsSelectorEventLoopPolicy()`


Discussion:

Resolving patch:
diff --git a/bokeh/server/tornado.py b/bokeh/server/tornado.py
--- a/bokeh/server/tornado.py
+++ b/bokeh/server/tornado.py
@@ -689,4 +689,7 @@ def _keep_alive(self):
 # See https://github.com/bokeh/bokeh/issues/9507
 if sys.platform == 'win32' and sys.version_info[:3] >= (3, 8, 0):
     import asyncio
-    asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
+    if type(asyncio.get_event_loop_policy()) is asyncio.WindowsProactorEventLoopPolicy:
+        # WindowsProactorEventLoopPolicy is not compatible with tornado 6
+        # fallback to the pre-3.8 default of WindowsSelectorEventLoopPolicy
+        asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())


Test patch:
Repository: bokeh/bokeh

Issue:
Autoload JS in notebook broken after PR #9777
Autoload JS produces code like:
```ts
const hashes = ;
```
in the notebook, due to lack of hashes dict being passed to the template. Could have been avoided if `bundle.hashes` was used instead of passing `hashes` independently and duplicating data.


Discussion:

Resolving patch:
diff --git a/bokeh/embed/bundle.py b/bokeh/embed/bundle.py
--- a/bokeh/embed/bundle.py
+++ b/bokeh/embed/bundle.py
@@ -80,7 +80,7 @@ def __init__(self, **kwargs):
         self.js_raw = kwargs.get("js_raw", [])
         self.css_files = kwargs.get("css_files", [])
         self.css_raw = kwargs.get("css_raw", [])
-        self.hashes = kwargs.get("hashes", None)
+        self.hashes = kwargs.get("hashes", {})
 
     def __iter__(self):
         yield self._render_js()
@@ -183,7 +183,7 @@ def bundle_for_objs_and_resources(objs, resources):
     if ext is not None:
         js_raw.append(ext)
 
-    return Bundle.of(js_files, js_raw, css_files, css_raw, js_resources.hashes if js_resources else None)
+    return Bundle.of(js_files, js_raw, css_files, css_raw, js_resources.hashes if js_resources else {})
 
 #-----------------------------------------------------------------------------
 # Private API
diff --git a/bokeh/embed/standalone.py b/bokeh/embed/standalone.py
--- a/bokeh/embed/standalone.py
+++ b/bokeh/embed/standalone.py
@@ -102,7 +102,7 @@ def autoload_static(model: Union[Model, Document], resources: Resources, script_
 
     (_, elementid) = list(render_item.roots.to_json().items())[0]
 
-    js = wrap_in_onload(AUTOLOAD_JS.render(bundle=bundle, elementid=elementid, hashes=bundle.hashes or {}))
+    js = wrap_in_onload(AUTOLOAD_JS.render(bundle=bundle, elementid=elementid))
 
     tag = AUTOLOAD_TAG.render(
         src_path = script_path,
diff --git a/bokeh/resources.py b/bokeh/resources.py
--- a/bokeh/resources.py
+++ b/bokeh/resources.py
@@ -346,7 +346,7 @@ def _server_urls(self):
     def _resolve(self, kind):
         paths = self._file_paths(kind)
         files, raw = [], []
-        hashes = None
+        hashes = {}
 
         if self.mode == "inline":
             raw = [self._inline(path) for path in paths]


Test patch:
diff --git a/tests/unit/bokeh/test_resources.py b/tests/unit/bokeh/test_resources.py
--- a/tests/unit/bokeh/test_resources.py
+++ b/tests/unit/bokeh/test_resources.py
@@ -126,7 +126,7 @@ def test_js_resources_hashes_mock_non_full(self, v, monkeypatch) -> None:
         monkeypatch.setattr(resources, "__version__", v)
         r = resources.JSResources()
         assert r.mode == "cdn"
-        assert r.hashes == None
+        assert r.hashes == {}
 
 
 class TestCSSResources(object):
Repository: bokeh/bokeh

Issue:
Deprecation warnings after PR #9807
E.g. running bokeh server shows:
```
BokehDeprecationWarning: bokeh.core.property.regex is deprecated, use bokeh.core.property.string module instead
```
All references to `.regex` module within bokeh should have been updated in PR #9807.


Discussion:
@ayushiitr2901 please submit a follow up PR to fix this.
More generally, everything should really only ever import from the top level `bokeh.properties` and not from sub-modules (which I thought was already the case but should have suggested to check) 
I think to find and updating all references to the `.regex `module with `.string` would solve the issue. Should I continue with the same? Or we can update the files to call regex from `bokeh.properties` rather than calling the sub-module directly.
The only files causing the error are `bokeh/core/property/color.py` and `bokeh/core/property/visual.py`, both in the property folder itself. I think calling to` string `module directly would be better.

Resolving patch:
diff --git a/bokeh/core/property/color.py b/bokeh/core/property/color.py
--- a/bokeh/core/property/color.py
+++ b/bokeh/core/property/color.py
@@ -29,7 +29,7 @@
 from .either import Either
 from .enum import Enum
 from .numeric import Byte, Percent
-from .regex import Regex
+from .string import Regex
 
 #-----------------------------------------------------------------------------
 # Globals and constants
diff --git a/bokeh/core/property/visual.py b/bokeh/core/property/visual.py
--- a/bokeh/core/property/visual.py
+++ b/bokeh/core/property/visual.py
@@ -38,7 +38,7 @@
 from .enum import Enum
 from .numeric import Float, Int
 from .primitive import String
-from .regex import Regex
+from .string import Regex
 
 #-----------------------------------------------------------------------------
 # Globals and constants


Test patch:
Repository: bokeh/bokeh

Issue:
Minor typo in bokeh.transform reference docs
In https://docs.bokeh.org/en/latest/docs/reference/transform.html theres a minor typo under the `cumsum` function :

> **cumsum(field, include_zero=False)**
>    &nbsp; &nbsp; Create a Create a DataSpec dict to generate a CumSum expression for a ColumnDataSource.

The `Create a` occurs twice.


Discussion:

Resolving patch:
diff --git a/bokeh/transform.py b/bokeh/transform.py
--- a/bokeh/transform.py
+++ b/bokeh/transform.py
@@ -53,7 +53,7 @@
 #-----------------------------------------------------------------------------
 
 def cumsum(field, include_zero=False):
-    ''' Create a Create a ``DataSpec`` dict to generate a ``CumSum`` expression
+    ''' Create a ``DataSpec`` dict to generate a ``CumSum`` expression
     for a ``ColumnDataSource``.
 
     Examples:


Test patch:
Repository: bokeh/bokeh

Issue:
[FEATURE] Allow hiding tooltips for muted glyphs
Started at https://discourse.bokeh.org/t/possible-to-hide-tooltips-for-muted-lines/5075

**Describe the solution you'd like**
Currently, `HoverTool` shows tooltips for all visible glyphs, even if they're muted. It would be good to be able to optionally exclude muted glyphs.



Discussion:

Resolving patch:
diff --git a/bokeh/models/tools.py b/bokeh/models/tools.py
--- a/bokeh/models/tools.py
+++ b/bokeh/models/tools.py
@@ -1124,6 +1124,11 @@ class HoverTool(Inspection):
     span on h or v directions.
     """)
 
+    muted_policy = Enum("show", "ignore",
+                        default="show", help="""
+    Whether to avoid showing tooltips on muted glyphs.
+    """)
+
     point_policy = Enum("snap_to_data", "follow_mouse", "none", help="""
     Whether the tooltip position should snap to the "center" (or other anchor)
     position of the associated glyph, or always follow the current mouse cursor


Test patch:
Repository: bokeh/bokeh

Issue:
Broken link to colorcet repo in palettes.py
A broken link has been pointed out in docs.bokeh.org by eagle-eyed user zeknafar:
https://discourse.bokeh.org/t/broken-link-in-palettes-documentation/5116/2

There is a corresponding outdated link in /bokeh/palettes.py.



Discussion:

Resolving patch:
diff --git a/bokeh/palettes.py b/bokeh/palettes.py
--- a/bokeh/palettes.py
+++ b/bokeh/palettes.py
@@ -325,7 +325,7 @@
 source file.
 
 .. _ColorBrewer: http://colorbrewer2.org/#type=sequential&scheme=BuGn&n=3
-.. _colorcet: https://bokeh.github.io/colorcet
+.. _colorcet: https://colorcet.holoviz.org
 .. _D3: https://github.com/d3/d3-3.x-api-reference/blob/master/Ordinal-Scales.md#categorical-colors
 .. _Matplotlib: http://matplotlib.org/examples/color/colormaps_reference.html
 


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] Race condition between legend and glyph when using `legend_label`
#### ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
Bokeh 2.0.2-4-gea1f11fc4

#### Description of expected behavior and the observed behavior
Adding a glyph with a lot of data points breaks the plot in unexpected ways.
Note that if you don't see the described behavior, you can try changing the `100000` below to a higher number.
However, even with low values the behavior can be observed if you press the button more than once.

#### Complete, minimal, self-contained example code that reproduces the issue

```python
from bokeh.layouts import row
from bokeh.models import Button, ColumnDataSource
from bokeh.plotting import curdoc, figure

p = figure()

src = ColumnDataSource(dict(x=list(range(100000))))
b = Button(label="Add line")


def add_line():
    p.line('x', 'x', source=src, legend_label=str(len(p.renderers)))


b.on_click(add_line)
curdoc().add_root(row(p, b))
```

#### Stack traceback and/or browser JavaScript console output
After pressing the "Add line" button, you can see this in the JS console:
```
Uncaught (in promise) TypeError: Cannot read property 'draw_legend' of undefined
    at LegendView._draw_legend_items (legend.js:226)
    at LegendView.render (legend.js:178)
    at PlotView._paint_levels (plot_canvas.js:843)
    at PlotView.paint (plot_canvas.js:825)
    at PlotView.repaint (plot_canvas.js:763)
    at plot_canvas.js:157
    at later (throttle.js:33)
```



Discussion:
I suppose this is a side effect of adding `lazy_initialize`, during which rendering can happen with half initialized state.

Resolving patch:
diff --git a/bokeh/plotting/_renderer.py b/bokeh/plotting/_renderer.py
--- a/bokeh/plotting/_renderer.py
+++ b/bokeh/plotting/_renderer.py
@@ -122,11 +122,14 @@ def create_renderer(glyphclass, plot, **kwargs):
         muted_glyph=make_glyph(glyphclass, kwargs, muted_visuals),
         **renderer_kws)
 
+    plot.renderers.append(glyph_renderer)
+
     if legend_kwarg:
+        # It must be after the renderer is added because
+        # if it creates a new `LegendItem`, the referenced
+        # renderer must already be present.
         update_legend(plot, legend_kwarg, glyph_renderer)
 
-    plot.renderers.append(glyph_renderer)
-
     return glyph_renderer
 
 def make_glyph(glyphclass, kws, extra):


Test patch:
Repository: bokeh/bokeh

Issue:
[TYPO] `cumsum()` transform function docstring mistake
The docstring accidentally states:
> For the start_angle value, the cumulative sums will start with a zero value. For start_angle, no initial zero will be added (i.e. the sums will start with the first angle value, and include the last).

The second `start_angle` should be `end_angle`.


Discussion:

Resolving patch:
diff --git a/bokeh/transform.py b/bokeh/transform.py
--- a/bokeh/transform.py
+++ b/bokeh/transform.py
@@ -66,7 +66,7 @@ def cumsum(field, include_zero=False):
 
         will generate a ``CumSum`` expressions that sum the ``"angle"`` column
         of a data source. For the ``start_angle`` value, the cumulative sums
-        will start with a zero value. For ``start_angle``, no initial zero will
+        will start with a zero value. For ``end_angle``, no initial zero will
         be added (i.e. the sums will start with the first angle value, and
         include the last).
 


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] `FactorRange`'s `start` property's help string references `end`
See [here](https://docs.bokeh.org/en/latest/docs/reference/models/ranges.html?highlight=factorrange#bokeh.models.ranges.FactorRange.start).


Discussion:

Resolving patch:
diff --git a/bokeh/models/ranges.py b/bokeh/models/ranges.py
--- a/bokeh/models/ranges.py
+++ b/bokeh/models/ranges.py
@@ -395,7 +395,7 @@ class FactorRange(Range):
     The start of the range, in synthetic coordinates.
 
         Synthetic coordinates are only computed in the browser, based on the
-        factors and various padding properties. The value of ``end`` will only
+        factors and various padding properties. The value of ``start`` will only
         be available in situations where bidirectional communication is
         available (e.g. server, notebook).
     """)


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] Elaborate on how the margin attribute works in documentation
When trying to adjust a margin the [documentation for the margin attribute](https://docs.bokeh.org/en/latest/docs/reference/models/layouts.html?highlight=margin#bokeh.models.layouts.Tabs.margin) didn't tell me everything I wanted to know. It took longer than I care to admit to figure out how it works and I think it'd help others if the documentation for margin explained:

- the ints in the tuple start at the top and go clockwise: top, right, bottom, left
- negative values can squeeze things together more tightly if desired


Discussion:
Hi @chrisjdixon That helps string could certainly use some elaboration. AFAIK the sense of "margin" here matches the standard CSS sense of "margin", but at a minimum we should link to something the w3schools reference for margin:

https://www.w3schools.com/Css/css_margin.asp

instead of just assuming that context. And possibly add some of our own explanation inline as well. 

We have applied to Google Summer of Docs so with any luck we might get someone to take on the project of reviewing/expanding all of the property helpstrings. However would you like to submit a Pull Request to update this specific one in the mean time? The relevant code section is here:

https://github.com/bokeh/bokeh/blob/master/bokeh/models/layouts.py#L117


Resolving patch:
diff --git a/bokeh/models/layouts.py b/bokeh/models/layouts.py
--- a/bokeh/models/layouts.py
+++ b/bokeh/models/layouts.py
@@ -116,6 +116,9 @@ class LayoutDOM(Model):
 
     margin = Tuple(Int, Int, Int, Int, default=(0, 0, 0, 0), help="""
     Allows to create additional space around the component.
+    The values in the tuple are ordered as follows - Margin-Top, Margin-Right, Margin-Bottom and Margin-Left,
+    similar to CSS standards.
+    Negative margin values may be used to shrink the space from any direction.
     """).accepts(Tuple(Int, Int), lambda v_h: (v_h[0], v_h[1], v_h[0], v_h[1])) \
         .accepts(Int, lambda m: (m, m, m, m))
 


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] `cd sphinx; make serve` doesn't work
#### ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
Bokeh 2.0.2-76-ga417746c9

#### Description of expected behavior and the observed behavior
The page at https://docs.bokeh.org/en/latest/docs/dev_guide/documentation.html mentions that it's possible to run `make serve` to serve the documentation locally. But running it results in:
```
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/home/p-himik/soft/miniconda3/envs/bokeh-dev/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/p-himik/soft/miniconda3/envs/bokeh-dev/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "docserver.py", line 43, in open_browser
    webbrowser.open("http://localhost:%d/en/latest/index.html" % PORT, new="tab")
  File "/home/p-himik/soft/miniconda3/envs/bokeh-dev/lib/python3.7/webbrowser.py", line 78, in open
    if browser.open(url, new, autoraise):
  File "/home/p-himik/soft/miniconda3/envs/bokeh-dev/lib/python3.7/webbrowser.py", line 251, in open
    "expected 0, 1, or 2, got %s" % new)
webbrowser.Error: Bad 'new' parameter to open(); expected 0, 1, or 2, got tab
```
Not sure where `"tab"` has come from, but it has been there forever.


Discussion:

Resolving patch:
diff --git a/sphinx/docserver.py b/sphinx/docserver.py
--- a/sphinx/docserver.py
+++ b/sphinx/docserver.py
@@ -40,7 +40,7 @@ def send_docs(filename):
 def open_browser():
     # Child process
     time.sleep(0.5)
-    webbrowser.open("http://localhost:%d/en/latest/index.html" % PORT, new="tab")
+    webbrowser.open("http://localhost:%d/en/latest/index.html" % PORT, new=2)
 
 data = {}
 


Test patch:
Repository: bokeh/bokeh

Issue:
[FEATURE] EditTool.empty_value should support 
It is frequently useful to add a string column to a glyph that is being edited using a `EditTool` but for some reason I did not allow string types in my initial implementation. I suggest simply adding String to the empty_value definition.


Discussion:

Resolving patch:
diff --git a/bokeh/models/tools.py b/bokeh/models/tools.py
--- a/bokeh/models/tools.py
+++ b/bokeh/models/tools.py
@@ -1221,7 +1221,7 @@ class EditTool(Gesture):
     A custom tooltip label to override the default name.
     """)
 
-    empty_value = Either(Bool, Int, Float, Date, Datetime, Color, help="""
+    empty_value = Either(Bool, Int, Float, Date, Datetime, Color, String, help="""
     Defines the value to insert on non-coordinate columns when a new
     glyph is inserted into the ``ColumnDataSource`` columns, e.g. when a
     circle glyph defines 'x', 'y' and 'color' columns, adding a new


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] `js_on_event` doesn't work when used in a callback
#### ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
Bokeh 2.1.0rc1

#### Description of expected behavior and the observed behavior
Any call to `js_on_event` when using `bokeh serve` should add the corresponding callback.
But since it modifies the `js_event_callbacks` property in-place, the frontend is never notified about the change.

#### Complete, minimal, self-contained example code that reproduces the issue
```python
from bokeh.io import curdoc
from bokeh.layouts import column
from bokeh.models import CustomJS, Button

b1 = Button(label="console.log")


def set_js_on_click():
    b1.js_on_click(CustomJS(code="console.log('hello');"))


b2 = Button(label='Set callback')
b2.on_click(set_js_on_click)

curdoc().add_root(column(b2, b1))
```



Discussion:

Resolving patch:
diff --git a/bokeh/model.py b/bokeh/model.py
--- a/bokeh/model.py
+++ b/bokeh/model.py
@@ -365,18 +365,13 @@ def struct(self):
     # Public methods ----------------------------------------------------------
 
     def js_on_event(self, event, *callbacks):
-
         if not isinstance(event, str) and issubclass(event, Event):
             event = event.event_name
 
-        if event not in self.js_event_callbacks:
-            self.js_event_callbacks[event] = []
-
-        for callback in callbacks:
-            if callback in self.js_event_callbacks[event]:
-                continue
-            self.js_event_callbacks[event].append(callback)
+        old_callbacks = self.js_event_callbacks.get("event", [])
+        new_callbacks = [ callback for callback in callbacks if callback not in old_callbacks ]
 
+        self.js_event_callbacks[event] = old_callbacks + new_callbacks
 
     def js_link(self, attr, other, other_attr, attr_selector=None):
         ''' Link two Bokeh model properties using JavaScript.


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] Incorrect type of `Select.options`
#### ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
Bokeh 2.1.0

#### Description of expected behavior and the observed behavior
`Select.options` says that it accepts 
```python
Either(List(Either(String, Tuple(Either(Int, String), String))),
       Dict(String, List(Either(String, Tuple(Either(Int, String), String))))
```

In reality, it doesn't accept `Int`s there as
1. `Select.value` can only be a string
2. `Select` in BokehJS doesn't use integers at all

An easy solution is to just drop `Int` from that field descriptor.
A (maybe) better solution is to allow integers in `Select.value` and `Select` in BokehJS. But it would require remembering the right type and converting the currently selected value in HTML to it so the correct type is stored in the model and used in every callback.


Discussion:
My vote is just to remove it and simplify the type

Resolving patch:
diff --git a/bokeh/models/widgets/inputs.py b/bokeh/models/widgets/inputs.py
--- a/bokeh/models/widgets/inputs.py
+++ b/bokeh/models/widgets/inputs.py
@@ -234,8 +234,8 @@ class Select(InputWidget):
     ''' Single-select widget.
 
     '''
-    options = Either(List(Either(String, Tuple(Either(Int, String), String))),
-        Dict(String, List(Either(String, Tuple(Either(Int, String), String)))), help="""
+    options = Either(List(Either(String, Tuple(String, String))),
+        Dict(String, List(Either(String, Tuple(String, String)))), help="""
     Available selection options. Options may be provided either as a list of
     possible string values, or as a list of tuples, each of the form
     ``(value, label)``. In the latter case, the visible widget text for each


Test patch:
Repository: bokeh/bokeh

Issue:
[BUG] cElementTree has been deprecated and will be removed in favor of ElementTree
Reference : https://bugs.python.org/issue36543

```
bokeh/sampledata/us_states.py
33:import xml.etree.cElementTree as et

bokeh/sampledata/us_counties.py
40:import xml.etree.cElementTree as et
```



Discussion:
Reference : https://bugs.python.org/issue36543

Resolving patch:
diff --git a/bokeh/sampledata/us_counties.py b/bokeh/sampledata/us_counties.py
--- a/bokeh/sampledata/us_counties.py
+++ b/bokeh/sampledata/us_counties.py
@@ -37,7 +37,7 @@
 
 # Standard library imports
 import csv
-import xml.etree.cElementTree as et
+import xml.etree.ElementTree as et
 
 # Bokeh imports
 from ..util.sampledata import external_path, open_csv
diff --git a/bokeh/sampledata/us_states.py b/bokeh/sampledata/us_states.py
--- a/bokeh/sampledata/us_states.py
+++ b/bokeh/sampledata/us_states.py
@@ -30,7 +30,7 @@
 import codecs
 import csv
 import gzip
-import xml.etree.cElementTree as et
+import xml.etree.ElementTree as et
 
 # Bokeh imports
 from ..util.sampledata import package_path


Test patch: