Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-02-01 Thread Kanwei Li
Committed On Tue, Feb 1, 2011 at 10:27 AM, Peter wrote: > Hi Kanewi, > > Sorry - make that three changesets on this branch to consider > mering/transplanting: > https://bitbucket.org/peterjc/galaxy-central/changeset/blastplus_jan31 > > Parameter handling, > https://bitbucket.org/peterjc/galaxy-ce

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-02-01 Thread Peter
Hi Kanewi, Sorry - make that three changesets on this branch to consider mering/transplanting: https://bitbucket.org/peterjc/galaxy-central/changeset/blastplus_jan31 Parameter handling, https://bitbucket.org/peterjc/galaxy-central/changeset/aa82d8273063 Cope with errors on stderr, https://bitbuc

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-02-01 Thread Peter
Hi Kanwei, On Mon, Jan 31, 2011 at 5:16 PM, Peter wrote: > On Wed, Jan 5, 2011 at 9:07 PM, Daniel Blankenberg wrote: >> Hi Peter, >> >> We had some discussion today about Kanwei's email and opted for the >> nicer looking access method. I've added a note to the ToolConfigSyntax >> wiki page about

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-31 Thread Peter
On Wed, Jan 5, 2011 at 9:07 PM, Daniel Blankenberg wrote: > Hi Peter, > > We had some discussion today about Kanwei's email and opted for the > nicer looking access method. I've added a note to the ToolConfigSyntax > wiki page about special characters. > > Thanks, > > Dan Thanks Dan, Kanwei - co

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-05 Thread Daniel Blankenberg
Hi Peter, We had some discussion today about Kanwei's email and opted for the nicer looking access method. I've added a note to the ToolConfigSyntax wiki page about special characters. Thanks, Dan On Jan 5, 2011, at 3:07 PM, Peter wrote: > On Wed, Jan 5, 2011 at 8:02 PM, Daniel Blankenberg

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-05 Thread Peter
On Wed, Jan 5, 2011 at 8:02 PM, Daniel Blankenberg wrote: > Hi Peter, > > The method to access additional fields from .loc files has been changed in > 4804:376cce23623d to be of the form: > ${param.fields.path}. > :) Did you see Kanwei's email pointing out that while this is nice, it won't work

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-05 Thread Daniel Blankenberg
Hi Peter, The method to access additional fields from .loc files has been changed in 4804:376cce23623d to be of the form: ${param.fields.path}. Thanks again for your input, Dan On Jan 4, 2011, at 12:35 PM, Peter wrote: > On Tue, Jan 4, 2011 at 2:26 AM, Daniel Blankenberg wrote: >> Hi Peter

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-04 Thread Kanwei Li
I would think the get_fields way is more robust since you wouldn't run into issues with special characters On Tue, Jan 4, 2011 at 12:35 PM, Peter wrote: > On Tue, Jan 4, 2011 at 2:26 AM, Daniel Blankenberg wrote: >> Hi Peter (and -dev), >> >> Would something like ${param.fields.path} be preferre

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-04 Thread Peter
On Tue, Jan 4, 2011 at 2:26 AM, Daniel Blankenberg wrote: > Hi Peter (and -dev), > > Would something like ${param.fields.path} be preferred over > ${param.get_fields( 'path' )}? > > Thanks, > > Dan That looks nicer to type in the XML wrapper, but I am not overly bothered. Could we use either synt

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-03 Thread Daniel Blankenberg
Hi Peter (and -dev), Would something like ${param.fields.path} be preferred over ${param.get_fields( 'path' )}? Thanks, Dan On Jan 3, 2011, at 4:28 PM, Peter wrote: > Hi Dan, > > On Wed, Nov 24, 2010 at 2:49 PM, Daniel Blankenberg wrote: >> Hi Peter, >> >>> I have to say the proposed way t

Re: [galaxy-dev] NCBI BLAST+ wrappers in Galaxy?

2011-01-03 Thread Peter
Hi Dan, On Wed, Nov 24, 2010 at 2:49 PM, Daniel Blankenberg wrote: > Hi Peter, > >> I have to say the proposed way to get at the path from within the >> wrapper XML file looks very nasty. Is this a short term solution? > > Yes, that is very nasty and a bad stop-gap solution that needs to not > pr