headers
Miguel A. Arranz | 1 Feb 2005 15:17

[Rd] Problem with Linux installation

Dear R-devel members:

I have been trying to install the latest versions of R-devel with no success. 
It builds with no problem, but 'make install' breaks with the error
make[2]: Entering directory `/home/bayes/R/R-devel/src/include'
make[2]: *** No rule to make target `install-no', needed by `install'.  Stop.
m
I guess there is a minor problem with the Makefile, which did not appear on 
the version I am running now (2005-01-26)

Thanks in advance,

Miguel A.

______________________________________________
R-devel <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 1 comment |
headers
Prof Brian Ripley | 1 Feb 2005 14:31
Picon
Picon
Favicon

[Rd] Re: [R] RData loading weirdness

[Moved to R-devel: see the posting guide for the currently made 
distinction.]

The format of .RData has not changed, so this is still of interest.

We have seen things like this, the problem being the way an out-of-memory 
condition got handled by Linux -- how much memory did his machine have?
(Remember 67Mb is compressed, often highly compressed.)

It has certainly been possible to save a workspace that needs much more 
memory to be restored on the same machine than it originally took.

We've found Linux to be rather unhelpful with out-of-memory conditions: 
one of our servers started `randomly' killing processes when its swap 
space got full -- and one of the first was the sshd daemon which cut off 
all remote access ....

On Tue, 1 Feb 2005, Barry Rowlingson wrote:

>
> I've just had an interesting thing happen to one of our students. He's using 
> R 1.9.1 on Linux, and so I dont expect bugfixes, I'm just reporting this out 
> of interest in case anyone else has had this happen.
>
> Starting R caused a seg fault shortly after "[Previously saved workspace 
> restored]". Running "R --no-restore-data" worked fine so I suspected a 
> corrupted .RData. It was 67M big, with about 400 objects - nothing extreme 
> there. But then doing load(".RData") worked fine. There were his objects. How 
> strange.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prof Brian Ripley | 1 Feb 2005 14:44
Picon
Picon
Favicon

[Rd] Re: [R] Process to both write to and read from (pipe/fork)?

[Moved from R-help.]

One reason you cannot easily do this with basic R functions is that it is 
not portable.  E.g. pipes on Windows 98 do not work like that, and 
system() on that OS has to work hard to do something similar.

If we only had to consider standard Unices, pipe() would allow read-write 
modes.  As it is, it is easy for you to write an OS-specific extension.

BTW, please re-read the distinction between R-devel and R-help in the 
posting guide: this (and most of your other recent postings) seem to me to 
fall unambiguously within the specification for R-devel.

On Tue, 1 Feb 2005, Jan T. Kim wrote:

> Dear all,
>
> I would like to start a process from an R program in such a way that
> I can both feed input into the process and read the process's output.
> It seems that in R, I can have a pipe for writing into another process's
> input or a pipe for reading from another process's output, but not both.
>
> Doing both necessitates forking, such that the child can start the
> external process and feed that with some input, and the parent can
> read the output from the external process. Additionally, this requires
> obtaining a plain pipe, i.e. one with an input handle (for writing to)
> and an output handle (for reading from) prior to forking, so the child
> can connect the external process's stdout to the input handle and the
> parent can read that from the output handle.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Dalgaard | 1 Feb 2005 14:58
Picon
Favicon

Re: [Rd] Re: [R] RData loading weirdness

Prof Brian Ripley <ripley <at> stats.ox.ac.uk> writes:

> We've found Linux to be rather unhelpful with out-of-memory
> conditions: one of our servers started `randomly' killing processes
> when its swap space got full -- and one of the first was the sshd
> daemon which cut off all remote access ....

This is running off-topic, but I believe that this has been recently
worked on, and at least SuSE (I'm not going home just to open the lid
on the laptop running FC3 just now!) now has the behaviour controlled
by kernel flags in /proc/sys/vm/local-oom-kill and
/proc/sys/vm/overcommit_memory. Not sure what the first one means
exactly, though ...

--

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard <at> biostat.ku.dk)             FAX: (+45) 35327907

______________________________________________
R-devel <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 0 comments |
headers
Prof Brian Ripley | 1 Feb 2005 15:04
Picon
Picon
Favicon

Re: [Rd] Problem with Linux installation

On Tue, 1 Feb 2005, Miguel A. Arranz wrote:

> Dear R-devel members:
>
> I have been trying to install the latest versions of R-devel with no success.

R-devel changes many times a day: see the SVN logs.

> It builds with no problem, but 'make install' breaks with the error
> make[2]: Entering directory `/home/bayes/R/R-devel/src/include'
> make[2]: *** No rule to make target `install-no', needed by `install'.  Stop.
> m
> I guess there is a minor problem with the Makefile, which did not appear on
> the version I am running now (2005-01-26)

Remember R-devel says

Version 2.1.0 Under development (unstable) (2005-02-01), ISBN 3-900051-07-0

