Re: [Rd] Suggestions for R-devel / R-help digest format
Don't most people use a newsreader? For example, pointed to here : gmane.comp.lang.r.general gmane.comp.lang.r.devel IIUC, NNTP downloads headers only, when you open any post it downloads the body at that point. So it's more efficient than email (assuming you don't open every single post). I guess RSS is similar/better. Newsreaders handle threading and you can watch/ignore threads easily. Actually subscribing via email? The only reason I am subscribed is to post unmoderated (and to encourage Martin with +1 on his subscriber count); I have email delivery turned off in the mailman settings. Thought everyone did that! If I counted correctly, there are 36 gmane mirrors for various packages and sigs. You can watch all these (including r-devel and r-help) via gmane without needing to subscribe on mailman at all. Matthew "Saravanan" wrote in message news:4e160850.1040...@gmail.com... > Thanks Steve and Brian ! > > Probably, I will create a gmail account for mailing lists and let it take > care of the threading. > > Regards, > Saravanan > > On 07/07/2011 12:02 PM, Brian G. Peterson wrote: >> On Thu, 2011-07-07 at 11:44 -0500, Saravanan wrote: >>> Hello, >>> >>> I am passive reader of both R-devel and R-help mailing lists. I am >>> sending the following comments to r-devel as it seemed more suitable. I >>> am aware that this list uses GNU mailman for the list management. I have >>> my options set that it sends a email digest. One thing I find is that >>> the digest consists of emails that ordered temporarlly. For eg lets say >>> there are two threads t1 and t2 and the emails arrive as e1 of t1, e2 of >>> t2, e3 of t3 . The digest lists them as e1,e2 and then e3. Is it >>> possible to somehow configure it as T1 : e1,e3 and then T2 : e2 ? >>> >>> This is the digest format that google groups uses which is incredibly >>> helpful as you can read all the messages in a thread. Additionally, it >>> also helpfully includes a header that lists all the threads in digest so >>> that you can jump to the one you are interested in. I checked the >>> mailman options but could not find any. >>> >>> Does anyone else have the same issue? It is not a big issue in R-devel >>> but R-help is a much more high traffic mailing list. I am interested in >>> hearing how you read/filter your digest mails in either R-help or other >>> high volume mailing lists. >> This really has nothing to do with R, but rather mailman. >> >> I use folders, filtered on the server using SIEVE and/or procmail. No >> digest required. I get the mails immediately, not later in the day or >> the next day, and can use all my various email clients easily to >> read/respond. >> >> mailman supports a MIME digest format that includes a table of contents >> with links to each MIME part. mailman does not support a threaded >> digest, to the best of my knowledge. >> >> Regards, >> >> - Brian >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Vignette pdfs missing from zip file after Rcmd build --binary call
Thanks for the reply. In a round about way, it helped me figure out how to solve the problem. I had always called Rcmd build --binary first to make a zip file for windows users and in <2.11.0 this command added all the vignette pdfs to the source directory, and then I called Rcmd build --no-vignettes to prepare the tar.gz file. This made me realize that someone on a unix machine would not build the tar.gz file this way, and I should follow a more unix-like build sequence. For the sake of documenting my solution, here's my responses and how they led to my solution. Note, I'm buildiing packages on a windows machine. > It sort of defeats the purpose to create a tar ball and then not use it ;) ?? I do use it. The unix and mac users download the tar.gz file to install the package. I create windows binaries for windows users. In the past, I created the zip file from the source directory not the tar.gz built from the source directory using the command Rcmd build --binary FOO, where FOO is the source directory. BTW, I know the tar.gz file build on a windows machine is not perfect for mac/unix users; this is just for development in a small group with mac and windows users. I've been building packages for years with 2.11.0 and below, but something has changed in 2.13.0 in how vignette pdfs are being transferred to the package zip files. >> Things I have tried unsuccessful >> I tried using the tar.gz file as the source > > That is indeed the usual way. > > Can you be more specific as of what errors you get? It may point to issues > in the your package. Also the command is R CMD INSTALL not install. Sorry I meant to capitalize 'install'. I do call it that way. The error I got was Warning: invalid package 'FOO.tar.gz' Error: ERROR: no package specified I assumed the error had to do with a tar.gz file not being a valid 'target' for Rcmd build. I have never seen a tar.gz file used in a Rcmd build call before. But your comment suggested that FOO.tar.gz should work, and on closer inspection, I realized I had misspelled the filename. Once I fixed that, R CMD install --build FOO.tar.gz worked and built the zip file. >> Rcmd build --binary FOO.tar.gz (got error) cannot change to directory 'FOO.tar.gz' (ok, I just won't use that) >> R CMD INSTALL --build FOO.tar.gz (built the package binaries in the zip >> file, so I'll switch to this) Once I got here, I realized I could just build the zip file using 'R CMD INSTALL --build FOO.tar.gz' as appeared to be intended. But on closer inspection, my tar.gz file also appeared to be missing some of the vignette pdfs in a package that included a makefile in inst/doc. It turned out that this file did not have the line 'texi2dvi --pdf *.tex' to create pdfs from all the tex files after Rcmd's sweave call before it called the makefile. In R 2.11.0, these pdfs were being added to the source directory by the call 'Rcmd build --binary' . I never ran 'Rcmd build' first so never noticed that the tar.gz file from 'Rcmd build' would be missing vignette pdfs. I added the line texi2dvi --pdf *.tex' to the makefile and everything seems ok now. So my new steps for building unix and windows packages is the following: Rcmd build FOO (build the tar.gz file) R CMD INSTALL --build FOO.tar.gz (build the windows binaries; I'm doing this on a windows machine btw). Again, thanks! --Eli __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invalid body argument for function
On Thu, Jun 30, 2011 at 9:35 AM, Duncan Murdoch wrote:
> On 29/06/2011 9:09 PM, Michael Lawrence wrote:
>
>> Hi guys,
>>
>> Looks like mkCLOSXP cannot handle external pointers as the function body.
>> Work around is obvious, but I guess it's a bug nonetheless.
>>
>
> I don't know if it's a bug. The mkCLOSXP code has a list of types that it
> accepts; external pointers and environments aren't in that list, so you get
> the same error you saw with
>
> fun<- eval(substitute(function() x, list(x = environment(
>
> There's a comment
>
> /* This is called by function() {}, where an invalid
> body should be impossible. When called from
> other places (eg do_asfunction) they
> should do this checking in advance */
>
>
> I don't know whether there's any reason for the restriction, but I'd want
> to look closely at what gets done with the body to make sure that putting an
> environment or external pointer or other weird type there doesn't cause
> other problems.
>
>
Ok, well if this is user error, then the error message should not ask the
user to report it as a bug. The comment cited above is incorrect, since it
is indeed possible to give function() an incorrect body.
Thanks,
Michael
> Duncan Murdoch
>
> > library(RGtk2)
>> > fun<- eval(substitute(function() x, list(x = gtkWindow(
>> Error in eval(expr, envir, enclos) : invalid body argument for "function"
>> Should NEVER happen; please bug.report() [mkCLOSXP]
>>
>> > sessionInfo()
>> R version 2.14.0 Under development (unstable) (--)
>> Platform: i686-pc-linux-gnu (32-bit)
>>
>> locale:
>> [1] C
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> other attached packages:
>> [1] RGtk2_2.20.13 qtbase_0.8-16 visnab_0.0.1
>>
>> loaded via a namespace (and not attached):
>> [1] BSgenome_1.21.3 Biobase_2.11.10 Biostrings_2.21.6
>> [4] DBI_0.2-5 GenomicFeatures_1.5.5 GenomicRanges_1.3.39
>> [7] IRanges_1.11.11 MutableRanges_0.2.0 RColorBrewer_1.0-2
>> [10] RCurl_1.5-0 RSQLite_0.9-4 Rsamtools_1.5.13
>> [13] XML_3.2-0 biomaRt_2.7.2 colorspace_1.0-1
>> [16] dichromat_1.2-3 munsell_0.2 objectSignals_0.5.1
>> [19] plumbr_0.6.2 plyr_1.4.1qtpaint_0.7.22
>> [22] rtracklayer_1.13.3scales_0.1.0 stringr_0.4
>>
>>[[alternative HTML version deleted]]
>>
>> __**
>> 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
Re: [Rd] invalid body argument for function
On Jul 9, 2011, at 00:17 , Michael Lawrence wrote:
> On Thu, Jun 30, 2011 at 9:35 AM, Duncan Murdoch
> wrote:
>
>> On 29/06/2011 9:09 PM, Michael Lawrence wrote:
>>
>>> Hi guys,
>>>
>>> Looks like mkCLOSXP cannot handle external pointers as the function body.
>>> Work around is obvious, but I guess it's a bug nonetheless.
>>>
>>
>> I don't know if it's a bug. The mkCLOSXP code has a list of types that it
>> accepts; external pointers and environments aren't in that list, so you get
>> the same error you saw with
>>
>> fun<- eval(substitute(function() x, list(x = environment(
>>
>> There's a comment
>>
>> /* This is called by function() {}, where an invalid
>> body should be impossible. When called from
>> other places (eg do_asfunction) they
>> should do this checking in advance */
>>
>>
>> I don't know whether there's any reason for the restriction, but I'd want
>> to look closely at what gets done with the body to make sure that putting an
>> environment or external pointer or other weird type there doesn't cause
>> other problems.
>>
>>
> Ok, well if this is user error, then the error message should not ask the
> user to report it as a bug. The comment cited above is incorrect, since it
> is indeed possible to give function() an incorrect body.
Yes. Of course, the message predates certain object types, so things may have
gotten out of sync.
I don't actually see why is would be a problem to allow any (user-visible)
object as the body of a function. All that happens is that the return value of
the function would be that object, no?
There was at some point a push towards regularizing the language, and these
checks may be a relic of that.
(The current code is "svn blame"d to me, but it was a branch update in
Dec.1999, and I can't really be bothered to go find out on which branch it
happened on and who did it. Besides, the wench is dead...)
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] short documentation suggestion for "by" --- reference simplify2array and ave
in the documentation for "by", please change the "See also" section to
\seealso{\code{\link{tapply}}, \code{\link{simplify2array}},
\code{\link{ave}}}
(simplify2array, by, and ave should probably also be mentioned in the "See
also" section of "apply".)
hope this helps.
/iaw
Ivo Welch (ivo.we...@gmail.com)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
