Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lingtypology: easy mapping for Lingustic Typology #95

Closed
10 of 13 tasks
agricolamz opened this issue Jan 29, 2017 · 46 comments
Closed
10 of 13 tasks

lingtypology: easy mapping for Lingustic Typology #95

agricolamz opened this issue Jan 29, 2017 · 46 comments

Comments

@agricolamz
Copy link

agricolamz commented Jan 29, 2017

Summary

  • What does this package do? (explain in 50 words or less):
    Provides R with the Glottolog database http://glottolog.org and some more abilities for purposes of linguistic mapping. The Glottolog database contains the catalogue of languages of the world. This package helps researchers to make a linguistic maps, using philosophy of the Cross-Linguistic Linked Data project http://clld.org/, which allows for while at the same time facilitating uniform access to the data across publications. A tutorial for this package is available on GitHub pages https://agricolamz.github.io/lingtypology/ and package vignette.

  • Paste the full DESCRIPTION file inside a code block below:

Package: lingtypology
Type: Package
Title: Linguistic Typology and Mapping
Version: 1.0.1
Depends: R (>= 2.10)
Imports:
    leaflet,
    stats,
    stringdist,
    magrittr,
    grDevices,
    rowr
Author: George Moroz
Maintainer: George Moroz <[email protected]>
Description: Provides R with the Glottolog database <http://glottolog.org> and some more abilities for purposes of linguistic cartography. The Glottolog database contains the catalogue of languages of the world. This package helps researchers to make a linguistic maps, using philosophy of the Cross-Linguistic Linked Data project <http://clld.org/>, which allows for while at the same time facilitating uniform access to the data across publications. A tutorial for this package is available on GitHub pages <https://agricolamz.github.io/lingtypology/> and package vignette.
License: GPL (>= 2)
URL: https://CRAN.R-project.org/package=lingtypology, https://github.com/agricolamz/lingtypology/
LazyData: TRUE
RoxygenNote: 5.0.1
Suggests:
    knitr,
    rmarkdown
VignetteBuilder: knitr
  • URL for the package (the development repository, not a stylized html page):
    lingtypology

  • Who is the target audience?
    Linguists, Linguistic typologists

  • Are there other R packages that accomplish the same thing? If so, what is different about yours?
    No, as far as I know

Requirements

Confirm each of the following by checking the box. This package:

  • does not violate the Terms of Service of any service it interacts with.
  • has a CRAN and OSI accepted license.
  • contains a README with instructions for installing the development version.
  • includes documentation with examples for all functions.
  • contains a vignette with examples of its essential functions and uses.
  • has a test suite.
  • has continuous integration with Travis CI and/or another service.

Publication options

  • Do you intend for this package to go on CRAN?
    Yes
  • Do you wish to automatically submit to the Journal of Open Source Software? If so:
    • The package contains a paper.md with a high-level description in the package root or in inst/.
    • The package is deposited in a long-term repository with the DOI:
    • (Do not submit your package separately to JOSS)

Detail

  • Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

  • Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

  • I use not.snake.style function names. Sorry.
  • I didn't provide example usage in my README.md, but I added a link to detailed tutorial.
  • If this is a resubmission following rejection, please explain the change in circumstances:

  • If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

@sckott
Copy link
Contributor

sckott commented Jan 30, 2017

Thank you for your submission @agricolamz

Editor checks:

  • Fit: The package meets criteria for fit and overlap
  • Automated tests: yes
  • License: The package has a CRAN or OSI accepted license
  • Repository: The repository link resolves correctly
  • Archive (JOSS only, may be post-review): NA
  • Version (JOSS only, may be post-review): NA

Editor comments

Currently seeking reviewers. It's a good fit and not overlapping.

  • Ran goodpractice::gp() - here's a few things to think about - we suggest following these suggestions
