Hi Luke,
Thanks also for your feedback! I will then follow the proposed route for the
problem at hand and I will report back if I encounter any issues.
I am also going look into the issues of stack checking and R_ToplevelExec.
Regards,
Andreas
2019-05-20 19:29 GMT+02:00 Tierney, Luke:
> Your
Hi Simon,
Your response hits the mark of why I am doing it that way rather than going
with what Stepan proposed. Also good to hear that you consider my analysis to
be pretty complete. Thanks for the feedback!
Regards,
Andreas
2019-05-20 15:54 GMT+02:00 Simon Urbanek:
> Stepan,
>
> Andreas gave
Letting a user supply the autoprint function would be nice also. In a way
you can already do that, using addTaskCallback(), but that doesn't let you
suppress the standard autoprinting.
Having the default autoprinting do its own style of method dispatch doesn't
seem right.
Bill Dunlap
TIBCO Softw
I think there was a similar discussion to this when I raised the issue of
interpreting the sort order for an object versus its underlying type. In
this anyNA example it is the is.na for the object versus the is.na for the
type, whereas in the discussion below, which Gabriel Becker raised, it was
FWIW it was the intention of the patch to make printing of unclassed
functions consistent with other base types. This was documented in the
"patch 3" section:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17398
I think we need a general way to customise auto-printing for base types
and even
It also is a problem with storage.modes "integer" and "complex":
3.6.0> print.integer <- function(x,...) "integer vector"
3.6.0> 1:10
[1] 1 2 3 4 5 6 7 8 9 10
3.6.0> print(1:10)
[1] "integer vector"
3.6.0>
3.6.0> print.complex <- function(x, ...) "complex vector"
3.6.0> 1
> William Dunlap via R-devel
> on Thu, 16 May 2019 11:56:45 -0700 writes:
> In R-3.6.0 autoprinting was changed so that print methods for the storage
> modes are not called when there is no explicit class attribute. E.g.,
> % R-3.6.0 --vanilla --quiet
>> print.funct
> Harvey Smith
> on Wed, 1 May 2019 03:20:55 -0400 writes:
> Inside of the anyNA() function, it will use the legacy any(is.na()) code
if
> x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(),
but
> it is also TYPEOF(x) == REALSXP. Therefore, it will s
Thanks. Addressed in r76559 (trunk) and r76560 (R-3-6-branch).
Best,
luke
On Tue, 21 May 2019, Maëlle SALMON via R-devel wrote:
> Dear R-devel team,
>
> Many thanks for the great resource that is "Writing R Extensions"!
>
> I noticed two occurrences of "his", one to refer to the R package user,
Dear R-devel team,
Many thanks for the great resource that is "Writing R Extensions"!
I noticed two occurrences of "his", one to refer to the R package user, another
to refer to the R package author. Folks in these two groups are not all men, so
I suggest changing the word to "their" to make i
On Wed, May 1, 2019 at 7:45 AM Harvey Smith wrote:
>
> Inside of the anyNA() function, it will use the legacy any(is.na()) code if
> x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but
> it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster
> ITERATE_BY_REGIO
11 matches
Mail list logo
