[Rd] freetype 2.5.1 and mono 3.2.5 (was Re: new bugs and new bundles Re: R/Sweave/cairo/freetype bug fix.)
The freetype people fixed the 2nd set of issues with system fonts shipped with Mac OS X, and released 2.5.1 almost immediately after that. So there are new bundles under http://sourceforge.net/projects/outmodedbonsai/files/R/ . Just a reminder that the official R binaries for windows/mac OS X are statically linked with rather dated versions of freetype with a few known issues. This affects the cairo-based functionalities in R. So a rebuild is needed. Most unix users should just upgrade their system's libfreetype, and dynamic-linking should take care of the rest. Also the routine upgrade of mono 3.2 5. It is, as usual, slightly adapted to run Illumina GenomeStudio and ...-like workloads on Linux and Mac OS X better. Hin-Tak Leung wrote: The most up-to-date version of freetype (2.5.0.1) have problems with at least two of the system fonts shipped with Mac OS X. So the "p1" in "2.5.0.1p1": cairo-1.12.16+freetype-2.5.0.1p1_macosx.tar.bz2 cairo-1.12.16+freetype-2.5.0.1p1_windows.tar.bz2 means "2.5.0.1" + 274207eb9a0e3bb20edf30e9a62e25120d5d15e5 (the fix for one of the problems). There might be p2 bundles if 2.5.1 doesn't come out soon enough with fixes for the rest of the problems. http://sourceforge.net/projects/outmodedbonsai/files/R/ Just so we are clear, if freetype have problem with a system font, fontconfig has problem with a system font, and cairo and R etc. Unix users should just upgrade. I'll get round to build R 2.15.3 (or 2.15.x) for windows and Mac OS X at some stage, but if somebody want to beat me to it, please feel free to do so. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dynamic lists at C level
Dear R-devel, I am trying to do something similar to dynamic length lists in R, but at C level. In R, that would be rather trivial: - determine the length of the list - create the list object - store the values for each component - access value components by using "[[" At C level, for a single component where I need to store a vector of length 5, I do: int *p_result; SEXP my_list = PROTECT(allocVector(VECSXP, 1)); SEXP result = SET_VECTOR_ELT(my_list, 0, allocVector(INTSXP, 5)); p_result = INTEGER(result); The number "1" (the length of "my_list") is dynamic, however. Is there a web reference where I could do some further reading on this topic? Thank you, Adrian -- Adrian Dusa Romanian Social Data Archive 1, Schitu Magureanu Bd. 050025 Bucharest sector 5 Romania Tel.:+40 21 3126618 \ +40 21 3120210 / int.101 Fax: +40 21 3158391 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dynamic lists at C level
Hi Adrian,
On 26 November 2013 at 18:12, Adrian Duşa wrote:
| Dear R-devel,
|
| I am trying to do something similar to dynamic length lists in R, but
| at C level.
|
| In R, that would be rather trivial:
| - determine the length of the list
| - create the list object
| - store the values for each component
| - access value components by using "[["
|
| At C level, for a single component where I need to store a vector of
| length 5, I do:
|
| int *p_result;
| SEXP my_list = PROTECT(allocVector(VECSXP, 1));
| SEXP result = SET_VECTOR_ELT(my_list, 0, allocVector(INTSXP, 5));
| p_result = INTEGER(result);
|
|
| The number "1" (the length of "my_list") is dynamic, however.
| Is there a web reference where I could do some further reading on this topic?
If you are open to C++, there is a fair amount of documentation for Rcpp
which some of us find easier.
Turing-equivalence does of course hold, and all we do here can also be done
at the C level given that we use the same 'SEXP foo(SEXP a, SEXP b, ...)'
interface -- while hiding most of it.
Here is a simple case where we define a creator function on the fly, compile,
link and load it and then have it creates lists of length 2 and 4, respectively:
R> library(Rcpp)
R> cppFunction("List adrian(int n) { return List(n); } ")
R> adrian(2)
[[1]]
NULL
[[2]]
NULL
R> adrian(4)
[[1]]
NULL
[[2]]
NULL
[[3]]
NULL
[[4]]
NULL
R>
Hope this helps, 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
Re: [Rd] dynamic lists at C level
On Tue, Nov 26, 2013 at 11:57 AM, Adrian Duşa wrote: [...] > I read the "Writing R Extensions" manual, I could only find how to > handle with R lists in C (section 5.9.6 Handling lists), but I could > not find how to a list in C, and access its components, and > this is basically where I got stuck. Create a new list with NEW_LIST(), set elements with SET_VECTOR_ELT(), query elements with VECTOR_ELT(). Search 'Writing R Extensions', and the R source code itself, and/or the source code of packages (authored by people you can trust, not my packages, please :), for the details. Gabor [...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dynamic lists at C level
Hi Dirk,
Thanks for your reply, at some point I did consider the possibility of
using Rcpp, but at that time I had already wrote a considerable amount
of regular C code.
Now I am only trying to extend that code a little, translating
everything in Rcpp would probably consume more time (although I agree
it might be easier to use).
I read the "Writing R Extensions" manual, I could only find how to
handle with R lists in C (section 5.9.6 Handling lists), but I could
not find how to a list in C, and access its components, and
this is basically where I got stuck.
Best,
Adrian
On Tue, Nov 26, 2013 at 6:43 PM, Dirk Eddelbuettel wrote:
>
> Hi Adrian,
>
> On 26 November 2013 at 18:12, Adrian Duşa wrote:
> | Dear R-devel,
> |
> | I am trying to do something similar to dynamic length lists in R, but
> | at C level.
> |
> | In R, that would be rather trivial:
> | - determine the length of the list
> | - create the list object
> | - store the values for each component
> | - access value components by using "[["
> |
> | At C level, for a single component where I need to store a vector of
> | length 5, I do:
> |
> | int *p_result;
> | SEXP my_list = PROTECT(allocVector(VECSXP, 1));
> | SEXP result = SET_VECTOR_ELT(my_list, 0, allocVector(INTSXP, 5));
> | p_result = INTEGER(result);
> |
> |
> | The number "1" (the length of "my_list") is dynamic, however.
> | Is there a web reference where I could do some further reading on this
> topic?
>
> If you are open to C++, there is a fair amount of documentation for Rcpp
> which some of us find easier.
>
> Turing-equivalence does of course hold, and all we do here can also be done
> at the C level given that we use the same 'SEXP foo(SEXP a, SEXP b, ...)'
> interface -- while hiding most of it.
>
> Here is a simple case where we define a creator function on the fly, compile,
> link and load it and then have it creates lists of length 2 and 4,
> respectively:
>
> R> library(Rcpp)
> R> cppFunction("List adrian(int n) { return List(n); } ")
> R> adrian(2)
> [[1]]
> NULL
>
> [[2]]
> NULL
>
> R> adrian(4)
> [[1]]
> NULL
>
> [[2]]
> NULL
>
> [[3]]
> NULL
>
> [[4]]
> NULL
>
> R>
>
> Hope this helps, Dirk
>
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
Adrian Dusa
Romanian Social Data Archive
1, Schitu Magureanu Bd.
050025 Bucharest sector 5
Romania
Tel.:+40 21 3126618 \
+40 21 3120210 / int.101
Fax: +40 21 3158391
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dynamic lists at C level
Hi Adrian, On 26 November 2013 at 18:57, Adrian Duşa wrote: | Thanks for your reply, at some point I did consider the possibility of | using Rcpp, but at that time I had already wrote a considerable amount | of regular C code. | | Now I am only trying to extend that code a little, translating | everything in Rcpp would probably consume more time (although I agree | it might be easier to use). Well there is no need to translate a single line. C++ works happily with your C code. But instead of creating the list in C (which you had difficulty with) you would create it in C++. | I read the "Writing R Extensions" manual, I could only find how to | handle with R lists in C (section 5.9.6 Handling lists), but I could | not find how to a list in C, and access its components, and | this is basically where I got stuck. Gabor gave you a good pointer. Grep'ing through existing packages is often a good idea. If you can stomach reading other people's code ;-) 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
Re: [Rd] dynamic lists at C level
On Tue, Nov 26, 2013 at 12:19 PM, Dirk Eddelbuettel wrote: [...] > Grep'ing through existing packages is often a > good idea. If you can stomach reading other people's code ;-) My experience is that you can learn at least as much from other people's code as from textbooks. Unless you are god, of course. :) Just choose wisely whose code you are reading. :) But this is getting a bit off-topic here. To be (slightly) on-topic: I would start checking out code from packages maintained by R-core members. Gabor [...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dynamic lists at C level
Thank you both, will then start from here. I didn't know that Rcpp could be fed with the C code, that's good to know...! Best wishes, Adrian On Tue, Nov 26, 2013 at 7:28 PM, Gábor Csárdi wrote: > On Tue, Nov 26, 2013 at 12:19 PM, Dirk Eddelbuettel wrote: > [...] >> Grep'ing through existing packages is often a >> good idea. If you can stomach reading other people's code ;-) > > My experience is that you can learn at least as much from other > people's code as from textbooks. Unless you are god, of course. :) > > Just choose wisely whose code you are reading. :) > > But this is getting a bit off-topic here. To be (slightly) on-topic: I > would start checking out code from packages maintained by R-core > members. > > Gabor > > [...] -- Adrian Dusa Romanian Social Data Archive 1, Schitu Magureanu Bd. 050025 Bucharest sector 5 Romania Tel.:+40 21 3126618 \ +40 21 3120210 / int.101 Fax: +40 21 3158391 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Blank lines in DESCRIPTION
Dear R-devel list,
I would like to enquire about the existence of blank lines in the
DESCRIPTION file.
Testing different possibilities with tools:::.read_description suggests
that starting or ending with blank lines is acceptable while blank lines
in the middle of the file get caught by
out <- tryCatch(read.dcf(dfile, keep.white = .keep_white_description_fields),
error = function(e) stop(gettextf("file '%s' is not in valid DCF
format",
dfile), domain = NA, call. = FALSE))
if (nrow(out) != 1)
stop("contains a blank line", call. = FALSE)
and produce the error.
However, the following news item from [1] seems to suggest that it
should not fail in case of such incorrect blank lines.
R CMD check no longer fails with an error if a ‘DESCRIPTION’ file incorrectly
contains a blank line. (Reported by Bill Dunlap.)
This has come up here [2], when github-specific information is appended
to a DESCRIPTION file that ends with a blank line.
Thank you very much in advance.
Best wishes,
Laurent
[1] http://cran.r-project.org/bin/windows/base/old/2.15.3/NEWS.R-2.15.3.html
[2] https://github.com/hadley/devtools/issues/383
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Blank lines in DESCRIPTION
Laurent,
blank lines between records are not allowed in DESCRIPTION, because they
separate paragraphs in DCF and a package must consist of a single paragraph.
This properly is used by R for multi-package DCF files where each paragraph
defines one package. Blank lines at the end may be tolerated, because there is
no second paragraph in that case. If you look at the commit you quote (r60495),
it specifically adds an error if there is more than one paragraph.
Cheers,
Simon
On Nov 26, 2013, at 6:03 PM, Laurent Gatto wrote:
> Dear R-devel list,
>
> I would like to enquire about the existence of blank lines in the
> DESCRIPTION file.
>
> Testing different possibilities with tools:::.read_description suggests
> that starting or ending with blank lines is acceptable while blank lines
> in the middle of the file get caught by
>
> out <- tryCatch(read.dcf(dfile, keep.white = .keep_white_description_fields),
>error = function(e) stop(gettextf("file '%s' is not in valid DCF
> format",
>dfile), domain = NA, call. = FALSE))
> if (nrow(out) != 1)
>stop("contains a blank line", call. = FALSE)
>
> and produce the error.
>
> However, the following news item from [1] seems to suggest that it
> should not fail in case of such incorrect blank lines.
>
> R CMD check no longer fails with an error if a ‘DESCRIPTION’ file incorrectly
> contains a blank line. (Reported by Bill Dunlap.)
>
> This has come up here [2], when github-specific information is appended
> to a DESCRIPTION file that ends with a blank line.
>
> Thank you very much in advance.
>
> Best wishes,
>
> Laurent
>
> [1] http://cran.r-project.org/bin/windows/base/old/2.15.3/NEWS.R-2.15.3.html
> [2] https://github.com/hadley/devtools/issues/383
>
> __
> 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
