Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

@flying-sheep flying-sheep Sep 21, 2016

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.

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.