[Rd] Typos in TclInterface.Rd (PR#9436)
Some typos in TclInferface.Rd
line 192: SIDE
\code{tclvalue} function, which can also occur on the left SIE of
line 199: INITIALIZES
\code{tclArray} creates a new Tcl array and INITALIZES it to the empty
line 221: DISTINCTION
argument; there are cases where the DISTICTION matters to Tcl,
Stephen
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 4.1
year = 2006
month = 12
day = 18
svn rev = 40228
language = R
version.string = R version 2.4.1 (2006-12-18)
Locale:
C
Search Path:
.GlobalEnv, package:tcltk, package:stats, package:utils, package:datasets,
package:graphics, package:grDevices, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typos in TclInterface.Rd (PR#9436)
If you are going to impose the cost on the developers of a bug report on
typos, please at least do as we _do_ ask and check the current version, in
your case at
https://svn.r-project.org/R/trunk/src/library/tcltk/man/TclInterface.Rd
You will I believe want to update your bug report.
On Tue, 2 Jan 2007, [EMAIL PROTECTED] wrote:
> Some typos in TclInferface.Rd
>
> line 192: SIDE
> \code{tclvalue} function, which can also occur on the left SIE of
>
> line 199: INITIALIZES
> \code{tclArray} creates a new Tcl array and INITALIZES it to the empty
>
> line 221: DISTINCTION
> argument; there are cases where the DISTICTION matters to Tcl,
>
> Stephen
> --please do not edit the information below--
>
> Version:
> platform = i686-pc-linux-gnu
> arch = i686
> os = linux-gnu
> system = i686, linux-gnu
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Locale:
> C
>
> Search Path:
> .GlobalEnv, package:tcltk, package:stats, package:utils, package:datasets,
> package:graphics, package:grDevices, package:methods, Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to execute R scripts simultaneously from multiple threads
Hi All, My problem is about parallel execution of R-scripts. My platform is linux. A program that is written in C needs to execute multiple R-scripts simultaneously. The C program makes use of multi-threading. Each thread must initiate the execution of one script. Performance is very important. Appearantly the R C-API does not provide a mechanism for parallel execution.. It is preferred that the solution is not based on multi-processing (like C/S), because that would introduce IPC overhead. Hopefully some thread-safe (single-proces) solution is readily available, written in C. What is the best solution to do this? (If there is no single-process solution, what is the alternative?) Regards, Erik. -- Shannon's Observation: Nothing is so frustrating as a bad situation that is beginning to improve. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] troubles installing SJava for R
Hello all, I am using R 2.4.0 and SJava 0.69-0 on linux. I am not able to install SJava on R. The following errors appear when installing: ... ** R ** inst WARNING: use of install..R is no longer supported ** preparing package for lazy loading Creating a new generic function for "merge" in "SJava" ** help >>> Building/Updating help pages for package 'SJava' Formats: text html latex example ... This error appears when I try to load SJava: ... Type 'q()' to quit R. > library(SJava) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library '/usr/local/lib/R/library/SJava/libs/SJava.so': /usr/local/lib/R/library/SJava/libs/SJava.so: undefined symbol: R_PPStackTop Error in library(SJava) : .First.lib failed for 'SJava' > q() ... Can anyone please help? Regards, Erik -- We are not a clone. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] troubles installing SJava for R
It seems the version of SJava you used needs updating. (install.R was deprecated long ago, formally so in 2.3.0, and R_PPStackTop was never part of the API.) Please do as the R posting guide asked you to, and contact the maintainer. (It also asked you not to report on obselete versions of R.) SJava is part of the Omegahat project, and that has its own mailing list: R-devel is not appropriate. On Wed, 3 Jan 2007, Erik van Zijst wrote: > Hello all, > > I am using R 2.4.0 and SJava 0.69-0 on linux. 'linux' is too vague here. My guess is that you are using R compiled as a shared library using a compiler that support visibility attributes. > I am not able to install SJava on R. The following errors appear when > installing: > > ... > ** R > ** inst > WARNING: use of install..R is no longer supported > ** preparing package for lazy loading > Creating a new generic function for "merge" in "SJava" > ** help > >>> Building/Updating help pages for package 'SJava' > Formats: text html latex example > ... > > This error appears when I try to load SJava: > > ... > Type 'q()' to quit R. > > > library(SJava) > Error in dyn.load(x, as.logical(local), as.logical(now)) : > unable to load shared library > '/usr/local/lib/R/library/SJava/libs/SJava.so': > /usr/local/lib/R/library/SJava/libs/SJava.so: undefined symbol: R_PPStackTop > Error in library(SJava) : .First.lib failed for 'SJava' > > q() > ... > > Can anyone please help? > > Regards, > Erik > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typos in TclInterface.Rd (PR#9436)
> If you are going to impose the cost on the developers of a bug report on
> typos, please at least do as we _do_ ask and check the current version, in
> your case at
>
> https://svn.r-project.org/R/trunk/src/library/tcltk/man/TclInterface.Rd
>
> You will I believe want to update your bug report.
Thanks, this one still remains (other two already fixed).
> > line 192: SIDE
> > \code{tclvalue} function, which can also occur on the left SIE of
Stephen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
Short Answer: There isn't one. On 1/3/07, Erik van Zijst <[EMAIL PROTECTED]> wrote: > Hi All, > > My problem is about parallel execution of R-scripts. My platform is linux. > > A program that is written in C needs to execute multiple R-scripts > simultaneously. The C program makes use of multi-threading. Each thread > must initiate the execution of one script. Performance is very important. > > Appearantly the R C-API does not provide a mechanism for parallel > execution.. > > It is preferred that the solution is not based on multi-processing (like > C/S), because that would introduce IPC overhead. > > Hopefully some thread-safe (single-proces) solution is readily > available, written in C. > > What is the best solution to do this? > > (If there is no single-process solution, what is the alternative?) > > Regards, > Erik. > -- > Shannon's Observation: > Nothing is so frustrating as a bad situation that is beginning to > improve. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
Byron Ellis wrote: > Short Answer: There isn't one. I was afraid so. Thanks for confirming. > On 1/3/07, Erik van Zijst <[EMAIL PROTECTED]> wrote: > >> Hi All, >> >> My problem is about parallel execution of R-scripts. My platform is >> linux. >> >> A program that is written in C needs to execute multiple R-scripts >> simultaneously. The C program makes use of multi-threading. Each thread >> must initiate the execution of one script. Performance is very important. >> >> Appearantly the R C-API does not provide a mechanism for parallel >> execution.. >> >> It is preferred that the solution is not based on multi-processing (like >> C/S), because that would introduce IPC overhead. >> >> Hopefully some thread-safe (single-proces) solution is readily >> available, written in C. >> >> What is the best solution to do this? >> >> (If there is no single-process solution, what is the alternative?) >> >> Regards, >> Erik. >> -- >> Shannon's Observation: >> Nothing is so frustrating as a bad situation that is beginning to >> improve. >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- Computers will not be perfected until they can compute how much more than the estimate the job will cost. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Which programming paradigm is the most used for make R packages?
Hi wizards, does somebody know Which programming paradigm is the most used for make R packages ? Thanks in advance. -- personal web site: http://www.geocities.com/ricardo_rios_sv/index.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote: > Hi All, > > My problem is about parallel execution of R-scripts. My platform is linux. > > A program that is written in C needs to execute multiple R-scripts > simultaneously. The C program makes use of multi-threading. Each thread > must initiate the execution of one script. Performance is very important. > > Appearantly the R C-API does not provide a mechanism for parallel > execution.. > > It is preferred that the solution is not based on multi-processing (like > C/S), because that would introduce IPC overhead. One thing to keep in mind is that IPC is very fast in Linux. So unless you are making lots of calls to really tiny functions this should not be an issue. What can be an issue is the overhead of starting a new R process. In which case you can make some helper processes that do the same thing you wanted from a multi-thread one and just pass the data around. best Vladimir Dergachev > > Hopefully some thread-safe (single-proces) solution is readily > available, written in C. > > What is the best solution to do this? > > (If there is no single-process solution, what is the alternative?) > > Regards, > Erik. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Which programming paradigm is the most used for make R packages?
On Wed, 3 Jan 2007, Ricardo Rios wrote: > Hi wizards, does somebody know Which programming paradigm is the most > used for make R packages ? Thanks in advance. R programming? Most R packages are either written solely in R or in R with a small amount of C or Fortran support code. That includes the packages which ship with R itself (although some have a substantial amount of support code). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
Thoughts from a pro-Smalltalk bigot:
"Byron Ellis" <[EMAIL PROTECTED]> writes:
> While a Smalltalk-style debugger would be pretty awesome, I suspect
> R's semantics would make restartable exceptions pretty difficult and
> R's current implementation would make getting the continuation-like
> object you'd need pretty difficult, at least across the range of
> platforms supported by R.
>
> A solution, of course, would be to implement R's interpreter in
> Smalltalk as a domain-specific language. Vista Smalltalk apparently
> hosts a Lisp/Scheme interpreter and I know of at least one Lisp
> implementation for Squeak, which serve as pretty good starting points
> for an S-like language. :-)
I've programmed extensively in both Splus/R and Smalltalk, and I am much less
enamored of this idea than I used to be. R and Smalltalk are fundamentally
different and require different mindsets to write decent code. Here are some
of the differences:
1. Smalltalk objects are passed by reference, while R passes by value.
2. Smalltalk programs consist of messages sent to objects (receivers) and
assignments. R programs consist of function calls and assignments.
3. Smalltalk is single-inheritance and single-dispatch. R has multiple
inheritance and multiple dispatch.
4. The simplicity of the Smalltalk model is in part responsible for the
fantastic development tools. Single dispatch lets every method belong to a
particular class. In fact, everything in the system is an instance of some
class, including messages, methods, and even classes themselves. The
system browser essentially just browses (and lets you edit) classes, and
that's essentially all that you need. There are other browsers, but
they're really just different views into the same thing.
5. The style of programming is different. One example is how to implement a
computation with some inputs that have default values. In R, you would
write a function like this:
myFun <- function(arg1, arg2 = default2, arg3 = default3){
...
return(aComputedResult)
}
and call it any of these ways:
answer <- myFun(arg1 = 1)
answer <- myFun(arg1 = 1, arg2 = 2)
answer <- myFun(arg1 = 1, arg3 = 3)
answer <- myFun(arg1 = 1, arg2 = 2, arg3 = 3)
The naive way to do the same in Smalltalk uses 4 methods implemented in the
class of arg1. The one that does the actual computing looks like this:
myFunArg2: firstNumber arg3: secondNumber
^ aComputedResult "'^' is the return operator."
The other three methods are:
myFunArg2: aNumber
^ self myFunArg2: aNumber arg3: default3
myFunArg3: aNumber
^ self myFunArg2: default2 arg3: aNumber
myFun
^ self myFunArg2: default2 arg3: default3
and the four ways you can invoke these are:
answer := 1 myFun.
answer := 1 myFunArg2: 2.
answer := 1 myFunArg3: 3.
answer := 1 myFunArg2: 2 arg3: 3.
Compared to R this is kind of clunky, with a combinatoric explosion in the
number of methods as the number of arguments increases. To avoid that, an
experienced Smalltalker might instead create the class MyFunArgs to
implement the idea of "arguments for computing myFun". MyFunArgs would
have instance variables arg1, arg2 and arg3, and myFun would be invoked by
sending the message 'compute' to an instance of myFunArgs. MyFunArgs would
have an initialize method that set up the default values, so that
MyFunArgs arg1: aNumber
returned an instance with arg1 set to aNumber, arg2 set to default2, and
arg3 set to default3. Then you'd call it in one of these ways:
answer := (MyFunArgs arg1: 1) compute.
answer := ((MyFunArgs arg1: 1) arg2: 2) compute.
answer := ((MyFunArgs arg1: 1) arg3: 3) compute.
answer := ((MyFunArgs arg1: 1) arg2: 2; arg3: 3) compute.
For all of these reasons and more, R code does not translate cleanly to
Smalltalk, and even writing an R interpreter in Smalltalk does not really take
advantage of the Smalltalk way of programming.
On the other hand, Smalltalk is a very nice language, and with a bit of work
to set up the fundamental classes (e.g., Matrix, Vector, StatisticalModel,
etc...), a very nice data analysis environment could be created using it. The
virtues of such a system would be many. First and foremost is that, at the
level of 'computing on the language', Smalltalk is easy to understand, as it
really consists of only a few simple ideas consistently exploited to create a
sophisticated system. Second, there are free Smalltalk implementations that
can create complicated GUI applications much more easily than can be done in R
or Splus. Third, even the slowest Smalltalk interpreters are faster than the R
interpreter. Of course, in many cases this would not matter since R and
Smalltalk programmers alike can always call out to C or Fortran for
numerically intensive computations.
Jeff
__
R-devel@r-project.org maili
Re: [Rd] Am I missing something about debugging?
On 03 Jan 2007 10:42:38 -0500, Jeffrey J. Hallman <[EMAIL PROTECTED]> wrote:
> Thoughts from a pro-Smalltalk bigot:
I'm surprised anyone took the idea seriously enough to respond. :-)
>
>
> I've programmed extensively in both Splus/R and Smalltalk, and I am much less
> enamored of this idea than I used to be. R and Smalltalk are fundamentally
> different and require different mindsets to write decent code. Here are some
> of the differences:
>
> 1. Smalltalk objects are passed by reference, while R passes by value.
Yes, but what's pass-by-value other than a possibly clever version of
[anObject doSomething:[anotherObject copy]]?
>
> 2. Smalltalk programs consist of messages sent to objects (receivers) and
>assignments. R programs consist of function calls and assignments.
>
> 3. Smalltalk is single-inheritance and single-dispatch. R has multiple
>inheritance and multiple dispatch.
I would argue that Smalltalk is heading in this direction with the
introduction of Traits and other class composition techniques.
Multiple-dispatch is something Smalltalks generally don't do, but it's
not something it can't do. Actually, there was a paper just recently
(on Arxiv maybe?) that showed a very elegant way of putting multiple
dispatch into a single dispatch system. Sadly, I seem to have
misplaced the PDF (Just more proof I need one of those Sony Reader
things...)
>
> 4. The simplicity of the Smalltalk model is in part responsible for the
>fantastic development tools. Single dispatch lets every method belong to a
>particular class. In fact, everything in the system is an instance of some
>class, including messages, methods, and even classes themselves. The
>system browser essentially just browses (and lets you edit) classes, and
>that's essentially all that you need. There are other browsers, but
>they're really just different views into the same thing.
More importantly, the reference-based-nature make it much easier to
change a method in a class and have the right thing happen. With R
it's unclear if you could make sure that all copies of a function are
accounted for without resorting to walking the image Sort of like
the problems with posing in modern Smalltalks.
>
> 5. The style of programming is different. One example is how to implement a
>computation with some inputs that have default values. In R, you would
>write a function like this:
>
>myFun <- function(arg1, arg2 = default2, arg3 = default3){
>...
>return(aComputedResult)
>}
>
>and call it any of these ways:
>
>answer <- myFun(arg1 = 1)
>answer <- myFun(arg1 = 1, arg2 = 2)
>answer <- myFun(arg1 = 1, arg3 = 3)
>answer <- myFun(arg1 = 1, arg2 = 2, arg3 = 3)
>
>The naive way to do the same in Smalltalk uses 4 methods implemented in the
>class of arg1. The one that does the actual computing looks like this:
>
>myFunArg2: firstNumber arg3: secondNumber
>
> ^ aComputedResult "'^' is the return operator."
>
>The other three methods are:
>
>myFunArg2: aNumber
> ^ self myFunArg2: aNumber arg3: default3
>
>myFunArg3: aNumber
> ^ self myFunArg2: default2 arg3: aNumber
>
>myFun
> ^ self myFunArg2: default2 arg3: default3
>
>and the four ways you can invoke these are:
>
>answer := 1 myFun.
>answer := 1 myFunArg2: 2.
>answer := 1 myFunArg3: 3.
>answer := 1 myFunArg2: 2 arg3: 3.
>
>Compared to R this is kind of clunky, with a combinatoric explosion in the
>number of methods as the number of arguments increases. To avoid that, an
>experienced Smalltalker might instead create the class MyFunArgs to
>implement the idea of "arguments for computing myFun". MyFunArgs would
>have instance variables arg1, arg2 and arg3, and myFun would be invoked by
>sending the message 'compute' to an instance of myFunArgs. MyFunArgs would
>have an initialize method that set up the default values, so that
>
>MyFunArgs arg1: aNumber
>
>returned an instance with arg1 set to aNumber, arg2 set to default2, and
>arg3 set to default3. Then you'd call it in one of these ways:
>
>answer := (MyFunArgs arg1: 1) compute.
>answer := ((MyFunArgs arg1: 1) arg2: 2) compute.
>answer := ((MyFunArgs arg1: 1) arg3: 3) compute.
>answer := ((MyFunArgs arg1: 1) arg2: 2; arg3: 3) compute.
>
> For all of these reasons and more, R code does not translate cleanly to
> Smalltalk, and even writing an R interpreter in Smalltalk does not really take
> advantage of the Smalltalk way of programming.
Actually, R's argument list is more like a dictionary than it is like
a Smalltalk or C-style argument list so I'd probably opt for something
with a Dictionary-like structure if I were building something in
Smalltalk. Hmm, R is Dicts all the way down!
However, this illustrates the point of WHY you might want a domain
specific language for statistics in Smalltalk. There are somethings
that the S
Re: [Rd] Which programming paradigm is the most used for make R packages?
On Wed, Jan 03, 2007 at 11:46:16AM -0600, Ricardo Rios wrote:
> Hi wizards, does somebody know Which programming paradigm is the most
> used for make R packages ? Thanks in advance.
>
You need to explain what you mean by the question, for example what
paradigms you have in mind.
R is a functional language; as I've discovered, this means some
standard OO programming approaches don't carry over too naturally. In
particular, functions don't really "belong" to classes. R purists
would probably want that to say class-based 00 programming doesn't
fit, since R is function-based OO.
There is a package that permits a more traditional ("class-based") OO
style; I think it's called R.oo.
Ross Boylan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Which programming paradigm is the most used for make R packages?
On 1/4/07, Ross Boylan <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 03, 2007 at 11:46:16AM -0600, Ricardo Rios wrote:
> > Hi wizards, does somebody know Which programming paradigm is the most
> > used for make R packages ? Thanks in advance.
> >
> You need to explain what you mean by the question, for example what
> paradigms you have in mind.
>
> R is a functional language; as I've discovered, this means some
> standard OO programming approaches don't carry over too naturally. In
> particular, functions don't really "belong" to classes. R purists
> would probably want that to say class-based 00 programming doesn't
> fit, since R is function-based OO.
>
> There is a package that permits a more traditional ("class-based") OO
> style; I think it's called R.oo.
More precisely, for the R purists, R.oo provides utility functions to
define S3 methods safely, and in addition, as you write, a top-level
class Object that provides class-based object-oriented design and
implementation with support for reference variables through standard
S3 inheritance.
Cheers
Henrik
>
> Ross Boylan
>
> __
> 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] Capturing argument values
Ross Boylan <[EMAIL PROTECTED]> writes: > I would like to preserve the values of all the arguments to a function > in a results object. > foo <- function(a, b=1) > foo(x, 3) > > match.call() looks promising, but it records that a is x, while I want > the value of x (in the calling frame). Also, if the invocation is > foo(x), then match.call doesn't record that b is 1. > > So I tried this (inside the function definition): > myargs <- lapply(names(formals()), > function(x) eval(as.name(x))) > > That's pretty close. However, my function has an optional argument in > this sense: > bar <- function(x, testing) ... > where code in the body is > if (! missing(testing)) do stuff > > When the eval in the previous lapply runs for a function call in which > testing is not supplied, I get > Error in eval(expr, envir, enclos) : argument "testing" is missing, > with no default > exposing a weakness in both my implementation and problem specification. > > I think I could simply screen "testing" out of the formals and be > happy, but are there better ways of handling this situation? Why not just give testing a default value? Otherwise, filtering out missing args as you mentioned. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
