[Rd] Bug? in some package installations when a Print is added in memory.c
Dear r-devel,
The first time i noticed this problem is when i enabled some debug
prints in memory.c
DEBUG_GC
DEBUG_ADJUST_HEAP
DEBUG_RELEASE_MEM etc.. These have some prints for debugging .Base R package
installation completes well and good.
The problem comes when some of the Recommended package installation happens.
The following Packages fail "KernSmooth,lattice,rpart,cluster,survival
etc..."
To know the problem i removed the redirection of error to null in
R-2.7.0/src/library/Recommended/Makefile (remove 2>/dev/null around line
number 80 )
and i came to know that it tries to compile packages based on output of some
R session which i think is not proper..
Easier Way to reproduce this
==
in InitMemory routine in memory.c add this piece of code in the starting
Rprintf("test print\n");//so that it is printed only once
//the same problem comes with printf but not fprintf(stderr ...) That means
only STDOUT matters for this Bug
and while the package installation starts you can see some thing like after
avoiding redirection of stderr (see above)
>>>
* Installing *source* package 'lattice' ...
** libs
make[3]: Entering directory `/tmp/R.INSTALL.NjKF3D/lattice/src'
gcc -std=gnu99 -I/home/subramra/performance-tests/R-2.7.0/include
-I/usr/local/include test print -fPIC -g -O2 -c init.c -o init.o
gcc -std=gnu99 -I/home/subramra/performance-tests/R-2.7.0/include
-I/usr/local/include test print -fPIC -g -O2 -c threeDplot.c -o
threeDplot.o
gcc: test: No such file or directory
gcc: print: No such file or directory
gcc: test: No such file or directory
gcc: print: No such file or directory
make[3]: *** [init.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [threeDplot.o] Error 1
make[3]: Leaving directory `/tmp/R.INSTALL.NjKF3D/lattice/src'
ERROR: compilation failed for package 'lattice'
** Removing '/home/subramra/performance-tests/R-2.7.0/library/lattice'
make[2]: *** [lattice.ts] Error 1
>>>
So essentially the problem is these packages try to compile files which are
printed out!!!And if there are prints in memory.c they FAIL.
Is this a BUG?
Thanks and Regards,
Subramanian R.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] confusing documentation (PR#13077)
Full_Name: Danny Version: 2.7.2 OS: Windows XP SP3 Submission from: (NULL) (71.139.13.68) Some parts of the R documentation seem pretty confusing. When R is launched, the text "Natural language support but running in an English locale" appears. What is this supposed to mean? It should probably be reworded or removed. The text "[Package stats version 2.7.2 Index]" appears at the bottom of each page. The "Index]" takes the user to the index. I believe that the developers meant to just link "Index" (without the closing brackets). However, to make it less confusing, it should look something like "[Package stats version 2.7.2] [Index]" with two separate sets of brackets. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RWeka can't evaluate classifier on new data (PR#13076)
Full_Name: Bin Ye Version: 2.7.2 OS: Window XP Submission from: (NULL) (146.9.105.101) command "evaluate_Weka_Classifier", option "newdata=" doesn't working. No matter you provide new data or not, it always gives you the confusion matrix evaluating with the training data. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in R-Intro document (PR#13079)
Full_Name: David Hedin Version: R 2.6.0 GUI 1.21 OS: Mac 10.4.11 Submission from: (NULL) (24.205.60.123) page 64 of the R introduction document makes the claim "If the probability=TRUE argument is given, the bars represent relative frequencies instead of counts" This is wrong, the densities (relative frequency/class width) are given, not the relative frequency. It's only true when the class width is 1. What IS the code which will produce a relative frequency histogram? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug? in some package installations when a Print is added in memory.c
subramanian R wrote:
So essentially the problem is these packages try to compile files which are
printed out!!!And if there are prints in memory.c they FAIL.
Is this a BUG?
Only in your code. There are things in the INSTALL script that rely on
calling R and looking at its output, e.g.
lib=`echo "cat('\n~~~', .libPaths()[1], '\n', sep = '')" | \
R_DEFAULT_PACKAGES=NULL "${R_EXE}" --no-restore --slave | \
grep '^~~~' | ${SED} 's/.*~~~//'`
This implies that if you modify R's output, you may break things. It is
not a bug that R's developers assume that they know what the output of R
will be. It would be if the assumptions were wrong, but this does not
include the case where someone makes deliberate changes to the code.
(The section above may or may not be the one that is giving you problem.
It's just to make the point.)
The fix could be to conditionalize your test prints on something (an
environment variable, or if you can access flags set by --slave) or just
not use the hacked version for package installation.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS Crash"}
> "VW" == Viechtbauer Wolfgang (STAT) <[EMAIL PROTECTED]> > on Fri, 26 Sep 2008 18:00:19 +0200 writes: VW> Hi all, I'm trying to fit a marginal (longitudinal) VW> model with an exponential serial correlation function to VW> the Orange tree data set. However, R crashes frequently VW> when using the gnls() function. With the following VW> simple example, I was able to reproduce the problem. VW> gnls.exp <- gnls(circumference ~ Asym/(1 + exp(-(age-xmid)/scal)) , VW> data = Orange, correlation = corExp(form = ~1 | Tree), VW> start = c(Asym=150, xmid=750, scal=300)) Yes, I can reproduce it (on a Linux (RHEL 5) 64bit server), using R 2.8.0 alpha : Use this for(i in 1:20)# for MM: ca. 8 to 10 times --> seg.fault try( gnls.exp <- gnls(circumference ~ Asym/(1 + exp(-(age-xmid)/scal)) , data = Orange, correlation = corExp(form = ~1 | Tree), start = c(Asym=150, xmid=750, scal=300)) ) If I run it in the debugger and then do a backtrace I see Error in gnls(circumference ~ Asym/(1 + exp(-(age - xmid)/scal)), data = Orange, : Step halving factor reduced below minimum in NLS step [] [...the same about 6 times...] [] Error in gnls(circumference ~ Asym/(1 + exp(-(age - xmid)/scal)), data = Orange, : Step halving factor reduced below minimum in NLS step Error in .makeMessage(..., domain = domain) : incorrect number of arguments to "<-" Error in .makeMessage(..., domain = domain) : incorrect number of arguments to "<-" Program received signal SIGABRT, Aborted. 0x003294e30155 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x003294e30155 in raise () from /lib64/libc.so.6 #1 0x003294e31bf0 in abort () from /lib64/libc.so.6 #2 0x004184f5 in R_gc_internal (size_needed=0) at ../../../R/src/main/memory.c:761 #3 0x0041b121 in Rf_cons (car=0x1b2ec088, cdr=0x1a3436d8) at ../../../R/src/main/memory.c:1755 #4 0x00578472 in applydefine (call=, op=0x1a3617a8, args=0x1ad47590, rho=0x1b2ea428) at ../../../R/src/include/Rinlinedfuns.h:153 #5 0x00575a42 in Rf_eval (e=0x1ad47558, rho=0x1b2ea428) at ../../../R/src/main/eval.c:461 #6 0x00576d50 in do_begin (call=0x1ad48450, op=0x1a362518, args=0x1ad47520, rho=0x1b2ea428) at ../../../R/src/main/eval.c:1174 #7 0x00575a42 in Rf_eval (e=0x1ad48450, rho=0x1b2ea428) at ../../../R/src/main/eval.c:461 #8 0x00578f9c in Rf_applyClosure (call=0x1b2e9958, op=0x1ad48370, arglist=0x1b2e9a70, rho=0x1b690298, suppliedenv=0x1b2e99c8) at ../../../R/src/main/eval.c:667 #9 0x004285b9 in Rf_usemethod (generic=0x67e8d7 "[", obj=, call=, args=, rho=0x, callrho=0x1b690298, defrho=0x1a384f28, ans=0x7fffcaa8d5a8) at ../../../R/src/main/objects.c:311 #10 0x00576a25 in Rf_DispatchOrEval (call=0x1a81d8d0, op=0x1a3622e8, generic=0x67e8d7 "[", args=0x1a81d908, rho=0x1b690298, ans=0x7fffcaa8d5a8, dropmissing=0, argsevald=0) at ../../../R/src/main/eval.c:1930 #11 0x004afc40 in do_subset (call=0x7716, op=0x7716, args=0x, rho=0x1b690298) at ../../../R/src/main/subset.c:577 #12 0x00575a42 in Rf_eval (e=0x1a81d8d0, rho=0x1b690298) at ../../../R/src/main/eval.c:461 #13 0x005780c7 in applydefine (call=0x1a81d748, op=0x1a3617a8, args=0x6, rho=0x) at ../../../R/src/main/eval.c:1318 #14 0x00575a42 in Rf_eval (e=0x1a81d748, rho=0x1b690298) at ../../../R/src/main/eval.c:461 #15 0x005775de in do_for (call=0x1a81d668, op=0x1a360180, args=0x1a81d6a0, rho=0x1b690298) at ../../../R/src/main/eval.c:1073 . and more (downto #155 for R's main(...) This is a bug, probably in the C code of package nlme which I guess corrupts memory somehere earlier, and we are seeing the effect only later. I'll leave this to the (memory-)debugging experts... Martin VW> On my and one other computer, R usually crashes when calling the gnls() function with this code three times in a row. I stumbled across this when trying to fit this model with different starting values. VW> Version information: VW> platform i386-pc-mingw32 .. VW> version.string R version 2.7.2 (2008-08-25) VW> Can anybody help figure out what causes this problem? VW> Best, VW> -- VW> Wolfgang Viechtbauer VW> Department of Methodology and Statistics VW> University of Maastricht, The Netherlands VW> http://www.wvbauer.com/ VW> ___ VW> [EMAIL PROTECTED] mailing list VW> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo
Re: [Rd] Error in R-Intro document (PR#13079)
> "d" == davidhedin <[EMAIL PROTECTED]> > on Sat, 27 Sep 2008 07:10:06 +0200 (CEST) writes: d> Full_Name: David Hedin Version: R 2.6.0 GUI 1.21 OS: Mac d> 10.4.11 Submission from: (NULL) (24.205.60.123) d> page 64 of the R introduction document makes the claim d> "If the probability=TRUE argument is given, the bars d> represent relative frequencies instead of counts" d> This is wrong, the densities (relative frequency/class d> width) are given, not the relative frequency. It's only d> true when the class width is 1. Thank you; I have added "divided by the bin width". Note that one could argue that it really depends on the definition of "relative" if paragraph you cite is really wrong. I could define "relative" to mean "relative WRT to the total and the bin width" :-) D> What IS the code which will produce a relative frequency d> histogram? Well, do you really want a y-axis scale which is neither counts nor has the usual density scale? I'd recommend against that. Here's an example derived from help(plot.histogram) : wwt <- hist(women$weight, nclass = 7, plot = FALSE) ## modify the result to show "relative frequencies" wt. <- wwt; wt.$density <- wwt$density * diff(wwt$breaks)[1] plot(wt., freq=FALSE, ylab="Relative Frequency") ## or probably rather wtP <- wwt; wtP$density <- wwt$density * 100 * diff(wwt$breaks)[1] plot(wtP, freq=FALSE, ylab="Relative Frequency [ % ]") But note that I would strongly advocate to use the default of counts instead of the above, since from counts, one intuitively gets a notion of *precision* (most people have a crude approximation of the Poisson built in their brains :-) which is completely lost when switching to percents. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] On modes, types and R documentation
> "BaRow" == Barry Rowlingson <[EMAIL PROTECTED]> > on Fri, 26 Sep 2008 07:50:33 +0100 writes: BaRow> 2008/9/25 Kingsford Jones <[EMAIL PROTECTED]>: >> >> Try >> >> ?type >> >> which correctly guesses the user is looking for the >> 'typeof' page. >> >> Or even >> >> example(type) >> >> Also, after a brief introduction, the R Language >> Definition document begins with a discussion of types. >> >> Kingsford Jones BaRow> But if, oh if, we could start R from scratch, would the documentation BaRow> contain such gems as: BaRow> "value: a character string giving the desired mode BaRow> or 'storage mode' (type) of the object." Barry, thank you, and we're very often very thankful for patches to the docs... I see you found this on help(mode) and there, it is documenting "value" for mode(x) <- value and storage.mode(x) <- value and for that reason got to the above gem. You probably know that 'type' / 'typeof' is an R-specific (non-S) concept which has been part of R even before it's pre-alpha version got a version number. It returns the basic R-internal "SEXP" type. storage.mode is similar (an old S concept), but slightly different: > storage.mode function (x) switch(tx <- typeof(x), closure = , builtin = , special = "function", tx) but I agree equivalent for almost all purposes. So maybe one should drop the '(type)' part in the above gem. - BaRow> """ BaRow> As storage mode "single" is only a pseudo-mode in BaRow> R, it will not be reported by mode or storage.mode: BaRow> use attr(object, "Csingle") to examine this. However, BaRow> mode<- can be used to set the mode to "single", which BaRow> sets the real mode to "double" and the "Csingle" BaRow> attribute to TRUE. Setting any other mode will remove BaRow> this attribute. Ah. I found this is cited from the 'Details' section of help(mode). Well, I could argue that this paragraph and almost all mentioning of "single" on that help page should be dropped, and only one link to help(single) should remain. One reason it's there, may be because this part is different from S/S-plus. I don't see why an average user should see any mention of "single" at all. BaRow> Looking at the R docs for typeof and mode it seems to BaRow> refer to modes, types, storage modes, (storage) BaRow> modes, 'storage mode' (type)s, real modes, BaRow> pseudo-modes and internal types. Confused? Clearly BaRow> people are! :-) nice list ! If we eliminated the above "single" paragraph, we'd eliminate "pseudo-mode" and "real mode"... Otherwise, I'm sure you know that type = internal type storage.mode = an almost equivalent union (of 'type') mode = an S/S-plus compatible version of storage.mode but for many years, we've now had class() which for the average user should be sufficient in 98% of the cases, and in the other 2% , typeof() would provide the extra info. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Outdated dependencies and install.packages()
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
> on Thu, 21 Aug 2008 10:53:58 +0200 writes:
PD> Martin Maechler wrote:
>>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
>>> on Wed, 20 Aug 2008 17:06:36 +0200 writes:
>>>
>>
PD> Prof Brian Ripley wrote:
>> >> On Wed, 20 Aug 2008, Peter Dalgaard wrote:
>> >>
>> >>> This looks like a buglet:
>> >>>
>> install.packages("lme4", depend=TRUE, lib="~/Rlibrary/")
>> >>> --- Please select a CRAN mirror for use in this session ---
>> >>> [...snip...]
>> >>> ** preparing package for lazy loading
>> >>> Error: package 'Matrix' 0.999375-4 was found, but >= 0.999375.11 is
>> >>> required by 'lme4'
>> >>> Execution halted
>> >>> ERROR: lazy loading failed for package 'lme4'
>> >>> ** Removing '/home/bs/pd/Rlibrary/lme4'
>> >>> ** Restoring previous '/home/bs/pd/Rlibrary/lme4'
>> >>>
>> >>> and the DESCRIPTION file for lme 4 does have
>> >>>
>> >>> Depends: methods, R(≥ 2.7.0), Matrix(≥ 0.999375-11), lattice
>> >>>
>> >>>
>> >>>
>> >>> Looks like we're either not checking the version requirement of
>> >>> dependencies, or something is making 4 > 11... (from my reading of
the
>> >>> code, it is the former, but I could have missed something).
>> >>
>> >> We don't check version requirements of dependencies in
>> >> install.packages(). That's a minefield related to having multiple
>> >> versions of a package on a system and which gets loaded/namespace
>> >> loaded, so you can easily have the needed version but pick up a
>> >> different one.
>> >>
>> >> Depending on whether lazy-loading is in place (and various other
>> >> issues) you may or may not need the dependencies to install the
>> >> package. It's also a problem that you can update dependencies to
>> >> incompatible ones, so the versions available at installation are only
>> >> part of the story.
>> >>
>> >> I don't see why the message reports .11 not -11, but that may be
>> >> related to "package_version" classes.
>> >>
>> >>> We should at least document the behaviour.
>> >>
>> >> I am not sure where you think it should be documented and is not.
>> >> But for install.packages():
>> >>
>> >> dependencies: logical indicating to also install uninstalled packages
>> >> on which these packages depend/suggest/import (and so on
>> >> recursively). Not used if 'repos = NULL'. Can also be a
>> >> character vector, a subset of 'c("Depends", "Imports",
>> >> "Suggests")'.
>> >>
>> >> 'uninstalled' seems pretty clear to me.
>> >>
PD> It isn't. Matrix 0.999375-11 was 'uninstalled'. The above could just
PD> mean that if you installed it, it wouldn't be installed again.
>>
PD> Something like "Notice that version dependencies are not checked." would
PD> help. (Assuming that people read the help page.)
>>
>> Or even more:
>>
>> "
>> Notice that version dependencies are not checked such that
>> outdated versions of installed packages are \emph{not} updated.
>> Consider using \code{\link{update.packages}()} before
>> \code{install.packages()}.
>> "
>>
>> Note that --- thanks to Heather Turner nice help.request() proposal ---
>> one of my top "TODOs" for R-devel is
>> to finish a generalization of the current
>> update.packages()
>> function (that I have not quite finished)
>> which will allow to only look for updates of specified set of
>> packages rather than all packages in a given lib.loc
>> {something that should *not* be triggered by a help.request()
>> for a user (as ours) who has ~ 2000 R packages installed}.
I have now finally committed this code to R-devel (rev 46576)
and plan to port it to R-2.8.0 alpha before feature freeze.
It may well be worth if a few people have a look, and maybe even
try to send their next R-help e-mail with the new
help.request() function ..
Martin
PD> That's essentially what happened to me (not with 2000 packages, though).
PD> I was looking into the lme4/aod issue - reinstall lme4 - Matrix out of
PD> date - update.packages() - wait for an hour or so for gtk2 and friends
PD> to be updated on my laptop...
PD> --
PD> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
PD> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
PD> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
PD> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
