Currently the function Rstd_Busy() does nothing (src/unix/sys-std.c):
void attribute_hidden Rstd_Busy(int which)
{
}
The function is called through a pointer and R interfaces can change
this pointer and, thus, use a different function. I don't plan to
create a whole new interface to R
On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
> Currently the function Rstd_Busy() does nothing (src/unix/sys-std.c):
>
>void attribute_hidden Rstd_Busy(int which)
>{
>}
>
> The function is called through a pointer and R interfaces can change
> this pointer and, thus, u
Hi!
This is an issue we encountered when trying to move the Rcmdr package
from the Depends to the Imports field for RcmrPlugin.* plug-in packages.
Rcmdr overrides a few functions from the tcltk package for convenience.
With the current approach, both Rcmdr and tcltk are in the Depends
field, and
On 14.12.2012 23:31, Paul Johnson wrote:
2 days ago, I posted my long message about the observed slowdown in a
package between R-2.15.0 and R-2.15.2.
Uwe Ligges urged me to make a self-contained R example. That was the
encouragement I needed. I tracked the problem down to a failing use of
a LA
On Sat, Dec 15, 2012 at 1:09 PM, Simon Urbanek
wrote:
> On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
>> I could avoid the crash if I knew that R is busy at the moment that
>> it receives the SIGWINCH. Thus my question is: Could Rstd_Busy()
>> set the value of a variable so packages l
On Dec 15, 2012, at 2:20 PM, Jakson Alves de Aquino wrote:
> On Sat, Dec 15, 2012 at 1:09 PM, Simon Urbanek
> wrote:
>> On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
>>> I could avoid the crash if I knew that R is busy at the moment that
>>> it receives the SIGWINCH. Thus my questio
On Sat, Dec 15, 2012 at 5:41 PM, Simon Urbanek
wrote:
>
> On Dec 15, 2012, at 2:20 PM, Jakson Alves de Aquino wrote:
>
>> On Sat, Dec 15, 2012 at 1:09 PM, Simon Urbanek
>> wrote:
>>> On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
I could avoid the crash if I knew that R is busy a
Henrik Bengtsson wrote:
^ In the 'parallel' package there is detectCores(), which tries its best
^ to infer the number of cores on the current machine. This is useful
^ if you wish to utilize the *maximum* number of cores on the machine.
^ Several are using this to set the number of cores when p
On Dec 15, 2012, at 5:32 PM, Jakson Alves de Aquino wrote:
> On Sat, Dec 15, 2012 at 5:41 PM, Simon Urbanek
> wrote:
>>
>> On Dec 15, 2012, at 2:20 PM, Jakson Alves de Aquino wrote:
>>
>>> On Sat, Dec 15, 2012 at 1:09 PM, Simon Urbanek
>>> wrote:
On Dec 15, 2012, at 6:36 AM, Jakson Alves
On Dec 15, 2012, at 7:38 PM, Norm Matloff wrote:
> Henrik Bengtsson wrote:
>
> ^ In the 'parallel' package there is detectCores(), which tries its best
> ^ to infer the number of cores on the current machine. This is useful
> ^ if you wish to utilize the *maximum* number of cores on the machine
On Sat, Dec 15, 2012 at 10:58:34PM -0500, Simon Urbanek wrote:
> On Dec 15, 2012, at 7:38 PM, Norm Matloff wrote:
> > Even if one has the entire machine to oneself, there is often
> > another very good reason not to use the maximum number of cores:
> > Using the maximum number of cores may reduce
On Sat, Dec 15, 2012 at 11:44 AM, Uwe Ligges
wrote:
>
>
> On 14.12.2012 23:31, Paul Johnson wrote:
>>
> That is the reason why R CMD check gives a WARNING in the checks of your
> package for quite some time now:
>
>
> checking foreign function calls ... WARNING
>
> Foreign function calls with 'PAC
On Sat, Dec 15, 2012 at 8:29 PM, Paul Johnson wrote:
> On Sat, Dec 15, 2012 at 11:44 AM, Uwe Ligges
> wrote:
>>
>> That is the reason why R CMD check gives a WARNING in the checks of your
>> package for quite some time now:
>>
>> checking foreign function calls ... WARNING
>>
>> Foreign function
13 matches
Mail list logo
