Re: [Rd] status of Java & rJava?
Simon, Java is still one of the most popular languages out there, in particular in large organizations. See e.g. https://www.tiobe.com/tiobe-index/ . However, there has been a lot of confusion because of Oracle's licencing change in 2019. But the good news is, there are more alternatives than ever. See e.g. https://labs.consol.de/development/2019/02/05/oracle-license-is-the-free-lunch-over.html . And also Oracle has a very interesting new VM significantly improving startup time, the community edition is under GPL-2. See https://www.graalvm.org/ . Cheers, Adrian Adrian Trapletti Steinstrasse 9b, 8610 Uster, Switzerland P +41 44 994 56 30 | M +41 79 103 71 31 adr...@trapletti.org | www.trapletti.org On Sun, Mar 29, 2020 at 12:02 PM wrote: > > ... > Message: 4 > Date: Sun, 29 Mar 2020 16:07:13 +1300 > From: Simon Urbanek > To: Spencer Graves > Cc: "r-devel@r-project.org" > Subject: Re: [Rd] status of Java & rJava? > Message-ID: <30424ef3-fd2e-44db-8d7a-c5ec976f4...@r-project.org> > Content-Type: text/plain; charset="us-ascii" > > Spencer, > > you could argue that Java is dead since Oracle effectively killed it by > removing all public downloads, but if you manage to get hold of a Java > installation then it works just fine with R. To my best knowledge there has > never been an issue if you installed rJava from source. macOS Catalina has > made binary distributions impossible due to additional restrictions on > run-time, but even that has been how solved with the release of rJava 0.9-12, > so please make sure you use the latest rJava. In most cases that I have seen > issues were caused by incorrect configuration (setting JAVA_HOME incorrectly > [do NOT set it unless you know what you're doing!], not installing Java for > the same architecture as R etc.). If you have any issues feel free to report > them. rJava 0.9-12 has quite a few changes that try to detect user errors > better and report them so I strongly suggest users to upgrade. > > Cheers, > Simon > > > > On 29/03/2020, at 9:18 AM, Spencer Graves > > wrote: > > > > Hello, All: > > > > > > Is Java being deprecated for R? > > > > > > I ask, because I've been unable to get rJava 0.9-11 to work under > > either macOS 10.15 or Windows 10, and I can't get rJava 0.9-12 to install > > -- and my Ecfun package uses it: I can't get "R CMD build Ecfun" to work > > on my Mac nor "R CMD check Ecfun_0.2-4" under Windows. Travis CI builds > > "https://github.com/sbgraves237/Ecfun"; just fine. > > > > > > The rJava maintainer, Simon Urbanek, has kindly responded to two of > > my three emails on this since 2020-03-20, but I've so far been unable to > > translate his suggestions into fixes for these problems. > > > > > > Should I remove rJava from Ecfun and see what breaks, then see if I > > can work around that? Should I provide the error messages I get for rJava > > from "update.packages()" and / or library(rJava) on both machines, with > > sessionInfo() to this list or to Stack Exchange or Stack Overflow? > > > > > > Since I'm getting so many problems with rJava on under both macOS and > > Windows 10, that suggests to me that potential users could have similar > > problems, and I should try to remove rJava from Ecfun. > > > > > > What do you think? > > Thanks, > > Spencer Graves > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ... > Subject: Digest Footer > > ___ > R-devel@r-project.org mailing list DIGESTED > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- > > End of R-devel Digest, Vol 205, Issue 21 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] status of Java & rJava?
I spoke too soon in saying that everything worked with OpenJDK:
"R CMD check Ecfun_0.2-4.tar.gz" using
"https://github.com/sbgraves237/Ecfun"; worked fine on my Mac but failed
with "error: DLL 'rJava' not found: maybe not installed for this
architecture?" under Windows 10. "00install.out" and
"Sys.getenv('PATH')" follow. "library(rJava)" seemed to work, and
"help(pac='rJava') displays 0.9-12. Suggestions? Thanks, Spencer Graves
* installing *source* package 'Ecfun' ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
*** arch - i386
Error: package or namespace load failed for 'Ecfun':
.onLoad failed in loadNamespace() for 'rJava', details:
call: library.dynam("rJava", pkgname, libname)
error: DLL 'rJava' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
*** arch - x64
ERROR: loading failed for 'i386'
* removing 'C:/Users/spenc/Documents/R/Ecfun/Ecfun.Rcheck/Ecfun'
##
> Sys.getenv('PATH')
[1] "C:\\Program Files\\R\\R-3.6.3\\bin\\x64;C:\\Program
Files\\AdoptOpenJDK\\jdk-11.0.6.10-hotspot\\bin;C:\\Program
Files\\Java\\jre1.8.0_241;C:\\Rtools\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program
Files\\Microsoft VS Code\\bin;C:\\Program Files\\Git\\cmd;C:\\Program
Files\\TortoiseSVN\\bin;c:\\programFiles\\ffmpeg\\ffmpeg-4.1\\;C:\\Program
Files\\Pandoc\\;C:\\Program Files\\MiKTeX
2.9\\miktex\\bin\\x64\\;C:\\Users\\spenc\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\spenc\\AppData\\Local\\GitHubDesktop\\bin;C:\\FFmpeg\\bin;C:\\RBuildTools\\3.5\\bin;C:\\Program
Files\\R\\R-3.6.3\\bin;C:\\Users\\spenc\\AppData\\Local\\Microsoft\\WindowsApps;C:\\RBuildTools\\3.5\\;"
On 2020-03-28 23:07, Prof Brian Ripley wrote:
On 29/03/2020 04:07, Simon Urbanek wrote:
Spencer,
you could argue that Java is dead since Oracle effectively killed it
by removing all public downloads, but if you manage to get hold of a
Java installation then it works just fine with R. To my best
knowledge there has never been an issue if you installed rJava from
source. macOS Catalina has made binary distributions impossible due
to additional restrictions on run-time, but even that has been how
solved with the release of rJava 0.9-12, so please make sure you use
the latest rJava. In most cases that I have seen issues were caused
by incorrect configuration (setting JAVA_HOME incorrectly [do NOT set
it unless you know what you're doing!], not installing Java for the
same architecture as R etc.). If you have any issues feel free to
report them. rJava 0.9-12 has quite a few changes that try to detect
user errors better and report them so I strongly suggest users to
upgrade.
There is OpenJDK, and https://adoptopenjdk.net provides binaries for
macOS, including the preferred Java 11 LTS. I just re-checked that,
and after
env
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
R CMD javareconf
I was able to install from source and check rJava 0.9-12 in 4.0.0
alpha. For the CRAN binary of 3.6.3 I had to make sure I was using
clang 7: 'clang' defaults to that in the Apple CLT which does not
support -fopenmp -- but the binary package just worked.
[All on Catalina.]
Thanks. That worked on Catalina. When installing OpenJDK on Windows
10, The default for "Set JAVA_HOME" was 'X'; I changed that to
install. It didn't work at first, but did after I rebooted.
Thanks again to both Simon Urbanek and Prof. Ripley. Spencer Graves
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is.vector could handle AsIs class better
Dear R-devel, AsIs class seems to be well handled by `typeof` and `mode` function. Those two functions are being referred when explaining `is.vector` behaviour in manual. Yet `is.vector` does not seem to be handling AsIs class the same way. is.vector(1L) #[1] TRUE is.vector(I(1L)) #[1] FALSE Is there any reason behind this behaviour? Could we have it supported so AsIs class is ignored when `is.vector` is doing its job? Best Regards, Jan Gorecki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.vector could handle AsIs class better
Jan, I believe it's because it has "a non-NULL attribute other than names" as per the documentation. In this case its class of "AsIs". Best, ~G On Sun, Mar 29, 2020 at 6:29 AM Jan Gorecki wrote: > Dear R-devel, > > AsIs class seems to be well handled by `typeof` and `mode` function. > Those two functions are being referred when explaining `is.vector` > behaviour in manual. Yet `is.vector` does not seem to be handling AsIs > class the same way. > > is.vector(1L) > #[1] TRUE > is.vector(I(1L)) > #[1] FALSE > > Is there any reason behind this behaviour? > Could we have it supported so AsIs class is ignored when `is.vector` > is doing its job? > > Best Regards, > Jan Gorecki > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Thanks, Paul. I've created a bug report to keep track of this (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17748), and taken the liberty of adding you to CC. We'll need to cherry-pick the fix for R 3.6.3 in Fedora 31. Iñaki On Sun, 29 Mar 2020 at 21:15, Paul Murrell wrote: > > Hi > > Thanks for your input on this Iñaki and Nicolas. > > I am starting testing an R fix for this problem today. > > As suggested, the plan is to allow the R user to specify a font family > other than "symbol" for plotmath output (or, more generally, in R > parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. > > Paul > > > On 27/03/20 11:30 pm, Iñaki Ucar wrote: > > On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot > > wrote: > >> > >> > >> > >> R brought this all on itself by hardcoding a Windows-only “Symbol” font > >> family name in its default conf. Linux systems are UTF-8 by default for > >> ~20 years now, they don’t need the forcing of magic font families to > >> handle symbols not present in the 8-bit legacy Windows encodings. > >> > >> The actual effect of this conf is not the selection of font files with > >> special and unusual symbols. It is to priorize fonts that match the > >> "Symbol" magic name. And those fonts are few and crumbling on Linux > >> systems, because no one has needed to bother with them since Linux > >> switched to UTF-8 last millenium. > >> > >> Just stop using “Symbol” in R and things will work a lot better. > >> Alternatively, prepare to maintain the “Symbol” aliasing stack in > >> fontconfig (and fight with wine for it), because *no* *one* *else* > >> *cares* about this legacy Windows-specific stuff. > > > > So, in the light of Nicolas' input (thanks!), I think that font > > selection should be fixed upstream in R. I'd be happy to put all this > > together in R's bugzilla, but I don't have an account. Could someone > > please invite me? > > > > Iñaki > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
I do my devel/patch work on Mac so I can take a shot at testing your branch in the next couple days. ~G On Sun, Mar 29, 2020 at 7:24 PM Paul Murrell wrote: > Hi > > I have created an R branch that contains a potential fix ... > > https://svn.r-project.org/R/branches/R-symfam/ > > This allows, for example, ... > > cairo_pdf(symbolfamily="OpenSymbol") > > ... to specify that the OpenSymbol family should be used as the "symbol" > font (e.g., for "plotmath") in R. > > This is just a separate branch for now because, while I have tested it > under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows > (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at > this stage of the release process for R 4.0.0. > > The attached file contains at least an outline of steps required to do a > minimal test if anyone wants to try the fix on Linux. > > cc'ing Simon and Jeroen in case they are able to help with checking that > this builds and works on Mac and/or Windows. > > NOTEs: > - 'symbolfamily' can only be specified when a graphics device is opened, > and it is then fixed for that device. > - on Windows, for cairo-based devices, the "symbol" font is still > hard-coded as "Standard Symbols L" > > Paul > > On 30/03/20 8:15 am, Paul Murrell wrote: > > Hi > > > > Thanks for your input on this Iñaki and Nicolas. > > > > I am starting testing an R fix for this problem today. > > > > As suggested, the plan is to allow the R user to specify a font family > > other than "symbol" for plotmath output (or, more generally, in R > > parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. > > > > Paul > > > > > > On 27/03/20 11:30 pm, Iñaki Ucar wrote: > >> On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot > >> wrote: > >>> > >>> > >>> > >>> R brought this all on itself by hardcoding a Windows-only “Symbol” font > >>> family name in its default conf. Linux systems are UTF-8 by default for > >>> ~20 years now, they don’t need the forcing of magic font families to > >>> handle symbols not present in the 8-bit legacy Windows encodings. > >>> > >>> The actual effect of this conf is not the selection of font files with > >>> special and unusual symbols. It is to priorize fonts that match the > >>> "Symbol" magic name. And those fonts are few and crumbling on Linux > >>> systems, because no one has needed to bother with them since Linux > >>> switched to UTF-8 last millenium. > >>> > >>> Just stop using “Symbol” in R and things will work a lot better. > >>> Alternatively, prepare to maintain the “Symbol” aliasing stack in > >>> fontconfig (and fight with wine for it), because *no* *one* *else* > >>> *cares* about this legacy Windows-specific stuff. > >> > >> So, in the light of Nicolas' input (thanks!), I think that font > >> selection should be fixed upstream in R. I'd be happy to put all this > >> together in R's bugzilla, but I don't have an account. Could someone > >> please invite me? > >> > >> Iñaki > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > p...@stat.auckland.ac.nz > http://www.stat.auckland.ac.nz/~paul/ > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
