soaplab-users Mailing List for Soaplab (Page 10)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I thought I finally got it. But it seems I am lost again. Or is it only
due to some inconsistency in the system ?
Tried to use that trick again, as described below. But this time with a
default value set to 'true'. Guess what. It does not work at all. Just
the opposite behaviour.
Consider the acd:

boolean: show_header  [
  additional: "Y"
  default: "Y"
  comment: "defaults"
  comment: "method --noheader"
]

The behaviour I expected was:
If the user sets show_header to 'true', the --noheader is not put on the
command line. In all other cases (e.g. show_header =3D> false) the =
passed
value is different from the default and thus, --noheader is put on the
command line.
It happened to be completely the way around.
On the other hand, if this was put in the acd (like in the old post
below) it behaves as expected.

boolean: no_header  [
  additional: "Y"
  default: "N"
  comment: "defaults"
  comment: "method --noheader"
]

Meaning: if no_header is set to 'true', --noheader is added to the
command line, if no_header is ommitted or set to 'false', the option is
not added to the command line because 'false' is the default value.

Why did it not work in the other way (the first example) ?
What is the system behind it ????
Am I missing something ?

Cheers,
Marc

> -----Original Message-----
> From: soa...@li...=20
> [mailto:soa...@li...] On Behalf=20
> Of Marc Logghe
> Sent: Thursday, February 23, 2006 6:06 PM
> To: soa...@li...
> Subject: RE: [Soaplab-users] ACD question
>=20
> Feels a little strange, answering my own post ;-)
>=20
> Finally I used this trick:
>=20
> boolean convert_to_uppercase [
>    additional: "Y"
>    prompt: "Convert to uppercase"
>    default: "false"
>    comment: "defaults"
>    comment: "method -u"
> ]
>=20
> The trick is taking advange of an applab feature and works as=20
> such: if a user passes a value that matches the default value=20
> (here set to false) the option is not passed to the command=20
> line. With any other value different from false (e.g true :-)=20
> applab will pass the option '-u' to the command line.
>=20
> You can use that trick also for other parameter types but you=20
> have to take care: you should not lie about the default value !!
> Because: Suppose you have a blast service and a paramater=20
> expect_cutoff that defaults to 1E-2 (at least, according to=20
> the acd file). However, the blastall default e-value is 10.0.
> Meaning, in the acd you actually lied about the real default=20
> e-value that blastall is using. As a consequence, when a user=20
> really passes the value 1E-2 for the expect_cutoff parameter,=20
> it matches the default value and therefor the option is not=20
> passed to the blastall command line. As a result, blastall is=20
> run with the real e-value of 10.0 !=20
>=20
> Hope it will help somebody, some day ...
>=20
> Cheers,
> Marc
>=20
>=20
>=20
> > -----Original Message-----
> > From: soa...@li...
> > [mailto:soa...@li...] On=20
> Behalf Of Marc=20
> > Logghe
> > Sent: Thursday, February 23, 2006 4:15 PM
> > To: soa...@li...
> > Subject: [Soaplab-users] ACD question
> >=20
> > Hi,
> > Suppose you have a command line that takes an option -u (let say it=20
> > means uppercase). If '-u' is omitted, it produces lowercase.
> > I started off like this:
> >=20
> > boolean convert_to_uppercase [
> >   additional: "Y"
> >   prompt: "Convert to uppercase"
> >   comment: "method -u"
> > ]
> >=20
> > A soaplab user would see the option 'convert_to_uppercase'.=20
> > Internally this is mapped by soaplab to '-u' without a value.
> > Problem is, no matter what value is given (true or false)=20
> this option=20
> > would be put on the command line and this is not what the user=20
> > expects.
> > Is there a way to make this conditinal ?
> > Something like:
> >   comment: "method @($$ =3D=3D true ? '-u' : '')
> >=20
> > I have a terrible feeling I am overlooking something ...
> > But any suggestions are welcome.
> > Thanks,
> > Marc
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting=20
> > language that extends applications into web and mobile=20
> media. Attend=20
> > the live webcast and join the prime developer group=20
> breaking into this=20
> > new coding territory!
> > =
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> > _______________________________________________
> > Soaplab-users mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplab-users
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language that extends applications into web and=20
> mobile media. Attend the live webcast and join the prime=20
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Soaplab-users mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplab-users
>=20

2005	Jan	Feb	Mar	Apr	May	Jun	Jul (14)	Aug	Sep (6)	Oct (13)	Nov (5)	Dec
2006	Jan (4)	Feb (8)	Mar (4)	Apr (8)	May (1)	Jun (8)	Jul (1)	Aug (4)	Sep (4)	Oct	Nov (9)	Dec
2007	Jan (7)	Feb	Mar (2)	Apr	May (2)	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2008	Jan	Feb (8)	Mar (39)	Apr (20)	May (11)	Jun (17)	Jul (7)	Aug (6)	Sep (4)	Oct (25)	Nov (7)	Dec (7)
2009	Jan (4)	Feb (9)	Mar	Apr	May	Jun (4)	Jul (3)	Aug (10)	Sep	Oct	Nov	Dec
2010	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug (2)	Sep	Oct (6)	Nov (1)	Dec
2011	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec

soaplab-users Mailing List for Soaplab (Page 10)

soaplab-users — Forum for Soaplab users and developers