Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0

2021-09-09 Thread Philippe GROSJEAN
Dear John,

The tcltk2 package on CRAN includes tablelist version 5.5. The latest 
development version on https://github.com/SciViews/tcltk2 includes tablelist 
version 6.9. The last version of tcltk2 was not pushed to CRAN yet because many 
Tcl/Tk packages were updated to higher versions and not everything is 
completely tested today (I just recently got a Mac M1 machine for testing on 
this system).

In the meantime, since I know you really want version 6.9 of tablelist, you can 
do remotes::install_github(“SciViews/tcltk2@25df401”), or inspect the code in 
tcltk2 to see how to include a pure-Tcl package and place it in Rcmdr (it 
weights roughly 1Mb).

Best,

Philippe

..<°}))><
 ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (Numerical Ecology
 ) ) ) ) )   Mons University, Belgium
( ( ( ( (
..

On 9 Sep 2021, at 23:44, John Fox mailto:j...@mcmaster.ca>> 
wrote:


Dear Brian,

Thank you for the additional explanation.

If I understand correctly, the X11 version of Tcl/Tk will continue to be 
distributed with the R CRAN Intel and arm64 builds because it is compatible 
with R.app. If so, the simplest solution is probably to distribute the patched 
TkTable package with these builds, for backwards compatibility (perhaps not 
just for the Rcmdr package).

Your instructions for including tktablelist with the Rcmdr package seem clear, 
and I'll give that a try in case TkTable continues to be unavailable in the 
arm64 build.

Best,
John

On 2021-09-09 4:57 p.m., Prof Brian Ripley wrote:
On 09/09/2021 21:34, John Fox wrote:
Dear Brian,

Thank you for responding so quickly. Please see below:
On 2021-09-09 2:59 p.m., Prof Brian Ripley wrote:
On 09/09/2021 19:03, John Fox wrote:
Dear Simon, Philippe, and list members,

I've encountered some Tcl/Tk-related issues with the Apple silicon arm64 build 
of R 4.1.0 for macOS. These issues affect the Rcmdr package, although they 
don't prevent it from working:

(1) Some fonts that are available for the Intel build appear to be missing from 
the arm64 build. Compare the screen shots of the Rcmdr main window at 
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png> 
(Intel build) and 
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png> 
(arm64 build). This problem is purely aesthetic.

It would be helpful to know what those fonts are.  This is likely to be a 
fontconfig issue and needs to be debugged by name.

I query the Tk default and fixed-width fonts via

 tclvalue(.Tcl("font actual TkDefaultFont -family")
 tclvalue(.Tcl("font actual TkFixedFont -family"))

and use those -- in the past, that produced pleasing font choices on all 
platforms. In the macOS Intel build, the resulting font families are "Verdana" 
and "Andale Mono"; in the arm64 build, "helvetica" and "courier". Perhaps the 
Intel and arm64 builds were just configured differently.
Yes, I think fontconfig was, and that may help Simon dig into this.

(2) The Tcl/Tk Tktable package is apparently absent from the arm64 build but 
still present in the Intel build. The Rcmdr detects its absence and suppresses 
some features (i.e., those requiring the Rcmdr data editor). I understand that 
the Tktable package is problematic and it may have been removed intentionally.

https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz 
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it uses 
'panic' which should be 'Tcl_Panic'.(The Intel build appears to be much 
older, 8.6.6.)

I have a patched version: AFAICS it installs entirely into /opt/R/arm64/lib I 
could tar it up and make it available.

I could also send the patch to Simon for future use, but note that 
https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk (not the 
X11 build in the CRAN build of R 4.1.[01]) and which does not support Tcl/Tk.

I'm sorry, but I don't quite understand that -- perhaps there's a typo here? Do 
you mean to say that an aqua build of Tcl/Tk will replace the X11 build after R 
4.1.1, and that Tktable will be incompatible with it?
There was, so let me expand.
There are two Tk implementations on macOS,
- using aqua, which is included in https://mac.r-project.org/libs-arm64/
- using X11, included in the CRAN distributions of R 4.1.[01] on amd64, and 
always used for Intel. So I do not have access to the details of that build.
As I recall, TkTable does not install for the aqua implementation, but does 
(when patched) for the X11 implementation.  My recollection is that XQuartz 
became available for amd64 not long before R 4.0.0 and Simon switched to X11 
Tk, although pre-releases had aqua Tk.
If so, first, I think that an aqua Tcl/Tk would be preferable to the current 

Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks

2013-11-28 Thread Philippe Grosjean

On 28 Nov 2013, at 14:38, John Fox j...@mcmaster.ca wrote:

 Dear Peter,
 
 On Thu, 28 Nov 2013 12:00:31 +0100
 peter dalgaard pda...@gmail.com wrote:
 
 On 28 Nov 2013, at 01:46 , John Fox j...@mcmaster.ca wrote:
 
 Hi Rob,
 
 I had some time today and so I started to implement this solution in the
 Rcmdr. I first tested whether setting
 
 system(defaults write org.R-project.R NSAppSleepDisabled -bool yes)
 
 fixes the problem; I verified via 
 
 system(defaults read org.R-project.R NSAppSleepDisabled)
 
 that the key was in fact set properly. 
 
 I'm afraid that even with NSAppSleepDisabled set, the Rcmdr still freezes
 periodically. Whatever is going on is probably more complicated than
 power-saving.
 
 
 Hmm. The tkfaq issue seems to have gone away for me. You did remember to 
 restart R.app after setting the key?
 
 
 I didn't remember to restart R.app because I didn't know that it was 
 necessary to do so. In fact, the code that I wrote, but didn't commit, for 
 the Rcmdr carefully resets the key to its previous state or deletes it if it 
 didn't previously exist when the Commander is closed.
 
 I think that you've almost surely identified my problem, but the solution 
 also raises a question about what to do. I'm reluctant to have the Rcmdr make 
 a permanent change to users' OS settings. I guess that I could detect whether 
 the NSAppSleepDisabled key is set and pop up a dialog box if it isn't, 
 offering to make the change, and suggesting that the user restart R.app. 
 (BTW, is there an easy way to check whether R is running in R.app or a 
 terminal?)

Look at svMisc::isAqua(), which uses indeed .Platform$GUI returning Aqua on 
R.app or X11 on R under a terminal. I am not sure, however, that R on a 
terminal returns *always* X11.
Best,

Philippe

 Wouldn't it be better to handle this issue in R.app or even in tcltk, however?
 
 If restarting R.app after setting the NSAppSleepDisabled key doesn't work for 
 me, I'll then pursue Rob's suggestions.
 
 Thanks for this,
 John




[…]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac