Nombre de la Persona Encargada: Marcos Prunello Usuario GitHub de la Persona Encargada: @mpru Repositorio: https://github.com/mpru/karel Versión Enviada: 0.1.1.9000 Tipo de Envio: Estándar Editora: @maurolepore Revisores: @vjimenez9, @joelnitta

Archivo: TBD Versión Aceptada: TBD Idioma: es

Pega el archivo DESCRIPTION completo dentro del siguiente bloque de código.

Package: karel
Title: Learning programming with Karel the robot
Version: 0.1.1.9000
Authors@R: 
    person(given = "Marcos",
           family = "Prunello",
           role = c("aut", "cre", "cph"),
           email = "[email protected]",
           comment = c(ORCID = "0000-0002-9611-527X"))
Description: This is the R implementation of Karel the robot, a programming 
  language created by Dr. R. E. Pattis at Stanford University in 1981. Karel is 
  an useful tool to teach introductory concepts about general programming, such 
  as algorithmic decomposition, conditional statements, loops, etc., in an 
  interactive and fun way, by writing programs to make Karel the robot achieve 
  certain tasks in the world she lives in. Originally based on Pascal, Karel 
  was implemented in many languages through these decades, including 'Java', 'C++', 
  'Ruby' and 'Python'. This is the first package implementing Karel in R.
Depends: R (>= 3.6.0)
Imports:
    purrr,
    dplyr,
    tidyr,
    ggplot2,
    magrittr,
    gganimate,
    cli
License: GPL-2
Encoding: UTF-8
LazyData: true
Language:
  en,
  es
RoxygenNote: 7.2.3
Suggests: 
    testthat (>= 3.0.0),
    knitr,
    rmarkdown
VignetteBuilder: knitr
URL: https://mpru.github.io/karel/
BugReports: https://github.com/mpru/karel/issues/
Config/testthat/edition: 3

Alcance

Por favor, indica qué categoría(s) aplican a este paquete. Las puedes encontrar en nuestras políticas de inclusión de paquetes (Inglés). Por favor, tilda todas las apropiadas. Si no estás seguro, te sugerimos que comiences un pre-envío.
- [ ] recuperación de datos (data retrieval)
- [ ] extracción de datos (data extraction)
- [ ] munging de datos (data munging)
- [ ] disposición o declaración de datos (data deposition)
- [ ] validación y prueba de datos (data validation and testing)
- [ ] automatización de flujos de trabajo (workflow automation)
- [ ] control de versiones (version control)
- [ ] manejo de citas y bibliometría (citation management and bibliometrics)
- [ ] envoltorios de software científico (scientific software wrappers)
- [ ] herramientas para trabajo de campo y reproducibilidad (field and lab reproducibility tools)
- [ ] ligamientos con software de base de datos (database software bindings)
- [ ] datos geoespaciales (geospatial data)
- [ ] análisis de texto (text analysis)
Explica cómo y por qué el paquete encaja dentro de estas categorías (1 a 3 oraciones):

Este paquete no entra en ninguna categoría, ya que está relacionado con Educación. Fue aceptado para el Programa Campeones, bajo la supervisión de @yabellini.
¿Cuál es la audiencia esperada y las aplicaciones científicas de este paquete?

Este paquete es utilizado por docentes para enseñar conceptos introductorios sobre programación, como descomposición algorítmica, declaraciones condicionales, bucles, etc., a estudiantes que posteriormente utilicen R como lenguaje de programación para otras tareas. Ha sido creado con un enfoque multilingüe que actualmente incluye los idiomas español e inglés, pero que puede ser expandido a otros de forma sencilla.
¿Hay otros paquetes de R que logren el mismo objetivo? Si los hay, ¿cómo se diferencian del tuyo, o alcanzan nuestro criterio del mejor de su categoría (documento en Inglés)?

No actualmente, según mi conocimiento.
(Si aplica) ¿Tu paquete cumple con nuestras guías de Ética, Privacidad de Datos e Investigación de Sujetos Humanos (documento en Inglés)?

No aplica.
Si ya has hecho una consulta de pre-envío, por favor pega el enlace al issue correspondiente, una publicación del foro, u otra discusión. Alternativamente, etiqueta al editor (con @tag) con el que te contactaste.

No realicé consulta de pre-envío.
(Si aplica) Explique las razones de los elementos pkgcheck que su paquete no puede pasar.

pkgcheck pasa cuando lo ejecuto localmente. He observado dos advertencias en el CI, pero creo que están relacionadas con pkgcheck y GitHub Actions, y no relacionadas directamente con mi paquete. En cuanto al estilo, obtengo la sugerencia de evitar largas líneas de código. Sin embargo, las únicas líneas de código que superan los 80 caracteres de ancho corresponden a cadenas de texto con mensajes en diferentes idiomas para los usuarios, dentro de las cuales prefiero no incluir saltos de línea.

Revisiones Técnicas

Tilda los siguientes items para confirmar que los has completado:

