Re: [Rd] Maintainer NOTE in R CMD Check
On 09.03.2014 06:29, Michael Sumner wrote:
I believe it's just a flag to notify that the author string has changed.
You might need to send a confirmation email that yes you did mean to
change, it is just a double check for both ends. I changed my email for a
package once for some reason and made the confirmation.
Cheers, Mike
On 9 Mar 2014 12:06, "S Ellison" wrote:
Using R 3.0.3 and Rtools 31, I now see a Note (reproduced on my R-forge
checks) of the form
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'firstname A B lastname '
This is just a Note that reminds CRAN maintainers to check that the
submission comes actually from his maintainer and not anybody else.
Best,
Uwe Ligges
where A and B are middle initials.
I can change to a 'firstname lastname' form or 'INITS lastname' form and
that removes the above Note*, but I then get a Note warning of maintainer
change.
Is either Note going to get in the way of CRAN submission? (And if one of
them will, which one?)
S Ellison
*A minor aside: I couldn't find any documented reason for that, or indeed
any restriction on the format of a maintaner's name other than 'name first
email second in <>'; perhaps I missed something there?
***
This email and any attachments are confidential. Any u...{{dropped:10}}
__
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] 2 bugs in R's grDevices, and fixes.
Since R 3.0.3 is just around the corner and the problem is still there, here is
a repost from around the new year.
Hin-Tak Leung wrote:
Just before the holiday, I asked the freetype developers what is the context
of these two comments about freetype in the code of R's grDevices:
=== R/src/library/grDevices/src/cairo/cairoFns.c around line 720 =
/* some FreeType versions have broken index support,
fall back to index 0 */
if (!FT_New_Face(ft_library,
(const char *) file, index, &face) ||
(index && !FT_New_Face(ft_library,
(const char *) file, 0, &face))) {
FcFontSetDestroy (fs);
#ifdef __APPLE__
/* FreeType is broken on OS X in that face index
is often wrong (unfortunately even for Helvetica!)
- we try to find the best match through enumeration.
And italic and bold are swapped */
if (style == 2) style = 1; else if (style == 1) style = 2;
==
It turned out that the R developers are accumulating a few mistakes,
which over the years gradually "somewhat" cancel each others out, at
the expenses of other applications misbehaving on Mac OS X.
Freetype is shipped with, and part of Mac OS X.
The bottom line is that there are two ways of building freetype on Mac OS X,
one against the Carbon API (i.e. Mac OS Classic), and the other against
the POSIX API(i.e. modern unix systems). Apple have always shipped the
Carbon build.
The "problem", or "broken" issues experienced by R users are because
the official binary of R has a private copy of freetype, and also
that is built differently from Apple's. The two copies both read and write
the public fontconfig's cache for fonts' metadata, with unpredictable
results to any application that uses fonts - which basically means every
GUI-based application.
The two builds differ by the "--with-old-mac-fonts" option, which
"allow Mac resource-based fonts to be used". They differ also on treatments
of dfonts (an intermediate font format from the transition of
Classic to X). Helvetica, Times, Courier, Geneva, Monaco are still currently
shipped as dfonts on Mac OS X.
Here are the two correct ways of doing things:
1. put either build in /usr/local, and use just one of it dynamically,
for everything.
2. if a private copy of freetype needs to be bundled, and that this
private copy interacts with the public font cache, it has to be
a Carbon build.
The freetype developers also kindly offer a 3rd option
- e2d2b1544f24413fa62e0c845184b429eb227e9d -
made on 27th Dec, to make the POSIX build matches the behavior of
the Carbon build on caching dfonts. For those unfortunate people
who alternate between using different builds on a daily or even hourly
basis, forced upon them by application binary builders.
Somewhat related, I have finally gotten round to make two small bundles,
which replace the small cairo.dll/cairo.so' in the official
windows or Mac R binaries, to fix quite a few problems with them,
the first of which was reported almost a year ago. Just move the two
small files in the official binaries aside and replace them by these:
http://sourceforge.net/projects/outmodedbonsai/files/R/
R-2.15.3-library-grDevices-libs-winCairo.zip
R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz
The windows dlls had been tested and verified to fix the original
problem. BTW, it is quite a challenge to try to plot
R graphs with non-latin texts using English windows. (also posted).
I'll post the test results for Mac OS X when I get round to it. Those
should be easier to do.
YMMV. The move/rename can always be reverted if things don't work out.
The code mentioned above at the begining should be removed (and was
removed before building the bundle). It penalizes some mac R users who
build R himself/herself to end up with a broken build.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bundling vendor library inside a package
If I have a vendor library (say libvendor.so) that I want my package to link to, what is the "right way" to bundle that inside my package? My ideal outcome would be that the package can be installed from tarball without having to worry about installing anything to /usr/lib or tweaking some systemwide variables. This isn't for public distribution so I'm not worried about CRAN restrictions or licensing issues. I'm running R 3.0.2 on Linux. I've put the library in the inst directory of my package, and provided PKG_LIBS=-L../inst -lvendor. That works for compilation but then I need to provide LD_LIBRARY_PATH for R to find the library at runtime. This seems like it must be a common problem, but after hours of Googling I haven't seen a straightforward answer. Thanks in advance, John [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] AIX 7.1 and R build problems
Has anyone managed to build R-3.0.2 from source on AIX 7.1 using gcc 4.2.0. The configure script finishes with: ... checking whether wctrans exists and is declared... no checking whether iswblank exists and is declared... no checking whether wctype exists and is declared... no checking whether iswctype exists and is declared... no configure: error: Support for MBCS locales is required. Scanning through the config.log the configure script seems to be happy with the C99 compliance at hand. I have tried reading NEWS, README, and R-Help archives but I can't get past this. I'm all Google'd out. Is my compiler too old? _ Michael Beddo Senior Scientist Data Ventures, Inc. 1475 Central Ave. Suite 230 | Los Alamos, NM 87544 tel 505.695.2132 http://www.dataventures.com | "Advanced - Effective - Actionable - Proven. Analytics" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bundling vendor library inside a package
On 6 March 2014 at 10:56, John Laing wrote: | If I have a vendor library (say libvendor.so) that I want my package to | link to, what is the "right way" to bundle that inside my package? My ideal | outcome would be that the package can be installed from tarball without | having to worry about installing anything to /usr/lib or tweaking some | systemwide variables. This isn't for public distribution so I'm not worried | about CRAN restrictions or licensing issues. I'm running R 3.0.2 on Linux. | | I've put the library in the inst directory of my package, and provided | PKG_LIBS=-L../inst -lvendor. That works for compilation but then I need to | provide LD_LIBRARY_PATH for R to find the library at runtime. As it is a local package, you could use the 'rpath' directive to encode the path to you vendor library in the shared library object which your package creates. >From http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html One link option you might use is ld's ``rpath'' option, which specifies the runtime library search path of that particular program being compiled. From gcc, you can invoke the rpath option by specifying it this way: -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH) If you use this option when building the library client program, you don't need to bother with LD_LIBRARY_PATH (described next) other than to ensure it's not conflicting, or using other techniques to hide the library. It work as long as you never change the underlying path. Which is a fine assumption as long you use the same R installation path -- which is quite likely. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
