rkward+update
klerer at sxmail.de
klerer at sxmail.de
Sat Mar 19 01:44:04 UTC 2016
Hello All,[a] Concerning the "mask issue" (see email pre-dating today attached below, reference 1) when one would use "rkward" frontend to work with R and some 'quirky' behaviour that surfaced as a result of "masking" event(s) when I executed some book examples (reference 2 below), there may be some of these events that were probably also interesting for the experienced "rkward" community. Thus, I would like to present (see [b]) those instances to the "rkward" mailing list.[b] I hope this could contribute to heal the lack of description
mentioned by Thomas Friedrichsmeier responding on the occasion of my
question. The email (that should have been) mentioned in (reference 1) contained the following list of preliminarily inoperable examples of R using my current "rkward" installation (extract of a mail sent to Mr Norman Matloff, author of the book referenced below by the end of this very email):"...Using R via the KDE frontend "rkward" on a recent linux flavour, there were the following surprises:(1)page 163> two <- function(u){ # Somehow, I obviously didn't get the idea of this example function; as an apparent stand-alone, "the + assign("u",2*u,pos=.GlobalEnv) source" of object "u" is obscured to this reader's eyes+ z <- 2*z+ }> two(x)(2)page 178> x <- newtree(8,3) # Could that mean that the example running unto page 182 depended on this very function and the underlyingFehler: konnte Funktion "newtree" nicht
finden package (and, additionally, which one package/ 'family' of packages)?(3)page 185> b <- newbookvec(c(3,4,5,5,12,13))> b$vec[1] 3 4 5 5 12 13$wrts[1] 0 0 0 0 0 0attr(,"class")[1] "bookvec"> b[2] # Now it is getting mysterious: According to the book (p. 185) "[1] 4" is the intended output + the call should have basically referred to the vector instead of the list, wright (wrong?)? $wrts [1] 0 0 0 0 0 0> b$vec[2] # ...in turn, one was probably wrong above when I was asking R the wrong question?!?[1] 4> b$vec[2] <- 88 # ...because of this, "b$vec[2]" would be apparently the better call rather than "b[2]"; how high are the odds to call
this 'inconsequetial' relative to what the book recommends???? inkonsequent NOMMA SCHAUN> b$vec[2] [1] 88> b$wrts # "write count incremented?"; that way (as 'prescribed' by the book) not at all... [1] 0 0 0 0 0 0> b[2] <- 88 # ... but that way the "write count" increased by one!?!!? What exactly is one to understand here right now...??> b[2]$wrts[1] 0 1 0 0 0 0(4)page 213Text on page 213 says: "Essentially, J was treated as a list for printing purposes. Now let's write our own print method:"> print.employee <- function(wrkr){+ cat(wrkr$name,"n")+ cat("salary",wrkr$salary,"n")+ cat("union member",wrkr$union,"n") # "nothing"
seriously deleterious detected while copying-by-typing that functionText on page 213 further on says: "So, any call to print() on an object of class "employee" should now be referred to print.employee(). We can check that formally:"> methods(,print.employee)no methods were found> methods(print.employee) # What does either the R user or the R editor (Rkward) does not comprehend at this moment?no methods were foundWarnmeldung: In methods(print.employee) : # Translation of German language error message to follow: Funktion 'print.employee' scheint nicht generisch sein "function 'print.employee' appears not to be generic" (5)Text on page 244 "The function write.table() works very much like read.table(), except that it writes a data frame instead of reading one. For instance, let's take the little Jack and Jill example
from the beginning of Chapter 5:"> kids <- c("Jack","Jill")> ages <- c(12,10)> d <- data.frame(kids,ages,stringsAsFactors=FALSE)> d kids ages1 Jack 122 Jill 10> write.table(d,"kds")> kds # Beginning with this line of R code, R complains that it cannot find/ recognise an object called "kds"!!! Where could it have been gone?(6)bottom of page 277> curve <- function(expr,from = NULL, to = NULL, n = 101, add = FALSE, type="l", ylab=NULL,log=NULL,xlim=NULL,...){+ sexpr <- substitute(expr)+ if(is.name(sexpr)){+ x <- if (lg != "" && "x" %in% strsplit(lg, NULL)[[1]]){+ if(any(c(from,to) <= 0))+ stop("'from' and 'to' must be > 0 with log="x"")+ exp(seq.int(log(from),log(to),length.out=n))+ }+ else seq.int(from,to,length.out=n)+ y <- eval(expr,envir=list(x=x),enclos=parent.frame())+ if(add)+ lines(x,y,type=type,...)+ else
plot(x,y,type=type,ylab=ylab,xlim=xlim,log=lg,...)+ } # the LITERALLY copied function has ONE CURLY BRACE less as one might expect it to have! >> Would one more left-hand-side open curly brace alleviate the problem(s) one might have executing the "literal" example >> This observation was followed by the finding that function "crv" (page 278), too, would probably not duely work because of the lack of one such curly brace ("}"). Has this been noted before or has this circumstance already been resolved one of this book's new edition(s) (if to-date prepared so far)? (7)page 310 ff : On copying-by-typing the book example, I became aware of the fact that on my R (version 3.0.2) the balance between "sim1" and "sim2" is rather skewed as long as that current book example holds.> system.time(print(sim1(10000))) [1] 0.5004 User System verstrichen # German
"verstrichen" means 'elapsed' 0.451 0.000 0.369 > system.time(print(sim1(100000))) [1] 0.5012 User System verstrichen # German "verstrichen" means 'elapsed' 4.335 0.000 3.708 > system.time(print(sim2(100000))) [1] 0.50283 User System verstrichen # German "verstrichen" means 'elapsed' 0.980 0.000 0.804>> Concluding from what ('my') R outputs above, "sim2" is considerably faster than "sim1" if, as insinuated above, R version evolution up to the spring/ early summer of 2015 had not led to the converse result the printed book copy I used indicates. ..."+++++++++++++++++++++++++++++++++++++++++++++++++++++++REFERENCES(1) EMAIL
Absender:
klerer at sxmail.de
Empfänger:
rkward-users at kde.org
Datum:
04.03.2016 01:04
Betreff:
rkward+update
Dear
"rkward" Team,
[0] Observing (partly) what one
subpage (https://rkward.kde.org/Contact) of your project
recommends, I am sending you herewith the output of
"rk.sessionInfo()"
(date of calling this function in "rkward" R console:
3rd March 2016)
-------START OF OUTPUT-------RKWard version: 0.6.1KDE
version (runtime): 4.13.3KDE version (compile time):
4.10.3Local KDE directory: /home/ichhalt/.kde/RKWard
storage directory: /home/ichhalt/.rkward/Debug message
file(s) in use (these may contain relevant diagnostic output in
case of
trouble):/tmp/rkward.frontend.n17001/tmp/rkward.rbackend.J17010R
version (compile time): 3.0.0 (2013-04-03 r62481)R
runtime session info:R version 3.0.2 (2013-09-25)Platform:
x86_64-pc-linux-gnu (64-bit)locale: [1]
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC=C
[3] LC_TIME=de_DE.UTF-8
LC_COLLATE=de_DE.UTF-8 [5]
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8 [7]
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
[9] LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8 [11]
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8attached base packages:[1]
stats graphics grDevices utils
datasets methods base
other attached packages:[1] rkward_0.6.1loaded
via a namespace (and not attached):[1] tools_3.0.2
-------END OF OUTPUT-------...maybe this would help to
resolve that which I really tried to put in few words below.
Please note that I am not consciously using html format for
emails under this address (as I was recently briskly feed-backed
on), text-only mode is not available to and thus unapplicable for
me thus far. [a] I
decided to delve into statistical programming language R in 2015,
seeking to get a properly embeddable R GUI. Since "rkward"
was described to be suitable for R on a Linux system (mine:
current Debian-flavour "Kubuntu" on a 64bit system)
that uses KDE, I choose the product you developed (current and
still running version: 0.6.1).
[b] In the meantime, I came across some problems concerning R
package and/ or R version update that are by now apparently
irresolvable. R package update via R console of "rkward"
seems to be/ have gone defective:
[b1] that is on entering the respective command
("install.packages(packageName)"), "rkward" R
console either gives back it (1); could not find the mirror or
(2); the very R package is unavailable for R version 3.0.2.
Without the latter error message, I would not have wanted to very
early learn about the uggly fact that I do not really know which
(bulk of) package(s) to replace to finally update/ upgrade R to a
higher version number-and whether "rkward" could
perform such a task.
[b2] Now that R version number approaches 3.5, I intend to better
learn about the problems I have no oversight over so far. It is
high time to determine how to 'liberate' R from some constraints
I experienced as (3); using "rkward" R console instead
of R-within-bash console resulted in unforeseen (non)results when
some commands were not yielding what logically and normally they
would have had to deliver. I was told (via email exchange with)
by an author of a a fairly instructive R book, Mr Norman Matloff,
that the GUI had not full take on R (he put it something like
that there was something "masked") as it could and
should have if all the intrinsic prerequisites of the respective
book examples were fulfiled.
[c] Hence, I would like to know whether there is already
awareness of this (bunch of) issue(s) and/ or whether there
existed a (projected) resolution to this problem. I am also and
still a beginner in Linux which would require me to have some
guidance on working my way out in an bash-only style (or,
alternatively, how one would have to proceed when using the
fine-tune package manager "Synaptic"). I can,
additionally, vaguely remember that a pop-up window during the
installation process of "rkward" and/ or "R"
on my system said something like "originally only conceived
to run on lubuntu"-maybe that is the "source of all
evil"... [d]
As I have, (un)fortunately, seen some moments ago on the rkward
home page, version 0.6.4 is available for installation. Would,
thus, a higher "rkward" version's installation heal the
problems (and make descriptions given by me in paragraphs [b1]
and [b1] obsolete) of an "rkward" version
unfunctionable when it comes to updates "the regular
way"? [e]
Thank you very much in advance.
Best regards,
Markus Hofstetter
_______________________________________________rkward-users
mailing
listrkward-users at kde.orghttps://mail.kde.org/mailman/listinfo/rkward-users
------------------------------------------------------------------------------------------------------------------------------------------(2) BOOK>AUTHOR Norman Matloff>TITLE "The Art of R programming. A tour of statistical software design">YEAR PUBLISHED 2011>ISBN-13 978-1-59327-384-2 -and- ISBN-10 1-59327-384-3>PAGE COUNT 373>PUBLISHER no starch press------------------------------------------------------------------------------------------------------------------------------------------Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-bochum.de> schrieb (04.03.2016 08:45):Hi!
On Fri, 4 Mar 2016 01:04:33 +0100
klerer at sxmail.de wrote:
[...]
> [a] I decided to delve into statistical programming
> language R in 2015, seeking to get a properly embeddable R GUI. Since
> "rkward" was described to be suitable for R on a Linux system (mine:
> current Debian-flavour "Kubuntu" on a 64bit system) that uses KDE, I
> choose the product you developed (current and still running version:
> 0.6.1).
[...]
As you have found out, neither R 3.0.2, nor RKWard 0.6.1 are current.
Note that this is not so much a problem specific to RKWard. Rather you
seem to have opted for a "long term support" version of KUbuntu, and
that does mean most packages will grow out-of-date over the lifetime of
your installation. RKWard _and_ R are _both_ rather old versions on your
installation. Fortunately, backport archives exist for both R and
RKWard (https://launchpad.net/~rkward-devel), so in general you can use
the most recent versions of R and RKWard running on an otherwise
conservative installation, rather easily.
> [b2] Now that R version number
> approaches 3.5, I intend to better learn about the problems I have no
> oversight over so far. It is high time to determine how to 'liberate'
> R from some constraints I experienced as (3); using "rkward" R
> console instead of R-within-bash console resulted in unforeseen
> (non)results when some commands were not yielding what logically and
> normally they would have had to deliver. I was told (via email
> exchange with) by an author of a a fairly instructive R book, Mr
> Norman Matloff, that the GUI had not full take on R (he put it
> something like that there was something "masked") as it could and
> should have if all the intrinsic prerequisites of the respective book
> examples were fulfiled.
RKWard does "mask" a handful of R functions. For instance, Sys.setwd()
is "overridden" to make RKWard aware of the current working directory,
when that gets changes. q() is overridden so that RKWard will prompt to
save files and data before you quit. require() is overridden so that
RKWard will offer a dialog to install packages if missing. X11() is
overridden to open the RK()-device, instead.
Also of course certain options have different defaults than in a
console session of R. For instance, browser is set to the internal
HTML-viewer, pager is set to open text files in an integrated window,
etc.
What I am _not_ currently aware of is any problems caused by this. If
you are running into any specific problem, please do report it. (NB:
you should upgrade to 0.6.4, first. We routinely do fix issues when we
encounter them. Perhaps, for instance you were running into lockup
issues using tcl/tk elements, which were fixed for 0.6.3).
[...]
> Would, thus, a
> higher "rkward" version's installation heal the problems (and make
> descriptions given by me in paragraphs [b1] and [b1] obsolete)
b1: Yes. b2: Depends on what exactly you are seeing. I cannot tell
based on your (lack of) description.
> of an
> "rkward" version unfunctionable when it comes to updates "the regular
> way"?
Use the PPAs, I linked to, above (rkward-stable-cran, probably). These
integrate into the "regular" Ubuntu package management.
Regards
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-users/attachments/20160319/17f01070/attachment-0001.html>
More information about the rkward-users
mailing list