Re: [Rd] kcachegrind and R
Le 11.04.2006 10:01, Romain Francois a écrit : > Hi, > > Is there a way to use kcachegrind on R code ? > I mean the R function written in R (not the C, etc ... functions). Has > someone tried to generate "Callgrind profile format" from ouputs of Rprof ? > > Romain > Hi all, I tried to answer my own question since yesterday. I made a package http://addictedtor.free.fr/packages/grindR_0.0.tar.gz that start the translation accordind to the kcachegrind manual there http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindCalltreeFormat The code is not entirely working (it is version 0.0), but at least it shows that it is possible to use kcachegrind on R code. Is there somebody interrested in such a project (to use it and/or help me improving it) ? Best Regards, Romain -- visit the R Graph Gallery : http://addictedtor.free.fr/graphiques mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php +---+ | Romain FRANCOIS - http://francoisromain.free.fr | | Doctorant INRIA Futurs / EDF | +---+ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] headerfile translation to Delphi (Pascal) completed
Hi, I am happy to announce that I finished the translation of almost all LGPL'ed R headerfiles to Delphi. As a test I did several demos which basically contain delphized versions of all the examples of chapter 5 in "Writing R Extensions". Please have a look in the attachments for details (DemosAndHeaders.txt), more information (Readme.txt) and an example of how it looks (Convolve.pas). The final version will be released some time later* as GPL. By now I'd like to make available the sources to all interested R regulars in order to try out and - maybe - to get some feedback. Just drop me a mail and I'm happy to send you the sources**. (Btw, I worked with Delphi 2006 (tested with D6 also). I don't know/use the FreePascal compiler so it's windows only (at least for the moment)). Best regards, Hans-Peter *After R2.3; also I need to do larger tests and think about some kind of testframework **I already sent them to the few persons I know who might be interested - - - | Hans-Peter Suter, Dipl. Natw. ETH / SW-Entwickler | Treetron Umweltinformatik, Zuerich Tel +41(1)242 22 55 | mailto: .@treetronPUNKTch | or: [EMAIL PROTECTED] DEMOS Available: - Convolve | - RegisteredConvolve | - Initialize | - GlobalVariables | - AcrossTheBoard In each folder is a specific script _rscript and in the Demo folder two global ones (_rscript/_rscriptMultiple) Convolve The first demo presents the convolve examples from the manual "Writing R Extensions" in a "Delphi-translated" version. The three interface functions .C, .Call and .External are used and the application of some macros in Rinternals.h and Rdefines.h (which become rhRInternal.pas and rhRDefines.pas) is shown. RegisteredConvolve -- "RegisteredDemoEx.dll" shows how to register a Delphi function in the "R_init_" call. [The RegisteredConvDemo was the first attempt but the freely called register method "RegisterConvolveRoutines" still crashes in some circumstances (see _rscriptMultiple.R) for unknown reason] Initialize -- This important demo prints the sequence of the initialize and finalize calls. Can be used as a template. Global variables Delphi cannot directly use global variables in DLL's. We have to assign them manually. This demo was our test ground. The units rhR, rhRInternal and rhR have such variables. Search for the overloaded function ToRVarsArr to find the relevant places. Across the board An extensive demo with basically all the remaining examples from "Writing R Extensions". We failed with print attributes (bloody Lisp!) and left out parsing R code, but the rest is here. HEADER UNITS [Quality: 1: tested, 2: anecdotic tests, 3: compiles, 4: unfinished Tested on R 2.2.1 and 2.3.alpha] R Headerfile becomes Quality Delphi unit -- Applic.h---> 3 rhApplic.pas Arith.h ~~~> 2 rhR.pas BLAS.h ---> 3 rhBlas.pas Boolean.h ~~~> 2 rhTypesAndConsts.pas Callbacks.h ---> 3 rhCallbacks.pas Complex.h ~~~> 2 rhTypesAndConsts.pas Constants.h ~~~> 3 rhTypesAndConsts.pas Error.h ~~~> 2 rhR.pas eventloop.h 4 (no entry points, probably unix-only) GraphicsBase.h (??) 4 (partly done, some types GPL only? FIXME) GraphicsDevice.h---> 3 rhGraphicsDevice.pas GraphicsEngine.h---> 3 rhGraphicsEngine.pas Lapack.h 4 (MAYBE LATER - exported in Rlapack.dll) libextern.h (xx) - (contains defines - not relevant) Linpack.h 4 (MAYBE LATER) Memory.h~~~> 3 rhR.pas Print.h ~~~> 2 rhR.pas PrtUtil.h ---> 3 rhPrtUtil.pas R-ftp-http.h---> 3 rhRftpHttp.pas R.h ~~~> 3 rhTypesAndConsts.pas Random.h~~~> 3 rhR.pas / rhTypesAndConsts.pas RConverters.h ---> 3 rhRConverters.pas Rdefines.h ---> 2 rhRDefines.pas Rdynload.h ---> 2 rhRDynload.pas Rdynpriv.h ~~~> 2 rhRDynload.pas Rgraphics.h ---> 3 rhRGraphics.pas Riconv.h---> 3 rhRIconv.pas Rinlinedfuns.h - (probably(?) only Gnu C compiler relevant) Rinternals.h---> 2 rhRInternals " (use Internal stuff) ~~~> 3 rhRUseInternals (NOT TO BE PUBLISHED
[Rd] Label size in MAplots
Hi I have a collection of arrays and I would like to carry out MAplots on them. The problem is that the CEL file names are pretty long as they contain the date of production, user initials etc.. (sorry, it's a legacy thing). Is there a way of reducing the label size so I can read the CEL filename and the Median and IQR statistics in the plot. It currently gets cut off and I can't see which file is which. I have tried labels.cex but it doesn't work. Any help appreciated. I'm also have the same issue with boxplots. Tony CSC/IC Microarray Centre, Imperial College, Hammersmith Campus, Du Cane Road London W12 0NN Tel: +44 20 8383 2405 Fax: +44 20 8383 8577 http://microarray.csc.mrc.ac.uk [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug#361968: Wrong name in manpage
> On Tue, 11 Apr 2006 20:56:27 -0400,
> Duncan Murdoch (DM) wrote:
> On 4/11/2006 7:45 PM, Dirk Eddelbuettel wrote:
>> R-devel'ers,
>>
>> On 11 April 2006 at 10:24, Dirk Eddelbuettel wrote:
>> |
>> | Kanru,
>> |
>> | Thanks for the bugreport.
>> |
>> | On 11 April 2006 at 22:03, Kanru Chen wrote:
>> | | Package: r-base-core
>> | | Version: 2.2.1.svn37668-1
>> | | Severity: minor
>> | |
>> | | In manpage of /usr/bin/R, the first, fourth and last line shows
`VERSION'
>> | | instead of `R'.
>>
>> I haven't seen any follow-up yet -- here is what it looks like (cut and
>> pasted from Emacs man page viewer) and note the 'Version' in place of R:
>>
>> VERSION(1)FSF
VERSION(1)
>>
>> NAME
>> Version - a language for data analysis and graphics
>>
>> SYNOPSIS
>> R [options] [< infile] [> outfile]
>> R CMD command [arguments]
>>
>> DESCRIPTION
>> Start R, a system for statistical computation and graphics, with the
>> specified options, or invoke an R tool via the 'R CMD' interface.
>> [...]
>>
>>
>> | | I believe it is a typo.
>> |
>> | More likely something is wrong with how R.1 is autogenerated using
help2man.
>> |
>> | Incidentally, that `R --version' now starts its ouput with 'Version'
rather
>> | than R had bit us in the RPy builds where the version number was
regexp'ed
>> | out of the result, and was still expecting the line to start with R just
like
>> | help2man seems to expect the program name first.
>>
>> It seems to stem from src/main/version.c:
>>
>> void attribute_hidden PrintVersionString(char *s)
>> {
>> if(strcmp(R_SVN_REVISION, "unknown")==0)
>> {
>> sprintf(s, "Version %s.%s %s (%s-%s-%s)",
>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY);
>> }
>> else{
>> if(strlen(R_STATUS)==0){
>> sprintf(s, "Version %s.%s (%s-%s-%s)",
>> R_MAJOR, R_MINOR, R_YEAR, R_MONTH, R_DAY);
>> }
>> else{
>> sprintf(s, "Version %s.%s %s (%s-%s-%s r%s)",
>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY,
>> R_SVN_REVISION);
>> }
>> }
>> }
>>
>> Would replacing 'Version ...' with 'R (Version ...)' be an acceptable
>> alternative ?
> I think the problem is that PrintVersion (a few lines up from there)
> used to put the R in front; PrintVersionString doesn't include the R.
> PrintVersionString is called from other places where the R would not be
> appropriate, but PrintVersion is only called when acting on `R
> --version' or synonyms.
> Fritz, I think this was your change in r36923 a few months ago. Do you
> have time to deal with it?
Yes, will do later today.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] type converters not being saved to workspace
Well, you may be right, but my experiments certainly suggested
otherwise (below).
But my main point is that we should look for a better approach, and I
think we agree there.
Prof Brian Ripley wrote:
> On Tue, 11 Apr 2006, John Chambers wrote:
>
>> (diverted to r-devel)
>>
>> The problem seems to be rather that loading of the saved image takes
>> place _after_ the packages are attached. So nothing that the methods
>> package does in its initialization will see the relevant type
>> converters or other methods objects.
>
>
> I am sorry, but that is not the case: see ?Startup. The image is
> loaded _before_ the packages are attached (as documented).
Perhaps. But then why is it that if I put some trace printing in the
.First.lib of methods, that printing comes out before the message
"Previously saved "?
> You can check explicitly by
>
> env R_DEFAULT_PACKAGES=NULL R --restore
> # R starts and loads the workspace
>
>> library(methods)
>
>
> and it still does not work (as I had tried before answering).
I'm not disputing that: the methods initialization did not call
cacheMetaData for the methods package itself--it was because the fix I
implemented to explicitly cache the generics in methods did NOT work
that I inferred the point about the ordering. (Some printout is below,
but of course I'm not asserting that the fix might not have a different
problem in it.)
--
enterprise:~/testR [160]> R
R : Copyright 2006, The R Foundation for Statistical Computing
Version 2.4.0 Under development (unstable) (2006-04-10 r37703)
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.
Natural language support but running in an English locale
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 an HTML browser interface to help.
Type 'q()' to quit R.
cacheMetaData called for methods namespace
[Previously saved workspace restored]
R> names(getMethods("coerce")@methods)
[1] "ANY" "function"
---
The methods from .GlobalEnv are not found until a second cacheMetaData
is done.
>
>> More generally, loading into .GlobalEnv will never cause the
>> equivalent of cacheMetaData(.GlobalEnv).
>>
>> It would be possible to hack the C code in main/saveload.c to
>> generate a call to cacheMetaData under the right circumstances, but
>> is that the best solution? Intuitively, it's the objects containing
>> the method/class definitions that should trigger actions when they
>> are loaded (emulating what happens when the corresponding setMethod
>> or setClass function call takes place). I.e., a load method for
>> these classes of objects. Possible?
>
>
> Yes, but it will not help here as the objects are loaded without
> methods being loaded.
>
> I hope one day when we have S4 objects marked in the object headers
> that loading such an object will load and attach the methods package.
>
>> It might be better, now that we're past feature freeze, to leave this
>> as a "design infelicity" for the upcoming release.
>
>
> Definitely.
>
> I think that package methods needs to cache metadata in its .onAttach
> not .onLoad. In principle it affects anything setting methods for
> generics in package:methods, but if this is done in a package, the
> dependency on methods will ensure that methods is loaded before the
> package, and then library() will run cacheMetaData on the package.
>
>
>> Prof Brian Ripley wrote:
>>
>>> It is recommended that you use a package for this sort of thing.
>>>
>>> When a package is loaded, the S4 methods it contains are merged into
>>> the metadata. When the global environment is loaded, they are not.
>>> Call 'cacheMetaData(1)' to do so.
>>>
>>> [This looks like a bug: cacheMetaData is called on .GlobalEnv in the
>>> startup code for package methods, but seems not to work when called
>>> from there. I think this is because package methods is not at that
>>> point on the search path (the call is from .onLoad) and hence the
>>> coerce() generic is not visible to cacheMetaData. If you have S4
>>> code in a package, it will ensure that package methods is attached
>>> before your package is loaded.]
>>>
>>> On Sun, 9 Apr 2006, Joseph Wang wrote:
>>>
Any one can explain why this happens or any work arounds?
> setClass('foo')
[1] "foo"
> setAs('foo', 'character', function(from) from)
> showMethods('coerce')
Function "coerce":
from = "ANY", to = "array"
from = "ANY", to = "call"
from = "ANY", to = "character"
from = "ANY", to = "complex"
from = "ANY", to = "environment"
from = "ANY", to = "expression"
[Rd] yet another problem with S4 dispatch (with setClassUnion)
Dear John and Seth, dear R-devels,
once again the question of method dispatch in S4 -- this time with
setClassUnion(); taking up your advice in
https://stat.ethz.ch/pipermail/r-devel/2006-April/037200.html
https://stat.ethz.ch/pipermail/r-devel/2006-April/037201.html
I have been too quick in stating that
>setClassUnion()---at least in my case---solves the problem;
>
The problem arises if I have a direct superclass "competing"
with the new class generated by setClassUnion();
consider the following code:
## C00 mother class to C01 and C02
setClass("C00", representation(a="numeric"), prototype =c(a=0))
setClass("C01", representation(a="numeric",b="numeric"), contains= "C00")
setClass("C02", representation(a="numeric",d="numeric"), contains= "C00")
#with setClassUnion:
setClassUnion("C01OrC02", c("C01","C02"))
# "+" methods for C00 and C01OrC02
#that this is a function to be dispatched on two arguments is
#not important for this example
setMethod("+", signature=c("C00","C00"), function(e1,e2)[EMAIL PROTECTED]@a})
setMethod("+", signature=c("C01OrC02","C01OrC02"),
function(e1,e2){if(is(e1,"C01")) e10 <- e1
# else: explicit coercion from C02 to C01
else e10 <- new("C01", [EMAIL PROTECTED], [EMAIL
PROTECTED])
if(is(e2,"C01")) e20 <- e2
# else: explicit coercion from C02 to C01
else e20 <- new("C01", [EMAIL PROTECTED], [EMAIL
PROTECTED])
[EMAIL PROTECTED]@b})
x1=new("C02", a=1, d=2)
x2=new("C02", a=1, d=3)
x1+x2 ## 2, i.e. uses C00-method
# but I would like to force usage of C01OrC02-method
Here the two classes C00 and C01OrC02 are direct superclasses to
C02, which exactly reflects my application of distribution classes,
confer https://stat.ethz.ch/pipermail/r-devel/2006-April/037190.html
How does the dispatching mechanism decide between
these two and is there a way to change precedence?
Of course, I could implement a "+" method for C02 directly
in this case, but suppose I have much more methods for
C01 and I want to use /all/ of them for C02, and cannot
organize things so that we have the inheritance chain
C00 -> C01 -> C02. What is the preferred way of doing
this?
Thank you already for your attention,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] yet another problem with S4 dispatch (with setClassUnion)
As I think Seth told you before, if you want to control the order of
inheritance at the same level, you need to use the intended order in the
contains= argument to setClass. In your example (retaining the class
union, although it's not required, the superclass could just be an
ordinary virtual class),
setClassUnion("C01OrC02")
## C00 mother class to C01 and C02
setClass("C00", representation(a="numeric"), prototype =c(a=0))
setClass("C01", representation(a="numeric",b="numeric"),
contains= c("C01OrC02", "C00"))
setClass("C02", representation(a="numeric",d="numeric"),
contains= c("C01OrC02", "C00"))
seems to give what you want.
> x1 + x2
[1] 5
> extends("C01")
[1] "C01" "C01OrC02" "C00"
To answer one of your other questions, the point about inheritance
asserting substitutability is that you now need to be sure that EVERY
method for C01OrC02 is preferred to a method for C00 for the new subclasses.
As a general design point, having these competing superclasses is likely
to confuse the user, if not the implementer. If you could, it would
make a clearer picture to have, e.g., C01orC02 be a subclass of C00.
Then the inheritance is obvious--C01or... is a parent, while C00 is a
grandparent. The special contains= then doesn't need to be repeated
for every subclass Cx.
Peter Ruckdeschel wrote:
>Dear John and Seth, dear R-devels,
>
>once again the question of method dispatch in S4 -- this time with
>setClassUnion(); taking up your advice in
>
>https://stat.ethz.ch/pipermail/r-devel/2006-April/037200.html
>https://stat.ethz.ch/pipermail/r-devel/2006-April/037201.html
>
>I have been too quick in stating that
>
>
>
>>setClassUnion()---at least in my case---solves the problem;
>>
>>
>>
>The problem arises if I have a direct superclass "competing"
>with the new class generated by setClassUnion();
>
>consider the following code:
>
>## C00 mother class to C01 and C02
>setClass("C00", representation(a="numeric"), prototype =c(a=0))
>setClass("C01", representation(a="numeric",b="numeric"), contains= "C00")
>setClass("C02", representation(a="numeric",d="numeric"), contains= "C00")
>
>#with setClassUnion:
>setClassUnion("C01OrC02", c("C01","C02"))
>
># "+" methods for C00 and C01OrC02
>#that this is a function to be dispatched on two arguments is
>#not important for this example
>
>setMethod("+", signature=c("C00","C00"), function(e1,e2)[EMAIL PROTECTED]@a})
>setMethod("+", signature=c("C01OrC02","C01OrC02"),
> function(e1,e2){if(is(e1,"C01")) e10 <- e1
># else: explicit coercion from C02 to C01
>else e10 <- new("C01", [EMAIL PROTECTED], [EMAIL
> PROTECTED])
> if(is(e2,"C01")) e20 <- e2
> # else: explicit coercion from C02 to C01
> else e20 <- new("C01", [EMAIL PROTECTED], [EMAIL
> PROTECTED])
> [EMAIL PROTECTED]@b})
>
>x1=new("C02", a=1, d=2)
>x2=new("C02", a=1, d=3)
>
>x1+x2 ## 2, i.e. uses C00-method
># but I would like to force usage of C01OrC02-method
>
>Here the two classes C00 and C01OrC02 are direct superclasses to
>C02, which exactly reflects my application of distribution classes,
>confer https://stat.ethz.ch/pipermail/r-devel/2006-April/037190.html
>
>How does the dispatching mechanism decide between
>these two and is there a way to change precedence?
>
>Of course, I could implement a "+" method for C02 directly
>in this case, but suppose I have much more methods for
>C01 and I want to use /all/ of them for C02, and cannot
>organize things so that we have the inheritance chain
>C00 -> C01 -> C02. What is the preferred way of doing
>this?
>
>Thank you already for your attention,
>Peter
>
>__
>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] New class: data.table
Hi, Following previous discussion on this list (http://tolstoy.newcastle.edu.au/R/devel/05/12/3439.html) I have created a package as suggested, and uploaded it to CRAN incoming : data.table.tar.gz. ** Your comments and feedback will be very much appreciated. ** >From help(data.table) : This class really does very little. The only reason for its existence is that the white book specifies that data.frame must have rownames. Most of the code is copied from base functions with the code manipulating row.names removed. A data.table is identical to a data.frame other than: * it doesn't have rownames * [,drop] by default is FALSE, so selecting a single row will always return a single row data.table not a vector * The comma is optional inside [], so DT[3] returns the 3rd row as a 1 row data.table * [] is like a call to subset() * [,...], is like a call to with(). (not yet implemented) Motivation: * up to 10 times less memory * up to 10 times faster to create, and copy * simpler R code * the white book defines rownames, so data.frame can't be changed ... => new class Examples: nr = 100 D = rep(1:5,nr/5) system.time(DF <<- data.frame(colA=D, colB=D)) # 2.08 system.time(DT <<- data.table(colA=D, colB=D)) # 0.15 (over 10 times faster to create) identical(as.data.table(DF), DT) identical(dim(DT),dim(DF)) object.size(DF)/object.size(DT) # 10 times less memory tt = subset(DF,colA>3) ss = DT[colA>3] identical(as.data.table(tt), ss) mean(subset(DF,colA+colB>5,"colB")) mean(DT[colA+colB>5]$colB) tt = with(subset(DF,colA>3),colA+colB) ss = with(DT[colA>3],colA+colB) # but could be: DT[colA>3,colA+colB] (not yet implemented) identical(tt, ss) tt = DF[with(DF,tapply(1:nrow(DF),colB,last)),] # select last row grouping by colB ss = DT[tapply(1:nrow(DT),colB,last)] # but could be: DT[last,group=colB] (not yet implemented) identical(as.data.table(tt), ss) Lkp=1:3 tt = DF[with(DF,colA %in% Lkp),] ss = DT[colA %in% Lkp]# expressions inside the [] can see objects in the calling frame identical(as.data.table(tt), ss) In each case above there is either a space, time, or code brevity advantage with the data.table. The motivation for the new class grew from the realization that performance of data.frames can be improved by removing the rownames. See here for the previous discussion http://tolstoy.newcastle.edu.au/R/devel/05/12/3439.html. Regards, Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stack checking, core dumps, and embedding R
On Tue, 11 Apr 2006, A.J. Rossini wrote: > > (This is under SBCL, i.e. satisfying Duncan's conjectures -- as soon > as I fix a few things (i.e. undoing CommonLispStat/R's threading which > is a bit SBCL specific, I'll try under CLISP, ECL, and CMUCL to > verify/check). > Also, according to http://www.cyrusharmon.org/cl/blog/display/49 SBCL uses SIGSEGV as an internal signalling mechanism, which might conflict with the new segfault catcher. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stack checking, core dumps, and embedding R
I'm pretty sure that we've fixed that problem. (I'm merging 2 different CL/R trees together, one of which is Cyrus's). An alternative fix patched R to undo that, but that's not kosher. best, -tony On 4/12/06, Thomas Lumley <[EMAIL PROTECTED]> wrote: > > On Tue, 11 Apr 2006, A.J. Rossini wrote: > > > > (This is under SBCL, i.e. satisfying Duncan's conjectures -- as soon > > as I fix a few things (i.e. undoing CommonLispStat/R's threading which > > is a bit SBCL specific, I'll try under CLISP, ECL, and CMUCL to > > verify/check). > > > > Also, according to > http://www.cyrusharmon.org/cl/blog/display/49 > SBCL uses SIGSEGV as an internal signalling mechanism, which might > conflict with the new segfault catcher. > >-thomas > > Thomas Lumley Assoc. Professor, Biostatistics > [EMAIL PROTECTED]University of Washington, Seattle > -- best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug#361968: Wrong name in manpage
I've committed a fix for 2.3 affecting only "R --version" (don't want to
play with real R output during feature freeze), and a cleaner solution
for 2.4 which gets the startup message and --version even more in
sync.
Passes all checks for me, and the man page looks OK again. Thanks for
spotting the bug.
Best,
Fritz
> On Wed, 12 Apr 2006 13:53:08 +0200,
> friedrich leisch (fl) wrote:
> On Tue, 11 Apr 2006 20:56:27 -0400,
> Duncan Murdoch (DM) wrote:
>> On 4/11/2006 7:45 PM, Dirk Eddelbuettel wrote:
>>> R-devel'ers,
>>>
>>> On 11 April 2006 at 10:24, Dirk Eddelbuettel wrote:
>>> |
>>> | Kanru,
>>> |
>>> | Thanks for the bugreport.
>>> |
>>> | On 11 April 2006 at 22:03, Kanru Chen wrote:
>>> | | Package: r-base-core
>>> | | Version: 2.2.1.svn37668-1
>>> | | Severity: minor
>>> | |
>>> | | In manpage of /usr/bin/R, the first, fourth and last line shows
`VERSION'
>>> | | instead of `R'.
>>>
>>> I haven't seen any follow-up yet -- here is what it looks like (cut and
>>> pasted from Emacs man page viewer) and note the 'Version' in place of R:
>>>
>>> VERSION(1)FSF
VERSION(1)
>>>
>>> NAME
>>> Version - a language for data analysis and graphics
>>>
>>> SYNOPSIS
>>> R [options] [< infile] [> outfile]
>>> R CMD command [arguments]
>>>
>>> DESCRIPTION
>>> Start R, a system for statistical computation and graphics, with the
>>> specified options, or invoke an R tool via the 'R CMD' interface.
>>> [...]
>>>
>>>
>>> | | I believe it is a typo.
>>> |
>>> | More likely something is wrong with how R.1 is autogenerated using
help2man.
>>> |
>>> | Incidentally, that `R --version' now starts its ouput with 'Version'
rather
>>> | than R had bit us in the RPy builds where the version number was
regexp'ed
>>> | out of the result, and was still expecting the line to start with R
just like
>>> | help2man seems to expect the program name first.
>>>
>>> It seems to stem from src/main/version.c:
>>>
>>> void attribute_hidden PrintVersionString(char *s)
>>> {
>>> if(strcmp(R_SVN_REVISION, "unknown")==0)
>>> {
>>> sprintf(s, "Version %s.%s %s (%s-%s-%s)",
>>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY);
>>> }
>>> else{
>>> if(strlen(R_STATUS)==0){
>>> sprintf(s, "Version %s.%s (%s-%s-%s)",
>>> R_MAJOR, R_MINOR, R_YEAR, R_MONTH, R_DAY);
>>> }
>>> else{
>>> sprintf(s, "Version %s.%s %s (%s-%s-%s r%s)",
>>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY,
>>> R_SVN_REVISION);
>>> }
>>> }
>>> }
>>>
>>> Would replacing 'Version ...' with 'R (Version ...)' be an acceptable
>>> alternative ?
>> I think the problem is that PrintVersion (a few lines up from there)
>> used to put the R in front; PrintVersionString doesn't include the R.
>> PrintVersionString is called from other places where the R would not be
>> appropriate, but PrintVersion is only called when acting on `R
>> --version' or synonyms.
>> Fritz, I think this was your change in r36923 a few months ago. Do you
>> have time to deal with it?
> Yes, will do later today.
> Best,
> Fritz
> __
> 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
