Re: [Rd] Runnable R packages
Doesn't Rtools provide everything needed to build R packages and R on Windows - including gcc? Am Sa., 2. Feb. 2019 um 22:29 Uhr schrieb Abs Spurdle : > Creating an .exe file isn't necessarily difficult. > The main problems are that you have to write and compile the C (or other) > files. > Otherwise, the complexity depends on the level of Inter Process > Communication that's required. > > Simply starting R with some initial conditions, is easy. > Even if you want to prompt the user to install missing packages, it isn't > necessarily difficult. > > It would be possible to take this one step further, and write an .exe > builder, that automates the process of creating .exe files. > Obviously, it would require a compiler and supporting libraries. > I have a preference for GCC, and I'm not sure if you can run GCC on Windows > without Cygwin. > > I may (or may not) look into this further, in a few weeks time. > > > On Sun, Feb 3, 2019 at 2:27 AM Barry Rowlingson < > b.rowling...@lancaster.ac.uk> wrote: > > > I don't think anyone denies that you *could* make an EXE to do all > > that. The discussion is on *how easy* it should be to create a single > > file that contains an initial "main" function plus a set of bundled > > code (potentially as a package) and which when run will install its > > package code (which is contained in itself, its not in a repo), > > install dependencies, and run the main() function. > > > > Now, I could build a self-executable shar file that bundled a package > > together with a script to do all the above. But if there was a "RUN" > > command in R, and a convention that a function called "foo::main" > > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > > easier to develop and test. > > > > If people think this adds value, then if they want to offer that value > > to me as $ or £, I'd consider writing it if their total value was more > > than my cost > > > > Barry > > > > > ___ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conventions: Use of globals and main functions
Hey,
I always found it a strength of R compared to many other langaugas that
simple things (running a script, doing something interactive, writing a
function, using lambdas, installing packages, getting help, ...) are very
very simple.
R is a commandline statistics program that happens to be a very elegant,
simple and consistent programming language too.
That beeing said I think the main task of scripts is to get things done via
running them end to end in a fresh session. Now, it very well may happen
that a lot of stuff has to be done. Than splitting up scripts into
subscripts and sourcing them from a meta script is a straightforward
solution. It might also be that some functionality is put into functions to
be reused in other places. This can be done by putting those function
definitions into separate files. Than one cane use source wherever those
functions are needed. Now, putting stuff that runs code and scripts that
define/provovide functions into the same script is a bad idea. Using the
main()-idioms described might prevent this the problems stemming from
mixing functions and function execution. But it would also encourage this
mixing which is - I think, a bad idea anyways.
Therefore, I am against fostering a main()-idiom - it adds complexity and
encourages bad code structuring (putting application code and function
definition code into one file).
If one needs code to behave differenlty in interactive sessions than in
non-interactive sessions - if( interactive() ){ } is one way to solve this.
If more solid software developement is needed packages are the way to go.
Best, Peter
Am So., 25. Aug. 2019 um 06:11 Uhr schrieb Cyclic Group Z_1 via R-devel <
r-devel@r-project.org>:
> In R scripts (as opposed to packages), even in reproducible scripts, it
> seems fairly conventional to use the global workspace as a sort of main
> function, and thus R scripts often populate the global environment with
> many variables, which may be mutated. Although this makes sense given R has
> historically been used interactively and this practice is common for
> scripting languages, this appears to disagree with the software-engineering
> principle of avoiding a mutating global state. Although this is just a rule
> of thumb, in R scripts, the frequent use of global variables is much more
> pronounced than in other languages.
>
> On the other hand, in Python, it is common to use a main function (through
> the `def main():` and `if __name__ == "__main__":` idioms). This is
> mentioned both in the documentation as well as in the writing of Python's
> main creator. Although this is more beneficial in Python than in R because
> Python code is structured into modules, which serve as both scripts and
> packages, whereas R separates these conceptually, a similar practice of
> creating a main function would help avoid the issues from mutating global
> state common to other languages and facilitate maintainability, especially
> for longer scripts.
>
> Although many great R texts (Advanced R, Art of R Programming, etc.)
> caution against assignment in a parent enclosure (e.g., using `<<-`, or
> `assign`), I have not seen many promote the use of a main function and
> avoiding mutating global variables from top level.
>
> Would it be a good idea to promote use of main functions and limiting
> global-state mutation for longer scripts and dedicated applications (not
> one-off scripts)? Should these practices be mentioned in the standard
> documentation?
>
> This question was motivated largely by this discussion on Reddit:
> https://www.reddit.com/r/rstats/comments/cp3kva/is_mutating_global_state_acceptable_in_r/
> .
> Apologies beforehand if any of these (partially subjective) assessments are
> in error.
>
> Best,
> CG
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conventions: Use of globals and main functions
Firtst, I think that thinking about best practice advise and beeing able to accomandate different usage scenarios is a good thing despite me arguing against introducing the main()-idiom. Let's have another turn on the global-environment is bad argument. It has two parts: (1) Glattering namespace. Glattering name space might become a problem because you might end up having used all reasonable words already so one has to extend the space for names with new namespaces. For scripting, this usually should be no problem since one can always create more space through the usage of environments - put code into a function, put objects into environments, or write a package. Glattering name space might also become a problem if things get complex. If your code base gets larger on name might be overwritten by the other on accident. This is a problem that can be solved by not simply extending the name space (more space) but by structuring it - keeping related things together, hiding unused helpers e.g. by putting them in a function, or an environment, or writing a package. Now, if we put everything into main() we have not solved much. Now instead of 100 objects glattering the global environment we have e.g. 5 obejcts in the global environment and 95 objects in the main()-function environment. (2) Changing global state. A thing that is a little bit related to the global environment is the idea of global state and the problems that arise when changing global state. But the global environment in R is not the same as a global state. First, all normal stuff in R (except environments, R6 objects, data.tables) are passed by copy (never mind how its implented under the hood). So when I assign a value to a new name, this will behave like if I made a copy - thus I simply do not care what happens to the value of the original because my copy's value is independent. Next, it is possible to misuse the global environment (or nay parent environment) as global state via either explicitly using assign(..., ..., env = globalenv()) or by using the <<- operator. Also, one has access to objects of enclosing envíronment when e.g. executing code in a function environment but this is read only by default. Although this is possible and it is done from time to time, this is not how things are done 99% of the time. The common practice - and I would say best practice also - is to use pure function that only depend on their inputs and do not change anything except returing a value. Using pure functions mainly prevents 99% of the problems with global state while using more name spaces does only chop these kind of problems into smaller and thus more numerous problems. Best, Peter Am Mi., 28. Aug. 2019 um 05:56 Uhr schrieb Cyclic Group Z_1 < cyclicgroup...@yahoo.com>: > > That beeing said I think the main task of scripts is to get things done > via running them end to end in a fresh session. Now, it very well may > happen that a lot of stuff has to be done. Than splitting up scripts into > subscripts and sourcing them from a meta script is a straightforward > solution. It might also be that some functionality is put into functions to > be reused in other places. This can be done by putting those function > definitions into separate files. Than one cane use source wherever those > functions are needed. Now, putting stuff that runs code and scripts that > define/provovide functions into the same script is a bad idea. Using the > main()-idioms described might prevent this the problems stemming from > mixing functions and function execution. But it would also encourage this > mixing which is - I think, a bad idea anyways. > > I actually would agree entirely that files should not serve as both source > files for re-used functions as well as application code. The suggestion for > a main() idiom is merely to reduce variable scope and bring R practices > more in line with generally recommended programming practices, not so that > they can act as packages/modules/libraries. When I compared R scripts > containing main functions to packages, I only mean in the sense that they > help manage scope (the latter through package namespaces). Any other named > functions besides main would be functions specifically tied to the script. > > I do see your point, though, that this could result in bad practice, > namely the usage mixing you described. > > Best, > CG > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conventions: Use of globals and main functions
The point is, that there are several possible problems. But. One the one hand they are not really problematic in my opinion (I do not care if my function has potential access to objects outside of its environment because this access is read-only at worst and it's not common practice to use this potential anyways). On the other hand I am not sure what the main()-idiom would actually add to the table other than allowing for the dual use of function definition and function execution code in the same script - which we agreed upon is bad practice. Best, Peter Am Mi., 28. Aug. 2019 um 17:58 Uhr schrieb Cyclic Group Z_1 < cyclicgroup...@yahoo.com>: > I appreciate the well-thought-out comments. > > To your first point, I am not sure what "glattering" means precisely (a > Google search revealed nothing useful), but I assume it means something to > the effect of overfilling the main namespace with too many names. Per Norm > Matloff's counterpoint in The Art of R Programming regarding this issue, > this is mostly avoided by well-defined, (sufficiently) long names. Also, > when a program is properly modularized, one generally wouldn't have this > many objects at the same time unless the complexity of a program demands > it. You can, for example, use named function scope outside main or > anonymous functions to limit variable scope to operations that need a given > variable. Using main() with any named functions closely tied to a script > defined outside it actually addresses this "glattering namespace" issue, > since, if we treat the global scope as a main function instead of using a > main() idiom, any functions that are defined in global scope will contain > all global variables within its search path. Alternatively, one can put all > named functions in a package; in some cases, however, it will make more > sense to keep a function defined within the script. Unless you never > modularize your code into functions and flatten everything out into a > common namespace, using main would be helpful to avoid > namespace-glattering. Maybe I'm missing something, but I'm not sure how > namespace-glattering favors not using a main() idiom, since avoiding > globals doesn't mean not structuring your code properly; it actually seems > to favor using main(). Given any properly structured program (organizing > functions as needed), the implementation that puts all variables into the > global workspace (same as the top-level functions) will be less safe since > all functions will contain all globals within its search path. (Unless, of > course, every single function is put into a package). > > To your second point, I agree that many of the issues associated with > global state/environment are generally less problematic when using pure (or > as pure as possible) functions. On a related note, lexically scoped > functional languages (especially pure functional ones) generally encourage > modularizing everything into functions, rather than having a lot of objects > exposed to the top level (not to say that globals are not used, only that > they are not the default choice). So the typical R way of doing this tends > to disagree with how things are normally done in functional programming. > Chopping our code into well-abstracted functions (and therefore namespaces) > is the functional way to do things and helps to minimize the state to which > any particular function has access. Organizing the functions we want to be > pure so that they are not defined in the same environment in which they are > called actually helps to ensure function purity in the input direction, > since those functions will not have lexical-scope access to called > variables. (That is, you may have written an impure function without > realizing it; organizing functions so they are not defined in the same > environment as when they are called helps to ensure purity.) > > Perhaps I am mistaken, but in either case, your points actually favor a > main() idiom, unless you take using main() to mean using main() with extra > bits (e.g., flattening your code structure). > > Admittedly, putting every single function into a package and not having > any named functions in your script generally addresses all of these issues. > > Best, > CG > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unicode display problem with data frames under Windows
Am .05.2015, 09:01 Uhr, schrieb Richard Cotton :
On 25 May 2015 at 19:43, Duncan Murdoch wrote:
http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r
Yes, but it is a bug, just a hard one to fix. It needs someone to
dedicate
a serious amount of time to deal with it.
Since most of the people who tend to do that generally use systems in
UTF-8
locales where this isn't a problem, or don't use Windows, it is
languishing.
Thanks for the link and the explanation of why the bug exists.
On May 25, 2015 9:39 AM, "Richard Cotton"
wrote:
> Here's a data frame with some Unicode symbols (set intersection and
> union).
>
> d <- data.frame(x = "A \u222a B \u2229 C")
>
> Printing this data frame under R 3.2.0 patched (r68378) and Windows
7, I
> see
>
> d
> ## x
> ## 1 A B n C
For future readers searching for a solution to this, you can get
correct printing by setting the CTYPE part of the locale to
Chinese/Japanese/Korean.
Sys.setlocale("LC_CTYPE", "Chinese")
## [1] "Chinese (Simplified)_People's Republic of China.936"
d
##x
## 1 A ∪ B ∩ C
There is another workaround.
The problem with the character transformation on printing data frames
stems from format() used within print.default(). Defining your own class
and print function that does not use format() allows for correct printing
in all locales.
Like this:
d <- data.frame(x = "A \u222a B \u2229 C")
d
## x
## 1 A B n C
class(d) <- c("unicode_df","data.frame")
# this is print.default from base R with only two lines modified, see #old#
print.unicode_df <- function (x, ..., digits = NULL, quote = FALSE, right
= TRUE,
row.names = TRUE)
{
n <- length(row.names(x))
if (length(x) == 0L) {
cat(sprintf(ngettext(n, "data frame with 0 columns and %d row",
"data frame with 0 columns and %d rows", domain = "R-base"),
n), "\n", sep = "")
}
else if (n == 0L) {
print.default(names(x), quote = FALSE)
cat(gettext("<0 rows> (or 0-length row.names)\n"))
}
else {
#old# m <- as.matrix(format.data.frame(x, digits = digits,
#old# na.encode = FALSE))
m <- as.matrix(x)
if (!isTRUE(row.names))
dimnames(m)[[1L]] <- if (identical(row.names, FALSE))
rep.int("", n)
else row.names
print(m, ..., quote = quote, right = right)
}
invisible(x)
}
d
## x
## [1,] A ∪ B ∩ C
--
Erstellt mit Operas E-Mail-Modul: http://www.opera.com/mail/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Add-on argument in sample()
Am .06.2015, 14:55 Uhr, schrieb Millot Gael :
Hi.
I have a problem with the default behavior of sample(), which performs
sample(1:x) when x is a single value.
This behavior is well explained in ?sample.
However, this behavior is annoying when the number of value is not
predictable. Would it be possible to add an argument
that desactivates this and perform the sampling on a single value ?
Examples:
sample(10, size = 1, replace = FALSE)
10
sample(10, size = 3, replace = TRUE)
10 10 10
sample(10, size = 3, replace = FALSE)
Error
I think the problem here is that the function actually does what you would
expect it to do given a statistic perspective. A sample of size three from
a population of one without allowing to draw elements again that were
drawn already is simply not defined. What shall the function give back?
... You can always wrap your code in a try() like this to prevent errors
to break loops or functions:
try(sample(...))
... or you might check your arguments before execution:
if ( !replace & length(population) >= size ){
sample(population, size = size , replace = replace)
}else{
...
}
Many thanks for your help.
Best wishes,
Gael Millot.
Gael Millot
UMR 3244 (IC-CNRS-UPMC) et Universite Pierre et Marie Curie
Equipe Recombinaison et instabilite genetique
Pav Trouillet Rossignol 5eme etage
Institut Curie
26 rue d'Ulm
75248 Paris Cedex 05
FRANCE
tel : 33 1 56 24 66 34
fax : 33 1 56 24 66 44
Email : gael.mil...@curie.fr
http://perso.curie.fr/Gael.Millot/index.html
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Best, Peter
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphical User Interface (GUI)
Have a look at gWidgets (John Verzani). Best, Peter Am 08.07.2015 22:29 schrieb "Dean Attali" : > Isn't this exactly what Shiny is meant for? > http://shiny.rstudio.com/ > > --- > http://deanattali.com > > On 8 July 2015 at 11:43, vthokienj wrote: > > > I'd like to create a user interface for my R code and have only seen > mostly > > older posts on the subject. > > I'm not looking for an IDE for development, but something that the end > user > > of the software would use. > > So something that would involve displaying buttons, listboxes, and drop > > down > > menus to a user that will facilitate various actions. > > > > I doubt there is anything Visual Studio-like that provides a toolbox to > > drag > > and drop, but what would be the simplest way to approach designing an > > interface? The basic goal of my program is to have the user enter data > > which > > would be saved to a database. Then, through the interface, various > buttons > > will draw various graphs on that data. > > > > Thanks in advance for any help on this. > > > > > > > > -- > > View this message in context: > > > http://r.789695.n4.nabble.com/Graphical-User-Interface-GUI-tp4709583.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 > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-devel @ Travis
Hey, Metacran's rbuilder is the place to get started: https://github.com/metacran/r-builder You should be good to go by placing this in your Github repo (branch): https://github.com/metacran/r-builder/blob/master/.travis.yml .. than tell Travis to whatch you repo. Best, Peter Am .01.2016, 09:45 Uhr, schrieb Måns Magnusson : Hi! I'm developing R packages and use Travis CI for continous integration. When submitting to CRAN Im suggestet to test the package using the latest R-devel. I would like that all test where run using Travis. Is there anyone who knows if this is possible to run travis test using the latest r-devel? -- Erstellt mit Operas E-Mail-Modul: http://www.opera.com/mail/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] split() - unexpected sorting of results
Hey, I found this - for me - quite surprising and puzzling behaviour of split(). split(1:11, as.character(1:11)) split(1:11, 1:11) When splitting by numerics everything works as expected - sorting of input == sorting of output -- but when using a character vector everything gets re-sorted alphabetical. Although, there are some references in the help files to what happens when using split, I did not find any note on this - for me - rather unexpected behaviour. I would like it best when the sorting of split results stays the same no matter the input (sorting of input == sorting of output) If that is not possibly a note of caution in the help pages and maybe an example might be valuable. Best, Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] split() - unexpected sorting of results
Thanks, for the explanation. Still, I think this is surprising bahaviour which might be handled better. Best, Peter Am 20.10.2017 9:49 nachm. schrieb "Iñaki Úcar" : > Hi Peter, > > 2017-10-20 21:33 GMT+02:00 Peter Meissner : > > Hey, > > > > I found this - for me - quite surprising and puzzling behaviour of > split(). > > > > > > split(1:11, as.character(1:11)) > > split(1:11, 1:11) > > > > > > When splitting by numerics everything works as expected - sorting of > input > > == sorting of output -- but when using a character vector everything gets > > re-sorted alphabetical. > > > > > > Although, there are some references in the help files to what happens > when > > using split, I did not find any note on this - for me - rather unexpected > > behaviour. > > As the documentation states, > >f: a ‘factor’ in the sense that ‘as.factor(f)’ defines the > grouping, or a list of such factors in which case their > interaction is used for the grouping. > > And, in fact, > > > as.factor(1:11) > [1] 1 2 3 4 5 6 7 8 9 10 11 > Levels: 1 2 3 4 5 6 7 8 9 10 11 > > > as.factor(as.character(1:11)) > [1] 1 2 3 4 5 6 7 8 9 10 11 > Levels: 1 10 11 2 3 4 5 6 7 8 9 > > Regards, > Iñaki > > > I would like it best when the sorting of split results stays the same no > > matter the input (sorting of input == sorting of output) > > > > If that is not possibly a note of caution in the help pages and maybe an > > example might be valuable. > > > > > > Best, Peter > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] split() - unexpected sorting of results
Thank you all for your input - most appreciated. Best, Peter Am 21.10.2017 07:35 schrieb "Rui Barradas" : > Hello, > > In order to solve that problem of sorting numerics made characters there > is package stringr, functions str_sort and str_order. > > library(stringr) > > set.seed(2447) > > x <- sample(11L) > sort(as.character(x)) > [1] "1" "10" "11" "2" "3" "4" "5" "6" "7" "8" "9" > > str_sort(as.character(x), numeric = TRUE) > [1] "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" > > str_order(as.character(x), numeric = TRUE) > #[1] 1 4 11 8 6 5 3 10 9 7 2 > > i <- str_order(as.character(x), numeric = TRUE) > as.character(x)[i] > #[1] "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" > > > Unfortunately this does not solve the OP's question, factor(), > as.factor(), split() and others use the base R sorter and this can only be > changed by changing their sources. > > Hope this helps, > > Rui Barradas > > Em 21-10-2017 00:32, Hervé Pagès escreveu: > >> Hi, >> >> On 10/20/2017 12:53 PM, Peter Meissner wrote: >> >>> Thanks, for the explanation. >>> >>> Still, I think this is surprising bahaviour which might be handled >>> better. >>> >> >> Maybe a little surprising, but no more than: >> >> > x <- sample(11L) >> >> > sort(x) >> [1] 1 2 3 4 5 6 7 8 9 10 11 >> >> > sort(as.character(x)) >> [1] "1" "10" "11" "2" "3" "4" "5" "6" "7" "8" "9" >> >> The fact that sort(), as.factor(), split() and many other things behave >> consistently with respect to the underlying order of character vectors >> avoids other even bigger surprises. >> >> Also note that the underlying order of character vectors actually >> depends on your locale. One way to guarantee consistent results across >> platforms/locales is by explicitly specifying the levels when making >> a factor e.g. >> >>f <- factor(x, levels=unique(x)) >>split(1:11, f) >> >> This is particularly sensible when writing unit tests. >> >> Cheers, >> H. >> >> >>> Best, Peter >>> >>> Am 20.10.2017 9:49 nachm. schrieb "Iñaki Úcar" : >>> >>> Hi Peter, >>>> >>>> 2017-10-20 21:33 GMT+02:00 Peter Meissner : >>>> >>>>> Hey, >>>>> >>>>> I found this - for me - quite surprising and puzzling behaviour of >>>>> >>>> split(). >>>> >>>>> >>>>> >>>>> split(1:11, as.character(1:11)) >>>>> split(1:11, 1:11) >>>>> >>>>> >>>>> When splitting by numerics everything works as expected - sorting of >>>>> >>>> input >>>> >>>>> == sorting of output -- but when using a character vector everything >>>>> gets >>>>> re-sorted alphabetical. >>>>> >>>>> >>>>> Although, there are some references in the help files to what happens >>>>> >>>> when >>>> >>>>> using split, I did not find any note on this - for me - rather >>>>> unexpected >>>>> behaviour. >>>>> >>>> >>>> As the documentation states, >>>> >>>> f: a ‘factor’ in the sense that ‘as.factor(f)’ defines the >>>>grouping, or a list of such factors in which case their >>>>interaction is used for the grouping. >>>> >>>> And, in fact, >>>> >>>> as.factor(1:11) >>>>> >>>> [1] 1 2 3 4 5 6 7 8 9 10 11 >>>> Levels: 1 2 3 4 5 6 7 8 9 10 11 >>>> >>>> as.factor(as.character(1:11)) >>>>> >>>> [1] 1 2 3 4 5 6 7 8 9 10 11 >>>> Levels: 1 10 11 2 3 4 5 6 7 8 9 >>>> >>>> Regards, >>>> Iñaki >>>> >>>> I would like it best when the sorting of split results stays the >>>>> same no >>>>> matter the input (sorting of input == sorting of output) >>>>> >>>>> If that is not possibly a note of caution in the help pages and >>>>> maybe an >>>>> example might be valuable. >>>>> >>>>> >>>>> Best, Peter >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> __ >>>>> R-devel@r-project.org mailing list >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et >>>>> hz.ch_mailman_listinfo_r-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84V >>>>> tBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=o5-lZ >>>>> T7zAjFNU8C0Z9D7XaQO_2NGmhKF-IbGZFhSvO0&s=4cZ9rSLJAVnnjULGMCD >>>>> PAclXHoc9_le3Z1DrZg0nQqg&e= >>>>> >>>>> >>>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et >>> hz.ch_mailman_listinfo_r-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84V >>> tBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=o5-lZ >>> T7zAjFNU8C0Z9D7XaQO_2NGmhKF-IbGZFhSvO0&s=4cZ9rSLJAVnnjULGMCD >>> PAclXHoc9_le3Z1DrZg0nQqg&e= >>> >>> >>> >> [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Citation if copying R base code
Dear Listeners, ... also I read the CRAN policies and tried to solve those questions myself I feel very much in the need of good advise ... I am currently finishing a package that -- to solve some nasty problems with dirty data -- uses its own as.Date() equivalent methods (i.e. its own generic and methods). Thereby, I shamelessly copied code from the as.Date() methods from the base package and only made some minor adjustments. For my main achievement was copy-pasting I feel obliged to cite the efforts made by base package authors - do I, should I? Currently I only use the help files to mention that the generic and its methods are basically the same as as.Date(), except this and that. And if yes how to do it best? What is the standard procedure here? Should I include base package authors as contributors in DESCRIPTION??? Am I allowed to use MIT + file license with that or is it wrong to do so? I appreciate any advise on these (I think important) but very confusing matters of referencing and licensing. Best, Peter PS: - My current description: https://github.com/petermeissner/wikipediatrend/blob/master/DESCRIPTION - the package specific as.Date() implementation: https://github.com/petermeissner/wikipediatrend/blob/master/R/wp_date.R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation if copying R base code
But how might I do that? Writing GPL in DESCRIPTION and putting my name in every R-file? Am 2014-11-06 15:46, schrieb Hadley Wickham: And if yes how to do it best? What is the standard procedure here? Should I include base package authors as contributors in DESCRIPTION??? Am I allowed to use MIT + file license with that or is it wrong to do so? No, you must use the GPL, since the code you copied is licensed under the GPL. You can choose to use version 2 or 3 (or both). You do not have permission to re-license R code under a different license. I think it's slightly murkier than that - MIT is GPL compatible, so you could license the code you've written as MIT, but the package as a whole would need to be GPL-2/3. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation if copying R base code
Thank you all for your advise, comments and suggestions.
To keep it simple and play it fair and save, I choose to take the
following actions:
Within DESCRIPTION
- the License now reads:
License: GPL (>= 2)
- the Authors are specified as
Authors@R: as.person(c(
"Peter Meissner [aut, cre]",
"R Core team [ctb] (wp_date() derived from base package as.Date())"
))
Also, the wp_date() help files mention where I copied and where I did
rewrite code. I hope that's fine and good for everyone.
Puh. - That's it.
Best, Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unicode display problem with data frames under Windows
Am .05.2015, 18:43 Uhr, schrieb Duncan Murdoch : On 25/05/2015 11:37 AM, Ista Zahn wrote: AFAIK this is the way it works on Windows. It has been discussed in several places, e.g. http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r , http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r (both of these came up when I googled the subject line of your email). Yes, but it is a bug, just a hard one to fix. It needs someone to dedicate a serious amount of time to deal with it. Since most of the people who tend to do that generally use systems in UTF-8 locales where this isn't a problem, or don't use Windows, it is languishing. Duncan Murdoch I understand that these problems are not easy to fix but ... I think that "most of the people who tend to do that generally use systems in UTF-8 locales" is a biased perception. Developers might tend to use Mac or Linux most often. For others Windows still is and probably will be the OS most often used. For most of them switching to something else is a major hurdle. What I often witness is that those non existent Windows users try to muddle through with numerous calls to Encoding() , iconv() and the like while at the same time never being sure if the strange behavior is due to their lack of understanding, Windows specifics or due to R. In the end they either succeed with their muddling or give up, - but do not change the system. So whoever might attempt the Hercules task will be praised by thousands ;-) Best, Peter Best, Ista On May 25, 2015 9:39 AM, "Richard Cotton" wrote: > Here's a data frame with some Unicode symbols (set intersection and union). > > d <- data.frame(x = "A \u222a B \u2229 C") > > Printing this data frame under R 3.2.0 patched (r68378) and Windows 7, I > see > > d > ## x > ## 1 A B n C > > Printing the column itself works fine. > > d$x > ## [1] A ∪ B ∩ C > ## Levels: A ∪ B ∩ C > > The encoding is correctly UTF-8. > > Encoding(as.character(d$x)) > ## [1] "UTF-8" > > Under Linux both forms of printing are fine for me. > > I'm not quite sure whether I've missed a setting or if this is a bug, so > > Am I doing something silly? > Can anyone else reproduce this? > > -- > Regards, > Richie > > Learning R > 4dpiecharts.com > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ 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