It is good practice toadd a "BugReports" field to DESCRIPTION, and point it to
    a bug tracker. Many online code hosting services provide bug
    trackers for free, https://github.com, https://gitlab.com, etc.avoid long code lines, it is bad for readability. Also,
    many people prefer editor windows that are about 80 characters
    wide. Try make your lines shorter than 80 characters

    R/aff.lang.R:14:1
    R/aff.lang.R:16:1
    R/area.lang.R:14:1
    R/area.lang.R:16:1
    R/country.lang.R:16:1
    ... and 58 more linesavoid sapply(), it is not type safe. It might return a
    vector, or a list, depending on the input data. Consider using
    vapply() instead.

    R/aff.lang.R:15:3
    R/area.lang.R:15:3
    R/country.lang.R:18:10
    R/is.glottolog.R:28:5
    R/iso.lang.R:15:3
    ... and 5 more linesnot import packages as a whole, as this can cause name
    clashes between the imported packages. Instead, import only the
    specific functions you need.avoid 'T' and 'F', as they are just variables which are
    set to the logicals 'TRUE' and 'FALSE' by default, but are not
    reserved words and hence can be overwritten by the user.  Hence,
    one should always use 'TRUE' and 'FALSE' for the logicals.

    R/is.glottolog.R:NA:NA
    R/map.feature.R:NA:NA
    R/map.feature.R:NA:NA
    R/map.feature.R:NA:NA
    R/map.feature.R:NA:NA
    ... and 8 more lines

Reviewers: @timelyportfolio (due: 2017-03-09) @tzakharko (due: 2017-03-13)

@sckott sckott added the holding label Jan 30, 2017
@agricolamz
Copy link
Author

Dear @sckott,

Thank you for your comment. I hope it will take me two days to sort it out.

@sckott
Copy link
Contributor

sckott commented Jan 31, 2017

thank you

@agricolamz
Copy link
Author

Dear @sckott ,

I tried testthat multiple times, but all the time it returns
'source_test_helpers' is not an exported object from 'namespace:testthat'

linux mint
RStudio 1.0.136
testthat 0.8.1

Do you know what should I do? Actually it is the third time, when I try to start use testthat...

@sckott
Copy link
Contributor

sckott commented Feb 6, 2017

@agricolamz can you put what you've tried on a different branch from master so I can try to help

@agricolamz
Copy link
Author

Hi, @sckott!

I created the test suit. But I still cannot build a package with my tests since I can't install the last version of testthat. And I cannot make covr work the way I expect. But... It is better than nothing. It is awful that I should remove my tests from the package folder to be able build it with devtools, but I spent a lot of time trying to fix it. It works well on Travis.

Can you help me with that? Can you see tests and tell me that it is what you've expected from me?

@sckott
Copy link
Contributor

sckott commented Feb 11, 2017

What do you mean you can't build it? I'm not sure what that refers to.

Can you show me the errors that happen when trying to install latest testthat?

Also, in your testthat.R file you should use test_check instead of test_package and the devtools::build(quiet = T) should be removed

@agricolamz
Copy link
Author

agricolamz commented Feb 11, 2017

Dear @sckott ,

here is a long version of my answer.

I changed testthat.R. It still doesn't work on my PC, but travis and codecov make it work correctly!

@sckott
Copy link
Contributor

sckott commented Feb 15, 2017

Sorry for delay @agricolamz - was traveling and back now, having a look over this

@sckott
Copy link
Contributor

sckott commented Feb 15, 2017

@agricolamz Let's move forward with review - you have tests now and at least they run on travis and they run fine for me as well - I'll kick off process looking for reviewers

I'll help with your machine's setup soon

@agricolamz
Copy link
Author

Dear @timelyportfolio,

Thank you for your comments! Since goodpractice depends on some version of testthat I cannot check my package by myself (see the comments above).

  • BugReports added
  • sapply changed to vapply
  • in most cases @import changed to @importFrom
  • T and F changed to TRUE and FALSE
  • I tried to change line length by myself, then I used formatR package, but there are still a lot of long lines...

@sckott
Copy link
Contributor

sckott commented Feb 20, 2017

Thanks @agricolamz

