fix(bol.R): set num_cores to 1 on Windows to prevent parallel execution issues (closes #603)

[PMassicotte]

parallel::mclapply does not seem to be working on Windows, so we force the number of cores to be 1.

[PMassicotte]

I am surprised that this issue (#604) was not reported before. @jalvesaq have you experienced this?

[jalvesaq]

I don't remember if I still had the virtual machine when we started using parallel execution. Maybe everyone is using WSL. For many, it might be simpler to stick with Vim and Vim-R, rather than migrate to Neovim and R.nvim. This would explain the existence of bugs and the absence of bug reports.

In my opinion, you should not dedicate too much of your time trying to fix bugs that don't affect you. I did this for years, and the result is that I'm tired and want to mostly retire from the development of R.nvim.

[PMassicotte]

In my opinion, you should not dedicate too much of your time trying to fix bugs that don't affect you. I did this for years, and the result is that I'm tired and want to mostly retire from the development of R.nvim.

Ah I am sorry to ear that. I know how it can feels. But we need you!

[richardsc]

In my opinion, you should not dedicate too much of your time trying to fix bugs that don't affect you. I did this for years, and the result is that I'm tired and want to mostly retire from the development of R.nvim.

Ah I am sorry to ear that. I know how it can feels. But we need you!

Just to second @PMassicotte here -- R.nvim has been a huge part of my coding workflow for the last two years, after switching from >15 years using Emacs+ESS. As a maintainer of an R package that is extensive, fairly popular, and has a diverse range of users (the oce package) I can understand the fatigue of chasing other people's bugs and requests.

It's been a goal of mine to better learn the R.nvim internals (and lua) to contribute back when possible, and this is motivation for me to try and find some time to dive in more.