Hello Community,
can I link upstream/DEVELOPMENT_3_12
https://www.bioconductor.org/packages/devel/bioc/html/tidybulk.html
with a branch that is not master?
For example send a local branch called DEVELOPMENT_3_12 to be in the above
web page?
Thanks a lot.
Best wishes.
*Stefano *
Stefano
Hello Lori and All,
I confirm that the bioconductor page for a package (e.g.,
https://www.bioconductor.org/packages/release/bioc/html/tidybulk.html ) has
a bug in practice. Namely that even though the icon build is green
Jeroen, how "reactive" are the rtools40 scripts. Will they pull the latest
version committed by Dr. Tierney or is there something which must be done
manually prior to we end-users rebuilding from source?
Thank you,
Avi
On Sun, Jun 7, 2020 at 11:01 PM peter dalgaard wrote:
> Ah, I see it now:
Thanks, Uwe:
Now, metan is on its way to CRAN.
Best
Tiago
-Mensagem original-
De: Uwe Ligges
Enviada em: domingo, 7 de junho de 2020 14:09
Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
Assunto: Re: [R-pkg-devel] Additional issues for the last version released on
CRAN
sorry, release "versions"
On Mon, Jun 8, 2020 at 11:17 AM Abby Spurdle wrote:
>
> On Mon, Jun 8, 2020 at 4:09 AM Fox, John wrote:
> > Does it make sense to withdraw the Windows R 4.0.1 binary until the issue
> > is resolved?
>
> Yes, it does.
> All the release reversions should be removed.
On Mon, Jun 8, 2020 at 4:09 AM Fox, John wrote:
> Does it make sense to withdraw the Windows R 4.0.1 binary until the issue is
> resolved?
Yes, it does.
All the release reversions should be removed.
__
R-devel@r-project.org mailing list
Ah, I see it now:
The remapping of free() to Rm_free() and calloc() to Rm_calloc() happens in
memory.c, but not in tcltk.c; the macro Calloc in R_ext/RS.h maps to a call to
R_chk_alloc which is defined in memory.h; RS.h is included in tcltk.c, so
tcltk.c winds up calling Rm_calloc() via
I've committed the change to use Free instead of free in tcltk.c and
sys-std.c (r78652 for R-devel, r78653 for R-patched).
We might consider either moving Calloc/Free out of the Windows
remapping or moving the remapping into header files so everything
seeing our header files uses our
FWIW, you can "test" this by using the daily R builds. They are here:
https://ci.appveyor.com/project/jeroen/base/history
This is the build before the change, it does not crash:
https://ci.appveyor.com/project/jeroen/base/builds/32781690
This is the build right after the change, it does crash:
> On 7 Jun 2020, at 18:59 , Jeroen Ooms wrote:
>
> On Sun, Jun 7, 2020 at 5:53 PM wrote:
>>
>> On Sun, 7 Jun 2020, peter dalgaard wrote:
>>
>>> So this wasn't tested for a month?
>>>
>>> Anyways, Free() is just free() with a check that we're not freeing a null
>>> pointer, followed by
> On 7 Jun 2020, at 17:53 , luke-tier...@uiowa.edu wrote:
>
> On Sun, 7 Jun 2020, peter dalgaard wrote:
>
>> So this wasn't tested for a month?
>>
>> Anyways, Free() is just free() with a check that we're not freeing a null
>> pointer, followed by setting the pointer to NULL. At that point
Right, so "reply-all and and explain: Have these been fixed?"
Best,
Uwe Ligges
On 04.06.2020 15:16, Tiago Olivoto wrote:
Dear all,
I have submitted a patch release (1.6.0) of my package metan
(https://cran.r-project.org/web/packages/metan/) to fix an additional issue
and implement some
On Sun, Jun 7, 2020 at 5:53 PM wrote:
>
> On Sun, 7 Jun 2020, peter dalgaard wrote:
>
> > So this wasn't tested for a month?
> >
> > Anyways, Free() is just free() with a check that we're not freeing a null
> > pointer, followed by setting the pointer to NULL. At that point of tcltk.c,
> > we
There is one other possibility:
It may be that the calloc/free pair picked up by the tcltk package DLL
is different from the pair picked up when building base R. (We provide
our own malloc framework, but if the macros aren't quite right it may
be that the system malloc is picked up in some
Hi,
Does it make sense to withdraw the Windows R 4.0.1 binary until the issue is
resolved?
Best,
John
> -Original Message-
> From: luke-tier...@uiowa.edu
> Sent: Sunday, June 7, 2020 11:54 AM
> To: peter dalgaard
> Cc: Jeroen Ooms ; Fox, John ; r-
> de...@r-project.org
> Subject:
On Sun, 7 Jun 2020, peter dalgaard wrote:
So this wasn't tested for a month?
Anyways, Free() is just free() with a check that we're not freeing a null
pointer, followed by setting the pointer to NULL. At that point of tcltk.c, we
have
for (objc = i = 0; i < length(avec); i++){
So this wasn't tested for a month?
Anyways, Free() is just free() with a check that we're not freeing a null
pointer, followed by setting the pointer to NULL. At that point of tcltk.c, we
have
for (objc = i = 0; i < length(avec); i++){
const char *s;
char *tmp;
if
On 07/06/2020 10:00 a.m., Jeroen Ooms wrote:
On Sun, Jun 7, 2020 at 3:13 AM Fox, John wrote:
Hi,
The following code, from the examples in ?TkWidgets , immediately crashes R
4.0.1 for Windows:
- snip
library("tcltk")
tt <- tktoplevel()
label.widget
Dear Jeroen,
Thank you for tracking down the source of the problem.
You probably saw that Peter Dalgaard reported that the tcltk package apparently
is working fine in R 4.0.1 on macOS. I haven't confirmed that myself because
the Mac binary for R 4.0.1 isn't yet on CRAN.
Best,
John
> On Jun
On Sun, Jun 7, 2020 at 3:13 AM Fox, John wrote:
>
> Hi,
>
> The following code, from the examples in ?TkWidgets , immediately crashes R
> 4.0.1 for Windows:
>
> - snip
> library("tcltk")
> tt <- tktoplevel()
> label.widget <- tklabel(tt, text = "Hello,
Dear Peter,
First, thank you for following up on this problem.
Unless I somehow inexplicably missed it, as I just confirmed, the R 4.0.1
Windows installer *doesn't* ask to install support files for Tcl/Tk.
Nor am I only one to notice this problem. I was made aware of it when several
Rcmdr
John,
The Windows installation instructions document has the following. So, one
obvious question is whether you did select it. (I haven't installed on WIndows
for ages, so I don't know whether this was changed recently or even whether the
selection is on or off by default).
-pd
Using package
Just to be clear, I was talking about Mac binary packages. The one available
and tested was
R-4.0-branch
4.0.1 RC
(2020/05/30, r78644)
from mac.r-project.org. (Simon Urbanek out of office for the weekend, I
suppose.)
-pd
> On 7 Jun 2020, at 08:27 , peter dalgaard wrote:
>
> Not happening
Not happening on Mac, so likely a Windows build issue.
(There's no 4.0.1 CRAN package yet, and no nightly build of 4.0.1 Patched, but
the only thing changed in the sources since r78644 is the VERSION file.)
-pd
> On 7 Jun 2020, at 03:13 , Fox, John wrote:
>
> Hi,
>
> The following code,
24 matches
Mail list logo