@sckott
Copy link
Contributor

sckott commented Feb 21, 2017

2nd reviewer assigned: @tzakharko - Thanks for reviewing Taras!

@agricolamz
Copy link
Author

agricolamz commented Feb 23, 2017

Dear @sckott , @tzakharko and @timelyportfolio. I added an additional arguments and rewrote the main function map.feature. So code coverage now is 98%!

@sckott
Copy link
Contributor

sckott commented Mar 8, 2017

just a short message to @timelyportfolio and @tzakharko your reviews are due soon 😸 - thx for reviewing!

@timelyportfolio
Copy link

@agricolamz working through a full review and very nicely done. First suggestion, add Date in DESCRIPTION. I think it is good practice but will also remove this warning.

## Warning in citation("lingtypology"): no date field in DESCRIPTION file of
## package 'lingtypology'

@timelyportfolio
Copy link

timelyportfolio commented Mar 8, 2017

I felt like the review should go in the lingtypology issues, so I have put it ropensci/lingtypology#9. @agricolamz, really well done, and far smoother than I expected. I appreciate your efforts. Please let me know if I can help in any additional way!

I should also add some context to my tests.

> devtools::session_info()
Session info ------------------------------------------------------------------
 setting  value                       
 version  R version 3.3.1 (2016-06-21)
 system   x86_64, mingw32             
 ui       RStudio (1.1.68)            
 language (EN)                        
 collate  English_United States.1252  
 tz       America/Chicago             
 date     2017-03-08                  

Packages ----------------------------------------------------------------------
 package      * version     date      
 assertthat     0.1         2013-12-06
 bindr          0.1         2016-11-13
 bindrcpp     * 0.1         2016-12-12
 colorspace     1.2-6       2015-03-11
 crayon         1.3.2       2016-06-28
 crosstalk      1.0.1       2017-01-09
 DBI            0.5-1       2016-09-10
 devtools       1.12.0      2016-06-24
 digest         0.6.9       2016-01-08
 dplyr        * 0.5.0.9000  2017-01-05
 htmltools      0.3.6       2016-10-24
 htmlwidgets    0.8         2016-11-10
 httpuv         1.3.3       2015-08-04
 jsonlite       1.2         2016-12-31
 lazyeval       0.2.0.9000  2016-07-04
 leaflet        1.0.2.9010  2017-01-26
 lingtypology * 1.0.3       2017-03-08
 magrittr       1.5         2014-11-22
 markdown       0.7.7       2015-04-22
 memoise        1.0.0       2016-01-29
 mime           0.5         2016-07-07
 munsell        0.4.3       2016-02-13
 plyr           1.8.4       2016-06-08
 R6             2.2.0       2016-10-05
 RColorBrewer   1.1-2       2014-12-07
 Rcpp           0.12.9.1    2017-01-31
 rowr           1.1.3       2016-12-22
 scales         0.4.1.9000  2016-11-21
 shiny          0.14.2.9001 2017-01-09
 stringdist     0.9.4.4     2016-12-16
 testthat     * 1.0.2       2016-04-23
 tibble         1.2-15      2017-01-10
 withr          1.0.2       2016-06-20
 xtable         1.8-2       2016-02-05
 yaml           2.1.14      2016-11-12
 source                                    
 CRAN (R 3.2.5)                            
 CRAN (R 3.3.2)                            
 Github (krlmlr/bindrcpp@0208bd4)          
 CRAN (R 3.2.4)                            
 CRAN (R 3.2.5)                            
 Github (rstudio/crosstalk@6a36da1)        
 CRAN (R 3.3.1)                            
 CRAN (R 3.3.2)                            
 CRAN (R 3.2.4)                            
 Github (hadley/dplyr@03bba6a)             
 Github (timelyportfolio/htmltools@c7e601a)
 local                                     
 CRAN (R 3.2.5)                            
 CRAN (R 3.3.2)                            
 Github (hadley/lazyeval@c155c3d)          
 Github (rstudio/leaflet@cbb3495)          
 local                                     
 CRAN (R 3.3.1)                            
 CRAN (R 3.2.5)                            
 CRAN (R 3.2.4)                            
 CRAN (R 3.3.2)                            
 CRAN (R 3.2.4)                            
 CRAN (R 3.2.5)                            
 CRAN (R 3.3.1)                            
 CRAN (R 3.2.3)                            
 Github (rcppcore/rcpp@d05d9c6)            
 CRAN (R 3.3.2)                            
 Github (hadley/scales@89c2a2f)            
 Github (rstudio/shiny@d836c68)            
 CRAN (R 3.3.3)                            
 CRAN (R 3.2.5)                            
 Github (hadley/tibble@3d6f8b4)            
 CRAN (R 3.2.5)                            
 CRAN (R 3.2.4)                            
 CRAN (R 3.3.2)  

