d idea.
Thanks very much!
Doug
From: Josiah Parry
Sent: Thursday, May 16, 2024 1:05 PM
To: ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA
Cc: R-devel@R-project.org
Subject: [Non-DoD Source] Re: [Rd] R for the US Air Force
You don't often get email from josiah.pa...@gma
my time here. That’s a
really good idea.
Thanks very much!
Doug
From: Josiah Parry
Sent: Thursday, May 16, 2024 1:05 PM
To: ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA
Cc: R-devel@R-project.org
Subject: [Non-DoD Source] Re: [Rd] R for the US Air Force
You don't often
Hey Doug,
R is not a product that is provided by a company or any vendor that can be
procured through a vendor e.g. something on a GSA schedule.
Seems like you're caught in the bureaucracy hell hole. I used to help the
USAF, and other DoD members use R when I was at RStudio (now Posit).
I
Hello,
The US Air Force used to have R available on our main network, but now those
who need to accept it back are
being very particular about what they're accepting in terms of official
documentation.
Would you be able to help me with this endeavor? I'm attaching a pdf that
shows what
The change suggested by Iago Giné Vázquez is indeed very simple. It
sets the background colour of the row and column headers to the
background of the rest of the dataentry window. With this patch, R
passes 'make check'. As Duncan Murdoch mentions, the X11 editor already
behaves this way.
If it's
A criticism of your suggestion is that it is not backwards compatible.
Does that matter? I don't know, but probably not. The X11 version of
the viewer does what you suggest.
Duncan Murdoch
On 2024-05-15 2:20 a.m., Iago Giné Vázquez wrote:
About the decisions:
Actually, the same way
About the decisions:
Actually, the same way dataedittext modifies the text colour not only
of data, but also of row and column names, and dataedituser modifies
the colour of all the borders, I think dataeditbg should modify the
background of all the window, at least that "inside" those
borders.
Hi,
as(x, "") is supported and does as.(x) for all
vector types except for raw. For example all the following coercions
work and do what you'd expect: as(1L, "logical"), as(1L, "double"),
as(1L, "complex"), as(1L, "character"), as(1L, "list"). But as(1L,
"raw") does not:
> as(1L, "raw")
Hello
On the other hand, i find that R_compact_intrange checks whether (r = n2 -
n1 + 1) >= R_XLEN_T_MAX, while seq_colon checks for (r = fabs(n2 - n1)) >=
R_XLEN_T_MAX. And only then n is defined as r + 1 + epsilon. r is not used
again
That is why seq_colon does not reject that size at first and
This seems like something that should be fairly easily doable. Why
don't you work out a patch?
Some decisions to make:
- What colours are we talking about? Would you want the labels to have
their colour set independent of the dialog colours? If so, would you
also want to configure the
Thanks again Duncan and Ivan,
I forward then the email to R-devel.
Summarizing, the dataedit options (in RGui preferences or RConsole) to
colouring the View output do not have effect on the background of the row
and column names (see https://ibb.co/Dkn2pVs).
Could this be implemented?
Thank
> Ivan Krylov via R-help
> on Tue, 14 May 2024 08:08:58 +0300 writes:
> Dear Ricardo Villalba, Thank you for spotting this corner
> case!
> В Mon, 13 May 2024 11:37:57 -0300 Ricardo Villalba
> пишет:
>> I track the messages to be coded here:
>>
On Mon, 13 May 2024, Ivan Krylov wrote:
[You don't often get email from ikry...@disroot.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
On Mon, 13 May 2024 09:54:27 -0500 (CDT)
luke-tierney--- via R-devel wrote:
Looks like I added that warning 22 years
On Mon, 13 May 2024 09:54:27 -0500 (CDT)
luke-tierney--- via R-devel wrote:
> Looks like I added that warning 22 years ago, so that should be enough
> notice :-). I'll look into removing it now.
Dear Luke,
I've got a somewhat niche use case: as a way of protecting myself
against rogue *.rds
On Sat, 11 May 2024, Peter Langfelder wrote:
On Sat, May 11, 2024 at 9:34 AM luke-tierney--- via R-devel
wrote:
On Sat, 11 May 2024, Travers Ching wrote:
The following code snippet causes R to hang. This example might be a
bit contrived as I was experimenting and trying to understand
Executive summary:
I believe revision 86265 makes it more difficult to build R with
OpenBLAS on Windows as now the entire LAPACK needs to be built to
obtain zspmv. Is there anything that can be done to allow the former
behavior to be used, something in Mkrules.local perhaps?
Detailed
On Sat, May 11, 2024 at 9:34 AM luke-tierney--- via R-devel
wrote:
>
> On Sat, 11 May 2024, Travers Ching wrote:
>
> > The following code snippet causes R to hang. This example might be a
> > bit contrived as I was experimenting and trying to understand
> > promises, but uses only base R.
>
>
On Sat, 11 May 2024, Travers Ching wrote:
The following code snippet causes R to hang. This example might be a
bit contrived as I was experimenting and trying to understand
promises, but uses only base R.
It looks like it is looking for "not_a_variable" recursively but since
it doesn't exist
The following code snippet causes R to hang. This example might be a
bit contrived as I was experimenting and trying to understand
promises, but uses only base R.
It looks like it is looking for "not_a_variable" recursively but since
it doesn't exist it goes on indefinitely.
x0 <- new.env()
x1
I am running a multilevel growth curve model to examine predictors of
social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a
continuous numeric variable. The age variable (Index1) has been coded as 0
for age 12, 1 for age 15 and 2 for age 18. I am currently using a time
varying
Dear Srinidhi,
You are trying to fit 1 random intercept and 2 random slopes per
individual, while you have at most 3 observations per individual. You
simply don't have enough data to fit the random slopes. Reduce the random
part to (1|ID).
Best regards,
Thierry
ir. Thierry Onkelinx
Statisticus
That should do it
Sent from my iPad
On Apr 30, 2024, at 9:57 AM, Iñaki Ucar wrote:
Many thanks both. I'll wait for Luke's confirmation to trigger the update with
the backported fix.
Iñaki
On Tue, 30 Apr 2024 at 12:42, Dirk Eddelbuettel
mailto:e...@debian.org>> wrote:
On 30 April 2024 at
Many thanks both. I'll wait for Luke's confirmation to trigger the update
with the backported fix.
Iñaki
On Tue, 30 Apr 2024 at 12:42, Dirk Eddelbuettel wrote:
>
> On 30 April 2024 at 11:59, peter dalgaard wrote:
> | svn diff -c 86235 ~/r-devel/R
>
> Which is also available as
>
>
On 30 April 2024 at 11:59, peter dalgaard wrote:
| svn diff -c 86235 ~/r-devel/R
Which is also available as
https://github.com/r-devel/r-svn/commit/f7c46500f455eb4edfc3656c3fa20af61b16abb7
Dirk
| (or 86238 for the port to the release branch) should be easily backported.
|
| (CC Luke in
svn diff -c 86235 ~/r-devel/R
(or 86238 for the port to the release branch) should be easily backported.
(CC Luke in case there is more to it)
- pd
> On 30 Apr 2024, at 11:28 , Iñaki Ucar wrote:
>
> Dear R-core,
>
> I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We
Dear R-core,
I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We
updated R to v4.4.0 in Fedora rawhide, F40, EPEL9 and EPEL8, so no problem
there. However, F38 and F39 will stay at v4.3.3, and I was wondering if
there's a specific patch available, or if you could point me
> Kurt Hornik writes:
Should be fixed now.
Best
-k
> Ivan Krylov via R-devel writes:
> Indeed, apparently using which.min/which.max on the string encoding is
> not good enough. ? which.min says that x can also be
> an R object for which the internal coercion to ‘double’ works
>
> Therneau, Terry M , Ph D writes:
> Let me give partial assent to Michael's suggestion: a) have an easy way to
> turn this on and b) add a strong suggestion to do so to the WRE manual.
> Kurt's example in the email shows how to do (a); but I just looked in the
> WRE manual and don't see
> Ivan Krylov via R-devel writes:
Indeed, apparently using which.min/which.max on the string encoding is
not good enough. ? which.min says that x can also be
an R object for which the internal coercion to ‘double’ works
and I guess we found a case where it does not work.
I'll look into
В Sat, 27 Apr 2024 13:56:58 -0500
Jonathan Keane пишет:
> In devel:
> > max(numeric_version(c("1.0.1.1", "1.0.3.1",
> "1.0.2.1")))
> [1] ‘1.0.1.1’
> > max(numeric_version(c("1.0.1.1000", "1.0.3.1000",
> "1.0.2.1000")))
> [1] ‘1.0.3.1000’
Thank
I've noticed something in R devel which seems a little off and not the
behavior I see in 4.4.0 or earlier versions. With numeric_versions that
have long (>8 digit) final components max and min return the first element
and not the max or min:
In devel:
> max(numeric_version(c("1.0.1.1",
I was horrified when I saw John Weinstein's article about Excel turning
gene names into dates. Mainly because I had been complaining about that
phenomenon for years, and it never remotely occurred to me that you could
get a publication out of it.
I eventually rectified the situation by publishing
On 2024-04-27 10:53 am, Mikael Jagan wrote:
Reading the body of function 'AnswerType' in bind.c, called from 'do_c'
and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically
in the recurse = TRUE case.
A corollary is that c(recursive = TRUE) and unlist(recursive = TRUE)
Reading the body of function 'AnswerType' in bind.c, called from 'do_c'
and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically
in the recurse = TRUE case.
A corollary is that c(recursive = TRUE) and unlist(recursive = TRUE)
treat expression vectors like expression(a, b)
Everyone, take a deep breath - there have been many disruptions in last few
days - some obvious, others associated with the R release and the BioC
disruptions on CRAN, so there is no need to panic and start devising
"solutions" for issues that are temporary. Things are being sorted out and some
On Fri, 26 Apr 2024 13:15:47 +0200
Gábor Csárdi wrote:
> That's not how this worked in the past AFAIR. Simply, the packages in
> the x.y.z/Recommended directories were included in
> src/contrib/PACKAGES*, metadata, with the correct R version
> dependencies, in the correct order, so that
On Fri, Apr 26, 2024 at 1:06 PM Ivan Krylov wrote:
>
> On Fri, 26 Apr 2024 12:32:59 +0200
> Martin Maechler wrote:
>
> > Finally, I'd think it definitely would be nice for
> > install.packages("Matrix") to automatically get the correct
> > Matrix version from CRAN ... so we (R-core) would be
On Fri, 26 Apr 2024 12:32:59 +0200
Martin Maechler wrote:
> Finally, I'd think it definitely would be nice for
> install.packages("Matrix") to automatically get the correct
> Matrix version from CRAN ... so we (R-core) would be grateful
> for a patch to install.packages() to achieve this
Since
On Fri, 26 Apr 2024, at 11:32 AM, Martin Maechler wrote:
>> Gábor Csárdi
>> on Fri, 26 Apr 2024 11:55:36 +0200 writes:
>
> > I don't know if this is a bug, but it is certainly weird. AFAICT R
> > 4.4.0 has Matrix 1.7-0.
>
> Yes, it *is* available from CRAN: You can see it
> Gábor Csárdi
> on Fri, 26 Apr 2024 11:55:36 +0200 writes:
> I don't know if this is a bug, but it is certainly weird. AFAICT R
> 4.4.0 has Matrix 1.7-0.
Yes, it *is* available from CRAN: You can see it when looking into the
4.4.0/ , specifically the
I don't know if this is a bug, but it is certainly weird. AFAICT R
4.4.0 has Matrix 1.7-0.
However, currently CRAN has
Package: Matrix
Version: 1.6-5
Priority: recommended
Depends: R (>= 3.5.0), methods
...
(plus another version for R >= 4.5.0 only).
Which has some weird consequences, e.g. if
On Thu, Apr 25, 2024 at 4:24 AM Ivan Krylov via R-devel
wrote:
>
> On Wed, 24 Apr 2024 15:31:39 -0500 (CDT)
> luke-tierney--- via R-devel wrote:
>
> > We would be better off (in my view, not necessarily shared by others
> > in R-core) if we could get to a point where:
> >
> > all entry
On 4/25/24 07:04, Kurt Hornik wrote:
...
> Sure, I'll look into adding something. (Too late for 4.4.0, of course.)
>
> Best
> -k
Great. Thanks!
H.
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
[[alternative HTML version deleted]]
On Thu, 25 Apr 2024 14:45:04 +0200
Jeroen Ooms wrote:
> Thoughts?
How verboten would it be to create an empty external pointer object,
add it to the preserved list, and set an on-exit finalizer to clean up
the curl multi-handle? As far as I can tell, the internet module is not
supposed to be
> Hervé Pagès writes:
> On 4/24/24 23:07, Kurt Hornik wrote:
>>> Hervé Pagès writes:
>>> Hi Kurt,
>>> Is it intended that numeric_version() returns an error by default on
>>> non-character input in R 4.4.0?
>> Dear Herve, yes, that's the intention.
>>
>>> It seems that I can turn this
> Dirk Eddelbuettel writes:
> Hi Kurt,
> On 25 April 2024 at 08:07, Kurt Hornik wrote:
> | > Hervé Pagès writes:
> |
> | > Hi Kurt,
> | > Is it intended that numeric_version() returns an error by default on
> | > non-character input in R 4.4.0?
> |
> | Dear Herve, yes, that's the
A clean build solves it for me too. Thank you!
(I need to add this to my "have you tried turning it off and back on
again?" list ...)
Ben
On 2024-04-25 8:07 a.m., luke-tier...@uiowa.edu wrote:
I saw it also on some of my Ubuntu builds, but the issue went away
after a make clean/make,
I'd like to raise this again now that 4.4 is out.
Below is a more complete patch which includes a function to properly
cleanup libcurl when R quits. Implementing this is a little tricky
because libcurl is a separate "module" in R, perhaps there is a better
way, but this works:
view:
Hi Kurt,
On 25 April 2024 at 08:07, Kurt Hornik wrote:
| > Hervé Pagès writes:
|
| > Hi Kurt,
| > Is it intended that numeric_version() returns an error by default on
| > non-character input in R 4.4.0?
|
| Dear Herve, yes, that's the intention.
|
| > It seems that I can turn this into
I saw it also on some of my Ubuntu builds, but the issue went away
after a make clean/make, so maybe give that a try.
Best,
luke
On Wed, 24 Apr 2024, Ben Bolker wrote:
I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone
else reproduce this?
View() seems to crash on
On Wed, 24 Apr 2024 15:31:39 -0500 (CDT)
luke-tierney--- via R-devel wrote:
> We would be better off (in my view, not necessarily shared by others
> in R-core) if we could get to a point where:
>
> all entry points listed in installed header files can be used in
> packages, at least
On 4/24/24 23:07, Kurt Hornik wrote:
>> Hervé Pagès writes:
>> Hi Kurt,
>> Is it intended that numeric_version() returns an error by default on
>> non-character input in R 4.4.0?
> Dear Herve, yes, that's the intention.
>
>> It seems that I can turn this into a warning by setting
>>
On Wed, 24 Apr 2024 19:35:42 -0400
Ben Bolker wrote:
> I'm using bleeding-edge R-devel, so maybe my build is weird. Can
> anyone else reproduce this?
>
>View() seems to crash on just about anything.
Not for me, sorry.
If you have a sufficiently new processor, you can use `rr` [*] to
> Hervé Pagès writes:
> Hi Kurt,
> Is it intended that numeric_version() returns an error by default on
> non-character input in R 4.4.0?
Dear Herve, yes, that's the intention.
> It seems that I can turn this into a warning by setting
>
On Wed, 24 Apr 2024, Hadley Wickham wrote:
A few more thoughts based on a simple question: how do you determine the
length of a vector?
Rf_length() is used in example code in R-exts, but I don't think it's
formally documented anywhere (although it's possible I missed it). Is using
in an
As suggested by Josh Ulrich, here's what I get when running under
valgrind.
$ R -d valgrind
==218120== Memcheck, a memory error detector
==218120== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==218120== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright
info
I'm using bleeding-edge R-devel, so maybe my build is weird. Can
anyone else reproduce this?
View() seems to crash on just about anything.
View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)
If I debug(View) I get to the last line of code with nothing
obviously
to make an explicit list of functions that
> > you consider to be part of the exported API, and then grandfather in
> > packages that used those functions prior to learning that we weren't
> > supposed to.
>
> Making a list and hoping that it will remain up to date is not
>
Hi Kurt,
Is it intended that numeric_version() returns an error by default on
non-character input in R 4.4.0? It seems that I can turn this into a
warning by setting
_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't seem
to be able to find any of this mentioned in the NEWS
On Wed, 24 Apr 2024, Hadley Wickham wrote:
That is not true at all - the presence of header does not constitute
declaration of something as the R API. There are cases where internal
functions are in the headers for historical or other reasons since the
headers are used both for the
> On Apr 25, 2024, at 12:55 AM, Hadley Wickham wrote:
>
>
>
> >>> That is not true at all - the presence of header does not constitute
> >> declaration of something as the R API. There are cases where internal
> >> functions are in the headers for historical or other reasons since the
> >>
A few more thoughts based on a simple question: how do you determine the
length of a vector?
Rf_length() is used in example code in R-exts, but I don't think it's
formally documented anywhere (although it's possible I missed it). Is using
in an example sufficient to consider a function to be part
> And in general, I'd urge R Core to make an explicit list of functions that
you consider to be part of the exported API
While I believe R Core is in the process of such clarification, I'd also
vote for this. Now that WRE has "experimental" category, and if we take the
current definition of
>
>
>
> >>> That is not true at all - the presence of header does not constitute
> >> declaration of something as the R API. There are cases where internal
> >> functions are in the headers for historical or other reasons since the
> >> headers are used both for the internal implementation and
> On Apr 24, 2024, at 12:52 AM, Hadley Wickham wrote:
>
>>
>>
>>
ALTREP is part of the official R api, as illustrated by the presence of
src/include/R_ext/Altrep.h. Everything declared in the header files in
>> that
directory is official API AFAIK (and I believe that is more
Let me give partial assent to Michael's suggestion: a) have an easy way to
turn this on
and b) add a strong suggestion to do so to the WRE manual. Kurt's example in
the email
shows how to do (a); but I just looked in the WRE manual and don't see any
reference to
it, nor any mention from R
>
>
>
> > > ALTREP is part of the official R api, as illustrated by the presence of
> > > src/include/R_ext/Altrep.h. Everything declared in the header files in
> that
> > > directory is official API AFAIK (and I believe that is more definitive
> than
> > > the manuals).
> > >
> >
> > That is not
> Michael Chirico writes:
Michael,
You may have seen that some time ago I added
check.R:cprof <- Sys.getenv("_R_CHECK_EXAMPLES_PROFILE_", "")
etc so one can use the _R_CHECK_EXAMPLES_PROFILE_ env var to specify a
profile to use when running the examples, e.g.
>>> Please see slide deck by Gabriel Becker, with L Tierney, M Lawrence
> and
> >> T
> >>> Kalibera.
> >>>
> >>>
> >>>
> >>
> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP
> >>>
> On Apr 23, 2024, at 10:29 AM, Hadley Wickham wrote:
>
>
>
> On Mon, Apr 22, 2024 at 5:14 PM Simon Urbanek
> wrote:
>
>
> > On Apr 22, 2024, at 7:37 PM, Gabriel Becker wrote:
> >
> > Hi Yutani,
> >
> > ALTREP is part of the official R api, as illustrated by the presence of
> >
On Mon, Apr 22, 2024 at 5:14 PM Simon Urbanek
wrote:
>
>
> > On Apr 22, 2024, at 7:37 PM, Gabriel Becker
> wrote:
> >
> > Hi Yutani,
> >
> > ALTREP is part of the official R api, as illustrated by the presence of
> > src/include/R_ext/Altrep.h. Everything declared in the header files in
> that
pdf
>>> <
>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf
>>>
>>>
>>> ALTREP framework implements an abstraction underneath traditional R C API
>>> - Generalizes whats underneath the API
>>> - Without changin
t; >
>>> >
>>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP
>>> > .pdf
>>> > <
>>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf
>>> >
>>>
Hi all,
What it says in the title. This is likely to cause a lot of CRAN packages
to fail (I can try and quantify this if seen fit), but I think it's for the
best. Packages should not (IMHO) be relying on partial matching in package
code / tests. One might be more permissive for vignette/examples
Forum/16-ALTREP
>> > .pdf
>> > <
>> https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP.pdf
>> >
>> >
>> > ALTREP framework implements an abstraction underneath traditional R C
>> API
>> > - Generalize
; > - Without changing how data are accessed
> > - Compatible with all C code which uses the API
> > - Compatible with R internals
> >
> >
> > I hope this helps,
> > Hernando
> >
> >
> > -Original Message-
> > From: R-dev
gt;
>
> -----Original Message-
> From: R-devel On Behalf Of Hiroaki Yutani
> Sent: Sunday, April 21, 2024 8:48 PM
> To: r-devel
> Subject: [Rd] Is ALTREP "non-API"?
>
> Writing R Extension[1] defines "API" as:
>
> Entry points which are do
this helps,
Hernando
-Original Message-
From: R-devel On Behalf Of Hiroaki Yutani
Sent: Sunday, April 21, 2024 8:48 PM
To: r-devel
Subject: [Rd] Is ALTREP "non-API"?
Writing R Extension[1] defines "API" as:
Entry points which are documented in this manual and declared in an
Writing R Extension[1] defines "API" as:
Entry points which are documented in this manual and declared in an
installed header file. These can be used in distributed packages and will
only be changed after deprecation.
But, the document (WRE) doesn't have even a single mention of ALTREP, the
0143
was 306 Charles Cox Drive Canton, GA 30115
470-758-0799
404-788-1216
From: George Ostrouchov
Sent: Wednesday, January 10, 2024 3:06 PM
To: r-devel@r-project.org
Cc: Mike Marchywka
Subject: Re: [Rd] using Paraview "in-situ" with R?
Gene names being misinterpreted by spreadsheet software (read.csv is
no different) is a classic issue in bioinformatics. It seems like
every practitioner ends up encountering this issue in due time. E.g.
https://pubmed.ncbi.nlm.nih.gov/15214961/
Tangentially, your code will be more efficient if you add the data
files to a *list* one by one and then apply bind_rows or
do.call(rbind,...) after you have accumulated all of the information
(see chapter 2 of the _R Inferno_). This may or may not be practically
important in your particular
As an aside, the odd format does not seem to bother data.table::fread() which
also happens to be my personally preferred workhorse for these tasks:
> fname <- "/tmp/r/filename.csv"
> read.csv(fname)
Gene SNP prot log10p
1 YWHAE 13:62129097_C_T 1433 7.35
2 YWHAE 4:72617557_T_TA
On 16/04/2024 7:36 a.m., Rui Barradas wrote:
Às 11:46 de 16/04/2024, jing hua zhao escreveu:
Dear R-developers,
I came to a somewhat unexpected behaviour of read.csv() which is trivial but worthwhile
to note -- my data involves a protein named "1433E" but to save space I drop
the quote so it
Hum...
This boils down to
> as.numeric("1.23e")
[1] 1.23
> as.numeric("1.23e-")
[1] 1.23
> as.numeric("1.23e+")
[1] 1.23
which in turn comes from this code in src/main/util.c (function R_strtod)
if (*p == 'e' || *p == 'E') {
int expsign = 1;
switch(*++p) {
case '-':
Às 11:46 de 16/04/2024, jing hua zhao escreveu:
Dear R-developers,
I came to a somewhat unexpected behaviour of read.csv() which is trivial but worthwhile
to note -- my data involves a protein named "1433E" but to save space I drop
the quote so it becomes,
Gene,SNP,prot,log10p
On 16 April 2024 at 10:46, jing hua zhao wrote:
| Dear R-developers,
|
| I came to a somewhat unexpected behaviour of read.csv() which is trivial but
worthwhile to note -- my data involves a protein named "1433E" but to save
space I drop the quote so it becomes,
|
| Gene,SNP,prot,log10p
|
Dear R-developers,
I came to a somewhat unexpected behaviour of read.csv() which is trivial but
worthwhile to note -- my data involves a protein named "1433E" but to save
space I drop the quote so it becomes,
Gene,SNP,prot,log10p
YWHAE,13:62129097_C_T,1433E,7.35
OK, I've moved your suggestions into the tracker for further discussion:
https://bugs.r-project.org/show_bug.cgi?id=18703
https://bugs.r-project.org/show_bug.cgi?id=18704
https://bugs.r-project.org/show_bug.cgi?id=18705
I will tackle a patch for 18705 to start with as the lowest-hanging fruit.
I think we should try to advance and hopefully finalize this
thread before we forget about it ..
> Michael Chirico n Thu, 11 Apr 2024 09:10:11 -0700 writes:
>> I would assume that
>> library(Matrix, include.only="isDiagonal")
>> implies that only `isDiagonal` ends up on the
On Sun, 14 Apr 2024, Matthew Kay wrote:
[You don't often get email from matthew@u.northwestern.edu. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi,
Short version of my question: Rf_applyClosure was marked
attribute_hidden in Oct 2023, and I am curious
Hi,
Short version of my question: Rf_applyClosure was marked
attribute_hidden in Oct 2023, and I am curious why and if there is an
alternative interface to it planned.
Long version:
I have been toying with building a package that makes it easier to do
non-standard evaluation directly using
> I would assume that
> library(Matrix, include.only="isDiagonal")
> implies that only `isDiagonal` ends up on the search path
This could also be a reasonable behavior, but neither does that happen
today.
> I think a far better approach to solve Michael's problem is simply to use
> fac2sparse
On Thu, 11 Apr 2024, Duncan Murdoch wrote:
On 11/04/2024 7:04 a.m., Martin Maechler wrote:
Michael Chirico
on Mon, 8 Apr 2024 10:19:29 -0700 writes:
> Right now, attaching the same package with different include.only=
has no
> effect:
> library(Matrix,
On 11/04/2024 7:04 a.m., Martin Maechler wrote:
Michael Chirico
on Mon, 8 Apr 2024 10:19:29 -0700 writes:
> Right now, attaching the same package with different include.only= has no
> effect:
> library(Matrix, include.only="fac2sparse")
> library(Matrix)
>
> Michael Chirico
> on Mon, 8 Apr 2024 10:19:29 -0700 writes:
> Right now, attaching the same package with different include.only= has no
> effect:
> library(Matrix, include.only="fac2sparse")
> library(Matrix)
> ls("package:Matrix")
> # [1] "fac2sparse"
Dear Henrik (and everyone else):
Here's a patch implementing support for immediateConditions in
'parallel' socket clusters. What do you think?
I've tried to make the feature backwards-compatible in the sense that
an older R starting a newer cluster worker will not pass the flag
enabling
Reminder that the registration deadline for this event is this Sunday.
On Wed, Mar 13, 2024, at 9:16 AM, Heather Turner wrote:
> Dear All,
>
> R Dev Day @ Imperial will take place on Friday 26 April at Imperial
> College London:
> https://pretix.eu/r-contributors/r-dev-day-imperial-2024/
>
>
Right now, attaching the same package with different include.only= has no
effect:
library(Matrix, include.only="fac2sparse")
library(Matrix)
ls("package:Matrix")
# [1] "fac2sparse"
?library does not cover this case -- what is covered is the _loading_
behavior of repeated calls:
> [library and
Thanks for the report. Fixed in R-devel and R-patched (both
R-4-4-branch and R-4-3-branch).
On Fri, 5 Apr 2024, June Choe wrote:
[You don't often get email from jchoe...@gmail.com. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
There seems to be a bug in
1 - 100 of 40997 matches
Mail list logo