[x] He leído la guía sobre paquetes de rOpenSci.
[x] He leído la guía para autores y pienso mantener este paquete durante al menos 2 años o encontrar un reemplazo.

Este paquete:

[x] No viola los Términos de Servicio de ningún servicio con los que interactúa.
[x] Tiene una licencia aceptada por CRAN y OSI.
[x] Contiene un archivo README con instrucciones para instalar la versión de desarrollo.
[x] Incluye documentación con ejemplos para todas las funciones, creada con roxygen2.
[x] Contiene una viñeta (vignette) con ejemplos de sus funciones esenciales y su uso.
[x] Tiene una suite de tests (documento en Inglés).
[x] Tiene integración contínua (documento en Inglés), incluyendo reporte de cobertura de tests.

Opciones de Publicación

[x] ¿Tienes intenciones de subir este paquete a CRAN?
[ ] ¿Tienes intenciones de enviar este paquete a Bioconductor?
[ ] ¿Deseas enviar un Artículo de Aplicaciones sobre tu paquete a Methods in Ecology and Evolution (documento en Inglés)? Si es así:

Opciones para MEE

[ ] Este paquete es novedoso y será de interés para la mayoría de lectores de la revista.
[ ] El manuscrito que describe el paquete no tiene más de 3000 palabras y está escrito en Inglés.
[ ] Tienes intenciones de archivar el código del paquete en un repositorio a largo plazo, que cumple los requerimientos de la revista (mira las Políticas de Publicación de MEE (documento en Inglés))
(Alcance: Considera los Objetivos y Alcance de MEE (documento en Inglés) para tu manuscrito. No otorgamos garatías de que tu manuscrito esté en el ámbito de MEE.)
(Aunque no es requerido, recomendamos tener un manuscrito completamente preparado y en Inglés, al momento de enviar.)
(Por favor, no envíes tu paquete de forma separada a Methods in Ecology and Evolution)

Código de Conducta

[x] Estoy de acuerdo en cumplir el Código de Conducta de rOpenSci (documento en Inglés) durante el proceso de revisión, y en mantener mi paquete si éste es aceptado.

Dec 28 '23 14:12 mpru

Thanks for submitting to rOpenSci, our editors and @ropensci-review-bot will reply soon. Type @ropensci-review-bot help for help.

Dec 28 '23 14:12 ropensci-review-bot

:rocket:

Editor check started

:wave:

Dec 28 '23 14:12 ropensci-review-bot

Checks for karel (v0.1.1.9000)

git hash: 4b057e67

:heavy_check_mark: Package is already on CRAN.
:heavy_check_mark: has a 'codemeta.json' file.
:heavy_check_mark: has a 'contributing' file.
:heavy_check_mark: uses 'roxygen2'.
:heavy_check_mark: 'DESCRIPTION' has a URL field.
:heavy_check_mark: 'DESCRIPTION' has a BugReports field.
:heavy_check_mark: Package has at least one HTML vignette
:heavy_check_mark: All functions have examples.
:heavy_check_mark: Package has continuous integration checks.
:heavy_check_mark: Package coverage is 87%.
:heavy_check_mark: R CMD check found no errors.
:heavy_check_mark: R CMD check found no warnings.
:eyes: Function names are duplicated in other packages

(Checks marked with :eyes: may be optionally addressed.)

Package License: GPL-2

1. Package Dependencies

Details of Package Dependency Usage (click to open)

The table below tallies all function calls to all packages ('ncalls'), both internal (r-base + recommended, along with the package itself), and external (imported and suggested packages). 'NA' values indicate packages to which no identified calls to R functions could be found. Note that these results are generated by an automated code-tagging system which may not be entirely accurate.

type	package	ncalls
internal	base	104
internal	karel	44
internal	utils	9
internal	methods	5
internal	stats	3
imports	cli	21
imports	dplyr	10
imports	ggplot2	6
imports	magrittr	6
imports	tidyr	4
imports	purrr	2
imports	gganimate	1
suggests	testthat	NA
suggests	knitr	NA
suggests	rmarkdown	NA
linking_to	NA	NA

Click below for tallies of functions used in each package. Locations of each call within this package may be generated locally by running 's <- pkgstats::pkgstats(<path/to/repo>)', and examining the 'external_calls' table.

base

c (33), message (22), call (17), paste (10), for (4), all (3), list (3), nrow (2), apply (1), array (1), dim (1), emptyenv (1), if (1), integer (1), new.env (1), numeric (1), seq_len (1), which (1)

karel

beepers_present (3), get_beepers_df_row (2), get_pkg_env (2), load_super_karel (2), move (2), right_is_clear (2), turn_around (2), avanzar (1), cargar_super_karel (1), check_user_world (1), check_walls (1), conseguir_amb (1), create_beepers (1), darse_vuelta (1), derecha_abierto (1), draw_karel_df (1), facing_east (1), facing_north (1), facing_south (1), facing_west (1), front_is_blocked (1), front_is_clear (1), generate_world (1), karel_has_beepers (1), karel_has_no_beepers (1), left_is_blocked (1), left_is_clear (1), no_beepers_present (1), pick_beeper (1), plot_static_world (1), put_beeper (1), put_hor_walls (1), right_is_blocked (1), run_actions (1), turn_left (1), turn_right (1)