and installation of gettext/libintl is actively `under development' at 
present.  I don't know exactly when you got your version, but it works 
right now with GNU make on Linux and Solaris (there seem to be some 
problems with Solaris make that I am in the middle of tracking down).

We do try to have `make all check dist' working at the end of each day 
(GMT) so the snapshot tarball builds, but `make install' is only checked 
at the end of bouts of development (why would anyone want to install an 
unstable version?).

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan T. Kim | 1 Feb 2005 20:50
Picon
Picon

[Rd] Re: [R] Process to both write to and read from (pipe/fork)?

On Tue, Feb 01, 2005 at 01:44:37PM +0000, Prof Brian Ripley wrote:
> [Moved from R-help.]
> 
> One reason you cannot easily do this with basic R functions is that it is 
> not portable.  E.g. pipes on Windows 98 do not work like that, and 
> system() on that OS has to work hard to do something similar.

Ok, thanks -- I really thought (and hoped) that I was just overlooking
something obvious.

I'm not fully convinced that the portability issues necessarily
preclude providing the fork / pipe facilities, as there already is some
differentiation present now, reflected by capabilities(). In fact,
when I saw that availability of fifos is reflected by capabilities(),
I thought that then, more basic pipes must also be accessible somehow
(and spent some effort investigating this idea).

> If we only had to consider standard Unices, pipe() would allow read-write 
> modes.  As it is, it is easy for you to write an OS-specific extension.

Well, that is probably reasonably easy, but (not the least due to that
fact) I'm still surprised that it has not been done already. I can hardly
imagine that I'm the first one to want to use some external utility from
an R program in this way.

So, what do you R-devel folks do in this case, and what would you
recommend?

> BTW, please re-read the distinction between R-devel and R-help in the 
> posting guide: this (and most of your other recent postings) seem to me to
(Continue reading)

Permalink | Reply | 3 comments |
headers
yuedong | 2 Feb 2005 04:31
Picon

[Rd] anova.glm (PR#7624)

There may be a bug in the anova.glm function.

deathstar[32] R

R : Copyright 2004, The R Foundation for Statistical Computing
Version 2.0.1  (2004-11-15), ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.

> counts <- c(18,17,15,20,10,20,25,13,12)
> outcome <- gl(3,1,9)
> treatment <- gl(3,3)
> glm.D93 <- glm(counts ~ outcome + treatment, family=poisson())
> anova(glm.D93,test="Chisq")
Analysis of Deviance Table

Model: poisson, link: log

Response: counts
(Continue reading)

Permalink | Reply | 501 comments |
headers
Prof Brian Ripley | 2 Feb 2005 08:37
Picon
Picon
Favicon

Re: [Rd] anova.glm (PR#7624)

A poisson family has dispersion 1 by definition of 'Poisson'.
You need a quasipoisson family to use a moment estimate of dispersion.

This difference is described on the help page for anova.glm.
Note the estimated dispersion *is* used and *is* one:

> summary(glm.D93)$dispersion
[1] 1

as it ought to be (and is in S-PLUS too).  That it is not used in S-PLUS 
is not documented (and it is not used in summary.glm either) and is at 
least an inconsistency.

Your assumption that R is wrong and S-PLUS (sic) is correct is not 
appreciated.  Why did you file this as an R bug and not an S-PLUS one?

On Wed, 2 Feb 2005 yuedong <at> pstat.ucsb.edu wrote:

> There may be a bug in the anova.glm function.

But not in the one in R!

> deathstar[32] R
>
> R : Copyright 2004, The R Foundation for Statistical Computing
> Version 2.0.1  (2004-11-15), ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Paul Gilbert | 2 Feb 2005 15:58
Picon

[Rd] Re: package checks and tests; was: Re: A "rude" question

[moved to R-devel]

I am a bit concerned by the fact that package developers would be 
removing all tests. The tests seem like one of the main mechanisms for 
ensuring that CRAN does not descend to the almost useless state of 
statlib: there is an automatic mechanism for removing packages that no 
longer work.

I have several tests that I don't put in packages, because they are very 
long or they don't work without locally available databases, but I think 
it is important that there should be tests that check the main 
functionality of packages.  For very long tests like monte carlo 
simulations it is usually fairly easy to devise some short version (a 
few iterations) which checks that the software actually works and gives 
results that are the same as they always have been, even though it does 
not check the more serious statistical problems one would actually want 
to do.

Perhaps there should be another directory, called something like 
longTests, that is not run daily but is run occasionally.

On r-help I suggested that users might contribute tests to package 
developers, but another possibility is that there is some mechanism for 
them to contribute suites of package tests directly to CRAN. This would 
provide a mechanism for more complete checking of packages, and perhaps 
a just system for removing packages when the developer is no longer 
active and the package is broken.

Paul Gilbert
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus G. Daniels | 2 Feb 2005 19:50

[Rd] modules with libtool and -dlpreopen

Has anyone looked at setting up R to build its modules with libtool's 
dlpreopen?

[libtool -dlpreopen is a facility that allows one to simulate dynamic 
linking on platforms that lack it.  However, it requires collecting all 
of the component `shared' objects into one and linking them (and a 
metadata structure) into a single executable.]

Thanks.

______________________________________________
R-devel <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 0 comments |

Gmane