@sckott
Copy link
Contributor

sckott commented Mar 8, 2017

@timelyportfolio please put the review here in a new comment. thanks

@timelyportfolio
Copy link

timelyportfolio commented Mar 8, 2017

linqtypology review

author: "Kenton Russell"
date: "March 8, 2017"

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 4


Review Comments

  1. Very thorough and well-written package with some quite nifty usage of leaflet.

  2. Add Date in DESCRIPTION as suggested in comment

  3. Add a quick example for makelink. Can be as simple as makelink("Adyghe"). Well done adding examples for all documented functions!

  4. Get 100% coverage :) So close, and to get there might be as simple as adding to test-lang-country.R. However, I could easily be mistaken.

    expect_equal(lang.country(list("North Korea", "Lebanon")), c("Korean", "English", "French", "Assyrian Neo-Aramaic",  "Northern Kurdish", "Armenian", "North Levantine Arabic", "Turoyo", "Chaldean Neo-Aramaic", "Standard Arabic", "Pidgin Madam"))
    
  5. Optional, but style code according to a styleguide (does ROpenSci have one?) to make more readable.

@timelyportfolio
Copy link

One other question, what is the difference between languoids and linguoids? Should this be consistent? For instance ?lang.iso versus ?map.feature.

@sckott
Copy link
Contributor

sckott commented Mar 20, 2017

@tzakharko please get your review in, deadline was about 1 week ago

@tzakharko
Copy link

tzakharko commented Mar 21, 2017

Review of package lingtypology


This review is for the lingtypology version 1.02, as available on CRAN at the moment of the review. The review has been jointly carried out by a geographer and a linguist/programmer.

  • As the reviewer we confirm that there are no conflicts of interest for us to review this work (such as being a major contributor to the software).

The package pursues two main goals: on one hand, to offer some basic querying functionality of Glottolog language catalogue, and on the other hand, provide simple CLLD-style interactive mapping functionality leveraging the Leaflet library. In addition to the vanilla Glottolog 2.7 database, the package includes a custom author-edited version of the database (the changes are documented in the package vignette).

The Glottolog querying interface consists of a family of functions specialised in a single task (e.g. a function that maps language names to its genealogical affiliation, a function that maps language ISO-code to language names etc.). We liked the thought the author put into making the names of the functions regular and predictable (they all follow the same RESULT.SOURCE naming schema), even though we are wondering whether this approach can lead to increased namespace pollution as new query functionality is added in the future. A single unified querying function might have been a more elegant solution. A shortcoming of the querying interface is that it only provides one bit of information at a time. If one wants to create a data frame containing, say, both coordinates and the area name, one has to write quite a lot of boilerplate. This also means that the package poorly integrates with existing powerful data transformation tools for R such as dplyr, tidyr and others. Overall, the reviewers feel conflicted about the utility of the querying functionality, as the same can be achieved using a data frame containing Glottolog data with state-of-the-art R tools, with comparable effort and much more flexibility.