cli

cli_abort (21)

dplyr

n (4), tibble (3), filter (2), case_when (1)

utils

de (7), data (2)

ggplot2

geom_point (2), scale_x_continuous (2), scale_y_continuous (2)

magrittr

%>% (6)

methods

el (5)

tidyr

expand_grid (4)

stats

time (3)

purrr

pmap_dfr (2)

gganimate

gifski_renderer (1)

2. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

code in R (100% in 9 files) and
1 authors
12 vignettes
no internal data file
7 imported packages
63 exported functions (median 1 lines of code)
111 non-exported functions in R (median 3 lines of code)

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages The following terminology is used:

loc = "Lines of Code"
fn = "function"
exp/not_exp = exported / not exported

All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the checks_to_markdown() function

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure	value	percentile	noteworthy
files_R	9	55.2
files_vignettes	12	99.6
files_tests	5	81.7
loc_R	912	65.7
loc_vignettes	1844	96.8	TRUE
loc_tests	310	64.9
num_vignettes	12	99.9	TRUE
n_fns_r	174	87.6
n_fns_r_exported	63	91.0
n_fns_r_not_exported	111	85.7
n_fns_per_file_r	10	86.7
num_params_per_fn	2	11.9
loc_per_fn_r	1	0.0	TRUE
loc_per_fn_r_exp	1	0.0	TRUE
loc_per_fn_r_not_exp	3	1.5	TRUE
rel_whitespace_R	21	69.7
rel_whitespace_vignettes	38	98.6	TRUE
rel_whitespace_tests	17	57.6
doclines_per_fn_exp	66	77.1
doclines_per_fn_not_exp	0	0.0	TRUE
fn_call_network_size	66	71.8

2a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package

3. `goodpractice` and other checks

Details of goodpractice checks (click to open)

3a. Continuous Integration Badges

GitHub Workflow Results

id	name	conclusion	sha	run_number	date
7347999524	pages build and deployment	success	1367b6	20	2023-12-28
7347980615	pkgcheck	success	4b057e	13	2023-12-28
7347980611	pkgdown	success	4b057e	23	2023-12-28
7347980603	R-CMD-check	success	4b057e	5	2023-12-28

3b. `goodpractice` results

`R CMD check` with rcmdcheck

rcmdcheck found no errors, warnings, or notes

Test coverage with covr

Package coverage: 87.04

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function	cyclocomplexity
check_user_world	28
check_walls	16

Static code analyses with lintr

lintr found the following 53 potential issues:

message	number of times
Avoid library() and require() calls in packages	4
Lines should not be more than 80 characters.	45
unexpected symbol	4

4. Other Checks

Details of other checks (click to open)

:heavy_multiplication_x: The following function name is duplicated in other packages:

- move from BacArena, chess, cubing, red, rugarch, seqinr, SpaDES.tools

Package Versions

package	version
pkgstats	0.1.3.9
pkgcheck	0.1.2.11

Editor-in-Chief Instructions:

This package is in top shape and may be passed on to a handling editor

Dec 28 '23 16:12 ropensci-review-bot

@mpru Thank you for the submission. I am working on finding a handling editor.

Jan 02 '24 19:01 jhollist

@ropensci-review-bot assign @maurolepore as editor

Jan 03 '24 13:01 maurolepore

Assigned! @maurolepore is now the editor

Jan 03 '24 13:01 ropensci-review-bot

@mpru, es un placer editar tu paquete.

Pronto empezaré a trabajar en la lista de verificación.

Mientras tanto:

[x] ¿Confirmas que la revisión debe ser en Castellano?
[ ] Por favor, sugiere 3 revisores/as. En rOpenSci, generalmente convocamos a no más de 1 de las personas sugeridas, pero utilizamos el resto para comprender mejor el perfil que crees que añadiría valor a tu paquete. Por favor evita conflictos de interés.

Jan 03 '24 13:01 maurolepore

@mpru, perdón por la confusión.

Dado que el paquete es multilingüe, el equipo editorial considera que la mejor opción es nominar un/a revisor/a en español y otro/a en inglés.

Jan 03 '24 15:01 maurolepore

Hola, @maurolepore, gracias por involucrarte en este envío. Ambos idiomas están bien para mí y me parece genial la idea del equipo editorial. No estoy familiarizado con los nombres de la lista de revisores como para nominar candidatos. ¿Tal vez vos puedas ayudarme con eso?

Jan 06 '24 20:01 mpru

@mpru,

Seguro ayudo con eso. Nuestra guia ofrece varias ideas sobre donde buscar revisore/as:

https://devdevguide.netlify.app/es/softwarereview_editor.es#where-to-look-for-reviewers

Yo usare esa misma guia pero en rOpenSci nos interesa tu opinion.

Cuando encuentres algun/a candidato/a por favor consiera evitar conflictos de interes.

