suppress screen messages in R
I am trying to include R modules in Galaxy. A few of the things I encounter: a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user. b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops! (this happened with function image() when making pdf of array images) In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage. How to go around this? And I think, the galaxy team will probably have to answer this one.
Hi, I'm relatively new to Galaxy, but I believe that this is one of the major reasons people use tool wrappers. The wrappers, usually written in Python, capture the standard error output stream and redirect it to a related file. The current Galaxy behavior is that anything written to stderr is interpreted as an error. I've seen a comment on this list a few days ago that the G-team realizes that they should move away from this and use the tool's exit status; however, that is for some future version. For now, wrappers are the way to go. Regards, -Al -----Original Message----- From: galaxy-dev-bounces@lists.bx.psu.edu [mailto:galaxy-dev-bounces@lists.bx.psu.edu] On Behalf Of Freddy Sent: Wednesday, October 27, 2010 9:14 AM To: galaxy-dev@lists.bx.psu.edu Subject: [galaxy-dev] suppress screen messages in R I am trying to include R modules in Galaxy. A few of the things I encounter: a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user. b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops! (this happened with function image() when making pdf of array images) In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage. How to go around this? And I think, the galaxy team will probably have to answer this one. _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Al Simons wrote:
Hi,
I'm relatively new to Galaxy, but I believe that this is one of the major reasons people use tool wrappers. The wrappers, usually written in Python, capture the standard error output stream and redirect it to a related file.
The current Galaxy behavior is that anything written to stderr is interpreted as an error. I've seen a comment on this list a few days ago that the G-team realizes that they should move away from this and use the tool's exit status; however, that is for some future version. For now, wrappers are the way to go.
To clarify, we settled on checking stderr because it was determined that many tools did not set a non-zero exit code upon error, and thus relying on the exit code was not a reliable way to detect failure. The simplest workaround for tools which do set exit codes and write unsuppressable warnings or info to stderr is to wrap them and capture their stderr and return code. If the code is 0, do not display stderr or print info/warnings to stdout. If the code is non-zero, print something (including the captured stderr) to stderr. The proposed change to this behavior is to allow the tool author to decide whether Galaxy should consider the return code, the stderr, or both in determining failure. An issue exists for it in our tracker here: http://bitbucket.org/galaxy/galaxy-central/issue/325/ Freddy, if you have a look at the R tools we've included in the distribution, you'll see that many of them suppress warnings for this very reason.
Regards, -Al
-----Original Message----- From: galaxy-dev-bounces@lists.bx.psu.edu [mailto:galaxy-dev-bounces@lists.bx.psu.edu] On Behalf Of Freddy Sent: Wednesday, October 27, 2010 9:14 AM To: galaxy-dev@lists.bx.psu.edu Subject: [galaxy-dev] suppress screen messages in R
I am trying to include R modules in Galaxy.
A few of the things I encounter:
a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user.
b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops!
(this happened with function image() when making pdf of array images)
In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage.
How to go around this?
And I think, the galaxy team will probably have to answer this one.
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Oct 27, 2010, at 9:19 AM, Al Simons wrote:
I've seen a comment on this list a few days ago that the G-team realizes that they should move away from this and use the tool's exit status; however, that is for some future version.
To be clear, we want to make this an option. So few programs set exit status properly which is why we did not do it that way by default.
On Wed, Oct 27, 2010 at 2:14 PM, Freddy <freddy.debree@wur.nl> wrote:
I am trying to include R modules in Galaxy.
A few of the things I encounter:
a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user.
b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops!
(this happened with function image() when making pdf of array images)
In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage.
How to go around this?
And I think, the galaxy team will probably have to answer this one.
Hi Freddy, Currently Galaxy treats and output to stderr as an error (even though it is conventional to write debug messages and progress information to stderr rather than stdout). Galaxy also ignores the error level return code (conventionally non-zero for an error). See: http://bitbucket.org/galaxy/galaxy-central/issue/325/allow-tool-authors-to-d... As a workaround, you can pipe stderr to /dev/null - probably the simplest solution is to copy the script plotting/r_wrapper.sh or stats/r_wrapper.sh (which are almost but not quite identical). Peter
Freddy, what we also did for some of the MUMmer tools I am porting that also has occasional additional output... We capture stderror en stdout and either pipe it to dev/null like Peter says or what I prefer for developemnt is to pipe-append all stdout and/or stderr to a log file as output in galaxy. Since for the R scripts to run you will use a wrapper anyway you could also check the stderr status in that wrapper. To grab sterr and stdout you can use: 1>&- or 2>&- to pipe them to dev/null. I have it conditional in my galaxy_too config to choose if you want the log yes or no. Hope it helps and is what you mean! Cheers Alex ________________________________________ Van: galaxy-dev-bounces@lists.bx.psu.edu [galaxy-dev-bounces@lists.bx.psu.edu] namens Freddy [freddy.debree@wur.nl] Verzonden: woensdag 27 oktober 2010 15:14 Aan: galaxy-dev@lists.bx.psu.edu Onderwerp: [galaxy-dev] suppress screen messages in R I am trying to include R modules in Galaxy. A few of the things I encounter: a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user. b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops! (this happened with function image() when making pdf of array images) In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage. How to go around this? And I think, the galaxy team will probably have to answer this one. _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
I can sink() any messages/warnings to dev/null in R, I'll give that a try. On 10/27/2010 4:48 PM, Bossers, Alex wrote:
Freddy,
what we also did for some of the MUMmer tools I am porting that also has occasional additional output... We capture stderror en stdout and either pipe it to dev/null like Peter says or what I prefer for developemnt is to pipe-append all stdout and/or stderr to a log file as output in galaxy. Since for the R scripts to run you will use a wrapper anyway you could also check the stderr status in that wrapper.
To grab sterr and stdout you can use: 1>&- or 2>&- to pipe them to dev/null. I have it conditional in my galaxy_too config to choose if you want the log yes or no.
Hope it helps and is what you mean!
Cheers Alex
________________________________________ Van: galaxy-dev-bounces@lists.bx.psu.edu [galaxy-dev-bounces@lists.bx.psu.edu] namens Freddy [freddy.debree@wur.nl] Verzonden: woensdag 27 oktober 2010 15:14 Aan: galaxy-dev@lists.bx.psu.edu Onderwerp: [galaxy-dev] suppress screen messages in R
I am trying to include R modules in Galaxy.
A few of the things I encounter:
a) warnings: any warnings() message in R makes Galaxy stop! For R in the shell this means nothing. It simply warns you and that is all, there is no problem or error, just a potential problem with for example rownames in a data.frame which is usually not a big deal to the user.
b) screen messages: this is for example the outcome of a boolean somewhere in the function you are then using in R. It simply outputs a vector with the outcome from a boolean somewhere in the function. However, for Galaxy this is enough reason to see this as an error! and thus: stops!
(this happened with function image() when making pdf of array images)
In principle this is wrong, because Galaxy should only stop in case of an error, not because of one of the above. Still, you do want to see screen output, cause it is helpful in the devel stage.
How to go around this?
And I think, the galaxy team will probably have to answer this one.
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Dear all, Thanks for the clarifications so far. The solution is as follows. What works is indeed sending stderr to dev/null with 2>&- in the tool.xml file. This means running R straight as an R-script. This is ofcourse a drastic measure, but this way you don't need a wrapper.
participants (6)
-
Al Simons -
Bossers, Alex -
Freddy -
James Taylor -
Nate Coraor -
Peter