We were puzzled by the fact, that the author of the package chose not to expose the languoid codes used by the Glottolog database (glottocodes). What is exposed is language name (which, as noted by the author himself, is often ambiguous) as well as the ISO-code (which have a lot of limitations, furthermore, its not clear which version of ISO is used). This makes it impossible to use the package with many modern typological datasets, which usually include glottocode mappings. Also, it needs mentioning that the way the author uses the term languoid differs from Glottolog's terminology, which can be potentially very confusing to a user. In common linguistic terminology (and explicitly so in Glottolog) languoid refers to any relevant group of linguistic varieties (e.g. dialects, languages, language families and so on). The package, however, appears to restrict this to language level only.

The second important area of functionality of the package is creating interactive maps about languages. Here, the package offers a light wrapper over the Leaflet for R package. This wrapper integrates with the Glottolog database for querying language coordinates, but can be also used separately, with user-provided data. In the package documentation, the author uses both the terms "cartography" and "mapping". At the same time, the package lacks important features associated with full-featured cartographic maps (orientation, projection, etc.). It does not seem possible to visualise continuous or ordered data (ratios, counts etc.). Furthermore, we were not able to find an option to display a Pacific-centered map by default, which is a common task for creating maps in linguistic typology.

In summary, we believe that the strength of the package lies in quick access to Glottolog as well as the ability to quickly create simple maps, which would make it great for teaching and quick illustrations. However, this comes at a great cost of flexibility. In particular, linguists who work with complex databases will most likely find the features of the package to be too limited and are almost always better off using packages such as dplyr and leaflet/ggmap directly.

General recommendations

  • We strongly suggest the author to change the name of the package to better reflect its purpose and functionality. The name lingtypology suggests that the package focuses on general issues in typology. This is clearly not the case.

  • It would make sense to provide better access to the underlaying Glottolog data: expose glottocodes, allow one to query the list of languages present in the database etc. (note: the development version does expose the Glottolog tables, which is great)

  • The author uses the term "languoid" where he actually means "language". The documentation should be modified accordingly.

  • Consider replacing the family of query functions by a unified interface to avoid namespace pollution.

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Additional comments

  • The name makelink() clashes with the standard stats function make.link()
  • makelink() does not do any data validation, creating invalid links for invalid language names without warning
  • Its a bit awkward that the color assignment in map.feature() is random by default. Is there any valid use case for that?
  • The author uses both terms "mapping" and "cartography". This is confusing, especially since the package does not provide any functionality for creating cartographic maps.
  • The package description in DESCRIPTION and README are different. One states that the "Provides [...] some [...] abilities for purposes of linguistic cartography" and another "[...] provides additional functionality for linguistic typology". Both are somewhat misleading.
  • We were unable to locate the contribution guidelines

@tzakharko
Copy link

@sckott @agricolamz Sorry about the delay, we wanted to take a bit more time to write a proper review and also we were two people which meant more coordination effort!

@sckott
Copy link
Contributor

sckott commented Mar 21, 2017

@timelyportfolio and @tzakharko thanks for your reviews!

@tzakharko we'd love to give your other reviewer credit - do they have a github account?

@tzakharko
Copy link

@sckott Sure, its @languageSpaceLabs, sorry for not mentioning it earlier. Thanks!

@sckott
Copy link
Contributor

sckott commented Mar 21, 2017

thanks @tzakharko !

@sckott
Copy link
Contributor

sckott commented Mar 21, 2017

@tzakharko do you have an estimate of how many hrs the review took?

1 similar comment
@sckott
Copy link
Contributor

sckott commented Apr 3, 2017

@tzakharko do you have an estimate of how many hrs the review took?

@sckott
Copy link
Contributor

sckott commented Apr 3, 2017

@agricolamz Both reviews in - let me know if you have any questions

@agricolamz
Copy link
Author

@sckott Thank you. I've made a lot of changes, so I'll write, when all comments from reviews will be satisfied. Now I'm in a fieldwork, so I'll write at the mid of April. Greetings from Daghestan.

@tzakharko
Copy link

tzakharko commented Apr 4, 2017 via email

@sckott
Copy link
Contributor

