SEND TO STDERR:
Currently utils::menu() and utils::select.list() with graphics=FALSE
queries the user via the standard output (stdout). I'd like to
suggest to do this via standard error (stderr) instead, or at least
have an option to choose which output stream.
If they would send to stderr, they
On Tue, Apr 29, 2014 at 12:51 PM, Jeroen Ooms wrote:
> On Tue, Apr 29, 2014 at 6:37 AM, Gabriel Becker
> wrote:
> >
> > pkg::fun() will call function fun from the namespace of package pkg
> > *without loading it onto the search path*
>
> It is important to use conventional terminology here. The
On Tue, Apr 29, 2014 at 6:37 AM, Gabriel Becker wrote:
>
> pkg::fun() will call function fun from the namespace of package pkg
> *without loading it onto the search path*
It is important to use conventional terminology here. The package (and
its dependencies) gets loaded but not *attached*. The `
On Apr 29, 2014, at 6:39 AM, JaiReddy wrote:
> May I know if we have any C api(or any other way) in retrieving the parse
> error message after calling R_ParseVector?
>
R_ParseErrorMsg
But AFAICS it's not part of the API, so beware (although it's not hidden). By
now I think it's safer to use
Just a quick note because (perhaps embarassingly) I didn't know this for a
long time:
pkg::fun() will call function fun from the namespace of package pkg
*without loading it onto the search path*
> fastdigest::fastdigest("hi there")
[1] "6fed537931bd23b42d3046c4d80790a1"
> search()
[1] ".GlobalEn
On Mon, Apr 28, 2014 at 2:55 PM, Konrad Rudolph <
konrad.rudolph+r-de...@gmail.com> wrote:
>
> So this is my question: what do other people think? Which is the most
> useful and least confusing alternative from the usersâ perspective?
>
The most useful is alternative is "write packages".
The
May I know if we have any C api(or any other way) in retrieving the parse
error message after calling R_ParseVector?
--
View this message in context:
http://r.789695.n4.nabble.com/C-API-for-parse-error-tp4689662.html
Sent from the R devel mailing list archive at Nabble.com.
___
> Martin Maechler
> on Tue, 29 Apr 2014 10:41:19 +0200 writes:
>
> on Tue, 29 Apr 2014 08:25:41 + writes:
>> [...snip...]
>> Martin Maecher wrote:
>>> > I have now committed svn rev 65507 --- to R-devel only for now ---
>>> > the above: exact =
On Tue, Apr 29, 2014 at 10:41:19AM +0200, Martin Maechler wrote:
> >
> > on Tue, 29 Apr 2014 08:25:41 + writes:
>
> > [...snip...]
> > Martin Maecher wrote:
>
> >> > I have now committed svn rev 65507 --- to R-devel only for now ---
> >> > the above: exact =
> peter dalgaard
> on Tue, 29 Apr 2014 09:32:21 +0200 writes:
> On 28 Apr 2014, at 19:17 , Martin Maechler
wrote:
>>
> [...snip...]
I think there should be two separate discussions:
>>
a) have an option (argument to type.convert and possibly
>
> on Tue, 29 Apr 2014 08:25:41 + writes:
> [...snip...]
> Martin Maecher wrote:
>> > I have now committed svn rev 65507 --- to R-devel only for now ---
>> > the above: exact = NA is the default
>> > and it means "warning + FALSE".
>> >
>> > In
[...snip...]
Martin Maecher wrote:
> > I have now committed svn rev 65507 --- to R-devel only for now ---
> > the above: exact = NA is the default
> > and it means "warning + FALSE".
> >
> > Interestingly, I currently get 5 identical warnings for one
> > simple call, so there seems clearly ro
Dear R developers,
i have already send the question below to r-help but got no responses.
Perhaps it is more suitable for r-devel due to its rather technical
level. It would really help me to find a solution (or to find out that
there is none).
Is there any way to access/print/save the con
On 28 Apr 2014, at 19:17 , Martin Maechler wrote:
>
[...snip...]
>>> I think there should be two separate discussions:
>
>>> a) have an option (argument to type.convert and possibly
>>> read.table) to enable/disable this behavior. I'm strongly
>>> in favor of this.
>
>> In my (not committed)
14 matches
Mail list logo
