Displaying 20 results from an estimated 500 matches similar to: "typos in src/main/gram.y (PR#8780)"
2008 Sep 03
8
suggestion of new API function for embedded programming.
While doing some embedded programming and trying to figure out how to generate
a hand coded SEXP equivalent of the line
"t.test(x,conf.level=(1-p))$conf.int[2]" I had an idea for an addition to the
embedded API.
There are a number of hidden or static parse functions (R_ParseBuffer,
R_Parse1Buffer, etc.) which take an IoBuffer* and returns a parsed tree. If
one or more of these
2004 Nov 12
1
plot.rpart ignores uniform=TRUE if graphics device is not open (PR#7361)
Full_Name: Hsiu-Khuern Tang
Version: 2.0.0
OS: Debian GNU/Linux
Submission from: (NULL) (156.153.255.236)
Hi all,
If fit is an rpart object,
plot(fit, uniform=TRUE)
ignores uniform=TRUE if the graphics device is not already open.
To reproduce this:
library("rpart")
example(plot.rpart)
dev.off() # <- works OK without this
plot(fit, uniform=TRUE) # <- uniform=TRUE is ignored
2019 Nov 30
2
Inconsistent behavior for the C AP's R_ParseVector() ?
Hi,
The behavior of
```
SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
```
defined in `src/include/R_ext/Parse.h` appears to be inconsistent depending
on the string to be parsed.
Trying to parse a string such as `"list(''=1+"` sets the
`ParseStatus` to incomplete parsing error but trying to parse
`"list(''=123"` will result in R sending a message to the
2001 Aug 07
1
cannot assign to NULL dimnames (PR#1042)
Full_Name: Hsiu-Khuern Tang
Version: 1.3.0
OS: GNU/Linux (Debian unstable)
Submission from: (NULL) (192.6.19.124)
Hi all,
I am not sure this is a bug rather than an intentional design, but here
goes:
If I do
> a <- matrix(1:4, nrow=2)
> dimnames(a)[[1]] <- c("a", "b")
I get the following error message because dimnames(a) is NULL:
Error: more elements
2008 Aug 04
2
Parsing code with newlines
Dear List,
When I try to parse code containing newline characters with R_ParseVector, I
get a compilation error. How can I compile code that includes comments and
newlines?
I am using the following:
void* my_compile(char *code)
{
SEXP cmdSexp, cmdExpr = R_NilValue;
ParseStatus status;
PROTECT (cmdSexp = allocVector (STRSXP, 1));
SET_STRING_ELT (cmdSexp, 0, mkChar (code));
2019 Nov 30
2
Inconsistent behavior for the C AP's R_ParseVector() ?
Hi again,
Beside R_ParseVector()'s possible inconsistent behavior, R's handling of
zero-length named elements does not seem consistent either:
```
> lst <- list()
> lst[[""]] <- 1
> names(lst)
[1] ""
> list("" = 1)
Error: attempt to use zero-length variable name
```
Should the parser be made to accept as valid what is otherwise possible
2019 Dec 07
2
Inconsistent behavior for the C AP's R_ParseVector() ?
Thanks for the quick response Tomas.
The same error is indeed happening when trying to have a zero-length
variable name in an environment. The surprising bit is then "why is this
happening during parsing" (that is why are variables assigned to an
environment) ?
We are otherwise aware that the error is not occurring in the R console,
but can be traced to a call to R_ParseVector() in
2015 Mar 11
2
Notes on building a gcc toolchain for Rtools (but not multilib)
On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote:
> On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler <avraham.adler at gmail.com> wrote:
>>
>> I successfully rebuilt R-devel_2015-03-09 with the most recent version
>> of Rtools tonight, building both ICU_531 and this time libcurl (7.39)
>> as well (and OpenBLAS, of course). The
2015 Mar 09
5
Notes on building a gcc toolchain for Rtools (but not multilib)
On Mon, Mar 9, 2015 at 3:50 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote:
>> Hi,
>>
>> [This is a follow-up to the "New version of Rtools for Windows" thread
>> in January, but I just subscribed and don't know how to reply to an
>> old thread -- my apologies.]
>
> I am planning to
2015 Mar 11
1
Notes on building a gcc toolchain for Rtools (but not multilib)
On Wed, Mar 11, 2015 at 1:23 PM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote:
> On Tue, Mar 10, 2015 at 10:47 PM, Avraham Adler <avraham.adler at gmail.com> wrote:
>> On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote:
>>> On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler <avraham.adler at gmail.com> wrote:
>>>>
2019 Dec 14
2
Inconsistent behavior for the C AP's R_ParseVector() ?
Le lun. 9 d?c. 2019 ? 09:57, Tomas Kalibera <tomas.kalibera at gmail.com> a
?crit :
> On 12/9/19 2:54 PM, Laurent Gautier wrote:
>
>
>
> Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a
> ?crit :
>
>> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>>
>> Thanks for the quick response Tomas.
>>
>> The same error
2015 Mar 10
2
Notes on building a gcc toolchain for Rtools (but not multilib)
----- Original Message -----
> From: "Duncan Murdoch" <murdoch.duncan at gmail.com>
> To: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at r-project.org
> Sent: Monday, March 9, 2015 10:40:02 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)
>
> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
> > On
2019 Dec 09
3
Inconsistent behavior for the C AP's R_ParseVector() ?
Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a
?crit :
> On 12/7/19 10:32 PM, Laurent Gautier wrote:
>
> Thanks for the quick response Tomas.
>
> The same error is indeed happening when trying to have a zero-length
> variable name in an environment. The surprising bit is then "why is this
> happening during parsing" (that is why
2015 Mar 10
3
Notes on building a gcc toolchain for Rtools (but not multilib)
----- Original Message -----
> From: "Duncan Murdoch" <murdoch.duncan at gmail.com>
> To: "Dan Tenenbaum" <dtenenba at fredhutch.org>
> Cc: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at r-project.org
> Sent: Tuesday, March 10, 2015 11:37:12 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)
2015 Mar 10
1
Notes on building a gcc toolchain for Rtools (but not multilib)
On Tue, Mar 10, 2015 at 4:07 AM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
> On 09/03/2015 11:02 PM, Hsiu-Khuern Tang wrote:
>> Hi Duncan,
>>
>> On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch
>> <murdoch.duncan at gmail.com> wrote:
>>> On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote:
>>>>
>>>> On Mon, Mar 9, 2015 at
2015 Mar 11
2
Notes on building a gcc toolchain for Rtools (but not multilib)
On 10/03/2015 3:17 PM, Duncan Murdoch wrote:
> On 10/03/2015 2:56 PM, Dan Tenenbaum wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Duncan Murdoch" <murdoch.duncan at gmail.com>
> >> To: "Dan Tenenbaum" <dtenenba at fredhutch.org>
> >> Cc: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at
2007 Apr 07
2
Rf_PrintValue problem with methods::show
Hi,
I think this is a bug (even though I can't find documentation
explicitly saying that it should work). Basically, Rf_PrintValue(obj)
fails when 'obj' is an S4 object that should be printed using show()
rather than print(). From the error message I'm guessing that the need
to use show is detected correctly but then show is not found.
"cbind2" in the code below is just
2015 Mar 11
2
Notes on building a gcc toolchain for Rtools (but not multilib)
On Tue, Mar 10, 2015 at 3:17 PM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
>
> That's a bug. I haven't tracked down what's going wrong with our
> regular code. If I can't find that and fix it soon, I'll make Internet2
> the default. For now, you can do it yourself using the instructions on
> ?setInternet2.
>
> Duncan Murdoch
I
2009 Jul 02
3
Question about <<- assignment
Is this expected behavior?
> z <- 1:5
> z[1] <<- 0
Error in z[1] <<- 0 : object "z" not found
The documentation seems to suggest that z will be found in the global
environment and modified accordingly.
Best,
Hsiu-Khuern.
2006 Oct 13
2
How to see if row names of a dataframe are stored compactly
Reading the list of changes for R version 2.4.0, I was happy to see that the
row names of dataframes can be stored compactly (as the integer n when
row.names(df) is 1:n).
help(row.names) contains this paragraph:
Row names of the form '1:n' for 'n > 2' are stored internally in a
compact form, which might be seen by calling 'attributes' but never
via