profile
viewpoint
Mateusz Paprocki mattpap Wrocław, Poland

ContinuumIO/docker-images 549

Repository of Docker images created by Continuum Analytics

ContinuumIO/anaconda-issues 513

Anaconda issue tracking

ContinuumIO/anaconda-recipes 103

Continuum managed recipes for free anaconda packages.

ContinuumIO/flask-ldap-login 98

Flask ldap integration

ContinuumIO/ciocheck 21

Continuum Analytics linter, formatter and test suite helper.

ContinuumIO/anaconda-clean 20

removes configuration files that are left behind when uninstalling Anaconda

ContinuumIO/anaconda-ec2 16

Anaconda plugin for StarCluster

ContinuumIO/ashiba 16

App building framework for Wakari and Anaconda.

ContinuumIO/DBAdapter 12

SQL database adapters forked from IOPro

pull request commentbokeh/bokeh

Update vertex_renderer properly in PolyEditTool

First of all thanks! I think this change makes sense, the only thing I might worry about is if a user switches out the data source which would leave a callback on a non-existent data source. That said I think this is sufficiently uncommon.

nitrocalcite

comment created time in a minute

Pull request review commentbokeh/bokeh

Update vertex_renderer properly in PolyEditTool

 export class PolyEditToolView extends PolyToolView {     if (!this.model.active)       return +    const vsync_renderer = this.model.renderers[0]+    const vsync_updater = () => this._update_vertices(vsync_renderer)+    let vsync_ds = null+    if (vsync_renderer !== undefined) vsync_ds = vsync_renderer.data_source+     const renderers = this._select_event(ev, "replace", this.model.renderers)     if (!renderers.length) {       this._set_vertices([], [])       this._selected_renderer = null       this._drawing = false+      this._cur_index = null+      if (vsync_ds !== null)+        vsync_ds.disconnect(vsync_ds.properties.data.change, vsync_updater)       return     }+    if (vsync_ds !== null)
    if (vsync_ds != null)
nitrocalcite

comment created time in 4 minutes

Pull request review commentbokeh/bokeh

Update vertex_renderer properly in PolyEditTool

 export class PolyEditToolView extends PolyToolView {     if (!this.model.active)       return +    const vsync_renderer = this.model.renderers[0]+    const vsync_updater = () => this._update_vertices(vsync_renderer)+    let vsync_ds = null+    if (vsync_renderer !== undefined) vsync_ds = vsync_renderer.data_source+     const renderers = this._select_event(ev, "replace", this.model.renderers)     if (!renderers.length) {       this._set_vertices([], [])       this._selected_renderer = null       this._drawing = false+      this._cur_index = null+      if (vsync_ds !== null)
      if (vsync_ds != null)
nitrocalcite

comment created time in 5 minutes

Pull request review commentbokeh/bokeh

Update vertex_renderer properly in PolyEditTool

 export class PolyEditToolView extends PolyToolView {     if (!this.model.active)       return +    const vsync_renderer = this.model.renderers[0]+    const vsync_updater = () => this._update_vertices(vsync_renderer)+    let vsync_ds = null+    if (vsync_renderer !== undefined) vsync_ds = vsync_renderer.data_source

@mattpap Might correct me here but this might be simpler:

    const vsync_ds = vsync_renderer?.data_source

but also necessitates the change below.

nitrocalcite

comment created time in 5 minutes

issue commentholoviz/panel

python 3.6.12 builds blank heroku app

I see no reason to continue having that separate repo.

cisaacstern

comment created time in an hour

push eventbokeh/bokeh

tcmetzger

commit sha 0e22ed80f29063e4693f68803bee45d73cb2d74b

Fix reference to styling.rst

view details

push time in an hour

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

Setting value after the input is rendered does work, as can be seen in the first example here:

https://www.w3schools.com/jsref/prop_color_value.asp

I guess a test we could try in Bokeh is to add a post-render hook that the ColorPicker could use to set the value on after a render.

bryevdv

comment created time in 2 hours

issue commentholoviz/panel

Support developing BasicTemplate Templates outside of Panel project

@jlstevens , @philippjfr . I think finishing https://github.com/holoviz/panel/pull/1730 before this one would make sense. Loading indicators will be simple to use for a lot of users. This request is important. But not the first step for a lot of users.

MarcSkovMadsen

comment created time in 2 hours

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

What's also interesting is that after selecting a new color the widget and the Bokeh model color property successully update (e.g. the linked line color takes effect) but the value of the DOM element never changes:

Screen Shot 2020-11-23 at 8 57 45 AM

I guess that's not too surprising from the Bokeh code but I would have assumed the browser would update value on a selection. Furthermore, default initial color specifying does work here:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color

i.e. it works when a literal <input> in in HTML. I gather there is somehing specific to the way we are dynamically adding the DOM element that Safari is not happy with.

bryevdv

comment created time in 2 hours

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

@xavArtley appreciate the reference, though it's definitely my first preference to use the native color pickers if possible:

  • much less code to maintain on our end
  • browser-native look and feel

That's why I never open a PR.

bryevdv

comment created time in 2 hours

issue commentholoviz/panel

python 3.6.12 builds blank heroku app

I'm not quite clear whether this is really a panel issue or an issue with the example.

@jbednar @philippjfr I thought we were no longer using holoviz-demos. If that is true, we should archive all those repos (and move anything useful to pyviz-topics).

cisaacstern

comment created time in 2 hours

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

@xavArtley appreciate the reference, though it's definitely my first preference to use the native color pickers if possible:

  • much less code to maintain on our end
  • browser-native look and feel

That said I don't know how to get this working on safari so maybe we will to to consider other options.

bryevdv

comment created time in 2 hours

issue commentholoviz/panel

Support developing BasicTemplate Templates outside of Panel project

@philippjfr This sounds like a reasonable request but I'm not sure about its priority. I've assigned it to the the 'next' milestone but feel free to bump it as appropriate.

MarcSkovMadsen

comment created time in 2 hours

issue commentholoviz/panel

Reserved keywords when working with interact

I've given this an enhancement label as this is not expected to ever work but as you point out, it would very helpful to issue a better error message.

Hoxbro

comment created time in 2 hours

issue commentholoviz/panel

Dashboard Graph does not render correctly in Jupyter Notebook/Lab

Thanks for filing this issue!

It looks to me like there is a failure in the plotly JS somewhere but is tricky to say what exactly is going wrong. It would be helpful if you could see if this issue persists with a more minimal example.

iDataist

comment created time in 2 hours

startedDerULF1/8bit-computer

started time in 3 hours

startedvisrealm/vrcpu

started time in 3 hours

issue commentbokeh/bokeh

[FEATURE] Please add necessary testing files to pypi releases

@bryevdv the issue I was seeing was due to an internal system problem of my making. It has been fixed. Sorry.

epsilon-0

comment created time in 4 hours

issue commentbokeh/bokeh

[BUG] ModuleNotFound error for every sub-module I try to import

@bryevdv Actually I immediately remembered the search path thing when he told me the solution. I was just trying to be funny.

amoh-godwin

comment created time in 4 hours

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

Hello,

I'm not sure if it's not overkilling just to solve this bug, however some times ago I tried to implement a color picker without relying on the one implemented on each browser. (I needed a color picker when integrating a bokeh app using cefpython)

The developpements are in the following branch: https://github.com/bokeh/bokeh/tree/xav/redesign_color_picker

If you think it can be interesting I could submit a PR and continue the developpement

bryevdv

comment created time in 7 hours

issue closedholoviz/panel

Add option to toggle throttled on widgets with interact and depends

Is your feature request related to a problem? Please describe.

I often want to use the value_throttled for my dashboard´s widgets and the only way to do it right now is the hard way by adding an explicit widget instance to pn.interact or pn.depends.

Describe the solution you'd like

Either add a keyword like throttled to pn.interact and pn.depends or create a new function which use the value_throttled if it exist for the widget e.g. pn.interact_throttled.

Additional context

Here are examples of pn.interact and pn.depends with a throttled keyword: interact_example

ezgif com-video-to-gif

closed time in 9 hours

Hoxbro

push eventbokeh/bokeh

Mateusz Paprocki

commit sha 53b5fea142aeafa5f95a61f7de49ecb406f24e7c

Use bokehjs' test framework to start chrome in examples' tests (#10711)

view details

Mateusz Paprocki

commit sha 7f4770d96f5e8a639bdc8cef8a2754c61d5711cc

Fix bokehjs' SVG export when ToolbarBox is present (#10713) * Move CanvasLayer to core/util/canvas * Fix expect(fn).to.not.throw assertion * Make ToolbarBase behave even more like LayoutDOM * Add integration tests

view details

Mateusz Paprocki

commit sha ebd0bbf1550d0abcf3dc0e0cf68ffa31d9f24801

Allow to configure TapTool with a gesture (tap or doubletap) (#10705)

view details

Mateusz Paprocki

commit sha 716a2979ab392462b9c9cf5f1ec8d1a92f54635b

Detect dependency cycles in build and fix existing cycles (#10707) * Allow to detect module cycles in build * Break dependency cycle between core/has_props and document * Split up core/util/serialization * Resolve cyclic dependencies in data tables * Break cyclic dependency between core/util/{types,array} * Use AnyRef() in internal property definitions Those internal properties are usually bad design anyway, and should be replaced with views (internal state management). * Simplify code a bit in selection policies * Make cycle detection optional for now Use `node make build --detect-cycles` to enable cycle detection. * Refine implementation and API

view details

Timo Cornelius Metzger

commit sha d90509208c7b926ef45824e51d4ee5f915e2144d

Add information about themes (#10710) * Add information about themes * Update wording * Remove import of built_in_themes

view details

tcmetzger

commit sha 1202c7f21ef2c36cfbdd5be82a27f1f1f8711fd3

Merge branch 'branch-2.3' into timo/userguide/quickstart

view details

push time in 13 hours

issue commentbokeh/bokeh

[BUG] ColorPicker does not respect initial color

@mattpap I think I see the proximate cause that the color swatch is black even though the value is set:

Screen Shot 2020-11-22 at 10 06 43 PM

But i don't know where or why the shadow dom parts come from (ignore the defaultValue that was just an earlier experiment)

bryevdv

comment created time in 13 hours

issue commentbokeh/bokeh

[BUG] Whiskers `base` have reduced precision

discovered that multi_line is broken from precision on current branch-2.3 @mattpap do you know if there is an issue?

golmschenk

comment created time in 14 hours

pull request commentbokeh/bokeh

Migrate from marker glyphs to scatter glyph

@mattpap what does making a new custom extension marker look like? There's just now a question on the Discourse about updating some very old Custom marker code and I'm suddenly not really sure what that might look like after this change

https://discourse.bokeh.org/t/refactoring-custom-markerview-from-v2/6156/2

mattpap

comment created time in 14 hours

Pull request review commentbokeh/bokeh

Migrate from marker glyphs to scatter glyph

 class Circle(Marker):     and y dimensions and use the maximum of the two, 'min' selects the minimum.     """) -class CircleCross(Marker):-    ''' Render circle markers with a '+' cross through the center. '''+def Asterisk(*args, **kwargs):+    ''' Render asterisk '*' markers. '''+    deprecated((2, 3, 0), "Asterisk()", "Scatter(marker='asterisk')")+    return Scatter(*args, **kwargs, marker="asterisk") -    __example__ = "examples/reference/models/CircleCross.py"+def CircleCross(*args, **kwargs):+    ''' Render circle markers with a '+' cross through the center. '''+    deprecated((2, 3, 0), "CircleCross()", "Scatter(marker='circle_cross')")+    return Scatter(*args, **kwargs, marker="circle_cross") -class CircleDot(Marker):+def CircleDot(*args, **kwargs):     ''' Render circle markers with center dots. '''+    deprecated((2, 3, 0), "CircleDot()", "Scatter(marker='circle_dot')")+    return Scatter(*args, **kwargs, marker="circle_dot") -    __example__ = "examples/reference/models/CircleDot.py"--class CircleX(Marker):+def CircleX(*args, **kwargs):     ''' Render circle markers with an 'X' cross through the center. '''+    deprecated((2, 3, 0), "CircleX()", "Scatter(marker='circle_x')")+    return Scatter(*args, **kwargs, marker="circle_x") -    __example__ = "examples/reference/models/CircleX.py"--class CircleY(Marker):+def CircleY(*args, **kwargs):     ''' Render circle markers with an 'Y' cross through the center. '''+    deprecated((2, 3, 0), "CircleY()", "Scatter(marker='circle_y')")+    return Scatter(*args, **kwargs, marker="circle_y") -    __example__ = "examples/reference/models/CircleY.py"--class Cross(Marker):+def Cross(*args, **kwargs):     ''' Render '+' cross markers. '''+    deprecated((2, 3, 0), "Cross()", "Scatter(marker='cross')")+    return Scatter(*args, **kwargs, marker="cross") -    __example__ = "examples/reference/models/Cross.py"--class Dash(Marker):-    ''' Render dash markers. Use ``angle`` to rotate and create vertically-    oriented short lines.-    '''--    __example__ = "examples/reference/models/Dash.py"+def Dash(*args, **kwargs):+    ''' Render dash markers. '''+    deprecated((2, 3, 0), "Dash()", "Scatter(marker='dash')")+    return Scatter(*args, **kwargs, marker="dash") -class Diamond(Marker):+def Diamond(*args, **kwargs):     ''' Render diamond markers. '''+    deprecated((2, 3, 0), "Diamond()", "Scatter(marker='diamond')")+    return Scatter(*args, **kwargs, marker="diamond") -    __example__ = "examples/reference/models/Diamond.py"--class DiamondCross(Marker):+def DiamondCross(*args, **kwargs):     ''' Render diamond markers with a '+' cross through the center. '''+    deprecated((2, 3, 0), "DiamondCross()", "Scatter(marker='diamond_cross')")+    return Scatter(*args, **kwargs, marker="diamond_cross") -    __example__ = "examples/reference/models/DiamondCross.py"--class DiamondDot(Marker):+def DiamondDot(*args, **kwargs):     ''' Render diamond markers with center dots. '''+    deprecated((2, 3, 0), "DiamondDot()", "Scatter(marker='diamond_dot')")+    return Scatter(*args, **kwargs, marker="diamond_dot") -    __example__ = "examples/reference/models/DiamondDot.py"--class Dot(Marker):+def Dot(*args, **kwargs):     ''' Render dots (one-quarter radius circles). '''+    deprecated((2, 3, 0), "Dot()", "Scatter(marker='dot')")+    return Scatter(*args, **kwargs, marker="dot") -    __example__ = "examples/reference/models/Dot.py"--class Hex(Marker):+def Hex(*args, **kwargs):     ''' Render hexagon markers. '''+    deprecated((2, 3, 0), "Hex()", "Scatter(marker='hex')")+    return Scatter(*args, **kwargs, marker="hex") -    __example__ = "examples/reference/models/Hex.py"--class HexDot(Marker):+def HexDot(*args, **kwargs):     ''' Render hexagon markers with center dots. '''+    deprecated((2, 3, 0), "HexDot()", "Scatter(marker='hex_dot')")+    return Scatter(*args, **kwargs, marker="hex_dot") -    __example__ = "examples/reference/models/HexDot.py"--class InvertedTriangle(Marker):+def InvertedTriangle(*args, **kwargs):     ''' Render upside-down triangle markers. '''+    deprecated((2, 3, 0), "InvertedTriangle()", "Scatter(marker='inverted_triangle')")+    return Scatter(*args, **kwargs, marker="inverted_triangle") -    __example__ = "examples/reference/models/InvertedTriangle.py"--class Plus(Marker):+def Plus(*args, **kwargs):     ''' Render filled plus markers '''+    deprecated((2, 3, 0), "Plut()", "Scatter(marker='plus')")+    return Scatter(*args, **kwargs, marker="plus") -    __example__ = "examples/reference/models/Plus.py"--class Square(Marker):+def Square(*args, **kwargs):     ''' Render square markers. '''+    deprecated((2, 3, 0), "Square()", "Scatter(marker='square')")+    return Scatter(*args, **kwargs, marker="square") -    __example__ = "examples/reference/models/Square.py"--class SquareDot(Marker):+def SquareDot(*args, **kwargs):     ''' Render square markers with center dots. '''+    deprecated((2, 3, 0), "SquareDot()", "Scatter(marker='square_dot')")+    return Scatter(*args, **kwargs, marker="square_dot") -    __example__ = "examples/reference/models/SquareDot.py"--class SquarePin(Marker):+def SquarePin(*args, **kwargs):     ''' Render pin-cushion square markers. '''+    deprecated((2, 3, 0), "SquarePin()", "Scatter(marker='square_pin')")+    return Scatter(*args, **kwargs, marker="square_pin") -    __example__ = "examples/reference/models/SquarePin.py"--class SquareCross(Marker):+def SquareCross(*args, **kwargs):     ''' Render square markers with a '+' cross through the center. '''+    deprecated((2, 3, 0), "SquareCross()", "Scatter(marker='square_cross')")+    return Scatter(*args, **kwargs, marker="square_cross") -    __example__ = "examples/reference/models/SquareCross.py"--class SquareX(Marker):+def SquareX(*args, **kwargs):     ''' Render square markers with an 'X' cross through the center. '''+    deprecated((2, 3, 0), "SquareX()", "Scatter(marker='square_x')")+    return Scatter(*args, **kwargs, marker="square_x") -    __example__ = "examples/reference/models/SquareX.py"--class Triangle(Marker):+def Triangle(*args, **kwargs):     ''' Render triangle markers. '''+    deprecated((2, 3, 0), "Triangle()", "Scatter(marker='triangle')")+    return Scatter(*args, **kwargs, marker="triangle") -    __example__ = "examples/reference/models/Triangle.py"--class TriangleDot(Marker):+def TriangleDot(*args, **kwargs):     ''' Render triangle markers with center dots. '''+    deprecated((2, 3, 0), "TriangleDot()", "Scatter(marker='triangle_dot')")+    return Scatter(*args, **kwargs, marker="triangle_dot") -    __example__ = "examples/reference/models/TriangleDot.py"--class TrianglePin(Marker):+def TrianglePin(*args, **kwargs):     ''' Render pin-cushion triangle markers. '''+    deprecated((2, 3, 0), "TrianglePin()", "Scatter(marker='triangle_pin')")+    return Scatter(*args, **kwargs, marker="triangle_pin") -    __example__ = "examples/reference/models/TrianglePin.py"--class X(Marker):+def X(*args, **kwargs):     ''' Render 'X' markers. '''+    deprecated((2, 3, 0), "X()", "Scatter(marker='x')")+    return Scatter(*args, **kwargs, marker="x") -    __example__ = "examples/reference/models/X.py"--class Y(Marker):+def Y(*args, **kwargs):     ''' Render 'Y' markers. '''--    __example__ = "examples/reference/models/Y.py"+    deprecated((2, 3, 0), "Y()", "Scatter(marker='y')")+    return Scatter(*args, **kwargs, marker="y")  #----------------------------------------------------------------------------- # Dev API #----------------------------------------------------------------------------- -marker_types = {-    "asterisk": Asterisk,-    "circle": Circle,-    "circle_cross": CircleCross,-    "circle_dot": CircleDot,-    "circle_x": CircleX,-    "circle_y": CircleY,-    "cross": Cross,-    "dash": Dash,-    "diamond": Diamond,-    "diamond_cross": DiamondCross,-    "diamond_dot": DiamondDot,-    "dot": Dot,-    "hex": Hex,-    "hex_dot": HexDot,-    "inverted_triangle": InvertedTriangle,-    "plus": Plus,-    "square": Square,-    "square_cross": SquareCross,-    "square_dot": SquareDot,-    "square_pin": SquarePin,-    "square_x": SquareX,-    "triangle": Triangle,-    "triangle_dot": TriangleDot,-    "triangle_pin": TrianglePin,-    "x": X,-    "y": Y,-}-

I think marker_type should be kept for now (at least as a list of the names) and then removed at 3.0

mattpap

comment created time in 14 hours

Pull request review commentbokeh/bokeh

Migrate from marker glyphs to scatter glyph

 Previously ``Line``, ``Fill``, ``Text`` and ``Hatch`` visuals were used in primi scalar and vector contexts. Those were split and now context-specific visuals, e.g., ``Line``, ``LineScalar`` and ``LineVector`` have to used in respective contexts. This aligns visuals with mixins, among other things.++Marker models are deprecated+~~~~~~~~~~~~~~~~~~~~~~~~~~~~++Models like ``Asterisk``, ``CircleX``, ``X``, etc. are deprecated in bokeh. Use ``Scatter``+glyph with respective marker types instead. Marker methods on ``Figure`` will default to

A concrete example snippet would be good here

mattpap

comment created time in 14 hours

Pull request review commentbokeh/bokeh

Migrate from marker glyphs to scatter glyph

 export abstract class MarkerGL extends BaseGLGlyph {   protected vbo_bg_color: VertexBuffer & {used?: boolean}   protected index_buffer: IndexBuffer -  protected last_trans: Transform--  protected _baked_offset: [number, number]+  static is_supported(marker_type: MarkerType): boolean {+    switch (marker_type) {+      case "asterisk":+      case "circle":+      case "circle_cross":+      case "circle_x":+      case "cross":+      case "diamond":+      case "diamond_cross":+      case "hex":+      case "inverted_triangle":+      case "square":+      case "square_cross":+      case "square_x":+      case "triangle":+      case "x":+        return true+      default:+        return false+    }+  } -  protected init(): void {-    const {gl} = this+  constructor(gl: WebGLRenderingContext, readonly glyph: MarkerLikeView, readonly marker_type: MarkerType) {+    super(gl, glyph) +    const defs = [`#define USE_${marker_type.toUpperCase()}`]     const vert = vertex_shader-    const frag = fragment_shader(this._marker_code)+    const frag = `${defs.join("\n")}\n\n${fragment_shader}`

I don't love this with the #define Why not store the fragment shaders as an attribute on the marker class? Then the concerns are grouped together, the giant every-fragment file can be avoided, and the presence or absence of a fragment shader on a class can directly be used to determine gl-support, rather than having to maintain a separate list in sync, as above?

mattpap

comment created time in 15 hours

Pull request review commentbokeh/bokeh

Migrate from marker glyphs to scatter glyph

 export abstract class MarkerGL extends BaseGLGlyph {   protected vbo_bg_color: VertexBuffer & {used?: boolean}   protected index_buffer: IndexBuffer -  protected last_trans: Transform--  protected _baked_offset: [number, number]+  static is_supported(marker_type: MarkerType): boolean {+    switch (marker_type) {+      case "asterisk":+      case "circle":+      case "circle_cross":+      case "circle_x":+      case "cross":+      case "diamond":+      case "diamond_cross":+      case "hex":+      case "inverted_triangle":+      case "square":+      case "square_cross":+      case "square_x":+      case "triangle":

Why not an enum for gl-supporting markers?

mattpap

comment created time in 15 hours

PR opened bokeh/bokeh

Update vertex_renderer properly in PolyEditTool

Proposed fix for #10670

This adds a listener to the PolyEditTool's first renderer's data source. The listener updates the vertex_renderer appropriately when the data source is updated.

An alternative implementation would add such listeners to all of the renderers present, rather than just the first. However, I don't think this is required, because:

  1. In most (all?) use cases, all the renderers will share the same data source
  2. It will always be possible to update the vertex_renderer appropriately via the first renderer's data source

Please let me know what you think of this approach and if there are any issues. Thanks!

+23 -4

0 comment

1 changed file

pr created time in 15 hours

more