sckott commented Apr 4, 2017

thanks @tzakharko

@agricolamz
Copy link
Author

agricolamz commented Apr 26, 2017

Dear @sckott, @languageSpaceLabs, @tzakharko and @timelyportfolio!

I've made a lot of changes: most of them are on CRAN, some of them are not.

  1. I decided to keep functions of Result.Source style. That is because for that people who is new to R that functions are more intuitive than core R functions. I even added some more functions of that type (for glottolog codes).
  2. I agree that I can leave users with dataframe (or anything else), so they can make any query by themselves using base R functions or tidyverse. I increased a database and now it contains a lot of information from Glottolog (e. g. information about writing systems, about number of speakers and so on), but I don't think that all that new columns are on every day need for the users. All Glottolog database versions that are used in lingtypology are available for simple search.
  3. I agree that absence of glottocodes in any version of Glottolog database is something strange. So I added them to the databases used in lingtypology. And I added some function for searching using glottocodes.
  4. When I started doing that package I had idea that languoid term let me use one word for language and dialect,but for my today purposes I agree with the reviewers: it can be changed to language. So I changed it everywhere in documentation.
  5. I used "cartography" and "mapping" as synonyms. Now I change all “cartography” to “mapping” in whole documentation.
  6. In the last version (on CRAN) it is possible to visualise continuous or ordered data.
  7. Actually there was an option to create a Pacific-centered maps. But it have not been described anywhere. In the last version I made Pacific-centerd maps as a default one and added the argument that makes Atlantic-centered maps.
  8. The main goal of my package is to create a tool that makes easy to create linguistic maps. I'm agree that for the linguists who work with complex databases it is too limited. Map is really nice visualisation, so there should be a tool that allows you to write one or two lines of code for creating fast linguistic visualisation. I've seen a lot of linguists that don't do this type of visualisation only because of the programming pain. So I'm pretty sure that lingtypology is not only “for teaching and quick illustrations”. It can be used in scientific articles on typology, dialectology and contact linguistics.
  9. Unfortunately I'm not convinced that the name of the package should be changed. The main idea of the package: give me a vector of languages, give me a vector of features and I color them for you! I know that linguistic typology is not about dividing languages into types. I think about typology as a program of the investigation linguistic diversity of the world. In that cases linguistic maps is a really nice way to visualise that diversity.
  10. make.link() is changed to url.lang().
  11. I added validation for url.lang() and for languages (actually, langouids) that have no coordinates. So all created links should be correct and no unmapped language comes silently.
  12. map.feature() coloring is fixed now. And I added more options for coloring (see tutorial).

As a conclusion, I would like to thank my reviewers. I'm really appreciate time that you've spent on my package. I really happy that I learn new nice ideas that I partially implemented.

UPD

  • 100% coverage, as @timelyportfolio wished.
  • added function, that creates density estimation contour.

@sckott
Copy link
Contributor

sckott commented May 4, 2017

Thanks for all the changes @agricolamz

On check i see

* checking R code for possible problems ... NOTE
polygon.points: no visible global function definition forsdUndefined global functions or variables:
  sd
Consider adding
  importFrom("stats", "sd")

goodpractice highlighted the following

── GP lingtypology ─────────────────
It is good practice to

  ✖ omit "Date" in DESCRIPTION. It is not required and it
    gets invalid quite often. A build date will be added to the package
    when you perform `R CMD build` on it.
  ✖ avoid long code lines, it is bad for readability. Also,
    many people prefer editor windows that are about 80 characters
    wide. Try make your lines shorter than 80 characters

    R/aff.lang.R:15:1
    R/aff.lang.R:18:1
    R/aff.lang.R:19:1
    R/area.lang.R:15:1
    R/area.lang.R:18:1
    ... and 129 more lines

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...),
    1:NROW(...) and 1:NCOL(...) expressions. They are error prone and
    result 1:0 if the expression on the right hand side is zero. Use
    seq_len() or seq_along() instead.

    R/polygon.points.R:29:19

  ✖ not import packages as a whole, as this can cause name
    clashes between the imported packages. Instead, import only the
    specific functions you need.
  ✖ fix this R CMD check NOTE: polygon.points: no visible
    global function definition for ‘sd’ Undefined global functions or
    variables: sd Consider adding importFrom("stats", "sd") to your
    NAMESPACE file.
  ✖ fix this R CMD check NOTE: Note: found 132 marked UTF-8
    strings

