Hi,
In R < 3.0.0, we used to get:
> substring(c(A="abcdefghij", B="123456789"), 2, 6:2)
A B A B A
"bcdef" "2345" "bcd""23" "b"
But in R >= 3.0.0, we get:
> substring(c(A="abcdefghij", B="123456789"), 2, 6:2)
[1] "bcdef" "2345" "bcd" "23"
Gabor
I agree with you. There's Travis CI, and r-travis -- an attempt to
integrate R package testing with Travis. Pushing back to GitHub is
possible, but the setup is somewhat difficult. Also, this can be subject
to race conditions because each push triggers a test run and they can
happen in
Pushing back to github is not so difficult. See e.g
http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html
You can manage branches easily in travis. You could for example decide to do
something different if you are on the master branch ...
Romain
Le 13 déc. 2013 à 12:03, Kirill Mü
>
> It would have those benefits, but it would be harder to prototype
> changes by actually replacing the `if` function. Implementations that
> want to optimize the calls have other ways to do it, e.g. the sorts of
> things the compiler does.
>
Does anyone actually prototype changes to the `if` f
On 12/13/2013 12:50 PM, Romain Francois wrote:
> Pushing back to github is not so difficult. See e.g
> http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html
Thanks for the writeup, I'll try this. Perhaps it's better to push the
results of `R CMD build`, though.
> You can manage branche
>> It would have those benefits, but it would be harder to prototype
>> changes by actually replacing the `if` function. Implementations that
>> want to optimize the calls have other ways to do it, e.g. the sorts of
>> things the compiler does.
>>
>
> Does anyone actually prototype changes to the
On 13-12-13 8:36 AM, Justin Talbot wrote:
It would have those benefits, but it would be harder to prototype
changes by actually replacing the `if` function. Implementations that
want to optimize the calls have other ways to do it, e.g. the sorts of
things the compiler does.
Does anyone actua
On Dec 11, 2013, at 7:30 PM, Hin-Tak Leung wrote:
> Here is a rather long discussion etc about freetype 2.5.2, problem with the
> survival package, and build R 2.15.x with gcc 4.8.x. Please feel free to skip
> forward.
>
> - freetype 2.5.2:
>
> the fix to cope with one of the Mac OS X's syste
On Dec 11, 2013, at 7:30 PM, Hin-Tak Leung wrote:
> Here is a rather long discussion etc about freetype 2.5.2, problem with the
> survival package, and build R 2.15.x with gcc 4.8.x. Please feel free to skip
> forward.
>
> - freetype 2.5.2:
>
> the fix to cope with one of the Mac OS X's syste
On 12/11/2013 4:39 PM, Kirill Müller wrote:
Hi
Quite a few R packages are now available on GitHub long before they
appear on CRAN, installation is simple thanks to
devtools::install_github(). However, it seems to be common practice to
keep the .Rd files (and NAMESPACE and the Collate section in
On Fri, Dec 13, 2013 at 6:03 AM, Kirill Müller
wrote:
> Gabor
>
> I agree with you. There's Travis CI, and r-travis -- an attempt to integrate
> R package testing with Travis. Pushing back to GitHub is possible, but the
> setup is somewhat difficult. Also, this can be subject to race conditions
>
It seems like an easy solution to the "users don't know make" problem is to
provide a make file which runs any R code it finds in
pkg/inst/preinstall/preinstall.R, perhaps in dev_tools/inst/extras or
simply from a website.
That way the users don't need to know make, they just need to know what to
FWIW this is essentially what RForge.net provides. Each GitHub commit triggers
a build (branches are supported as the branch info is passed in the WebHook)
which can be either "classic" R CMD build or a custom shell script (hence you
can do anything you want). The result is a tar ball (which inc
Oh, I didn't know RForge.net supported external git repos, cool!
Gabor
On Fri, Dec 13, 2013 at 3:14 PM, Simon Urbanek
wrote:
> FWIW this is essentially what RForge.net provides. Each GitHub commit
> triggers a build (branches are supported as the branch info is passed in the
> WebHook) which c
Btw. one thing that probably would not work (well) with RForge.net (or
another CRAN-like repo), is the multiple branches.
The problem is that you cannot put the branch name in the package
version string, because that is not allowed, and then the versions
from the multiple branches get mixed up. Th
Thanks a lot. This would indeed solve the problem. I'll try mkdist today ;-)
Is the NEWS file parsed before of after mkdist has been executed?
Would you be willing to share the code for the infrastructure, perhaps
on GitHub?
-Kirill
On 12/13/2013 09:14 PM, Simon Urbanek wrote:
FWIW this i
On 12/13/2013 06:09 PM, Brian Diggs wrote:
One downside I can see with this third approach is that by making the
package documentation generation part of the build process, you must
then make the package depend/require roxygen (or whatever tools you
are using to generate documentation). This de
17 matches
Mail list logo