Jan 07 '24 19:01 maurolepore

Dear @mpru,thanks for your work. Editor checks were super smooth.

You'll see some comments that require your attention. They are labeled ml01, ml02, and so on. The one(s) starting with a checkbox are required. The one(s) starting with a bullet are just for your consideration.

Editor checks:

[x] Documentation: The package has sufficient documentation available online (README, pkgdown docs) to allow for an assessment of functionality and scope without installing the package. In particular,
- [x] Is the case for the package well made?
- [x] Is the reference index page clear (grouped by topic if necessary)?
- [x] Are vignettes readable, sufficiently detailed and not just perfunctory?
[x] Fit: The package meets criteria for fit and overlap.
[x] Installation instructions: Are installation instructions clear enough for human users?
[ ] Tests: If the package has some interactivity / HTTP / plot production etc. are the tests using state-of-the-art tooling?
[x] Contributing information: Is the documentation for contribution clear enough e.g. tokens for tests, playgrounds?
[x] License: The package has a CRAN or OSI accepted license.
[x] Project management: Are the issue and PR trackers in a good shape, e.g. are there outstanding bugs, is it clear when feature requests are meant to be tackled?

Editor comments

FIT

rOpenSci accepts this package as part of the Champions program.

VIGNETTES

ml01. In the article "Getting started" consider removing "new" so that this sentence is still valid many years from now:

karel is a new R package ...

TESTS

[ ] ml02. Please explain if and how the package tests interactivity.

ml03. I see few general tests. Consider spliting them in to more, smaller, specific tests so that it's easier to detect the problem when a test fails.

A search for "test_that(" shows that the test titles seem too general -- https://github.com/search?q=repo%3Ampru%2Fkarel%20test_that(&type=code

And I see many expectations per tests, e.g.:

https://github.com/mpru/karel/blob/master/tests/testthat/test-actions.R

You want to arrange things such that, when a test fails, you’ll know what’s wrong and where in your code to look for the problem. This motivates all our recommendations regarding file organisation, file naming, and the test description. Finally, try to avoid putting too many expectations in one test - it’s better to have more smaller tests than fewer larger tests.

-- https://r-pkgs.org/testing-basics.html#test-organisation

ml04. I see the expected error is not specific.

Usually you care about two things when testing an error:

Does the code fail? Specifically, does it fail for the right reason?

Does the accompanying message make sense to the human who needs to deal with the error?

-- https://r-pkgs.org/testing-basics.html#expectations

ml05. "Your test files should not include these library() calls." -- https://r-pkgs.org/testing-basics.html#test-organisation

For example see https://github.com/search?q=path%3Atests%2Ftestthat+repo%3Ampru%2Fkarel+library%28karel%29&type=code

Jan 07 '24 21:01 maurolepore

Thanks Mauro! I already started working in your comments, I'm reviewing and changing my unit tests. I'll suggest reviewers as well.

Jan 13 '24 12:01 mpru

@ropensci-review-bot seeking reviewers

Jan 17 '24 01:01 maurolepore

Please add this badge to the README of your package repository:

