bug or misuse? "flat" param does not work

[Andrew Uzilov]

Hi all...

I have a demo up here:

http://users.soe.ucsc.edu/~auzilov/tmp/plotVarna.U1a.html

If you look at the page source, you will see that I set the "flat"
param to "1":

<param name='flat' value='1' />

but the "Flat exterior loops" style or drawing is not being done. If
you hit Ctrl+F, that works, but the param is being ignored.

The same thing occurs when I use the command-line VARNA. Setting "-
flat" to 1 is basically ignored.

Am I doing this wrong, or is this a bug?

Thanks,
Andrew

[Yann Ponty]

Hi Andrew,

The proper values for the "flat" applet parameter are "true" and
"false",
as illustrated by the "planarized" example:
http://varna.lri.fr/example8.html

Browsing through the specs, I see the usage example does not match
this spec, and will fix this glitch asap.

Thanks for the feedback/example,

Yann

[Andrew V. Uzilov]

Hi Yann...

Thanks for the clarification! Yes, that does the trick.

I think there is another page that needs to be corrected:

http://varna.lri.fr/specs.html

There it says that the "flat" parameter is an "int", not a boolean.

Also -- I am not entirely sure if the "error" and "warning" params are
working. Shouldn't I get a error or warning message if I set the
wrong param, like when I set flat" to "1" instead of a boolean? Here
is an example:

http://users.soe.ucsc.edu/~auzilov/tmp/plotVarna.errorTest.U1a.html

Note that I turned on "warning" and "error" there is a bad parameter downstream:

<param name='algorithm' value='radi_BAD_PARAM_VALUE_ate' />

but the applet does not seem to complain. I do not see anything
logged to error or warning log in Firefox 3.6.3 (on CentOS Linux) when
I load the applet. I see the same when running VARNA from the command
line -- no error messages written to STDOUT or STDERR. Is this the
correct behavior?

Thanks,
Andrew

[Yann Ponty]

On May 17, 9:01 pm, "Andrew V. Uzilov" <andrew.uzi...@gmail.com>
wrote:

> There it says that the "flat" parameter is an "int", not a boolean.

Right, sorry for the waste of your time!

> Also -- I am not entirely sure if the "error" and "warning" params are
> working.  Shouldn't I get a error or warning message if I set the
> wrong param, like when I set flat" to "1" instead of a boolean?  Here

> is an example...

This one might arise from a slight inconsistency in the way we treat
errors/warnings.
Basically, VARNA used to throw exceptions around anytime something
even remotely suspicious happened, and the warning/error params were
just interpreted as "ignore warning" or "display a warning popup".
As the code became more and more complicated, it gradually became
harder (and almost impossible now) to stick to such a policy. Indeed,
the exceptions must be thrown before any change is made, or at least
at a moment which preserves a legal internal state for the applet,
since we do not want the applet to crash afterward. Consequently, the
current approach tends to silently ignore errors in input parameters
and such...
Another, maybe better, approach would consist in removing exceptions
and add some sort of log where the errors/warnings would be
displayed.
These errors/warnings only seem to be helpful for debugging anyway, do
you agree?

Best,

Yann

[Andrew V. Uzilov]

On Mon, May 17, 2010 at 4:28 PM, Yann Ponty <yann....@gmail.com> wrote:
>> Also -- I am not entirely sure if the "error" and "warning" params are
>> working.  Shouldn't I get a error or warning message if I set the
>> wrong param, like when I set flat" to "1" instead of a boolean?  Here
>> is an example...
>
> This one might arise from a slight inconsistency in the way we treat
> errors/warnings.
> Basically, VARNA used to throw exceptions around anytime something
> even remotely suspicious happened, and the warning/error params were
> just interpreted as "ignore warning" or "display a warning popup".
> As the code became more and more complicated, it gradually became
> harder (and almost impossible now) to stick to such a policy. Indeed,
> the exceptions must be thrown before any change is made, or at least
> at a moment which preserves a legal internal state for the applet,
> since we do not want the applet to crash afterward. Consequently, the
> current approach tends to silently ignore errors in input parameters
> and such...
> Another, maybe better, approach would consist in removing exceptions
> and add some sort of log where the errors/warnings would be
> displayed.
> These errors/warnings only seem to be helpful for debugging anyway, do
> you agree?

I am not entirely surely I follow you, although I probably would
understand this better if I looked at the code.

Let's not worry about the "error" and "warning" params. My only real
concern is that a clueless user such as myself may set illegal values
for other parameters -- e.g. wrong types (like my fumbling with "flat"
earlier), nonsensical values (like a non-existent layout algorithm
name provided as the "algorithm" param) and so forth. So, ideally,
the UI should tell the user that they specified an invalid config
somehow. I'm not particularly concerned about debugging VARNA, I just
want to be told when I misuse the program.

I'm basically asking for simple sanity checks. I am not asking for
extensive cross-referencing of all params to make sure the specified
state is correct/sensible, but just some simple type and value
checking. For example, when a param is drawn from a list of values
(e.g. naview, radiate, etc.), that you specified something that
belongs in the list and didn't make a typo. It would improve
usability by novices.

Cheers,
Andrew

[Yann Ponty]

I guess my answer was confusing. What I basically meant was:
"This has been only partially coded, please accept our apologies" ;)
By debugging, I was referring to user-side debugging.
I don't even dream of having users debug VARNA, but would love to be
proven wrong :)

> ... just some simple type and value

> checking.  For example, when a param is drawn from a list of values
> (e.g. naview, radiate, etc.), that you specified something that
> belongs in the list and didn't make a typo.  

Perfectly sensible, I will try to work on this when I find a few
hours.

> It would improve usability by novices.

Again, absolutely agree.

[Andrew V. Uzilov]

Thanks Yann!

And thank you for making this excellent tool! I have been hacking
away at various ways to do RNA visualization, and this is by far the
best.

Cheers,
Andrew