Re: [Rd] the case of building R snapshot without svn nor network connection.

[peter dalgaard]

On Mar 16, 2013, at 02:50 , Hin-Tak Leung wrote:

> 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.

It is not a design goal in any project that I know of, that svn exports should 
be equivalent to distribution tarballs. In simple projects, that might be the 
case, but requiring a "make dist" step is quite common before the final 
shipment. 

An actual design goal has been to ensure that snapshot builds carry an SVN 
revision number so that we can detect whether issues are reported on versions 
prior to a known fix. This is done via an "svn info" command because that was 
the path of least resistance (you can't really e.g. maintain the SVN-REVISION 
file in svn because it would need to change on every commit). There's no 
particular intention to hardwire SVN as the source code management tool, but as 
it happens to be what we use, that tiny subsystem of the build system has to be 
specific to SVN.

The generic point is that you are given access to a working tool that is 
internal to the core R developers. We are not putting restrictions on what you 
do with that access, but if you want to play the game by other rules than we 
do, you need to take the consequences. If things don't work and you start 
complaining about them being "broken", steps may be taken to make it clearer 
who broke them.

As Jari Oksanen put it recently:

"I think the rule is that you can do anything as long as you don't complain. If 
you want to complain, you must follow the instructions."

Peter D.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] numerics from a factor

[Ulrike Grömping]

Hi Terry,

you can use type.convert instead of as.numeric for numbers with decimals:

type.convert(levels(factor(1:6/2)), dec=unlist(options("OutDec")))

Best,
Ulrike


Am 16.03.2013 12:00, schrieb r-devel-requ...@r-project.org:

Date: Fri, 15 Mar 2013 12:47:01 -0500
From: Terry Therneau
To:"r-devel@r-project.org"  
Subject: [Rd] numerics from a factor
Message-ID:<51435e95@mayo.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

Re: [Rd] the case of building R snapshot without svn nor network connection.

[Hin-Tak Leung]

--- On Sat, 16/3/13, peter dalgaard  wrote:

> On Mar 16, 2013, at 02:50 , Hin-Tak Leung wrote:
> 
> > 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.
> 
> It is not a design goal in any project that I know of, that
> svn exports should be equivalent to distribution tarballs.
> In simple projects, that might be the case, but requiring a
> "make dist" step is quite common before the final shipment.

Yes and no. Many projects much larger than R have a "make dist" target. 
However, I don't know of any where they make it a feature and a design goal and 
actively go forward that a 'make dist' tar ball differs substantially in 
functionality from a snapshot close to the release revision, and also actively 
make sure that a snapshot does not work.

Try name one.

Even if you can name one other such project, is that honestly good practice to 
emulate?

> An actual design goal has been to ensure that snapshot
> builds carry an SVN revision number so that we can detect
> whether issues are reported on versions prior to a known
> fix. This is done via an "svn info" command because that was
> the path of least resistance (you can't really e.g. maintain
> the SVN-REVISION file in svn because it would need to change
> on every commit). There's no particular intention to
> hardwire SVN as the source code management tool, but as it
> happens to be what we use, that tiny subsystem of the build
> system has to be specific to SVN.

As is evident, dependence on svn is already hardwired. Look at the issue 
leading up to this discussion: there were (are, since there isn't a new release 
yet) code in Matrix, and also elsewhere from a cursory grep, where code paths 
are conditional on specific version commit numbers, and do different things 
before/after specific svn revision numbers. 

> The generic point is that you are given access to a working
> tool that is internal to the core R developers. We are not
> putting restrictions on what you do with that access, but if
> you want to play the game by other rules than we do, you
> need to take the consequences. If things don't work and you
> start complaining about them being "broken", steps may be
> taken to make it clearer who broke them.

There is a difference between "unsupported" ("I don't want to spend time 
hearing about issues arising from going off the beaten path"), versus 'actively 
discourage going off "beaten" path'. 

Where, of course, "beaten path" is defined by a small group of people, as is 
"design goal". (it is a feature to break).

> As Jari Oksanen put it recently:
> 
> "I think the rule is that you can do anything as long as you
> don't complain. If you want to complain, you must follow the
> instructions."
> 
> Peter D.
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk 
> Priv: pda...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
>

__
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.

[Dirk Eddelbuettel]

Can you please stop this?  You made your point, repeatedly.  Nobody has come
to your side.  

And you *do* have easy alternatives:

   i)  git repo,  see https://github.com/wch/r-source

   ii) nighly tarballs,  see ftp://ftp.stat.math.ethz.ch/Software/R

Whatever your particular circumstances are (which you never detailed in a way
that made me understand what your issue is), one of these should work.

As I said before, 'svn up && make distclean && ~/bin/makeRdevel' works just
fine for me with the configure choice I prefer hardwired in the script.  I
never sync to r-recommended and *honestly* have no idea what your issue is.
I just rebuilt two days ago without an issue:

   edd@max:~$ ~/bin/R-devel.sh --version|head -1
   R Under development (unstable) (2013-03-15 r62262) -- "Unsuffered 
Consequences"


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] the case of building R snapshot without svn nor network connection.

[Hin-Tak Leung]

Network access is *not* a given, nor is the privilege of installing arbitrary 
"uncertified" and "non-essential" tools - whatever the meaning of "uncertified" 
and "non-essential" are, those being defined, as is "design goal", etc, by some 
small committee.

It is a very common scenario, e.g. banks & telecom, some part of 
public/government service and health care. This does not seem to sink in 
without repeating.

--- On Sat, 16/3/13, Hin-Tak Leung  wrote:

> 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

Re: [Rd] the case of building R snapshot without svn nor network connection.

[Simon Urbanek]

On Mar 16, 2013, at 10:13 AM, Hin-Tak Leung wrote:

> Network access is *not* a given, nor is the privilege of installing arbitrary 
> "uncertified" and "non-essential" tools - whatever the meaning of 
> "uncertified" and "non-essential" are, those being defined, as is "design 
> goal", etc, by some small committee.
> 
> It is a very common scenario, e.g. banks & telecom, some part of 
> public/government service and health care. This does not seem to sink in 
> without repeating.
> 

Network access is not needed to build R - apparently that fact did not seem to 
sink in, either. This entire thread is based on false assumptions and as such 
the only place for it is /dev/null


> --- On Sat, 16/3/13, Hin-Tak Leung  wrote:
> 
>> 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
> 
> 

__
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.

[Yihui Xie]

"the only place for it is /dev/null" --> hi Achim, I bet this is a
nice fortune candidate :)

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sat, Mar 16, 2013 at 9:39 AM, Simon Urbanek
 wrote:
> On Mar 16, 2013, at 10:13 AM, Hin-Tak Leung wrote:
>
>> Network access is *not* a given, nor is the privilege of installing 
>> arbitrary "uncertified" and "non-essential" tools - whatever the meaning of 
>> "uncertified" and "non-essential" are, those being defined, as is "design 
>> goal", etc, by some small committee.
>>
>> It is a very common scenario, e.g. banks & telecom, some part of 
>> public/government service and health care. This does not seem to sink in 
>> without repeating.
>>
>
> Network access is not needed to build R - apparently that fact did not seem 
> to sink in, either. This entire thread is based on false assumptions and as 
> such the only place for it is /dev/null
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Mirroring R on a DVCS

[Laurent Gautier]

Hi,

I have been looking at mirroring the SVN R repository into a DVCS 
(Mercurial, Git, bzr, etc...).


The idea would be to have that as an always up-to-date untouched master 
(a mirror) but having it in a DVCS would make forks easier to make and 
maintain, and possibly ease up the process of having patches included 
upstream.


Would anyone else be interested ?


Laurent

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Mirroring R on a DVCS

[Peter Meilstrup]

There is already a mirror on GitHub at https://github.com/wch/r-source .

Peter

On Mar 16, 2013, at 11:17, Laurent Gautier  wrote:

