Re: [Rd] Why do methods of "initialize" have no "srcref" attribute as other S4 mehtods?
Thank You very much. This is a great help.
I would never ever have thought of either unRematchDefinition or getSrcref.
I will incorporate this new insight and report about any further
discoveries (or problems leading to them ;-))
Thanks again
Markus
2014/1/8 Duncan Murdoch
> On 14-01-07 2:40 PM, Markus Müller wrote:
>
>> For documentation we use a system that generates Rd files from special
>> comments in the code. (inlinedocs).
>> It is crucial to be able to get the defining source code for objects like
>> methods to extract the comments from it.
>>
>> Here is an R session that shows how this works for several kinds of
>> methods
>> and (at the end of the session) how if fails for methods of "initialize"
>>
>> require("methods")
>>> setGeneric( "myGen",function(arg){standardGeneric("myGen")})
>>>
>> [1] "myGen"
>>
>>> setMethod(
>>>
>> + f="myGen",
>> + signature="numeric",
>> + definition=function # a function with comments in its source
>> + ### that are used to document it with inlinedocs
>> + (arg ##<< another special comment for the argument
>> + ){
>> + 2*arg
>> + ### a description for the return value
>> + }
>> + )
>> [1] "myGen"
>>
>> we can get the whole function definition with comments back
>> by the following snippet:
>>
>>> attr(getMethod("myGen","numeric"),"srcref")
>>>
>> function # a function with comments in its source
>> ### that are used to document it with inlinedocs
>> (arg ##<< another special comment for the argument
>> ){
>>2*arg
>>### a description for the return value
>> }
>>
>>>
>>>
>> this also works for operators
>>
>> setMethod("$",
>>>
>> + signature(x = "MyClass"),
>> + function
>> + (x, ##<< first arg
>> + name ##<< second ag
>> + ) { }
>> + )
>> [1] "$"
>>
>>> attr(getMethod("$","MyClass"),"srcref")
>>>
>> function
>> (x, ##<< first arg
>> name ##<< second ag
>> ) { }
>>
>>>
>>> setClass(
>>>
>> +Class="MyClass",
>> +representation(
>> +val="numeric"
>> +)
>> + )
>>
>> It works also for other functions already defined:
>>
>> setGeneric("plot")
>>>
>> [1] "plot"
>>
>>> setMethod("plot",
>>>
>> + signature(x = "MyClass"),
>> + function # a comment
>> + (x, y, ...)
>> + {
>> + stop("need a definition for the method here")
>> + }
>> + )
>> [1] "plot"
>>
>>> attr(getMethod("plot","MyClass"),"srcref")
>>>
>> function # a comment
>> (x, y, ...)
>> {
>> stop("need a definition for the method here")
>> }
>>
>>>
>>>
>> However if we overload initialize there is no "srcref" attribute:
>>
>> setMethod(
>>>
>> + f="initialize",
>> + signature="MyClass",
>> + definition=function # here are also comments but we can not retrieve
>> them
>> + (.Object,value){
>> + .Object@val<- value
>> + return(.Object)
>> + }
>> + )
>> [1] "initialize"
>>
>>>
>>> attr(getMethod("initialize","MyClass"),"srcref")
>>>
>> NULL
>>
>> Is there a reason for this behavior, and more important still,
>> Ist there a way to get at the source of my constructors to document them
>> automatically?
>>
>
> I don't know the why of the design, but the comments are there, just not
> where you were looking. You can get them as follows:
>
> f <- getMethod("initialize", "MyClass")
> getSrcref(unRematchDefinition(f))
>
> This should work for the other cases too, where unRematchDefinition does
> nothing. I don't know if there are any cases where it will fail, but if
> there are, please let me know.
>
> Probably the getSrcref function should do this automatically when it sees
> that f is a method definition, but I'll wait to hear if it's the wrong
> approach.
>
> Duncan Murdoch
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN rejects package because of write statement in Fortran
I recently developed an R package to make available a very large legacy program written in Fortran. My package has been rejected by CRAN due to this Write statement with the message "As 'Writing R Extensions' warns you against including Fortran I/O, this will not be allowed." The issue is that this Write statement does not involve I/O it is inernally writing an integer to a character which is then placed in an appropriate message (character string) passed to the error handling function recommened in writing R extensions rexit(message). I'm working with a very large legacy program which was developed over 16 years and I am reluctant to rewrite the entire error handling sections in R. I was wondering if anyone has gotten CRAN to accept a package with a Fortran write statement converting numbers to characters or if anyone has found another method for doing type conversion in Fortran without the "write" statement. Thanks for your help Marian -- View this message in context: http://r.789695.n4.nabble.com/CRAN-rejects-package-because-of-write-statement-in-Fortran-tp4683287.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why do methods of "initialize" have no "srcref" attribute as other S4 mehtods?
On 14-01-08 6:51 AM, Markus Müller wrote:
Thank You very much. This is a great help.
I would never ever have thought of either unRematchDefinition or getSrcref.
I will incorporate this new insight and report about any further
discoveries (or problems leading to them ;-))
After thinking about this a while, I decided that it's really a bug that
getSrcref didn't do this automatically. So now it does (in R-patched
and R-devel).
Duncan Murdoch
Thanks again
Markus
2014/1/8 Duncan Murdoch mailto:murdoch.dun...@gmail.com>>
On 14-01-07 2:40 PM, Markus Müller wrote:
For documentation we use a system that generates Rd files from
special
comments in the code. (inlinedocs).
It is crucial to be able to get the defining source code for
objects like
methods to extract the comments from it.
Here is an R session that shows how this works for several kinds
of methods
and (at the end of the session) how if fails for methods of
"initialize"
require("methods")
setGeneric( "myGen",function(arg){__standardGeneric("myGen")})
[1] "myGen"
setMethod(
+ f="myGen",
+ signature="numeric",
+ definition=function # a function with comments in its source
+ ### that are used to document it with inlinedocs
+ (arg ##<< another special comment for the argument
+ ){
+ 2*arg
+ ### a description for the return value
+ }
+ )
[1] "myGen"
we can get the whole function definition with comments back
by the following snippet:
attr(getMethod("myGen","__numeric"),"srcref")
function # a function with comments in its source
### that are used to document it with inlinedocs
(arg ##<< another special comment for the argument
){
2*arg
### a description for the return value
}
this also works for operators
setMethod("$",
+ signature(x = "MyClass"),
+ function
+ (x, ##<< first arg
+ name ##<< second ag
+ ) { }
+ )
[1] "$"
attr(getMethod("$","MyClass"),__"srcref")
function
(x, ##<< first arg
name ##<< second ag
) { }
setClass(
+Class="MyClass",
+representation(
+val="numeric"
+)
+ )
It works also for other functions already defined:
setGeneric("plot")
[1] "plot"
setMethod("plot",
+ signature(x = "MyClass"),
+ function # a comment
+ (x, y, ...)
+ {
+ stop("need a definition for the method here")
+ }
+ )
[1] "plot"
attr(getMethod("plot","__MyClass"),"srcref")
function # a comment
(x, y, ...)
{
stop("need a definition for the method here")
}
However if we overload initialize there is no "srcref" attribute:
setMethod(
+ f="initialize",
+ signature="MyClass",
+ definition=function # here are also comments but we can
not retrieve
them
+ (.Object,value){
+ .Object@val<- value
+ return(.Object)
+ }
+ )
[1] "initialize"
attr(getMethod("initialize","__MyClass"),"srcref")
NULL
Is there a reason for this behavior, and more important still,
Ist there a way to get at the source of my constructors to
document them
automatically?
I don't know the why of the design, but the comments are there, just
not where you were looking. You can get them as follows:
f <- getMethod("initialize", "MyClass")
getSrcref(unRematchDefinition(__f))
This should work for the other cases too, where unRematchDefinition
does nothing. I don't know if there are any cases where it will
fail, but if there are, please let me know.
Probably the getSrcref function should do this automatically when it
sees that f is a method definition, but I'll wait to hear if it's
the wrong approach.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R on Windows: mkdir of Rtools creates directories with read-only permissions [WEIRD]
This is is an issue that bugged me for a while. I encountered a year ago (April 2012) when I first tried to build R from source on Windows. I never figured out what the solution is or if I'm doing something wrong myself (but I have found a tedious workaround). I'm still on the same Windows 7 Ultimate machine with NTFS, but I now made sure I started from scratch so I have a completely fresh setup (see details at the end). PROBLEM: At the very first step I do: C:\R\src\gnuwin32>make all [... Waiting. No errors until ...] cp R.dll ../../bin/i386 Building ../../../bin/i386/Rblas.dll gcc -std=gnu99 -shared -o ../../../bin/i386/Rblas.dll blas.o cmplxblas.o ../../gnuwin32/dllversion.o Rblas.def -L../../../bin/i386 -lR -lgfortran c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lR collect2: ld returned 1 exit status make[2]: *** [../../../bin/i386/Rblas.dll] Error 1 make[1]: *** [Rblas] Error 2 make: *** [rbuild] Error 2 However: C:\R\src\gnuwin32>dir ..\..\bin\i386\ Volume in drive C is Windows7_OS Volume Serial Number is E038-51CC Directory of C:\R\bin\i386 01/08/2014 06:18 PM . 01/08/2014 06:18 PM .. 01/08/2014 06:18 PM 3,059,712 R.dll 01/08/2014 06:18 PM 348,995 Rgraphapp.dll 01/08/2014 06:18 PM 102,975 Riconv.dll 01/08/2014 06:18 PM 154,917 Rzlib.dll 4 File(s) 3,666,599 bytes 2 Dir(s) 22,424,739,840 bytes free What's weird is that these files have **read permission disabled**: C:\R\src\gnuwin32>file ..\..\bin\i386\*.dll ..\..\bin\i386\R.dll: writable, executable, regular file, no read permission ..\..\bin\i386\Rgraphapp.dll: writable, executable, regular file, no read permission ..\..\bin\i386\Riconv.dll:writable, executable, regular file, no read permission ..\..\bin\i386\Rzlib.dll: writable, executable, regular file, no read permission What is going on? Have anyone else seen this? I've also tried running as Administrator - no difference. TROUBLESHOOTING / WORKAROUND: It appears that 'mkdir' (of Rtools) causes this problem, because if I manually pre-create 'C:\R\src\gnuwin32\bin\i386' using Windows' mkdir it works, e.g. C:\R\src\gnuwin32>rm -fR ..\..\bin\ C:\R\src\gnuwin32>cmd /C mkdir ..\..\bin\i386 C:\R\src\gnuwin32>make rbuild [...] Building ../../../bin/i386/Rblas.dll gcc -std=gnu99 -shared -o ../../../bin/i386/Rblas.dll blas.o cmplxblas.o ../../gnuwin32/dllversion.o Rblas.def -L../../../bin/i386 -lR -lgfortran make --no-print-directory -C front-ends mkdir -p ../../../bin/i386 cp Rgui.exe ../../../bin/i386/Rgui.exe mkdir -p ../../../bin/i386 cp Rterm.exe ../../../bin/i386/Rterm.exe mkdir -p ../../../bin/i386 cp Rcmd.exe ../../../bin/i386/Rcmd.exe mkdir -p ../../../bin/i386 cp RSetReg.exe ../../../bin/i386/RSetReg.exe mkdir -p ../../../bin/i386 cp R.exe ../../../bin/i386/R.exe mkdir -p ../../../bin/i386 cp Rscript.exe ../../../bin/i386/Rscript.exe mkdir -p ../../../bin/i386 cp open.exe ../../../bin/i386/open.exe mkdir -p ../../../bin cp Rfe.exe ../../../bin/R.exe mkdir -p ../../../bin cp Rfe.exe ../../../bin/Rscript.exe make[1]: `COPYRIGHTS' is up to date. make --no-print-directory -C ../modules -f Makefile.win \ CFLAGS='-O3 -Wall -pedantic -mtune=core2' FFLAGS='-O3 -mtune=core2' gcc -std=gnu99 -shared -s -o ../../../bin/i386/Rlapack.dll dlamch.o dlapack.o cmplx.o init_win.o Rlapackrc.o -L../../../bin/i386 -lR -lRblas -lgfortran cp lapack.dll ../../../modules/i386/lapack.dll and there is (obviously) read permissions on those files: C:\R\src\gnuwin32>file ..\..\bin\i386\*.dll ..\..\bin\i386\R.dll: PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit ..\..\bin\i386\Rblas.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit ..\..\bin\i386\Rgraphapp.dll: PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit ..\..\bin\i386\Riconv.dll:PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit ..\..\bin\i386\Rlapack.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit ..\..\bin\i386\Rzlib.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Pre-creating the proper directories is tedious and only works up to the point of 'make distribution', where I haven't found a similar workaround (without modifying the Makefiles). Note, I can get to the point where I have build and check everything (including recommended packages). Just to convince you that mkdir is the problem, I can reproduce the problem from this point, by removing the bin/ directory again and relying on Rtools mkdir again; C:\R\src\gnuwin32>rm -fR ..\..\bin C:\R\src\gnuwin32>make rbuild make[3]: Nothing to be done for `svnonly'. installing C headers make[1]: `libRblas.dll.a' is up to date. make[4]: Nothing to be done for `svnonly'. installing C headers make --no-print-directory -C ../extra/intl CFLAGS='-O3
