hi there, thanks for the feedback, sorry about the cross-posting, and that
makes sense given the nojss option, which I was not aware of.
On Wed, Jan 8, 2020 at 9:16 AM Achim Zeileis
wrote:
> On Wed, 8 Jan 2020, Iñaki Ucar wrote:
>
> > On Wed, 8 Jan 2020 at 19:21, Toby Hocking wrote:
> >>
> >> H
> On Jan 10, 2020, at 3:10 PM, Gábor Csárdi wrote:
>
> On Fri, Jan 10, 2020 at 7:23 PM Simon Urbanek
> wrote:
>>
>> Henrik,
>>
>> the example from the post works just fine in CRAN R for me - the post was
>> about homebrew build so it's conceivably a bug in their libraries.
>
> I think it
> On Jan 10, 2020, at 3:10 PM, Gábor Csárdi wrote:
>
> On Fri, Jan 10, 2020 at 7:23 PM Simon Urbanek
> wrote:
>>
>> Henrik,
>>
>> the example from the post works just fine in CRAN R for me - the post was
>> about homebrew build so it's conceivably a bug in their libraries.
>
> I think it
Henrik,
the whole point and only purpose of mc* functions is to fork. That's what the
multicore package was about, so if you don't want to fork, don't use mc*
functions - they don't have any other purpose. I really fail to see the point -
if you use mc* functions you're very explicitly asking f
On Fri, Jan 10, 2020 at 7:23 PM Simon Urbanek
wrote:
>
> Henrik,
>
> the example from the post works just fine in CRAN R for me - the post was
> about homebrew build so it's conceivably a bug in their libraries. That's
> exactly why I was proposing a more general solution where you can simply
>
On Fri, Jan 10, 2020 at 11:23 AM Simon Urbanek
wrote:
>
> Henrik,
>
> the example from the post works just fine in CRAN R for me - the post was
> about homebrew build so it's conceivably a bug in their libraries.
Thanks for ruling that example out.
> That's exactly why I was proposing a more ge
On Fri, Jan 10, 2020 at 7:23 PM Simon Urbanek
wrote:
>
> Henrik,
>
> the example from the post works just fine in CRAN R for me - the post was
> about homebrew build so it's conceivably a bug in their libraries.
I think it works now, because Apple switched to a different SSL
library for libcurl.
Henrik,
the example from the post works just fine in CRAN R for me - the post was about
homebrew build so it's conceivably a bug in their libraries. That's exactly why
I was proposing a more general solution where you can simply define a function
in user-space that will issue a warning or stop
The RStudio GUI was just one example. AFAIK, and please correct me if
I'm wrong, another example is where multi-threaded code is used in
forked processing and that's sometimes unstable. Yes another, which
might be multi-thread related or not, is
https://stat.ethz.ch/pipermail/r-devel/2018-Septemb
If I understand the thread correctly this is an RStudio issue and I would
suggest that the developers consider using pthread_atfork() so RStudio can
handle forking as they deem fit (bail out with an error or make RStudio work).
Note that in principle the functionality requested here can be easi
lille stor,
As a general rule, please do not cross-post.
And almost certainly do not simultaneously as you did here and on
https://stackoverflow.com/questions/59663174/get-memory-address-of-an-r-data-frame
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
The documentation (help("Syntax")) gives the operator precedence of the
assignment operators and help, from highest to lowest, as:
‘<- <<-’ assignment (right to left)
‘=’assignment (right to left)
‘?’help (unary and binary)
If I under
On 1/10/20 7:33 AM, Henrik Bengtsson wrote:
I'd like to pick up this thread started on 2019-04-11
(https://hypatia.math.ethz.ch/pipermail/r-devel/2019-April/077632.html).
Modulo all the other suggestions in this thread, would my proposal of
being able to disable forked processing via an option or
13 matches
Mail list logo
