Re: [Rd] Comments in the DESCRIPTION file
Hi, I am not that familiar with the DCF... But R seems to accept # quite easely. More precisely: Before posting my message, I try it on a small package: R CMD check or R CMD INSTALL did not make any warning or error (whereas they do if I use '#' alone). After reading your response, I dig a bit more. The source of my DESCRIPTION file was: --- 8< -- #: ###: This is some kind of 'section 1' ###: Package: packBasic1 Title: Very simple package Version: 0.9.2 License: GPL (>=2.0) Description: A package #: #: #: ###: This is 'section 2' ###: Author: Christophe Genolini Maintainer: Christophe Genolini --- 8< -- The DESCRIPTION file after installation was: --- 8< -- #: ###: Package: packBasic1 Title: Very simple package Version: 0.9.2 License: GPL (>=2.0) Description: A package #: Author: Christophe Genolini Maintainer: Christophe Genolini Built: R 3.0.0; ; 2013-05-02 06:50:57 UTC; windows --- 8< -- So I guess there was a problem. But if I number the comments line, then it works: --- 8< - #1: ###2: This is some kind of 'section 1' ###3: Package: packBasic1 Title: Very simple package Version: 0.9.2 License: GPL (>=2.0) Description: A package #4: #5: #6: ###7: This is 'section 2' ###8: Author: Christophe Genolini Maintainer: Christophe Genolini Built: R 3.0.0; ; 2013-05-02 06:49:27 UTC; windows --- 8< - Christophe -- View this message in context: http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4666017.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
[Rd] Catch SIGINT from user in backend C++ code
Hi, I was wondering if anybody knew how to trap SIGINTs (ie Ctrl-C) in backend C++ code for R extensions? I'm writing a package that uses the GPU for some hefty matrix operations in a tightly coupled parallel algorithm implemented in CUDA. The problem is that once running, the C++ module cannot apparently be interrupted by a SIGINT, leaving the user sat waiting even if they realise they've launched the algorithm with incorrect settings. Occasionally, the SIGINT gets through and the C++ module stops. However, this leaves the CUDA context hanging, meaning that if the algorithm is launched again R dies. If I could trap the SIGINT, then I could make sure a) that the algorithm stops immediately, and b) that the CUDA context is destructed nicely. Is there a "R-standard" method of doing this? Thanks, Chris -- Dr Chris Jewell Lecturer in Biostatistics Institute of Fundamental Sciences Massey University Private Bag 11222 Palmerston North 4442 New Zealand Tel: +64 (0) 6 350 5701 Extn: 3586 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] foreign: write.xport
I see in the archives significant discussion about SAS, CDISC formats etc. for FDA, but no direct suggestion of adding a write.xport method to the foreign package. Are there significant barriers to doing so? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] diag() when input is a numeric scalar
Hi All, I'm wondering why when passing a single numeric value that contains any decimals to diag() that the value is silently coerced to a integer for constructing an identify matrix. To me, an input like diag(5.435) seems fairly ambiguous and is more than likely a programming mistake, since it's not obvious that a 5x5 identity matrix should be created. I've seen some code where other writers have been burned on this as well, especially when trying extract diagonal elements but forget about the scalar case. A warning or message would help track this problem down really quickly to force the author to use diag(floor(5.435)) explicitly, if indeed that is there intention. Thoughts? Phil -- View this message in context: http://r.789695.n4.nabble.com/diag-when-input-is-a-numeric-scalar-tp4665986.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] Catch SIGINT from user in backend C++ code
On Thu, May 2, 2013 at 12:50 AM, Jewell, Chris wrote: > Hi, > > I was wondering if anybody knew how to trap SIGINTs (ie Ctrl-C) in backend > C++ code for R extensions? I'm writing a package that uses the GPU for some > hefty matrix operations in a tightly coupled parallel algorithm implemented > in CUDA. > > The problem is that once running, the C++ module cannot apparently be > interrupted by a SIGINT, leaving the user sat waiting even if they realise > they've launched the algorithm with incorrect settings. Occasionally, the > SIGINT gets through and the C++ module stops. However, this leaves the CUDA > context hanging, meaning that if the algorithm is launched again R dies. If > I could trap the SIGINT, then I could make sure a) that the algorithm stops > immediately, and b) that the CUDA context is destructed nicely. > > Is there a "R-standard" method of doing this? > I think R_CheckUserInterrupt() might be the right way to go but I haven't used it much, so not sure if it gives you recovery ability. Cheers, Michael > Thanks, > > Chris > > > -- > Dr Chris Jewell > Lecturer in Biostatistics > Institute of Fundamental Sciences > Massey University > Private Bag 11222 > Palmerston North 4442 > New Zealand > Tel: +64 (0) 6 350 5701 Extn: 3586 > > __ > 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
Re: [Rd] diag() when input is a numeric scalar
On Thu, May 2, 2013 at 12:35 AM, philchalmers wrote: > Hi All, > > I'm wondering why when passing a single numeric value that contains any > decimals to diag() that the value is silently coerced to a integer for > constructing an identify matrix. To me, an input like diag(5.435) seems > fairly ambiguous and is more than likely a programming mistake, since it's > not obvious that a 5x5 identity matrix should be created. I've seen some > code where other writers have been burned on this as well, especially when > trying extract diagonal elements but forget about the scalar case. A warning > or message would help track this problem down really quickly to force the > author to use diag(floor(5.435)) explicitly, if indeed that is there > intention. Thoughts? > I agree it's probably rather dangerous, but it does seem consistent with much of R: matrix(0, ncol = 3.5) replicate(2.525, rnorm(3)) etc. So would you propose a global change (the oft talked about "strict mode") of R or just here? Either way, does this play nicely with R's goals of having integers and floats behave more or less interchangeably? That said, I'm slightly confused by a bit of your message: are you conflating the rounding to integer issue with the different behavior for scalars issue (same as with sample())? Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
I'll be the "anybody" to argue that
} else {
is an ugly kludge which you will never find in my source code. Yes, it's necessary at the
command line because the parser needs help in guessing when an expression is finished, but
is only needed in that case. Since I can hardly imagine using else at the command line
(that many correct characters in a row exceeds my typing skill) it's not an issue for me.
I most certainly would not inflict this construction on my pupils when teaching a class,
nor that any break of a long line has to be after "+" but not before, nor other crutches
for the parser's sake. Let them know about the special case of course, but don't
sacrifice good coding style the deficiency.
That said, I am completely ambivalent to the result of deparse. Just throwing up an
objection to the "purity" argument: things were beginning to sound a bit too bombastic :-).
Terry T.
On 05/02/2013 05:00 AM, r-devel-requ...@r-project.org wrote:
I want "} else {". Yihue wants "} else {". And I have not heard anybody
say they prefer the other way, unless you interpret Duncan's comment
"that's nonsense" as a blanket defense of the status quo. But I don't think
he meant that. This is a matter of style consistency and avoidance of new
R-user confusion and error.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trace with reference class
I got it, thanks! kohske 2013/5/2 John Chambers : > No intended change. The trace method was not updated when reference class > generators became functions. Should be fixed now in r-devel and 3.0.0 > patched (rev 62699). > > Thanks for the catch. > > John > > > On 4/29/13 11:30 PM, Kohske Takahashi wrote: >> >> Hi >> >> The final line of the example in ?setRefClass induces an error: >> >>> ## debugging all objects from class mEdit in method $undo() >>> mEdit$trace(undo, browser) >> >> Error in envRefInferField(x, what, getClass(class(x)), selfEnv) : >>'undo' is not a valid field or method name for reference class >> "refGeneratorSlot" >> >> $trace tries to embed the trace in the generator object (instead of >> the generated object). >> Has this functionality been removed? >> >> best, >> >> kohske >> >> -- >> Kohske Takahashi >> >> Assistant Professor, >> Research Center for Advanced Science and Technology, >> The University of Tokyo, Japan. >> http://www.fennel.rcast.u-tokyo.ac.jp/profilee_ktakahashi.html >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Kohske Takahashi Assistant Professor, Research Center for Advanced Science and Technology, The University of Tokyo, Japan. http://www.fennel.rcast.u-tokyo.ac.jp/profilee_ktakahashi.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] foreign: write.xport
On May 1, 2013, at 1:12 PM, Tim Bergsma wrote: > I see in the archives significant discussion about SAS, CDISC formats etc. > for FDA, but no direct suggestion of adding a write.xport method to the > foreign package. Are there significant barriers to doing so? Hi, The primary barrier would be that a member of the R Core team would likely need to have the interest and time to do this and then maintain the code in the future, if it were to become a part of the foreign package, since it is part of the Recommended packages that ship with R. The better alternative would be to see if you can use the SASxport package on CRAN: http://cran.r-project.org/web/packages/SASxport/ which looks like it was just recently updated, after Greg, the maintainer, had gone missing for a few years. So perhaps Greg has resurfaced to resolve some of the issues that resulted in the package failing CRAN checks recently. Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows, format.POSIXct and character encodings
>> identical(x, y)
>> # [1] TRUE
>>
>> # But, confusingly, ...
>>
>> charToRaw(x)
>> # [1] e5 8d 88 e5 89 8d 2b 2a e5 8d 88 e5 be 8c
>>
>> charToRaw(y)
>> # [1] 8c df 91 4f 2b 2a 8c df 8c e3
>>
>
> That's not confusing at all:
>
>> Encoding(x)
> [1] "UTF-8"
>> Encoding(y)
> [1] "unknown"
>
> The first string is in UTF-8 the second is in the local locale (here 932).
It's confusing because two "identical" objects have different
behaviour. Thanks for pointing out that it's documented, but it
doesn't make it any less confusing.
>> # And this causes a problem when you attempt to do
>> # stuff with the string
>>
>> gsub("+", "*", x, fixed = T)
>> # Error in gsub("+", "*", x, fixed = T) :
>> # invalid multibyte string at '<8c>'
>> gsub("+", "*", y, fixed = T)
>> # [1] "午前**午後"
>>
>
> This is where the problem lies - and it has nothing to do with format:
>
>> z=enc2utf8("午前+*午後")
>> gsub("+", "*", z, fixed = T)
> Error in gsub("+", "*", z, fixed = T) :
> invalid multibyte string at '<8c>'
So is there a way I can convert x into a utf-8 string in general? i.e.
how can I this regular expression not fail given that the text is
encoded in locale 932?
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] install.packages from own rpository - depencies
I am trying to setup a respository for students with a own package.
Its working fine when the depended packages are already installed with:
install.packages("mypackage",
type="source",repos="http://myrepository.example.com";)
but if the the dependencies are not already installed I get the
following error:
ERROR: dependencies 'igraph', 'chron', 'gdata' are not available for
package 'mypackage'
* removing 'C:/.../mypackage'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Comments in the DESCRIPTION file
On May 2, 2013, at 2:58 AM, cgenolin wrote: > Hi, > > I am not that familiar with the DCF... But R seems to accept # quite easely. The fact that R currently accepts invalid DCF files is not a guarantee that it won't be following the standard more closely in the future. What you are doing is illegal in the DCF standard so don't do it. If you do so, don't be surprised that it will fail tomorrow, you have been warned. Cheers, S > More precisely: > > Before posting my message, I try it on a small package: R CMD check or R CMD > INSTALL did not make any warning or error (whereas they do if I use '#' > alone). > > After reading your response, I dig a bit more. The source of my DESCRIPTION > file was: > > --- 8< -- > #: > ###: This is some kind of 'section 1' > ###: > Package: packBasic1 > Title: Very simple package > Version: 0.9.2 > License: GPL (>=2.0) > Description: A package > #: > #: > #: > ###: This is 'section 2' > ###: > Author: Christophe Genolini > Maintainer: Christophe Genolini > --- 8< -- > > The DESCRIPTION file after installation was: > > --- 8< -- > #: > ###: > Package: packBasic1 > Title: Very simple package > Version: 0.9.2 > License: GPL (>=2.0) > Description: A package > #: > Author: Christophe Genolini > Maintainer: Christophe Genolini > Built: R 3.0.0; ; 2013-05-02 06:50:57 UTC; windows > --- 8< -- > > So I guess there was a problem. > But if I number the comments line, then it works: > > --- 8< - > #1: > ###2: This is some kind of 'section 1' > ###3: > Package: packBasic1 > Title: Very simple package > Version: 0.9.2 > License: GPL (>=2.0) > Description: A package > #4: > #5: > #6: > ###7: This is 'section 2' > ###8: > Author: Christophe Genolini > Maintainer: Christophe Genolini > Built: R 3.0.0; ; 2013-05-02 06:49:27 UTC; windows > --- 8< - > > Christophe > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4666017.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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages from own rpository - depencies
On May 2, 2013, at 9:58 AM, Knut Krueger wrote:
> I am trying to setup a respository for students with a own package.
> Its working fine when the depended packages are already installed with:
> install.packages("mypackage",
> type="source",repos="http://myrepository.example.com";)
>
> but if the the dependencies are not already installed I get the following
> error:
> ERROR: dependencies 'igraph', 'chron', 'gdata' are not available for package
> 'mypackage'
> * removing 'C:/.../mypackage'
>
You should add the repositories for the dependencies as well, e.g.:
install.packages("mypackage",
type="source",repos=c("http://myrepository.example.com";,
"http://cran.r-project.org/";))
or make your repository more complete (e.g. if you want to pin certain versions
to guarantee interoperability).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Comments in the DESCRIPTION file
So it IS curently accepted, but may NOT be in the futur. Thanks for your answer. So I guess that using --- 8< - %1: %%%2: Section 1 %%%3 ... --- 8< - is correct, isn't it? Christophe -- View this message in context: http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4666058.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] Comments in the DESCRIPTION file
On May 2, 2013, at 10:17 AM, cgenolin wrote: > So it IS curently accepted, but may NOT be in the futur. Thanks for your > answer. > > So I guess that using > --- 8< - > %1: > %%%2: Section 1 > %%%3 > ... > --- 8< - > > is correct, isn't it? > Yes, that is legal (assuming a colon after the 3). FWIW this is legal as well: A##: B###: section 1 The two relevant requirements are: "A paragraph must not contain more than one instance of a particular field name." and "Field names must not begin with the comment character, #." see 5.1 Syntax of control files: http://www.debian.org/doc/debian-policy/ch-controlfields.html Cheers, Simon > Christophe > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4666058.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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Data in packages: save or write.table?
Hi all, I am trying to understand Writing R Extension... Section 1.1.5, data: I include two datasets in a package, one using 'save', the other using 'write.table': --- 8< myData1 <- data.frame(x=1:10) write.table(myData1,file="myData1.txt") myData2 <- data.frame(x=2:10) save(myData2,file="myData2.Rdata") --- 8< Then R CMD check aks me to document myData1, but does not ask me to document myData2. In the R session, after 'library(myPack)', the data 'myData2' is automatically present in the session while myData1 require the use of data(myData1). Is that correct, or is there a bug in my code? Christophe -- View this message in context: http://r.789695.n4.nabble.com/Data-in-packages-save-or-write-table-tp4666061.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] Patch proposal for R style consistency (concerning deparse.c)
On 01/05/2013 3:34 PM, Joris Meys wrote:
+1 for "} else {" . It might seem a detail, but I agree wholeheartedly
that this would make teaching R easier.
Just one last comment to finish off my participation in this thread. I
think that in general, "+1" votes mean almost nothing. To have a change
accepted, you need to convince a member of R Core that it's a good idea,
without convincing another one that it's a bad idea.
Personally I listen to arguments for changes, but repetitions of the
same argument are just irritating. I was not convinced by the
copy-and-paste argument. I think that if this is causing you problems
in teaching, you're doing it wrong. I'm not going to be convinced by
repetitions of that same argument.
Duncan Murdoch
Btw, thank you Paul for the link to your coding style document. It was
a nice read.
Cheers
Joris
On Wed, May 1, 2013 at 9:19 PM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
+1 to having runnable code emitted
It does emit runnable code, which is why Herve's complaint was
nonsense. It doesn't emit code of which every substring is runnable.
Duncan Murdoch
patch seems to work nicely, hopefully R-core will agree to
apply it to HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
mailto:pauljoh...@gmail.com>> wrote:
> Whoa.
>
> Don't let my valuable suggestion get lost.
>
> I want "} else {". Yihue wants "} else {". And I have not
heard anybody
> say they prefer the other way, unless you interpret Duncan's
comment
> "that's nonsense" as a blanket defense of the status quo.
But I don't think
> he meant that. This is a matter of style consistency and
avoidance of new
> R-user confusion and error.
>
> After reading the help for "if", I don't see how anybody can
argue against
> this. Good R code has this style:
>
> } else {
>
> and not
>
> }
> else
>
> because the latter fails if it is run line-by-line. While
trying to teach
> people how to write R programs, it would be nice if the
output of
> print.function was consistent with the good way, the way
that is actually
> practiced in the R source code itself. This is a major
source of new
> programmer confusion. Its very tough to explain and teach.
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science Assoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://quant.ku.edu
>
> [[alternative HTML version deleted]]
>
> __
> 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
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
On Thu, May 2, 2013 at 4:49 PM, Duncan Murdoch wrote:
> On 01/05/2013 3:34 PM, Joris Meys wrote:
>
>> +1 for "} else {" . It might seem a detail, but I agree wholeheartedly
>> that this would make teaching R easier.
>>
>
> Just one last comment to finish off my participation in this thread. I
> think that in general, "+1" votes mean almost nothing. To have a change
> accepted, you need to convince a member of R Core that it's a good idea,
> without convincing another one that it's a bad idea.
>
It means indeed nothing else than "I agree with this." Which is about as
informative as "This is nonsense."
There's only one valid argument for that patch, and that one is given.
Until now, I didn't see a valid argument to not apply the patch. As in code
that would break if the patch was applied. But I'm no expert, so I'm gladly
proven wrong.
> Personally I listen to arguments for changes, but repetitions of the same
> argument are just irritating. I was not convinced by the copy-and-paste
> argument. I think that if this is causing you problems in teaching, you're
> doing it wrong. I'm not going to be convinced by repetitions of that same
> argument.
>
It's not causing any problems in teaching, other than me answering to
questions of students with "yeah, that's how it's printed in the console,
but personally I won't do it like that. "
Why would I advise to use "} else { " in the first place? It's a matter of
semantics and opinion, I suppose. For me it makes it easier to find the
if() statement to which the else belongs. Or, in other words, using the "}
else {" construct stresses the fact that 'else' cannot stand on its own, it
always needs a previous if() clause. There's no harm in stressing that
through a minor change in the code formatting. But again, that's personal
opinion. I honestly didn't think such a small thing would cause such an
agile discussion...
Cheers
Joris
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
Writing R in a declarative style a la functional programming makes this whole
thread go away since you don't need if/else blocks.
•
Brian Lee Yung Rowe
On May 2, 2013, at 8:27 AM, Terry Therneau wrote:
> I'll be the "anybody" to argue that
> } else {
> is an ugly kludge which you will never find in my source code. Yes, it's
> necessary at the command line because the parser needs help in guessing when
> an expression is finished, but is only needed in that case. Since I can
> hardly imagine using else at the command line (that many correct characters
> in a row exceeds my typing skill) it's not an issue for me. I most certainly
> would not inflict this construction on my pupils when teaching a class, nor
> that any break of a long line has to be after "+" but not before, nor other
> crutches for the parser's sake. Let them know about the special case of
> course, but don't sacrifice good coding style the deficiency.
>
> That said, I am completely ambivalent to the result of deparse. Just
> throwing up an objection to the "purity" argument: things were beginning to
> sound a bit too bombastic :-).
>
> Terry T.
>
> On 05/02/2013 05:00 AM, r-devel-requ...@r-project.org wrote:
>> I want "} else {". Yihue wants "} else {". And I have not heard anybody
>> say they prefer the other way, unless you interpret Duncan's comment
>> "that's nonsense" as a blanket defense of the status quo. But I don't think
>> he meant that. This is a matter of style consistency and avoidance of new
>> R-user confusion and error.
>
> __
> 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
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
On 05/02/2013 05:26 AM, Terry Therneau wrote:
I'll be the "anybody" to argue that
} else {
is an ugly kludge which you will never find in my source code. Yes,
it's necessary at the command line because the parser needs help in
guessing when an expression is finished, but is only needed in that
case.
No, it's also needed wherever the if statement is at the top-level
(i.e. not nested within { ... }), in a package:
hpages@thinkpad:~$ R CMD INSTALL SomePackage
* installing to library
‘/home/hpages/R/R-3.0.0--disable-byte-compiled-packages/library’
* installing *source* package ‘SomePackage’ ...
** R
Error in parse(outFile) :
/home/hpages/svn/bioconductor/Rpacks/SomePackage/R/assignReads.R:8:1:
unexpected 'else'
7: }
8: else
^
ERROR: unable to collate and parse R files for package ‘SomePackage’
* removing
‘/home/hpages/R/R-3.0.0--disable-byte-compiled-packages/library/SomePackage’
or in a stand-alone script:
> source("somescript.R")
Error in source("somescript.R") : somescript.R:4:1: unexpected 'else'
3: }
4: else
^
It's invalid code. Period.
H.
Since I can hardly imagine using else at the command line (that
many correct characters in a row exceeds my typing skill) it's not an
issue for me. I most certainly would not inflict this construction on my
pupils when teaching a class, nor that any break of a long line has to
be after "+" but not before, nor other crutches for the parser's sake.
Let them know about the special case of course, but don't sacrifice good
coding style the deficiency.
That said, I am completely ambivalent to the result of deparse. Just
throwing up an objection to the "purity" argument: things were beginning
to sound a bit too bombastic :-).
Terry T.
On 05/02/2013 05:00 AM, r-devel-requ...@r-project.org wrote:
I want "} else {". Yihue wants "} else {". And I have not heard
anybody
say they prefer the other way, unless you interpret Duncan's comment
"that's nonsense" as a blanket defense of the status quo. But I don't
think
he meant that. This is a matter of style consistency and avoidance of
new
R-user confusion and error.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] loading of an unwanted namespace
I have a debugging environment for the survival package, perhaps unique to me, but I find
it works very well.
To wit, a separate directory with copies of the source code but none of the package
accuements of DESCRIPTION, NAMESPACE, etc. This separate space does NOT contain a copy of
src/init.c
Within this I use R --vanilla, attach my .RData file, survival.so file, and
away we go.
That is, until my first useage of it today under R 3.0. My runs get into trouble with
messages about
"conflicts with the survival namespace". My problem is that I can't figure out where or
how the name space is being searched out and attached. Any hints on where to look would be
appreciated. This "magical" load is
kind of spooky.
Here is a session that displays it. The "setup.s" file does the dyn.load and attaches some
data sets.
tmt-local3499% R --vanilla
R version 3.0.0 (2013-04-03) -- "Masked Marvel"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: i686-pc-linux-gnu (32-bit)> source('setup.s')
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
> search()
[1] ".GlobalEnv" "file:../.RData" "file:../data/.RData"
[4] "package:splines" "package:stats" "package:graphics"
[7] "package:grDevices" "package:utils" "package:datasets" > coxph(Surv(time, status) ~
age, data=lung)
Call:
coxph(formula = Surv(time, status) ~ age, data = lung)
coef exp(coef) se(coef) z p
age 0.0187 1.02 0.0092 2.03 0.042
Likelihood ratio test=4.24 on 1 df, p=0.0395 n= 228, number of events= 165
>
> # That worked fine, but the next fails
> coxph(Surv(time, status) ~ pspline(age), data=lung)
Error in FUN(X[[2L]], ...) :
(converted from warning) failed to assign RegisteredNativeSymbol for Cagfit5a to Cagfit5a
since Cagfit5a is already defined in the ‘survival’ namespace
>
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
>
[10] "package:methods" "Autoloads" "package:base"
>
> options(warn=2)
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.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading of an unwanted namespace
On 13-05-02 3:05 PM, Terry Therneau wrote:
I have a debugging environment for the survival package, perhaps unique to me,
but I find
it works very well.
To wit, a separate directory with copies of the source code but none of the
package
accuements of DESCRIPTION, NAMESPACE, etc. This separate space does NOT contain
a copy of
src/init.c
Within this I use R --vanilla, attach my .RData file, survival.so file, and
away we go.
That is, until my first useage of it today under R 3.0. My runs get into
trouble with
messages about
"conflicts with the survival namespace". My problem is that I can't figure out
where or
how the name space is being searched out and attached. Any hints on where to
look would be
appreciated. This "magical" load is
kind of spooky.
Here is a session that displays it. The "setup.s" file does the dyn.load and
attaches some
data sets.
I don't know a direct way to find this, but you could add some debugging
code to the .Onload function in survival, e.g. to print what the stack
is like when it's loading. That should be informative.
Duncan Murdoch
tmt-local3499% R --vanilla
R version 3.0.0 (2013-04-03) -- "Masked Marvel"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: i686-pc-linux-gnu (32-bit)> source('setup.s')
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
> search()
[1] ".GlobalEnv" "file:../.RData" "file:../data/.RData"
[4] "package:splines" "package:stats" "package:graphics"
[7] "package:grDevices" "package:utils" "package:datasets" > coxph(Surv(time,
status) ~
age, data=lung)
Call:
coxph(formula = Surv(time, status) ~ age, data = lung)
coef exp(coef) se(coef) z p
age 0.0187 1.02 0.0092 2.03 0.042
Likelihood ratio test=4.24 on 1 df, p=0.0395 n= 228, number of events= 165
>
> # That worked fine, but the next fails
> coxph(Surv(time, status) ~ pspline(age), data=lung)
Error in FUN(X[[2L]], ...) :
(converted from warning) failed to assign RegisteredNativeSymbol for Cagfit5a
to Cagfit5a
since Cagfit5a is already defined in the ‘survival’ namespace
>
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
>
[10] "package:methods" "Autoloads" "package:base"
>
> options(warn=2)
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.
__
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
Re: [Rd] loading of an unwanted namespace
On 05/02/2013 01:35 PM, Duncan Murdoch wrote:
On 13-05-02 3:05 PM, Terry Therneau wrote:
I have a debugging environment for the survival package, perhaps unique to me,
but I find
it works very well.
To wit, a separate directory with copies of the source code but none of the
package
accuements of DESCRIPTION, NAMESPACE, etc. This separate space does NOT
contain a copy of
src/init.c
Within this I use R --vanilla, attach my .RData file, survival.so file, and
away we go.
That is, until my first useage of it today under R 3.0. My runs get into
trouble with
messages about
"conflicts with the survival namespace". My problem is that I can't figure out
where or
how the name space is being searched out and attached. Any hints on where to
look would be
appreciated. This "magical" load is
kind of spooky.
Here is a session that displays it. The "setup.s" file does the dyn.load and
attaches some
data sets.
I don't know a direct way to find this, but you could add some debugging code to
the .Onload function in survival, e.g. to print what the stack is like when it's
loading. That should be informative.
trace(loadNamespace, quote(if (package == "survival") recover()))
will break into ?recover when survival is being loaded.
Martin
Duncan Murdoch
tmt-local3499% R --vanilla
R version 3.0.0 (2013-04-03) -- "Masked Marvel"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: i686-pc-linux-gnu (32-bit)> source('setup.s')
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
> search()
[1] ".GlobalEnv" "file:../.RData" "file:../data/.RData"
[4] "package:splines" "package:stats" "package:graphics"
[7] "package:grDevices" "package:utils" "package:datasets" > coxph(Surv(time,
status) ~
age, data=lung)
Call:
coxph(formula = Surv(time, status) ~ age, data = lung)
coef exp(coef) se(coef) z p
age 0.0187 1.02 0.0092 2.03 0.042
Likelihood ratio test=4.24 on 1 df, p=0.0395 n= 228, number of events= 165
>
> # That worked fine, but the next fails
> coxph(Surv(time, status) ~ pspline(age), data=lung)
Error in FUN(X[[2L]], ...) :
(converted from warning) failed to assign RegisteredNativeSymbol for Cagfit5a
to Cagfit5a
since Cagfit5a is already defined in the ‘survival’ namespace
>
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=C
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
>
[10] "package:methods" "Autoloads" "package:base"
>
> options(warn=2)
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.
__
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
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load inside a package in R >= 3.0
I see that for the x64 architecture a function is used called dyn.open. Is that what puts it in the appropriate namespace? The x86 version uses dyn.load and it doesn't seem to specify a package or namespace. I can't find any documentation for dyn.open - is it defined somewhere I can't find it? What would be a less ugly hack for accomplishing this? Thanks Adrian -Original Message- From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] Sent: Sunday, April 28, 2013 10:27 AM To: Adrian Mejia Cc: r-devel@r-project.org Subject: Re: [Rd] dyn.load inside a package in R >= 3.0 On 24.04.2013 19:55, Adrian Mejia wrote: > Hello, > I am trying to port a package that was built for R 2.15 over to R 3.0. This > package has an Initialize method that uses dyn.load to load a dll that was > built separately, and then uses .C() to make calls on the functions in that > dll. This worked fine in 2.15, however, I see that now for 3.0 .C() will only > search in the namespace of your current package. This seems to make it > impossible to use dyn.load for loading a dll, as I can't find a way to get > the loaded dll to belong to the namespace of the package that is using it. It > tells me that the function I'm trying to call is not resolved from the > current namespace, or if pass the .C function a value for the PACKAGE > optional argument it tells me that the symbol is not available for .C() for > the package. > Is there a way to still use dyn.load to use a dll inside my package? Do I > need to change the structure of my project to still be able to use my dll? If you need an example for such an ugly hack, see how we did it in the BRugs package. Best, Uwe Ligges > Thanks > Adrian > > [[alternative HTML version deleted]] > > __ > 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
Re: [Rd] diag() when input is a numeric scalar
Thanks for the reply Michael, Although I probably would lean a bit more to the 'strict mode', I wouldn't suggest changing the default behavior since it could break existing code and goes against R's current philosophy. However, adding an additional argument to some functions where the floating digits are ambiguous would be helpful, or allowing for an optional warning message would also work to avoid these problems. Perhaps better yet would be to include a global argument to option() to check for this type of default float to int coercion in base functions, simply to see if the users code does follow a kind of 'strict mode', and to print warnings whenever this occurs in areas where integers are needed and floats are being coerced. This way the base functionality would remain the same, but those who wanted to be warned about where the potential as.integer() ambiguity is occurring could know (personally, I would leave it on all the time, but that's a matter of preference). I wouldn't be so bold as to change what R currently does, but I would like the option to make it more strict if requested. Cheers. Phil -- View this message in context: http://r.789695.n4.nabble.com/diag-when-input-is-a-numeric-scalar-tp4665986p4666072.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
[Rd] Minimal build of R ...
Hi, I'm trying to cross-compile R to javascript so that it can run in a web-browser. Take as long as you need to stop laughing. So, as I was saying - I want to try and get a build of R running in the browser. [If you're not familiar with it already, you might enjoy looking at emscripten.org. It's a remarkably capable tool for translating LLVM bitcode to javascript. Check out some of the demos!] I'm trying to start out with the most minimal build of R possible. I can turn off various options in the configure script, but I'm wondering about the bundled R packages (base, stats etc). I'm guessing that the native code portions of these packages are dynamically loaded at runtime, which will probably need patching. To start off, I'd like to not build these packages if possible. So, is there a way to configure which packages in the library get built or is it just a case of editing the makefile? And is there a minimal set of them that would still allow R to run (not be useful - that can come later - just run)? Thanks in advance for any help anyone can provide :-) Jony -- Centre for Cold Matter, The Blackett Laboratory, Imperial College London, London SW7 2BW T: +44 (0)207 5947741 http://www.imperial.ac.uk/people/jony.hudson http://www.imperial.ac.uk/ccm/research/edm http://www.monkeycruncher.org http://j-star.org/ -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Please check link for R-patched.tar.gz
I have been trying to build R-patched from source using the link ftp://ftp.stat.math.ethz.ch/Software/R/R-patched.tar.gz Which the file list says is linked to R-patched_2013-05-01.tar.gz but what I download by both wget and curl (with -R -O --ssl ) is dated 2013-04-23 and builds to an old patch level It could be some hidden cache on my side (I've tried finding and removing) but I think the symbolic link may be wrong on the server. Please let me know if you think I am missing something. Best regards, John Minter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimal build of R ...
Jony, I'm currently writing up the paper for something with a similar result but very different implementation. The RBrowserPlugin package/browser plugin (joint with my advisor Duncan Temple Lang) embeds R within the web browser as an NPAPI plugin. This approach allows full bi-directional communication between R and the javascript engine (including direct function calling and references to native objects in both directions) using a user's existing local R installation (including packages). Devel source at https://github.com/gmbecker/RFirefox, release, (hopefully) officially cross-platform version to coincide with the paper going off for review. I had toyed with the idea of the emscripten approach, but I think putting R in the browser once is enough for me at the moment so I will happily keep an eye on your project instead of attacking that myself :). As for your actual question I can't really say, other than that I suspect you will not be able to dispense with base and methods, but that I would conjecture that stats is "optional". ~G On Thu, May 2, 2013 at 9:12 AM, Jony Hudson wrote: > Hi, > > I'm trying to cross-compile R to javascript so that it can run in a > web-browser. Take as long as you need to stop laughing. So, as I was saying > - I want to try and get a build of R running in the browser. [If you're not > familiar with it already, you might enjoy looking at emscripten.org. It's > a remarkably capable tool for translating LLVM bitcode to javascript. Check > out some of the demos!] > > I'm trying to start out with the most minimal build of R possible. I can > turn off various options in the configure script, but I'm wondering about > the bundled R packages (base, stats etc). I'm guessing that the native code > portions of these packages are dynamically loaded at runtime, which will > probably need patching. To start off, I'd like to not build these packages > if possible. > > So, is there a way to configure which packages in the library get built or > is it just a case of editing the makefile? And is there a minimal set of > them that would still allow R to run (not be useful - that can come later - > just run)? > > Thanks in advance for any help anyone can provide :-) > > > Jony > > -- > Centre for Cold Matter, The Blackett Laboratory, > Imperial College London, London SW7 2BW > T: +44 (0)207 5947741 > http://www.imperial.ac.uk/people/jony.hudson > http://www.imperial.ac.uk/ccm/research/edm > http://www.monkeycruncher.org > http://j-star.org/ > -- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimal build of R ...
On Thu, May 2, 2013 at 5:12 PM, Jony Hudson wrote:
> Hi,
>
> I'm trying to cross-compile R to javascript so that it can run in a
> web-browser. Take as long as you need to stop laughing. So, as I was saying -
> I want to try and get a build of R running in the browser. [If you're not
> familiar with it already, you might enjoy looking at emscripten.org. It's a
> remarkably capable tool for translating LLVM bitcode to javascript. Check out
> some of the demos!]
>
> I'm trying to start out with the most minimal build of R possible. I can turn
> off various options in the configure script, but I'm wondering about the
> bundled R packages (base, stats etc). I'm guessing that the native code
> portions of these packages are dynamically loaded at runtime, which will
> probably need patching. To start off, I'd like to not build these packages if
> possible.
>
> So, is there a way to configure which packages in the library get built or is
> it just a case of editing the makefile? And is there a minimal set of them
> that would still allow R to run (not be useful - that can come later - just
> run)?
You can run just "base:"
for(i in 1:(length(search()) - 2)){detach(2)}
search()
Not sure if you need "compiler" around for the build process, but we
survived without it once, so I'd assume you can get by without it if
you're willing to tweak.
Godspeed,
MW
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimal build of R ...
On May 2, 2013, at 6:18 PM, Gabriel Becker wrote: > Jony, > > I'm currently writing up the paper for something with a similar result but > very different implementation. The RBrowserPlugin package/browser plugin > (joint with my advisor Duncan Temple Lang) embeds R within the web browser > as an NPAPI plugin. > > This approach allows full bi-directional communication between R and the > javascript engine (including direct function calling and references to > native objects in both directions) using a user's existing local R > installation (including packages). > Minor detail: it requires you to have R *and* a special plugin which makes it pretty much non-deployable. It's completely unrelated to what Jony is proposing - which doesn't require any dependencies and is actually pretty cool and would be useful if feasible. FWIW: There are many ways to run R from a browser that already exist - without the need for plugins or other client-side hacks - that's the beauty of modern browsers :). To get this back on the actual topic: I have been toying with cross-compiling R when I was porting it on the iPhone and it's possible, however, you can't use the build process as-is. It does build core R properly, but the problem is that you need to bootstrap R to build any packages. I worked around the problem at the time by building packages on another platform and re-using those files (things like lazy-loaded DBs, compiled RD files etc.). I can imagine that you'll need some equivalent to dynamic linking, but conceptually it's nothing else but calling functions, so I think you should be able to compile each package separately and just replace the dynload code by code that loads another JavaScript. The nice thing is that packages will simply be just another JS libraries. That's all in theory, I didn't actually try that part. I suspect you'll have a lot of work, e.g. you'll need to map all the I/O operations that load compiled/stored R code, documentation, data from somewhere etc. Good luck! If all fails, you can always compile R for JS/Linux ;). Cheers, Simon > Devel source at https://github.com/gmbecker/RFirefox, release, (hopefully) > officially cross-platform version to coincide with the paper going off for > review. > > I had toyed with the idea of the emscripten approach, but I think putting R > in the browser once is enough for me at the moment so I will happily keep > an eye on your project instead of attacking that myself :). > > As for your actual question I can't really say, other than that I suspect > you will not be able to dispense with base and methods, but that I would > conjecture that stats is "optional". > > ~G > > > On Thu, May 2, 2013 at 9:12 AM, Jony Hudson wrote: > >> Hi, >> >> I'm trying to cross-compile R to javascript so that it can run in a >> web-browser. Take as long as you need to stop laughing. So, as I was saying >> - I want to try and get a build of R running in the browser. [If you're not >> familiar with it already, you might enjoy looking at emscripten.org. It's >> a remarkably capable tool for translating LLVM bitcode to javascript. Check >> out some of the demos!] >> >> I'm trying to start out with the most minimal build of R possible. I can >> turn off various options in the configure script, but I'm wondering about >> the bundled R packages (base, stats etc). I'm guessing that the native code >> portions of these packages are dynamically loaded at runtime, which will >> probably need patching. To start off, I'd like to not build these packages >> if possible. >> >> So, is there a way to configure which packages in the library get built or >> is it just a case of editing the makefile? And is there a minimal set of >> them that would still allow R to run (not be useful - that can come later - >> just run)? >> >> Thanks in advance for any help anyone can provide :-) >> >> >> Jony >> >> -- >> Centre for Cold Matter, The Blackett Laboratory, >> Imperial College London, London SW7 2BW >> T: +44 (0)207 5947741 >> http://www.imperial.ac.uk/people/jony.hudson >> http://www.imperial.ac.uk/ccm/research/edm >> http://www.monkeycruncher.org >> http://j-star.org/ >> -- >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- > Gabriel Becker > Graduate Student > Statistics Department > University of California, Davis > > [[alternative HTML version deleted]] > > __ > 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