[![Status at rOpenSci Software Peer Review](https://badges.ropensci.org/620_status.svg)](https://github.com/ropensci/software-review/issues/620)

Furthermore, if your package does not have a NEWS.md file yet, please create one to capture the changes made during the review process. See https://devguide.ropensci.org/releasing.html#news

Jan 17 '24 01:01 ropensci-review-bot

Hi @maurolepore. I'm sorry I couldn't do it sooner but I wanted to let you know that I worked on your comments and think it might be ready to give it another try.

Vignettes

The "Getting started" article was updated with your suggestion.

Tests

Unit tests were rewritten to make them more specific:
- I think it's easier now to detect the problem when a test fails, as the titles are more descriptive of what is being evaluated. Large tests with lots of expectations were replaced by smaller ones.
- Most of the test files were separated, creating a version for each implemented language. It is important to evaluate the external functions available in each language, to ensure that they are calling the correct internal functions.
Unit tests based on the vdiffr package were added to test for interactivity with snapshots:
- Before your comment, the package did not test interactivity or use any state-of-the-art tooling for something like that. Following your observation, I added test units that are based on the vdiffr package, which allows monitoring the appearance of graphics by generating SVG files and saving them as testthat snapshots.
- When a person using this package writes code to make Karel solve a problem, the result will be, provided everything goes well, a gif that shows Karel executing the programmed actions. The gif is created internally with gganimate from many ggplot2 plots. The package offers a function to access any of these graphs (plot_static_world), which I use to create examples and statements for new exercises, as well for debugging (it's not ment for students). The new units for testing interactivity execute pieces of code (simple or long) for Karel to solve various problems (taken from tutorials on the web) and use plot_static_world() to capture the graph that shows what Karel's world should be like at the end of each process. If the package works correctly and nothing has broken, these tests should indicate agreement between the captured image and the snapshot saved as reference. These tests are located in the file test-snapshots.R
Removed the library() calls in the tests files.

Others

Upgraded the version number from 0.1.1.9000 to 0.1.1.9001 (not sure if this is ok).
Added the rOpenSci badge required by the bot to the README file.
The NEWS file was modified to comply with rOpenSci suggestiones.
A wrong error message was discovered while writing new unit tests and was fixed.

Suggested reviewers

I saw that Maëlle Salmon was recently working on a package called babelquarto to create multilingual websites or books (like the one in the new version of the rOpenSci developer guide). Johannes Ranke and Joel Nitta appear as contributors in the babelquarto repo. Maybe one of these three people could be?
I also thought that we could call on the person who was my mentor during the Champions program, who already knows the project, Lukas Walrich, although I don't know if that could imply a conflict of interest.
Following the suggestion of searching among authors of rOpenSci packages is not easy since this submission does not fall into any of the categories (an exception has been made within the framework of the Champions program).
I didn't understand how to use Airtable to search for potential reviewers, could it be that the general public doesn't have access to the database and only editors?

That's all for now, thanks.

Feb 15 '24 07:02 mpru

@mpru thanks a lot for this! It will make the reviewers's job easier.

Upgraded the version number from 0.1.1.9000 to 0.1.1.9001 (not sure if this is ok).

I think it's OK. That's the kind of increment I see with fledge::bum_version() in my own packages.

I didn't understand how to use Airtable to search for potential reviewers, could it be that the general public doesn't have access to the database and only editors?

I think you're right, and Airtable is only useful to editors with the right access permission.

I'll resume the search for reviewers.

Feb 15 '24 20:02 maurolepore

@ropensci-review-bot assign @vjimenez9 as reviewer

Feb 22 '24 23:02 maurolepore

@vjimenez9 added to the reviewers list. Review due date is 2024-03-14. Thanks @vjimenez9 for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

Feb 22 '24 23:02 ropensci-review-bot

@vjimenez9: If you haven't done so, please fill this form for us to update our reviewers records.

Feb 22 '24 23:02 ropensci-review-bot

@vjimenez9, dado que el paquete es multilingüe, el equipo editorial considera que la mejor opción es nominar un/a revisor/a en español y otro/a en inglés. Podias revisarlo en español?

Feb 22 '24 23:02 maurolepore

@ropensci-review-bot assign @joelnitta as reviewer

Mar 03 '24 23:03 maurolepore

@joelnitta added to the reviewers list. Review due date is 2024-03-24. Thanks @joelnitta for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

Mar 03 '24 23:03 ropensci-review-bot

@joelnitta: If you haven't done so, please fill this form for us to update our reviewers records.

Mar 03 '24 23:03 ropensci-review-bot

:calendar: @vjimenez9 you have 2 days left before the due date for your review (2024-03-14).

Mar 12 '24 23:03 ropensci-review-bot

Hi!

Hoy es el ultimo dia de revisión que tengo. Ya prácticamente revisé todo el paquete y tengo mis comentarios y anotación...Entiendo que los agrego al documento PlatillaDeRevisionROpenSci.md. y subo este documento acá. Cierto? Espero terminar esto en el transcurso de la tarde, pero espero que no haya mucho problema si concluyo mañana por la mañana, porque mi Mac me esta dando problemas con la subida de archivos a github

Mar 14 '24 19:03 vjimenez9

Aqui el resultado de mi revisión:

PlatillaDeRevisionROpenSci.md

Revisión de un paquete

Por favor trata de marcar tantas casillas como te sea posible y elabora tus argumentos en comentarios abajo de cada una. Tu revisión no esta limitada a estos temas, tal como se describe en la guia para revisores (Reviewer Guide)

Por favor describe cualquier relación de trabajo que tengas/hayas tenido con los autores del paquete)

[X] Como revisor confirmo que no tengo conflictos de interés para poder hacer la revisión de este trabajo (si no estas segura si tienes un conflicto por favor entra en contacto con tu editor antes de arrancar con la revisión.

Documentación

El paquete incluye todos los siguiente tipos de documentación:

[X] Una declaración de necesidades que claramente describe las necesidades que el software esta diseñado a resolver y el public meta que busca atender en el archivo README
[ ] Instrucciones de instalación de la versión en desarrollo del paquete incluyendo cualquier dependencia no-estándar en el archivo README Nota: En README no se especifica que no es posible instalarlo en Ubuntu, tampoco que se requiere tener instalado RUST
[X] Viñeta(s) demostrando la funcionalidad principal que ademas corren localmente
[X] Documentación de las funciones exportadas Nota: Seria muy util que en la documentación se describa cada uno de los parametros de generar_mundo en lugar de solo listarlos. Hay que revisar porque no todas las funciones tienen ayuda (por ejemplo invertir)
[X] Ejemplos (que corren localmente) para todas las funciones exportadas
[X] Directrices comunitarias incluyendo una guia de contribución en el archivo README o el archivo CONTRIBUTING y un archivo DESCRIPTION que incluye URL, BugReports and Maintainer (todas en inglés por concenvión y para que puedan ser autogeneradas con Authors@R). Nota: No encontre BugReport, ni Maintener

Funcionalidad

[X] Instalación: La instalación se completa con éxito tal como fue documentada. En realidad, inicie la instalación en ubuntu, pero me marco que el paquete no estaba disponible para esa versión de R, buscando un poco mas, me tope que era el SO
[X] Funcionalidad: Toda afirmación de funcionalidad del software se confirma como existente.
[X] Desempeño: Toda afirmación de desempeño del software se confirma como alcanzada.
[X] Pruebas automáticas: Hay pruebas unitarias que cubren las funciones esenciales dentro del paquete con un rango razonable de entradas y condiciones. Todas las pruebas corren en la maquina local.
[ ] Directrices de empaque: El paquete cumple con las directrices de empaque de rOpenSci.

Estimación de horas dedicadas a la revisión: 6 horas.

[X] Si la o las persona(s) autora(s) lo considera(n) apropiado, yo estoy de acuerdo con que me reconozcan como revisor del paquete (el rol "rev') en la el archivo DESCRIPTION del paquete.

Comentarios de la revisión

¿El código cumple con los principios generales de la guía de revisión de Mozilla? No me queda claro si hubo alguna revisión por pares, o como dice la guia es un Flying Solo. Por otro lado me parece que la meta es clara y se cumple.
¿El paquete cumple con la guía de embalaje rOpenSci? en general si
¿Se podrían realizar mejoras en el estilo del código?
¿Hay duplicación de código en el paquete que debería reducirse? No necesariamente se duplica, pero hay lugares donde se puede obtimizar. Por ejemplo donde se dibuja a Karel, se pueden definir un grupo de vectores que se asignen al tible en función de la dirección, en lugar de crear los 4 tibles por separado.
Tambien cuando se hacen los chequeos ...se podria genear una función a la que se llama multiples veces con el objeto a checar... etc.
¿Se podrían realizar mejoras en la interfaz de usuario?
¿Se podrían realizar mejoras de rendimiento?
¿La documentación (instrucciones de instalación/viñetas/ejemplos/demostraciones) es clara y suficiente? ¿Utiliza el principio de múltiples puntos de entrada, es decir, tiene en cuenta el hecho de que cualquier documento puede ser el primer encuentro que el usuario tiene con el paquete y/o la herramienta/datos que incluye?
¿Se nombraron funciones y argumentos para trabajar juntos para formar una API de programación lógica común que sea fácil de leer y autocompletar? si
Si tiene sus propios datos/problemas relevantes, resuélvalos con el paquete. Es posible que encuentre aspectos difíciles y casos de uso en los que el autor no pensó. Me parece que no aplica

Mis notas:

Empece haciendo la instalación en una computadora con SO Ubuntu y me marcó

Warning in install.packages :
  package ‘Karel’ is not available for this version of R

Averigundo un poco, encontré que No hay una versión para ubuntu. Sería util que lo dijeran desde el README.

Luego hice la instalación en una macOS. Les dejo aqui los detalles de los inconvenientes que tuve para realizar la istalación (Solo con fines informativos):

> install.packages("karel")
also installing the dependencies ‘scales’, ‘lpSolve’, ‘ggplot2’, ‘transformr’, ‘tweenr’, ‘gganimate’, ‘gifski’

Warning in install.packages :
  lzma decoder corrupt dataY

Solución: descargar los compilables...

ejecutar_acciones()
ℹ The package "gifski" is required to use the `gifski_renderer`
✖ Would you like to install it?

Me indica que no esta instalado un compilador...y me pide instalar rust...¿Porque ? Bueno pues instalo rust:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Al volver intentar me dice:

Error in loadNamespace(x) : there is no package called ‘gifski’

Vuelvo a instalar el paquete, y me dice:

There is a binary version available but
  the source version is later:
        binary   source needs_compilation
gifski 1.6.6-1 1.12.0-2              TRUE

Do you want to install from sources the package which needs compilation? (Yes/no/cancel)

Durante 3 ocasiones le dije si y me volvía a marcar que la instalación se daba con errores, la ultima vez, le dije que no compilara...Y jalo!! jejeje.

Del texto :

En general es muy bonito "el karel" .

Tengo algunas sugerencias de modificación en el texto, que son eso "sugerencias" o comentarios de mi punto de vista. Siempre en el afan de mejorar o hacer mas claro el texto.

====Del texto:

Dice: Desafortunadamente, las computadoras no entienden español ni otro idioma humano. Hay que pasarles las instrucciones en un lenguaje que sean capaces de entender. Para eso debemos aprender algún lenguaje de programación, Comentario: Pero...los lenguajes de programación están escritos en su mayoría en idioma ingles, hay algunos incluso en español...que son idiomas humanos, creo que el problema no es el idioma sino la sintaxis del idioma.

Dice: Ahora bien, ¿por qué debemos estudiar programación en si nos dedicamos a la Estadística? La actividad de los profesionales estadísticos está atravesada en su totalidad por la necesidad de manejar con soltura herramientas informáticas que nos asisten en las distintas etapas de nuestra labor, desde la recolección y depuración de conjuntos de datos, pasando por la aplicación de distintas metodologías de análisis, hasta la comunicación efectiva de los resultados. Comentario: Me parece que no todo el mundo al que va dirigido este paquete es del area de estadística...O aunque aplique estadística se identifica como analista de datos o científicos de datos...¿No sería mas conveniente remplazar la pregunta por: ¿Porqué debemos aprender a programar cuando queremos analizar datos, generar estadísticas, gráficas y conclusiones? La actividad de los profesionales estadísticos, de ciencia de Datos, o cualquier persona que requiera hacer análisis de datos se potencia con el manejo de herramientas bioinformáticas y capacidades de programación que nos asisten...

Dice: en este tutorial estudiaremos los conceptos básicos de esta disciplina

Sugerencia: en este tutorial estudiaremos los conceptos básicos de los lenguajes de programación.

Dice: El lengua de programación en el que se basa ... Debe decir: El lenguaje de programación en el que se basa ...

Dice: que viene bien tener presentea.

Debe decir: que viene bien tener presente.

Dice: En programación, el lenguaje artificial e informal

Comentario:

No estoy tan de acuerdo que el pseudocodigo sea un "lenguaje artificial e informal".

Dice: El programa se guarda en un archivo con un nombre generalmente dividido en dos partes por un punto, por ejemplo: mi_primer_programa.R. La primera parte es la raíz del nombre con la cual podemos describir el contenido del archivo. La segunda parte es indicativa del uso del archivo, por ejemplo, .R indica que contiene un programa escrito en el lenguaje R. El proceso general de ingresar o modificar el contenido de un archivo se denomina edición.

Sugerencia: La codificación del programa se guarda en un archivo de texto plano con un identificador generalmente dividido en dos partes por un punto, por ejemplo: mi_primer_programa.R. La primera parte es el nombre del archivo. La segunda parte es indicativa del lenguaje que puede interpretar las instrucciones, por ejemplo, .R indica que contiene un programa escrito en el lenguaje R. El proceso general de escribir o modificar las instrucciones en un archivo se denomina edición.

En la sección de los errores creo que sería util hablar de que hay dos tipos de errores: los lógicos y los sintácticos. Estos últimos tienen que ver cuándo las instrucciones, o nombres de variables no son correctamente escritos y el programa no puede "interpretarlos". Los errores lógicos, se generan con instrucciones que el programa puede interpretar, pero que realizan cosas que no queremos.

Estoy de acuerdo que el procesador es el lenguaje que "procesa, interpreta y ejecuta" las instrucciones....Pero la frase "Todos los elementos disponibles para ser utilizados por el procesador constituyen su entorno o ambiente." Yo digo que no son elementos disponibles para el procesador, son elementos disponibles para el programador.

En la sección, organización de RStudio:

Me parece que hay que tener cuidado con decir que el editor es "un Word muy simple", puede sugerir erróneamente que se puede usar word para editar un archivo, cosa que es completamente errónea. Necesitamos un poderoso editor de texto plano como lo proporciona RStudio que puede hacer muchísimas cosas que un "simple word" no puede hacer durante la creación de un archivo de programación.

Dice: Abajo está la consola. Es la ventana que se comunica con R

Comentario: La consola es el ambiente interactivo entre R y el usuario.

Dice: Environment (ambiente): muestra todos los elementos que componen al ambiente o entorno.

Sugerencia: Environment (ambiente): muestra todos objetos generados en la sesión presente

Dice: History (historial): lista todas las instrucciones que R ha corrido anteriormente.

Sugerencia: History (historial): lista todas las instrucciones que el usuario ha ejecutado.

(Porque en los sistemas mutiusuario no vez todo lo que ha ejecuta R, solo lo que tu usuario ha ejecutado)

Dice: Packages: listado de los “paquetes” que tenemos instalados (ver más adelante). Debe decir: Packages: Herramienta de instalación, actualización y carga de los paquetes de R.

Tu ejemplo de la consola me confunde un poco:

1 + 2
#> [1] 3
5 * 3
#> [1] 15
exp(2)

¿No debería la instrucción ir después del prompt ">". Y justo la respuesta de R ir sin prompt? O ¿que es #> ? En todo caso, describe al usuario cual es el prompt del sistema que esta en espera de una instrucción y con cual prompt (si existe) , R te muestra los resultados

En la sección conociendo a karel

La función generar_mundo tiene un argumento "mundo001". Podrias aprovechar este hecho para introducir el concepto de "argumento", y porque los paréntesis vacíos a veces es la ausencia de argumentos o la existencia de argumentos definidos por default.

Descomposición algorítmica

Este es un tema muy importante y muy complejo, pero en el flujo de tu documentación siento un salto cuántico importante. Pasan de 0 a 100 en un solo acelerón...Pero no tengo una propuesta concreta de como "deshacelerar"

En esta sección también varias aseveraciones que me parecen desafortunadas. Por poner solo un ejemplo (hay varios) : Dice Es importante notar que, para que podamos usar la función girar_izquierda(), la misma tiene que ser definida y evaluada por R antes de que hagamos uso de la misma para resolver nuestro problema:

Comentario:

Yo creo en este caso, la función no es definida por R, es definida por el usuario, y esta definición debe estar "antes" de ser invocada en un programa de R.

Documentación de los subalgoritmos

En el propio texto indicas la importancia de documentar, para que se usa tu función y en el ejemplo nunca se especifica para qué sirve.

Nunca se indico qué significan los # al inicio de la linea y sería muy util para los usuarios, así que se puede aprovechar esta sección agregando un comentario que explica que la documentación se introduce como "comentarios" que son antecedidos por #

Podrías poner al menos una liga con lineamientos para la documentación de funciones (por ejemplo: https://combine-australia.github.io/r-pkg-dev/documenting-functions.html). O cualquier otra

Estructuras condicionales simples

Dice: se procede a ejecutar las acciones encerradas por esta estructura.

Sugiero que diga: se procede a ejecutar las acciones delimitadas entre las {} que definen el cuerpo de esta estructura.

Dice: Si la condición no se verifica,

Debe decir: Si la condición es falsa

Comentario: siempre se verifica, y esta verificación a veces arroja verdadero a veces falso. Pero veo que a lo largo del texto se usa muchas veces "verificar" como sinónimo de la evaluación verdadera, entonces, quizá solo al inicio, indicar esta "interpretación" de la palabra verificar. Algo así como: "Decimos que un enunciado se verifica, cuando su evaluación lógica es verdadera"

Dice: Mantener la prolijidad en nuestros programas es esencial. Sugiero que diga: Mantener la claridad en nuestros programas es esencial.

Dice: La letra i recibe el nombre de variable de iteración

Comentario: No hemos definido que es una variable. Mi sugerencia es incluir desde la primera o segunda seccion

Dice: El bloque de instrucciones se repite tantas veces como i tarde en llegar a 5 partiendo desde 1.

Sugerencia: El bloque de instrucciones se repite tantas veces como i tarde en llegar a 5 partiendo desde 1, esto se define con un rango de valores en R usando la nomenclatura 1:5.

Dice:

for (<variable> in <valor1>:<valor2>) {
    ...Acción/es...
}

Sugerencia:

for (<variable> in <valorInicial>:<valorFinal>) {
    ...Acción/es...
}

Mar 15 '24 19:03 vjimenez9

@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/620#issuecomment-2000346572 time 6

Mar 15 '24 21:03 maurolepore

Logged review for vjimenez9 (hours: 6)

Mar 15 '24 21:03 ropensci-review-bot

Muchas gracias @vjimenez9

Edite tu comentario para mostrar tu revision directamente aca. Es la forma mas habitual. Perdon que me olvide de aclararlo.

Mar 15 '24 21:03 maurolepore

:calendar: @joelnitta you have 2 days left before the due date for your review (2024-03-24).

Mar 22 '24 23:03 ropensci-review-bot

software-review
software-review copied to clipboard

Aprendiendo programación en R con la robot Karel

Archivo: TBD Versión Aceptada: TBD Idioma: es

Alcance

Revisiones Técnicas

Opciones de Publicación

Código de Conducta

Checks for karel (v0.1.1.9000)

1. Package Dependencies

2. Statistical Properties

2a. Network visualisation

3. `goodpractice` and other checks

3a. Continuous Integration Badges

3b. `goodpractice` results

`R CMD check` with rcmdcheck

Test coverage with covr

Cyclocomplexity with cyclocomp

Static code analyses with lintr

4. Other Checks

Editor-in-Chief Instructions:

Editor checks:

Editor comments

Revisión de un paquete

Documentación

Funcionalidad

Comentarios de la revisión

En la sección, organización de RStudio:

En la sección conociendo a karel

Descomposición algorítmica

Documentación de los subalgoritmos

Estructuras condicionales simples

software-review software-review copied to clipboard

Aprendiendo programación en R con la robot Karel

Archivo: TBD Versión Aceptada: TBD Idioma: es

Alcance

Revisiones Técnicas

Opciones de Publicación

Código de Conducta

Checks for karel (v0.1.1.9000)

1. Package Dependencies

2. Statistical Properties

2a. Network visualisation

3. goodpractice and other checks

3a. Continuous Integration Badges

3b. goodpractice results

R CMD check with rcmdcheck

Test coverage with covr

Cyclocomplexity with cyclocomp

Static code analyses with lintr

4. Other Checks

Editor-in-Chief Instructions:

Editor checks:

Editor comments

Revisión de un paquete

Documentación

Funcionalidad

Comentarios de la revisión

En la sección, organización de RStudio:

En la sección conociendo a karel

Descomposición algorítmica

Documentación de los subalgoritmos

Estructuras condicionales simples

software-review
software-review copied to clipboard

3. `goodpractice` and other checks

3b. `goodpractice` results

`R CMD check` with rcmdcheck