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:
>
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
https://stat.e
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 Calloc
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 calloc/free.
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:
ht
> 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 set
> 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 o
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 ha
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 cases)
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: Re
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++){
const
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 (!i
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 7
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, Wor
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 user
17 matches
Mail list logo