Re: [Rd] Package Unit Testing
> "miguel" == miguel manese <[EMAIL PROTECTED]> > on Mon, 3 Jul 2006 09:43:12 +0800 writes: miguel> Hello, Do we have like an official unit testing miguel> framework for packages? Like we do R CMD check, and miguel> say the scripts in /test are executed? yes. Just it's "./tests", not './test'. More specifically, all ./tests/*.R are executed and for those foobar.R for which there's a foobar.Rout.save file, the output is (R CMD Rdiff)ed agains the result of running foobar.R All this should be pretty obvious from the manual "Writing R Extensions". What was it in there that was not clear enough? miguel> Or do we roll out our own outside the package? Some people use the 'RUnit' package in addition or -- unfortunately -- alternatively to the "official" testing procedures via the "./tests" directory. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installation, permissions of /usr/local/lib/R (PR#9054)
On Sun, 2 Jul 2006, Peter Dalgaard wrote: >>> make install >>> >>> and everything works except that /usr/local/lib/R/etc/ldpaths was not >>> readable >>> as normal user. > More likely, the umask setting was too restrictive during make > install. AFAIR, "umask 022" (i.e. no write permission for anyone > except user, but read and execute allowed) is needed to enable > non-root users to run R. Some systems set it differently, and we're > not overriding that since it could be a policy issue. It's not a bug. Yep, umask was 077. Maybe 'make install' might warn about that after installation? -- Jori Mäntysalo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installation, permissions of /usr/local/lib/R (PR#9054)
On Sun, 2 Jul 2006, Peter Dalgaard wrote: >>> make install >>> >>> and everything works except that /usr/local/lib/R/etc/ldpaths was not >>> readable >>> as normal user. > More likely, the umask setting was too restrictive during make > install. AFAIR, "umask 022" (i.e. no write permission for anyone > except user, but read and execute allowed) is needed to enable > non-root users to run R. Some systems set it differently, and we're > not overriding that since it could be a policy issue. It's not a bug. Yep, umask was 077. Maybe 'make install' might warn about that after installation? -- Jori Mäntysalo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot with NAs in x and type="s" (PR#9046)
> "ReneL" == Rene Locher <[EMAIL PROTECTED]> > on Fri, 30 Jun 2006 15:26:18 +0200 (CEST) writes: ReneL> Full_Name: René Locher Version: Version 2.3.1 ReneL> (2006-06-01) OS: i386, mingw32 Submission from: ReneL> (NULL) (160.85.104.70) ReneL> The problem seems to occur only, when you want to ReneL> plot a vector containing a NA value at position 2 and ReneL> the plotting type is "s" or "S". Yes, thank you, René. An even simpler example is plot(0 / -1:1, type = "s") This will be fixed in R-patched and R-devel as of tomorrow's snapshots. Martin Maechler, ETH Zurich ReneL> ## start of code ReneL> O3<-c(0.8,NA,0.7,1.1,0.9,5.5,1.3,1,1.2) ReneL> ## The following error is reported with the two commands below: ReneL> ## Error in plot.xy(xy, type, ...) : unable to allocate memory (in GPolygon) ReneL> plot(O3,type="s") ReneL> plot(O3,type="S") ReneL> ## The following commands work without problems ReneL> plot(O3,type="l") ReneL> plot(c(0.6, O3),type="s") ReneL> plot(c(0.4,0.6, O3),type="s") ReneL> plot(O3[2:length(O3)], type="s") ReneL> ## end of code ReneL> Kind regards ReneL> René __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 object type available for testing
The default prototype object for an S4 class up to now has been a
zero-length list (nothing else worked). This is wrong in principle,
because it makes the objects look like vectors to low-level C code, and
they should not. It may also be the cause of some inefficiency.
A new low-level type has been added for these classes. It's currently
available in the r-devel version, but not turned on by default. If you
have code that makes use of S4 objects, or C-level code that tries to
handle all internal types, please try to test out the new feature.
To turn the feature on, set environment variable R_S4_Type to anything
non-empty, for example in bash
$ export R_S4_Type=TRUE
before starting up R. You can also turn the new type on and off in R by
calling methods:::.useS4Prototype(TRUE) or FALSE. (This is a temporary
situation, eventually the type will be made the default.)
Note the following points.
1. The type affects the prototype object for the class. Therefore what
matters is whether it's turned on when the call to setClass() takes
place. It has NO effect on objects generated from an existing class.
And turning the type off has no effect until a new setClass() call.
2. Classes that contain any of the basic R object types ("character",
"function", etc.) are unaffected by the change. Their prototype objects
will still have the inherited basic type, as they should.
3. To see what the current prototype is, use defaultPrototype(). If the
new type is on you should see:
> defaultPrototype()
4. Not directly related, but some changes have been made to make
automatic printing of S4 objects correspond more closely to a call to
show(), as per the green book.
John
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Business Offer (PR#9056)
--qzsoft_directmail_seperator Content-Type: text/plain; charset="DEFAULT" Content-Transfer-Encoding: base64 RGVhciBTaXIvTWFkYW0sCiAKSSBhbSBNci5YYWlvIFdhbmcsIERpcmVjdG9yIG9mIFNoZW5nYXJk IEVudGVycHJpc2UgQ28uLCBMdGQuIFRhaXdhbi4gV2UgYXJlIGV4cG9ydGVycyBhbmQgaW1wb3J0 ZXJzIG9mIGNoZW1pY2FsIHJhdyBtYXRlcmlhbHMgdG8gQ2FuYWRhL0FtZXJpY2EgYW5kIEV1cm9w ZS4KIApEdWUgdG8gb3VyIGV4cGFuc2lvbiBwcm9ncmFtbWUgYW5kIHdpdGggYSB2aWV3IHRvIHNw ZWNpYWxpemF0aW9uIGZvciBiZXR0ZXIgZWZmaWNpZW5jeSwgYW1vbmdzdCBvdGhlcnMsIHdlIGFy ZSBzZWFyY2hpbmcgZm9yIHJlcHJlc2VudGF0aXZlcyB3aG8gY2FuIGhlbHAgdXMgZXN0YWJsaXNo IGEgbWVkaXVtIG9mIGdldHRpbmcgdG8gb3VyCmN1c3RvbWVycyBpbiB0aGUgQ2FuYWRhL0FtZXJp Y2EgYW5kIEV1cm9wZSBhcyB3ZWxsIGFzIG1ha2luZyBwYXltZW50cyB0aHJvdWdoIHlvdSB0byB1 cy4KIApQbGVhc2UgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRyYW5zYWN0aW5nIGJ1c2luZXNz IHdpdGggdXMgd2Ugd2lsbCBiZSB2ZXJ5IGdsYWQuIFBsZWFzZSBjb250YWN0IHVzIGZvciBtb3Jl IGluZm9ybWF0aW9uIFN1YmplY3QgdG8geW91ciBzYXRpc2ZhY3Rpb24geW91IHdpbGwgYmUgZ2l2 ZW4gdGhlIG9wcG9ydHVuaXR5IHRvIG5lZ290aWF0ZSB5b3VyIG1vZGUgb2Ygd2hpY2ggd2Ugd2ls bCBwYXkgZm9yIHlvdXIgc2VydmljZXMgYXMgb3VyIHJlcHJlc2VudGF0aXZlIGluIENhbmFkYS9B bWVyaWNhIGFuZCBFdXJvcGUgKGluY2x1ZGluZyBVSykuCiAKUGxlYXNlIGlmIHlvdSBhcmUgaW50 ZXJlc3RlZDsgY29udGFjdCB1cyBhdDp4YWlvd25nQHlhaG9vLmNvLnVrICBmb3IgZnVydGhlciBp bmZvcm1hdGlvbi4KIApUaGFua3MgSW4gYWR2YW5jZS4KIApSZWdhcmRzLApNci4gWGFpbyBXYW5n CkRpcmVjdG9yClNoZW5nYXJkIEVudGVycHJpc2UgQ28uLCBMdGQuLApOby4gMTMsIExhbmUgMTg1 LCBEYWh1IFJkLiwKWWluZ2dlIEplbiwgVGFpcGVpLCBUYWl3YW4gMjM5LCBSLk8uQy4g --qzsoft_directmail_seperator-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Template" for model.matrix functions
On Mon, 3 Jul 2006, Gregor Gorjanc wrote: > Hello! > > I would like to write a function that would create a (part) of a model > matrix to be used in lm() like functions i.e > > lm(y ~ myFunc(x)) > > Where can I find a good example or a template for this as well as for > predict method? I would look at bs() and ns() in the splines package. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] noncentral F-distributed random numbers (PR#9055)
On Sat, 1 Jul 2006, [EMAIL PROTECTED] wrote:
>
> The rf() function reads:
>> rf
> function (n, df1, df2, ncp = 0)
> {
>if (ncp == 0)
>.Internal(rf(n, df1, df2))
>else rchisq(n, df1, ncp = ncp)/rchisq(n, df2)
> }
>
>
> where I believe both the numerator and the denominator should be divided by
> their corresponding degrees of freedom.
>
Yes. Fixed for 2.4.0.
I didn't add a denominator non-centrality parameter, since we don't have
code for qf, pf, or df for the doubly non-central distribution.
-thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package Unit Testing
Thanks to both of you. I found it in some obscure paragraph (or maybe I haven't read good enough, because after reading a couple of paragraphs you'd think you got it already and skip the remaining) on chapter 1, creating packages, about directory structure and on R CMD check. Cheers, M. Manese On 7/3/06, Martin Maechler <[EMAIL PROTECTED]> wrote: > > "miguel" == miguel manese <[EMAIL PROTECTED]> > > on Mon, 3 Jul 2006 09:43:12 +0800 writes: > > miguel> Hello, Do we have like an official unit testing > miguel> framework for packages? Like we do R CMD check, and > miguel> say the scripts in /test are executed? > > yes. Just it's "./tests", not './test'. > > More specifically, all ./tests/*.R are executed and for those > foobar.R for which there's a foobar.Rout.save file, > the output is (R CMD Rdiff)ed agains the result of running foobar.R > > All this should be pretty obvious from the manual > "Writing R Extensions". > What was it in there that was not clear enough? > > miguel> Or do we roll out our own outside the package? > > Some people use the 'RUnit' package in addition or -- unfortunately -- > alternatively to the "official" testing procedures via the > "./tests" directory. > > Martin Maechler, ETH Zurich > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
