Re: [Rd] Snippets from other packages/ License
Thanks Brian and Hadley, these all seem to be reasonable approaches! (For the current package I think I'll depend on the other one, but it's good to know how to proceed for future situations …). Felix Am 14.03.2013 um 16:52 schrieb Hadley Wickham : >> If you wish to fork the original code and include the code directly in >> your package, then your package will also need to be GPL>=3, you will need >> to list the authors of that code as Contributors in your DESCRIPTION file, >> and I would strongly recommend that you place this code in a separate .R >> file in your package, with a separate Copyright and License comment block in >> that separate file stating the origins and license for this code snippet. > > Another option is to email the original author and ask if they'd be > willing to license the code to you under whatever license your package > currently uses. > > Hadley > > -- > Chief Scientist, RStudio > http://had.co.nz/ > > __ > 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] removing union class
> Renaud Gaujoux
> on Wed, 13 Mar 2013 13:10:44 +0200 writes:
> Hi,
> I get the following error when trying to remove a union class:
>> setClassUnion('a', c('matrix', 'numeric'))
>> removeClass('a')
>> sessionInfo()
> R version 2.15.3 (2013-03-01)
> Platform: i686-pc-linux-gnu (32-bit)
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=C LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> Is this normal? Am I doing something wrong?
Well,... you forgot to show the error (and the traceback) :
> setClassUnion('a', c('matrix', 'numeric'))
> removeClass('a')
Error in .getClassFromCache(Class, where) : node stack overflow
> traceback()
1888: .getClassFromCache(Class, where)
1887: getClass(cl)
1886: checkAtAssignment("classRepresentation", "contains", "list")
1885: .deleteSuperClass(cdef, superclass)
1884: .removeSuperClass(subclass, superclass)
..
..
3: .deleteSuperClass(cdef, superclass)
2: .removeSuperClass(what, Class)
1: removeClass("a")
>
So that looks indeed like a bug in R's removeClass() or its
helper functions.
Note that this problem is somewhat dependent on the use of the
infamous "matrix" class {not properly defined as a class in S3,
as it may or may not have dimnames, and then tried to be made S4
compatible "as well as possible" in the methods package, see
getClass("matrix")
Of course, I could not have thought of a realistic situation
where this was a problem, but then you exemplify one :
> Hadley, this is problematic for devtools, because load_all tries to
cleanup
> S4 classes when an error occurs when loading a development package and
> crashes with no hint on the original error.
> Thank you.
> Bests,
> Renaud
Thank you for the report... although it would have been great if
it had come earlier, as we are approaching feature freeze for
3.0.0 very rapidly.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snippets from other packages/ License
On Thu, Mar 14, 2013 at 8:34 AM, Felix Schönbrodt wrote: > Hello, > > I want to use a function from another package (which is GPL>=3), about 20 > lines of code, in my own package. > I somewhat hesitate to depend on the entire package just for this single > function, but of course I want to credit the original authors. > > What would be the best way to do that? Where should I put that credit? Or > should I proceed completely different? Why so shy about the name and location of this function? I think I've seen cases like this before, where a package has a handy little function that has use outside the context of the package. In that case I think the best thing is often for that function to be taken out of that package completely, and put in a new package, because it isn't so tightly coupled to the aims of the package. Obviously this is overkill for one function, but its possible there's a few functions, or that they are handy enough to belong somewhere else, such as the plotrix package if its a little plotting function, or in one of Hadley's packages if it has an underscore in the name. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] removing union class
> Martin Maechler
> on Fri, 15 Mar 2013 11:39:18 +0100 writes:
> Renaud Gaujoux
> on Wed, 13 Mar 2013 13:10:44 +0200 writes:
>> Hi,
>> I get the following error when trying to remove a union class:
>>> setClassUnion('a', c('matrix', 'numeric'))
>>> removeClass('a')
>>> sessionInfo()
>> R version 2.15.3 (2013-03-01)
>> Platform: i686-pc-linux-gnu (32-bit)
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=C LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>> Is this normal? Am I doing something wrong?
> Well,... you forgot to show the error (and the traceback) :
>> setClassUnion('a', c('matrix', 'numeric'))
>> removeClass('a')
> Error in .getClassFromCache(Class, where) : node stack overflow
>> traceback()
> 1888: .getClassFromCache(Class, where)
> 1887: getClass(cl)
> 1886: checkAtAssignment("classRepresentation", "contains", "list")
> 1885: .deleteSuperClass(cdef, superclass)
> 1884: .removeSuperClass(subclass, superclass)
> ..
> ..
> 3: .deleteSuperClass(cdef, superclass)
> 2: .removeSuperClass(what, Class)
> 1: removeClass("a")
>>
> So that looks indeed like a bug in R's removeClass() or its
> helper functions.
or in the definition of "matrix" and "array" as S4-like
classes.
The infinite recursion happens because
"matrix" has "array" as subclass
and "array" has "matrix"
which by logic and usual set theory semantic would entail that
"array" and "matrix" must be the same class...
:-)
Well have to see how to resolve this as cleanly as possible.
Martin
> Note that this problem is somewhat dependent on the use of the
> infamous "matrix" class {not properly defined as a class in S3,
> as it may or may not have dimnames, and then tried to be made S4
> compatible "as well as possible" in the methods package, see
> getClass("matrix")
> Of course, I could not have thought of a realistic situation
> where this was a problem, but then you exemplify one :
>> Hadley, this is problematic for devtools, because load_all tries to
cleanup
>> S4 classes when an error occurs when loading a development package and
>> crashes with no hint on the original error.
>> Thank you.
>> Bests,
>> Renaud
> Thank you for the report... although it would have been great if
> it had come earlier, as we are approaching feature freeze for
> 3.0.0 very rapidly.
> Martin Maechler, ETH Zurich
> __
> 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] S4 generic not exported correctly / incorrect dispatch?
> Martin Morgan
> on Wed, 13 Mar 2013 12:43:59 -0700 writes:
> In this post
> https://stat.ethz.ch/pipermail/bioc-devel/2013-March/004152.html
> a package author reports that S4 dispatch fails. I can reproduce this
with a
> PkgA (attached; 'intervals' is a relatively light-weight CRAN package)
that has
> DESCRIPTION with
> Depends: intervals
> Imports: graphics
> NAMESPACE:
> importFrom(graphics, "plot")
> export("plot")
> exportMethods("plot")
> R/tmp.R
> setClass("A")
> setMethod("plot", "A", function(x, y, ...) {})
> and then
>> library(PkgA)
> Loading required package: intervals
>> plot
> function (x, y, ...)
> UseMethod("plot")
>
> notice that 'plot' is reported as an S3 generic, but should be an S4
generic.
> Removing Depends: intervals or changing to importsFrom(intervals, "plot")
> recovers S4 export
Indeed.
What happens is the following:
Because of the 'Depends: intervals',
the setMethod("plot", A", ...)
is *NOT* implicitly creating a new S4 plot() generic,
but rather sees the existing S4 plot generic in 'intervals' and
attaches its method there.
But as "you" fail to import plot from intervals, that is not
"seen" because it is masked by the S3 generic plot which you do
explicitly import from graphics.
If you (well the 'girafe' package author) really want to define
and export both S3 and S4 generics for plot, you should
ensure that you either import an S4 generic (from 'intervals', e.g.),
*or* that you explicitly create one yourself, using
setGeneric("plot", ..) to be in your own name space.
[But of course, the latter is not really what you'd want, I think].
Why are you opposed to
importsFrom(intervals, "plot")
?
I agree that it is ``asymmetric'' that you must think about how
to get plot as S4 generic, *because* you depend on a package
that defines plot as S4 generic,
whereas that package does not have to do the same.
I think we have to live with this infelicity of
interaction of namespace and S4 designs.
Martin
>> library(PkgA)
> Loading required package: intervals
>> plot
> standardGeneric for "plot" defined from package "graphics"
> function (x, y, ...)
> standardGeneric("plot")
>
> Methods may be defined for arguments: x, y
> Use showMethods("plot") for currently available ones.
> The 'intervals' package Depends: on methods but nothing else. It defines
S3 and
> S4 methods on plot, creating an implicit S4 generic in the process. It's
> NAMESPACE has
> S3method( "plot", "Intervals" )
> S3method( "plot", "Intervals_full" )
> exportMethods("plot")
> and we have
>> library(intervals)
>> plot
> standardGeneric for "plot" defined from package "graphics"
> function (x, y, ...)
> standardGeneric("plot")
>
> Methods may be defined for arguments: x, y
> Use showMethods("plot") for currently available ones.
> I think everyone is playing by the rules, and that plot should be
reported as an
> S4 generic in girafe / PkgA?
>> sessionInfo()
> R Under development (unstable) (2013-03-13 r62241)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=C LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] PkgA_1.2.3 intervals_0.14.0
> This is also seen in
>> sessionInfo()
> R version 3.0.0 alpha (2013-03-13 r62244)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> Martin
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
> x[DELETED ATTACHMENT external: PkgA_1.2.3.tar.gz, application/x-gzip]
> __
> 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] Registering method for "t.test"
Thanks for the response, Thomas.
I both exported the function and created a new S3-method in the namespace
file. By removing the function from the export command, the problem was
fixed...
Thanks for the help
Lukas
Am Freitag, 15. März 2013, 13:04:29 schrieb Thomas Lumley:
> On Thu, Mar 14, 2013 at 3:31 AM, Lukas Lehnert
>
> wrote:
> > Dear R-developers,
> >
> > in a new package, I'm currently working on, I tried to add a new method
> > to function "t.test". The new class, on which the method is based, is
> > called "speclib", so I defined the funcion for the new method as
> > "t.test.speclib".
> You shouldn't have a problem if you tell R it is a method for t.test. In
> the NAMESPACE, use
>
> S3method(t.test, speclib)
>
> rather than exporting the function by name, and in the usage section of the
> help page use
>
> \method{t.test}{speclib}
>
> > R CMD check now gives always a warning, that S3 methods are not
> > consistent, because R does not recognize that the basic function name
> > is "t.test" instead
> > of "t":
> >
> > t:
> > function(x)
> >
> > t.test.speclib:
> > function(x, y, paired, ...)
> >
> > Is there any workaround or do I have to rename the t.test.speclib
> > function to
> > something like t_test.speclib?
> >
> > Thank you in advance
> >
> > Lukas
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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] S4 generic not exported correctly / incorrect dispatch?
On 03/15/2013 04:42 AM, Martin Maechler wrote:
Martin Morgan
on Wed, 13 Mar 2013 12:43:59 -0700 writes:
> In this post
> https://stat.ethz.ch/pipermail/bioc-devel/2013-March/004152.html
> a package author reports that S4 dispatch fails. I can reproduce this
with a
> PkgA (attached; 'intervals' is a relatively light-weight CRAN package)
that has
> DESCRIPTION with
> Depends: intervals
> Imports: graphics
> NAMESPACE:
> importFrom(graphics, "plot")
> export("plot")
> exportMethods("plot")
> R/tmp.R
> setClass("A")
> setMethod("plot", "A", function(x, y, ...) {})
> and then
>> library(PkgA)
> Loading required package: intervals
>> plot
> function (x, y, ...)
> UseMethod("plot")
>
> notice that 'plot' is reported as an S3 generic, but should be an S4
generic.
> Removing Depends: intervals or changing to importsFrom(intervals, "plot")
> recovers S4 export
Indeed.
What happens is the following:
Because of the 'Depends: intervals',
the setMethod("plot", A", ...)
is *NOT* implicitly creating a new S4 plot() generic,
but rather sees the existing S4 plot generic in 'intervals' and
attaches its method there.
But as "you" fail to import plot from intervals, that is not
"seen" because it is masked by the S3 generic plot which you do
explicitly import from graphics.
Thanks for your help and insight, Martin.
There _was_ a change to intervals, overlooked in the other various moving parts,
with exportMethods(plot) added to the NAMESPACE.
So setMethod is finding and adding to the generic on the search path, but
exporting the (not implicitly promoted) S3 generic imported from graphics.
The 'surprise' is that plot on the search path wins out over plot in the name
space.
I think (?) I would have been 'surprised' later when PkgA's exportMethods(plot)
did not merge the methods on the implicit generic in PkgA with the implicit
generic on the search path, especially if PkgA had not also export(plot).
If you (well the 'girafe' package author) really want to define
and export both S3 and S4 generics for plot, you should
ensure that you either import an S4 generic (from 'intervals', e.g.),
*or* that you explicitly create one yourself, using
setGeneric("plot", ..) to be in your own name space.
[But of course, the latter is not really what you'd want, I think].
Why are you opposed to
importsFrom(intervals, "plot")
?
Conceptually, I'm implementing a method orthogonal to what other packages are
doing.
Practically, I'd like my name space to insulate me from what other packages do.
Thanks a lot for your help, I understand what is going on.
Martin
I agree that it is ``asymmetric'' that you must think about how
to get plot as S4 generic, *because* you depend on a package
that defines plot as S4 generic,
whereas that package does not have to do the same.
I think we have to live with this infelicity of
interaction of namespace and S4 designs.
Martin
>> library(PkgA)
> Loading required package: intervals
>> plot
> standardGeneric for "plot" defined from package "graphics"
> function (x, y, ...)
> standardGeneric("plot")
>
> Methods may be defined for arguments: x, y
> Use showMethods("plot") for currently available ones.
> The 'intervals' package Depends: on methods but nothing else. It defines
S3 and
> S4 methods on plot, creating an implicit S4 generic in the process. It's
> NAMESPACE has
> S3method( "plot", "Intervals" )
> S3method( "plot", "Intervals_full" )
> exportMethods("plot")
> and we have
>> library(intervals)
>> plot
> standardGeneric for "plot" defined from package "graphics"
> function (x, y, ...)
> standardGeneric("plot")
>
> Methods may be defined for arguments: x, y
> Use showMethods("plot") for currently available ones.
> I think everyone is playing by the rules, and that plot should be
reported as an
> S4 generic in girafe / PkgA?
>> sessionInfo()
> R Under development (unstable) (2013-03-13 r62241)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=C LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] PkgA_1.2.3 intervals_0.14.0
> This is also seen in
>> sessionInfo()
> R version 3.0.0 alpha (2013-03-13 r62244)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> Martin
> --
> Computational Biology / Fred Hutch
Re: [Rd] Failed to locate 'weave' output file / vignette product does not have a known filename extension
Hi.
I can reproduce 2 out of the 3 cases on R version 3.0.0 alpha
(2013-03-12 r62224) [Platform: x86_64-w64-mingw32/x64 (64-bit)]. The
error does not appear to be in the R vignette machinery but rather in
the vignettes themselves (or the packages they're using). Comments
below.
On Wed, Mar 13, 2013 at 1:16 PM, Henrik Bengtsson wrote:
> Hi,
>
> I contributed code to R r62130 which may be responsible for that (not
> sure). I'll investigate as soon as got the time.
>
> /Henrik
>
> On Wed, Mar 13, 2013 at 10:17 AM, Dan Tenenbaum wrote:
>> Hello,
>>
>> I'm seeing three different vignette-related errors with recent
>> versions of R-3.0.0 alpha.
>>
#
# Case #1: BitSeq
#
>> First, with the package BitSeq
>> (http://bioconductor.org/packages/2.12/bioc/html/BitSeq.html), I get
>> the following when trying to build the package:
>>
>> Error: processing vignette ’BitSeq.Rnw' failed with diagnostics:
>> Failed to locate the ‘weave’ output file (by engine ‘utils::Sweave’)
>> for vignette with name ‘BitSeq’. The following files exists in
>> directory ‘.’: ‘data-C0.est’, ‘data-C1.est’, ‘data-c0b0.prob’,
>> ‘data-c0b0.rpkm’, ‘data-c0b0.sam’, ‘data-c0b0.thetaMeans’,
>> ‘data-c0b1.rpkm’, ‘data-c1b0.rpkm’, ‘data-c1b1.rpkm’, ‘data.estVar’,
>> ‘data.means’, ‘data.par’, ‘data.pplr’, ‘data.tr’, ‘ensSelect1.fasta’,
>> ‘ensSelect1.tr’, ‘parameters1.txt’
>> Execution halted
>>
>> My guess is it's looking for BitSeq.tex, but it's not clear where it's
>> looking; the package is pretty straightforward, inst/doc contains
>> BitSeq.Rnw and nothing else (no Makefile).
>>
I failed to reproduce this when running the vignette manually;
> setwd("BitSeq/inst/doc/")
> Sweave("BitSeq.Rnw")
> tools:::find_vignette_product("BitSeq", by="weave")
[1] "BitSeq.tex"
However, when I look for the files listed in your error message I
don't find them in ".", but I do find them in
system.file("extdata",package="BitSeq"). Inspecting 'BitSeq.Rnw', I
find
# move to directory with the data
setwd(system.file("extdata",package="BitSeq"));
and at the very end
# restore the original working directory
setwd(old_directory);
My guess is that in your case there's an error occurring during Sweave
resulting in the current directory being incorrect upon return. This
causes the tools:::find_vignette_product() assertion following
immediately after to look in the incorrect directory.
[ It should be easy to update the R vignette mechanism such that this
check for the vignette output is done in the proper directory
regardless whether the vignette changes the current working directory
or not. ]
#
# Case #2: ppiData
#
>> Next, the package ppiData whose source is here:
>> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/ppiData
>> (login: readonly password: readonly)
>>
>> As you can see, there is no .tex file in the source of the package,
>> but after running R CMD build on it, the resulting .tar.gz file
>> contains
>> ppiData/inst/doc/ppiData.tex
>> Then the package fails check (excerpt of ppiData.Rcheck/00install.out):
>>
>> Error in vignette_type(Outfile) :
>> Vignette product ‘ppiData.tex’ does not have a known filename extension
>> (‘NA’)
>> ERROR: installing vignettes failed
>> * removing
>> ‘/home/biocbuild/bbs-2.12-data-experiment/meat/ppiData.Rcheck/ppiData’
>>
>> This package does not have a vignette Makefile either, so I'm not sure
>> why the tex file is included in the .tar.gz.
Building the vignette manually, I get:
> setwd("ppiData/inst/doc/")
> Sweave("ppiData.Rnw")
Writing to file ppiData.tex
Processing code chunks with options ...
[...]
Loading required package: lattice
2 : echo keep.source term verbatim (label = collectData, ppiData.Rnw:79)
Error: chunk 2 (label = collectData)
Error in as.list.default(org.Sc.sgdCOMMON2ORF) :
no method for coercing this S4 class to a vector
Enter a frame number, or 0 to exit
1: Sweave("ppiData.Rnw")
2: driver$runcode(drobj, chunk, chunkopts)
3: RweaveTryStop(err, options)
Selection:
So, that appears to be the root of the problem.
The "Error in vignette_type(Outfile) : Vignette product 'ppiData.tex'
does not have a known filename extension ('NA')" occurs after R has
temporarily built the package and then tries to install it. It fails
to pick up the above Sweave() error during the build process because
Sweave() leaves an (incomplete) 'ppiData.tex' file behind the R
vignette machinery believes it was successful and keeps going.
[ I don't know enough of the inner details of Sweave() and how it's
exception handling works, but hopefully it's possible to detect the
Sweave error and give a more informative error message earlier on. ]
>>
>> These two errors are with:
>>
>>> sessionInfo()
>> R version 3.0.0 alpha (2013-03-09 r62188)
>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>
>> locale:
>> [1] LC_CTYPE=en_
[Rd] numerics from a factor
A problem has been pointed out by a French user of the survival package and I'm looking for a pointer. > options(OutDec= ",") > fit <- survfit(Surv(1:6 /2) ~ 1) > fit$time [1] NA 1 NA 2 NA 3 A year or two ago some test cases that broke survfit were presented to me. The heart of the problem was numbers that were almost identical, where table(x) and unique(x) gave different counts of distinct values. The solution was to use "ftime <- factor(time)" at the top of the code, and do all the calulations using the integer levels of the factor as the unique time points. At the very end the numeric component "time" of the result is created using as.numeric(levels(ftime)). It's this last line that breaks. I could set the OutDec option within survfit and reset when I leave using on.exit. Any other simple solutions? Any other ways I could get caught by this issue? Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] the case of building R snapshot without svn nor network connection.
The decision to actively discourage non-subsersion usage of snapshot build is already made (r62183). So I am just here to register a differing opinion. - it is not about subversion vs other-version-control-tools. There are two parts of R's dev build process which requires an active network connection - tools/rsync-recommended and capturing `svn info` into R's headers. The former can be overridden with "./configure --with-recommended-packages=no". A few changes had been made in the last 6 months to make the latter mandatory. It used to be optional. --- there are genuine needs for testing snapshots in a non-networked minimalist environment - e.g. banks or telecom industries - where one wants a "standardised host" build, and often it means an "outdated host"; or in a virtual machine environment - which are non-networked for security reasons, and also do not have tools beyond necessary for compiling and building. This is quite a common scenario. --- AFAIK, 6 months ago, a snapshot copied to an non-networked host will build with "./configure --with-recommended-packages=no". Of course copying those recommended package tar balls across would be nicer. This is sadly no longer the case. - dependent on `svn info` and sitting on top of a svn checkout possibly also affects cross-compiling. But then, it is not clear whether it is still possible to cross-compile R, since quite a few changes have been made to remove the capability of cross-compiling R for windows on unix hosts in the last few years. - testing dev snapshots is about trying things and fixing bugs before release. Making it difficult for non-core people to "try", seem to go against that ethos. If that's the case, maybe the repository could be closed off to anonymous check outs altogether, just to make it clear that testing snapshots before releases or even close to release, is not welcomed. Just a thought. - although the official repository of the "main" linux kernel branch is git-based, there are mercurial mirrors; AFAIK the digital video broadcasting hardware support of the linux kernel is officially in mercurial repositories, but have git mirrors; likewise much of Xorg's is in mercurial but have git mirrors. I haven't heard of any much bigger public projects than R where some actively discourage others. - To be honest r62183 itself is probably a good reason to move away from server-side repositories to distributed repositories (hg/git/arch/bzr). Local enhancements - i.e. an in-house fork - some of which are never going upstream, such as a local revert of r62183 (or a local revert of any other upstream commits) is one reason why some have distributed repositories. Lastly, a minor grip. The current head of the HK government is probably sometimes called "HK Leung", just as some might call a certain old lady "UK Windsor" and a certain black person "US Obama". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] the case of building R snapshot without svn nor network connection.
On Mar 15, 2013, at 7:29 PM, Hin-Tak Leung wrote: > The decision to actively discourage non-subsersion usage of snapshot build is > already made (r62183). So I am just here to register a differing opinion. > > - it is not about subversion vs other-version-control-tools. There are two > parts of R's dev build process which requires an active network connection - > tools/rsync-recommended and capturing `svn info` into R's headers. That is a false statement - svn info doesn't require any network connection. Cheers, Simon > The former can be overridden with "./configure > --with-recommended-packages=no". A few changes had been made in the last 6 > months to make the latter mandatory. It used to be optional. > > --- there are genuine needs for testing snapshots in a non-networked > minimalist environment - e.g. banks or telecom industries - where one wants a > "standardised host" build, and often it means an "outdated host"; or in a > virtual machine environment - which are non-networked for security reasons, > and also do not have tools beyond necessary for compiling and building. This > is quite a common scenario. > > --- AFAIK, 6 months ago, a snapshot copied to an non-networked host will > build with "./configure --with-recommended-packages=no". Of course copying > those recommended package tar balls across would be nicer. This is sadly no > longer the case. > > - dependent on `svn info` and sitting on top of a svn checkout possibly also > affects cross-compiling. But then, it is not clear whether it is still > possible to cross-compile R, since quite a few changes have been made to > remove the capability of cross-compiling R for windows on unix hosts in the > last few years. > > - testing dev snapshots is about trying things and fixing bugs before > release. Making it difficult for non-core people to "try", seem to go against > that ethos. If that's the case, maybe the repository could be closed off to > anonymous check outs altogether, just to make it clear that testing snapshots > before releases or even close to release, is not welcomed. Just a thought. > > - although the official repository of the "main" linux kernel branch is > git-based, there are mercurial mirrors; AFAIK the digital video broadcasting > hardware support of the linux kernel is officially in mercurial repositories, > but have git mirrors; likewise much of Xorg's is in mercurial but have git > mirrors. I haven't heard of any much bigger public projects than R where some > actively discourage others. > > - To be honest r62183 itself is probably a good reason to move away from > server-side repositories to distributed repositories (hg/git/arch/bzr). Local > enhancements - i.e. an in-house fork - some of which are never going > upstream, such as a local revert of r62183 (or a local revert of any other > upstream commits) is one reason why some have distributed repositories. > > Lastly, a minor grip. The current head of the HK government is probably > sometimes called "HK Leung", just as some might call a certain old lady "UK > Windsor" and a certain black person "US Obama". > > __ > 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] the case of building R snapshot without svn nor network connection.
I'll quantify the first part - R is perhaps the only public software project hosted on a subversion repository for which the result of 'svn export ...' does not build. Not only that it does not build, but make it a feature that it does not build. Very few other projects actively try to go in that direction. --- On Fri, 15/3/13, Hin-Tak Leung wrote: > The decision to actively discourage > non-subsersion usage of snapshot build is already made > (r62183). So I am just here to register a differing > opinion. > > - it is not about subversion vs other-version-control-tools. > There are two parts of R's dev build process which requires > an active network connection - tools/rsync-recommended and > capturing `svn info` into R's headers. The former can be > overridden with "./configure > --with-recommended-packages=no". A few changes had been made > in the last 6 months to make the latter mandatory. It used > to be optional. > > --- there are genuine needs for testing snapshots in a > non-networked minimalist environment - e.g. banks or telecom > industries - where one wants a "standardised host" build, > and often it means an "outdated host"; or in a virtual > machine environment - which are non-networked for security > reasons, and also do not have tools beyond necessary for > compiling and building. This is quite a common scenario. > > --- AFAIK, 6 months ago, a snapshot copied to an > non-networked host will build with "./configure > --with-recommended-packages=no". Of course copying those > recommended package tar balls across would be nicer. This is > sadly no longer the case. > > - dependent on `svn info` and sitting on top of a svn > checkout possibly also affects cross-compiling. But then, it > is not clear whether it is still possible to cross-compile > R, since quite a few changes have been made to remove the > capability of cross-compiling R for windows on unix hosts in > the last few years. > > - testing dev snapshots is about trying things and fixing > bugs before release. Making it difficult for non-core people > to "try", seem to go against that ethos. If that's the case, > maybe the repository could be closed off to anonymous check > outs altogether, just to make it clear that testing > snapshots before releases or even close to release, is not > welcomed. Just a thought. > > - although the official repository of the "main" linux > kernel branch is git-based, there are mercurial mirrors; > AFAIK the digital video broadcasting hardware support of the > linux kernel is officially in mercurial repositories, but > have git mirrors; likewise much of Xorg's is in mercurial > but have git mirrors. I haven't heard of any much bigger > public projects than R where some actively discourage > others. > > - To be honest r62183 itself is probably a good reason to > move away from server-side repositories to distributed > repositories (hg/git/arch/bzr). Local enhancements - i.e. an > in-house fork - some of which are never going upstream, such > as a local revert of r62183 (or a local revert of any other > upstream commits) is one reason why some have distributed > repositories. > > Lastly, a minor grip. The current head of the HK government > is probably sometimes called "HK Leung", just as some might > call a certain old lady "UK Windsor" and a certain black > person "US Obama". > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
