On Fri, Jun 27, 2014 at 5:16 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
On Wed, Jun 18, 2014 at 12:14 PM, Peter Cock p.j.a.c...@googlemail.com
wrote:
On Wed, Jun 18, 2014 at 12:04 PM, Jan Kanis jan.c...@jankanis.nl wrote:
I am not using job splitting, because I am implementing this for a
On Fri, Jun 27, 2014 at 3:13 PM, John Chilton jmchil...@gmail.com wrote:
On Fri, Jun 27, 2014 at 5:16 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
On Wed, Jun 18, 2014 at 12:14 PM, Peter Cock p.j.a.c...@googlemail.com
wrote:
John - that Trello issue you logged,
On Fri, Jun 27, 2014 at 9:30 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
On Fri, Jun 27, 2014 at 3:13 PM, John Chilton jmchil...@gmail.com wrote:
On Fri, Jun 27, 2014 at 5:16 AM, Peter Cock p.j.a.c...@googlemail.com
wrote:
On Wed, Jun 18, 2014 at 12:14 PM, Peter Cock
I am not using job splitting, because I am implementing this for a client
with a small (one machine) galaxy setup.
Implementing a query limit feature in galaxy core would probably be the
best idea, but that would also probably require an admin screen to edit
those limits, and I don't think I can
On Wed, Jun 18, 2014 at 12:04 PM, Jan Kanis jan.c...@jankanis.nl wrote:
I am not using job splitting, because I am implementing this for a client
with a small (one machine) galaxy setup.
Ah - this also explains why a job size limit is important for you.
Implementing a query limit feature in
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit. For the gene bank links I guess
modifying the .loc file is the least bad way. Maybe it can be merged into
galaxy_blast, that would at least solve the interoperability problems.
On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote:
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit.
Are you using the optional job splitting (parallelism) feature in Galaxy?
That seems to be me to be a good
On Tue, Jun 17, 2014 at 2:55 PM, Peter Cock p.j.a.c...@googlemail.com wrote:
On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote:
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit.
Are you using the optional
On Mon, Jun 16, 2014 at 4:18 AM, John Chilton jmchil...@gmail.com wrote:
Hello Jan,
Thanks for the clarification. Not quite what I was expecting so I am
glad I asked - I don't have great answers for either case so hopefully
other people will have some ideas.
For the first use case - I would
Hello Jan,
Thanks for the clarification. Not quite what I was expecting so I am
glad I asked - I don't have great answers for either case so hopefully
other people will have some ideas.
For the first use case - I would just specify some default input to
supply to the input wrapper - lets call
I have two use cases: the first is for a modification of the ncbi blast
wrapper to limit the query input size (for a publically accessible galaxy
instance), so this needs a configuration option for the query size limit. I
was thinking about a separate config file in tool-data for this.
The second
I am writing a tool that should be configurable by the server admin. I am
considering adding a configuration file, but where should such a file be
placed? Is the tool-data directory the right place? Is there another
standard way for per-tool configuration?
Jan
I would have different answers for your depending on what options are
available to the server admin. What exactly about the tool is
configurable - can you be more specific?
-John
On Fri, Jun 13, 2014 at 10:59 AM, Jan Kanis jan.c...@jankanis.nl wrote:
I am writing a tool that should be
13 matches
Mail list logo
