Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PNG error message #409

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add PNG error message #409

wants to merge 1 commit into from

Conversation

flying-sheep
Copy link
Member

to counter the misconfigured R system issues that crop up.

my stance here is to be as helpful as possible, but not work around a definitely wrong setup.

if (insane_xlib || insane_cairo) {
help_msg <-
if (!xlib && !cairo) 'install an R that is configured to have either Xlib or cairo support'
else sprintf("put `options(bitmapType='%s')` into your ~/.Rprofile", if (xlib) 'Xlib' else 'cairo')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we know one of them works, can we just switch to that instead of complaining to the user? If it's running on a remote server (e.g. in Jupyterhub), they may well never see this error message, just the kernel dying.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don’t see a potential problem here:

  1. the kernel dies immediately
  2. the sysadmin currently setting up jupyterhub will see this
  3. (s)he will fix the error

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sysadmin may not notice, and if it takes a few days for them to get round to it, the user will conclude that the R kernel doesn't work and either stop trying or come and complain to us.

This is another instance of our usual debate: do we work around a bug or misconfiguration elsewhere, or complain and try to get other people to fix it? In this case (where we have one device that works), I suspect it's not the users' fault that something is picking the wrong default, so why ask them to do manually what we can perfectly well do in our own code? Computers are supposed to be labour-saving devices. ;-)

If you don't like workarounds, then we can try to work out the underlying cause of the issue and get it fixed. If that sounds hard, that's why workarounds are common! Pushing it onto the users is not a substitute.

If it has neither capability and we can't create a png device at all, there's nothing (AFAIK) we can do, so then crashing with an error message seems appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we can change the abort to a user-visible, non-suppressible warning without having a invasive change to our code, let’s do it! i also don’t want to make the check more than once, that wouldn’t make sense.

If it has neither capability and we can't create a png device at all, there's nothing (AFAIK) we can do, so then crashing with an error message seems appropriate.

OK, so we’re just talking about the case when xlib || cairo is TRUE. sure, we can display a warning and fix the option then!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants