unable to plot in jupyter notebook using R kernel #210
Comments
|
Thanks for the report. Definitely looks like #54 again. libxrender moved from datascience-notebook to minimal-notebook (https://github.com/jupyter/docker-stacks/blob/master/minimal-notebook/Dockerfile#L33) so it should still be available. Must be something else wrong now. |
parente
added
the
type:Bug
|
I'm running into the exact same issue. Not sure if this helps, but if I run |
|
I also spotted this in the output, right before the Kernel crashed: |
|
Did some digging, it might be related to this issue? conda/conda#2020 |
|
I played one round of bisect over recent builds listed here https://github.com/jupyter/docker-stacks/wiki/Docker-build-history
The only explicit diff between the last build that plots and the first build that doesn't is the update to use Notebook 4.2 and ipywidgets 5.1: Other implicit version changes may have snuck in during the docker image build, but we only allow most packages to vary in patch release number, not major or minor version. Plus, our builds are all done on the same box starting with a pull of the last build to gain the benefit of docker layer caching. This means anything before the notebook 4.2 version change in the Dockerfile will not have changed (e.g., version of libxrender pulled from debian). @takluyver @jakirkham have you seen any problems with IRkernel in notebook 4.2 with or without conda? |
|
@michael-erasmus hit the nail on the head. Comparing the last working build to the first non-working one, I see a third-order dependency version changed and broke things. In 2d878db, the libjpeg v8 is present: In 2bcf753 and newer, v8 is gone and v9 is there: @jakirkham Is there a conda-forge feedstock for irkernel that needs to be updated? Or a R_X11 feedstock? |
parente
added
the
tag:Upstream
Not yet. Someone started to get the ball rolling on R, but they are generally very busy and I believe there were a few tricks so it came to a stop. Though we do provide JPEG 9. So, it is possible that some of these R packages are not properly pinned against JPEG 8. Hence we JPEG is upgraded and that breaks them. I would recommend adding a |
Do you think we should add it to the images as a temporary fix and do a new build? Or do you think users should add it as a workaround until it's fixed upstream? |
|
Let's ask Continuum about fixing these packages to be properly pinned. If it looks like a long turnaround, we should probably pin it ourselves. Do we know exactly which packages were using JPEG? |
I do not. Is there a canonical place to look to figure it out? |
|
Just wanted to confirm that @jakirkham's suggestion did indeed work for me. I managed to get plotting to work by using a |
|
Glad to hear that @michael-erasmus. Could you please share with us what happened during |
|
@msarahan, do you know who/where we should notify someone about this pinning issue with R packages? Basically, the stack in this docker container |
|
CC @mingwandroid, who handles our R ecosystem. |
… issues by pulling in newer versions of rpy2 and ipywidgets. 1) Added freetds to allow access to database instances using odbc. 2) Create a shell .odbc.ini file that can be filled out to access a database instance. 3) Updated the version of rpy2 since the %R and %%R magic wouldn't work from the Python kernels so that R can be used in cells within a Python sheet. 4) Updated ipywidgets so that the widgets can be used within a Python3 sheet. Without this update it wouldn't show the controls in a Python3 sheet after running the sheet 5) Pinned the conda to jpeg 8 since the ggplot2 graphs wouldn't showup in R sheets. See jupyter#210
|
This appears to be fixed in the latest build (tag: @fyears, @michael-erasmus, please re-open if you still have problems once you update. |
|
New problem with plotting. This time, pinning to jpeg8 post-hoc does not fix the issue. Looking into what we might do. |
|
Sorry I missed this one. Pinging @mingwandroid who does the r stuff. |
|
The latest ( I can do the pinning in the scipy-notebook for the time being as a workaround until the R package(s) declare the libjpeg8 dependency properly. Or until we bump versions on all of the R packages so they all work with libjpeg9. I'll try the latter first. |
|
No luck upgrading all the R libs. One of them still wants libjpeg8. So pinning it is. |
Pin libjpeg to v8 (c) Copyright IBM Corp. 2016
|
I can't believe I missed this. Seems the problem is |
|
Not sure if this helps, but 54838ed and 7001472 pick up different revisions of r-base |
|
Please do |
|
On 54838ed... and on 7001472 |
|
Besides the Since I do not think the other upgraded packages are related to the graphics capabilities, I think |
|
@takluyver any thoughts on what in the delta above might be causing @jakirkham I tried removing the pin for libjpeg and installing jpeg9 from conda-forge, but to no avail. I get the same |
|
The change that broke plotting happened in r-base between 3.3.1-1 and 3.3.1-3. As a workaround, |
|
@mingwandroid do you have any thoughts on what might have changed between r-base 3.3.1 build number 1 (conda-archive/conda-recipes@601fd5d) and build number 3 (conda-archive/conda-recipes@dfe2d55) that could have flipped jpeg, png, and tiff capabilities from TRUE to FALSE as shown in #210 (comment)? I'm looking but not coming up with much. |
|
On a clean install on latest ArchLinux my capabilities include all of those. Can you try the same and report back? |
|
@mingwandroid, sure. Here's my bash history starting from a fresh docker debian container: Here's the output from the last command: |
|
I pushed a new image with the older r-base build for the time being. It's tagged If someone else can try it, that would be great. |
|
This issue is becoming quite large, so to keep the fire going 😄 or at least make note of it. It looks like currently this issue appears when a user tries to plot. Although, come the next IRkernel release/version this issue will appear on the first execution of a code cell such as This was discovered when running cc'ing @flying-sheep as you are familiar with this or at least making sure you are aware. For reference the error when running In conclusion this is not a big issue yet, but will be later. |
|
wait: when exactly will this occur? AFAIK only when there is an R system so extremely broken that a very basic call to a non-interactive device like or am i wrong? |
|
@parente datascience-notebook:54552d36cf0a works for me. I can plot again! |
|
@flying-sheep With irkernel 0.7 and conda r-base 3.3.1-3, I can crash the kernel by simply entering Switching back to r-base 3.3.1-1 resolves the issue. It seems that conda 3.3.1-3 build is the culprit again. |
|
thanks for the help, all of you! see ContinuumIO/anaconda-issues#1063 for more |
|
@flying-sheep Thanks for filing this upstream. I'm going to close this (massive) issue now to avoid giving the impression that plotting is still an issue here. When the anaconda issue closes upstream, we can unpin the R version here. |
|
@parente, would it be possible for you to test a new preview build of Thanks! |
|
PR #324 unpins jpeg and updates to r-base 3.3.2 which does not suffer from the original problems. |
|
Hi, I have exactly the same problem. I have problems creating charts in the jupyter notebook, sparmagic and R. This is my set up: R version 3.5.2 (2018-12-20) I used pip install everything |
I am using default configuration of
jupyter/datascience-notebook.By accessing
http://docker.local:8888/, I could start a notebook with R kernel, but I could not generate plots inside the notebook.The simple official example:
The #54 might relevant, but I am using the most up-to-todate image (20160519) .
The text was updated successfully, but these errors were encountered: