plotly-resampler: After upgrading from 0.3 to 0.8.1, one of my notebook cells with resampler runs indefinitely

I have several figures in a notebook. All other figures plot correctly and I can wrap PlotlyResampler around and show them. However, one particular figure plots just fine, but when I wrap it in PlotlyResampler my cell keeps running indefinitely. This unfortunately blocks my update to 0.8.1. Do you have any idea @jonasvdd ?

#32

FigureResampler(fig, default_n_shown_samples=MAX_POINTS).show_dash(mode="inline")

Other observations:

if I downgrade to 0.3.0 it still does not work,
if I downgrade to 0.3.0 and remove the dash show, it works fine

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 25 (11 by maintainers)

Commits related to this issue

:bug: parse object arrays for datetime or numeric dtypes, fixes #115 — committed to predict-idlab/plotly-resampler by jvdd 2 years ago

Most upvoted comments

I am running py3.7 in a Windows environment.

Update. I have installed the plotly resampler in a separate environment and the cell works fine. I must have a package incompatibility somewhere. I am checking.

Alexander-Serov on Sep 30, 2022

Hey! You are welcome, it has been a great pleasure to work with you guys so far. 😃 I wouldn’t say I am very knowledgeable in plotly in general (you guys should be much better), but I do indeed manipulate datetimes every day.

Considering the question of dropping/conversion of datetimes with different TZs, I think it’s important to ask oneself why different TZs got there in the first place:

As I mentioned, the most common case I see is that it’s the same named TZ, which - if read as unnamed - will appear as different TZs before and after DST (daylight saving time change) date. For example, for Los Angeles (the dataset I sent you) you will see UTC-07:00 and UTC-08:00. In this case, the only way to show it correctly would be to ask the user to convert to a named TZ. A priori, you cannot really infer you. For me, this is 99% of cases you will see as resampler input with different TZs.
if the data really come from different named TZs, there is not much we can do either. We could convert them to UTC or drop the TZ. Conversion to UTC has the disadvantage that the apparent datetime may be wrong. What would have happened at 6 pm in LA would be at ~midninght in UTC. The figures may be confusing. However, if you drop the TZ altogether, you may have an incorrect time shift around the DST dates.

This said, I know plotly itself manages some of these cases without converting all to UTC. I wonder if we can look up what they do in their code.

I will now try the rc2 to see if it fixes the kernel crash and have a look at the PR replies. 😃 If all goes well, we should have a new version soon. 😃

Alexander-Serov on Sep 28, 2022

Hi @Alexander-Serov,

First of all thanks for the thorough review on PR #116, @jonasvdd and me will take your remarks into account and update the PR accordingly in the following days. It is really nice to dive into & discuss code with other (more) experienced people - this is the power of open source 😄

Regarding your comment above: I was also able to reproduce the kernel crash (actually I encountered this issue as well when creating the first implementation in PR #116, but I thought the issue was fixed in the pre-release - which is apparently not the case 🙃 ). We’ll try to properly find the root cause for this issue and hopefully fix it as well in PR #116

jvdd on Sep 27, 2022