Please do make changes for the following

  • Remove the Date field in DESCRIPTION
  • namespace your call to sd like stats::sd or add to @importFrom
  • change the 1:length here https://github.com/agricolamz/lingtypology/blob/master/R/polygon.points.R#L29 to probably seq_along
  • do tidy code to 80 width, some of it may have to be done manually, but is worth it as the PDF manual on CRAN won't have text over-running the page and others that have a limited screen can read code more easily

@timelyportfolio @tzakharko no need to look over this more, but if you want to chime in on anything else do so soon

@agricolamz
Copy link
Author

Dear @sckott,

I did all corrections. The only problem is 80 width code. I've made a lot off changes, but there are still a lot of long lines.

@sckott
Copy link
Contributor

sckott commented May 5, 2017

@agricolamz Do get line width down to 80 eventually.

Approved! Thanks very much for your submission. Remaining steps:

  • I've added you to an lingtypology team for the rOpenSci organization, and invited you to our org, you should get a notification. Accept and transfer the repo (under "Settings") to rOpenSci, and then update any links for CI, coverage, and documentation.
  • Let me know if you are interested in doing a blog post about your package on the rOpenSci blog, either long-form / for more general audience (https://ropensci.org/blog/) or short form / more technical (https://ropensci.org/tech-notes/)

@agricolamz
Copy link
Author

agricolamz commented May 6, 2017

Thank you, @sckott!

I've made last changes with commit is "80 character width Procrustean bed".

I transfered lingtypology to ropensci and changed links everywhere, but I have no access to repository settings, so I can't set GithubPages to \docs subfolder, and can't change a link in package website (on the top of repository page). And I'm not sure that appveyor works correctly.

Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?

@sckott
Copy link
Contributor

sckott commented May 6, 2017

Try again now on the repo

looks like that appveyor build worked

closing now as approved, but can still chat here as needed

@sckott sckott closed this as completed May 6, 2017
@agricolamz
Copy link
Author

agricolamz commented May 7, 2017

Should I fork a repository to my github for creating a GitHub page that everybody used to look?

And I asked earlear

Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?

@maelle
Copy link
Member

maelle commented May 7, 2017

@agricolamz for creating a website for your package have a look at pkgdown (although I'm not sure you'll have admin rights to set the Github page source to docs/ yourself? 🤔 )

@agricolamz
Copy link
Author

agricolamz commented May 7, 2017

@maelle I used common html created by vigniette as an GitHub page with an adress https://agricolamz.github.io/lingtypology/. When I transfered the repo to rOpenSci, I did not have such rights (and I couldn't change the repo subtitle and set the Github page), but then @sckott have changed something and I got that rights. So I set the Github page.

The problem is actually about an old page. If I type https://github.com/agricolamz/lingtypology Github automatically redirect me to https://github.com/ropensci/lingtypology. But it doesn't work with Github pages... So the old link is broken. And my question was, should I fork my package back, for setting redirection for that link?

@maelle
Copy link
Member

maelle commented May 7, 2017

Oh I see and sorry I can't help you :-(

@sckott
Copy link
Contributor

sckott commented May 8, 2017

@agricolamz for the redirect problem, yeah, sounds like forking might be a way to fix that

Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?

Sorry missed this. Instructions here for contributing a post https://github.com/ropensci/roweb/blob/master/.github/CONTRIBUTING.md Let me know if you have any questions.

@sckott
Copy link
Contributor

sckott commented May 8, 2017

@agricolamz we'd want to get the post up on May 16th, so get it in day before then at latest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants