search

RLesur / crrri

A Chrome Remote Interface written in R
https://rlesur.github.io/crrri/
Other
157 stars 12 forks source link

Implement a verbose option #10

Closed RLesur closed 6 years ago

RLesur commented 6 years ago

In the current version, a lot of messages are written to the log. It could be annoying for higher level development. We have to implement a verbose option.

cderv commented 6 years ago

Are the messages only for debug purposes for the developers ?

If so, I could be interesting to use debugme. It is very powerful and easy to use. As we are on a low level api, could be enough.

Otherwise, I think a global option getOption("crrri.verbose") could be a good idea to enable / disable at a session level. I think this is better than a verbose argument in functions. If we want a user to have messages, we can also work on the returned value in console with cli like recent tidyverse tool.

We can also do both, according the message nature (toward developers or users).

What do you think ?

RLesur commented 6 years ago

I didn't know debugme. This is awesome! There are two kinds of messages here: messages sent during connexion/deconnexion (mainly for crrri debugging) and messages tracking the exchanges between the R websocket client and the remote websocket server. These lasts are essential for R devs when they will develop higher levels packages: during the development process and for debugging their packages. I think that debugme could cover the entire needs.

cderv commented 6 years ago

Ok I'll go with debugme then. But not sure it will offer the customising cli message that we have with usethis for example, or testthat. We'll see. 😄

cderv commented 6 years ago

Just a wild thought: Do you already have a script to test error message ? When it fails or succeed ?

cderv commented 6 years ago

There is the chrome command that is remaining as message because of echo_cmd=TRUE in processx::process$new.

Should we make this optional or always print the command ? Do you think it is this still required even for development ?

RLesur commented 6 years ago

Just a wild thought: Do you already have a script to test error message ? When it fails or succeed ?

No, I haven't.

There is the chrome command that is remaining as message because of echo_cmd=TRUE in processx::process$new.

Should we make this optional or always print the command ? Do you think it is this still required even for development ?

I found it useful when I developed the connexion functions (in order to compare behaviours depending on proxy, os...). I don't know whether anyone needs this.