> Hi,
> 
> I have been looking at mirroring the SVN R repository into a DVCS (Mercurial, 
> Git, bzr, etc...).
> 
> The idea would be to have that as an always up-to-date untouched master (a 
> mirror) but having it in a DVCS would make forks easier to make and maintain, 
> and possibly ease up the process of having patches included upstream.
> 
> Would anyone else be interested ?
> 
> 
> Laurent
> 
> __
> 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] Mirroring R on a DVCS

[Laurent Gautier]

Thanks. I missed it, I guess.

I am surprised by the relatively low number of forks...


L.

On 2013-03-16 11:28, Peter Meilstrup wrote:
> There is already a mirror on GitHub at https://github.com/wch/r-source .
>
> Peter
>
> On Mar 16, 2013, at 11:17, Laurent Gautier  > wrote:
>
>> Hi,
>>
>> I have been looking at mirroring the SVN R repository into a DVCS 
>> (Mercurial, Git, bzr, etc...).
>>
>> The idea would be to have that as an always up-to-date untouched 
>> master (a mirror) but having it in a DVCS would make forks easier to 
>> make and maintain, and possibly ease up the process of having patches 
>> included upstream.
>>
>> Would anyone else be interested ?
>>
>>
>> Laurent
>>
>> __
>> 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] Mirroring R on a DVCS

[Winston Chang]

The Github mirror isn't affiliated with R-core developers -- it just
fetches the changes from the R SVN repository periodically. Changes won't
go upstream to the main SVN repository, and that's probably why there
aren't very many forks of the Github repo.

-Winston


On Sat, Mar 16, 2013 at 1:44 PM, Laurent Gautier  wrote:

> Thanks. I missed it, I guess.
>
> I am surprised by the relatively low number of forks...
>
>
> L.
>
> On 2013-03-16 11:28, Peter Meilstrup wrote:
> > There is already a mirror on GitHub at https://github.com/wch/r-source .
> >
> > Peter
> >
> > On Mar 16, 2013, at 11:17, Laurent Gautier  > > wrote:
> >
> >> Hi,
> >>
> >> I have been looking at mirroring the SVN R repository into a DVCS
> >> (Mercurial, Git, bzr, etc...).
> >>
> >> The idea would be to have that as an always up-to-date untouched
> >> master (a mirror) but having it in a DVCS would make forks easier to
> >> make and maintain, and possibly ease up the process of having patches
> >> included upstream.
> >>
> >> Would anyone else be interested ?
> >>
> >>
> >> Laurent
> >>
> >> __
> >> 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
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] configure.ac clock_gettime (and R_CHECK_FUNCS) incorrect?

[Martin Morgan]

When R is configured with CFLAGS=-O2, clock_gettime is included

$ nm src/main/libR.a | grep clock_gettime
 U clock_gettime

whereas when configured with -O0 it is not

$ nm src/main/libR.a | grep clock_gettime
$

Similarly when built as a shared library the linker flags include or not -lrt, 
and ldd indicates dependency on librt or not.


This thread

  
http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-December/005022.html

lead to the conclusion that the test for clock_gettime from configure.ac:1838 is 
flawed, because


R_CHECK_FUNCS([clock_gettime timespec_get], [#include ])
if test "${ac_cv_have_decl_clock_gettime}" = "yes"; then
AC_CHECK_LIB(rt, clock_gettime)
fi

generates test code, from config.log, which looks like

| int
| main ()
| {
| #ifndef clock_gettime
|   char *p = (char *) clock_gettime;
| #endif
|
|   ;
|   return 0;
| }

when compiled with CFLAGS=-O2, the assignment to p is optimized out and the test 
succeeds whether clock_gettime is present or not; the autoconf macro may add 
-lrt to the compile flags.


When compiled with CFLAGS=-O0, the test fails and autoconf does not try to add 
-lrt, even though that might be (is) necessary.


It seems that R_CHECK_FUNCS (R_CHECK_DECLS) in general and the logic of this 
specific test need revisiting?


$ bin/R --version
R Under development (unstable) (2013-03-16 r62282) -- "Unsuffered Consequences"
...

on

$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

or

$ clang --version
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel