[galaxy-dev] bug with Galaxy form validation and dynamic_options population of drop-down menus where option values are integers

2012-02-29 Thread Leandro Hermida
Hello,

If you have a form with an input like this:

param name=input1 type=select dynamic_options=get_options() /

And the options dynamically generated have integers as values, e.g.
options tuples like this:

[ One, 1, 1 ],
[ Two, 2, 0 ],
[ Three, 3, 0 ]

When you try to submit the galaxy form you always get the validation
error  An invalid option was selected, please verify.

regards,
Leandro
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/


[galaxy-dev] uploading multiple files into one dataset

2012-02-29 Thread Jorrit Boekel

Dear list,

Our lab's proteomics data is frequently outputted into 50 files 
containing different fractions of proteins. The files are locally stored 
and not present on the Galaxy server. We've planned to somehow (inside 
galaxy) merge these files and split them into tasks so they can be run 
on the cluster. We would either merge/split the files by concatenation, 
or untar/tar files at every job, depending on filetype and tool. No 
problems so far.


However, I have been looking around for a way to upload 50 files 
simultaneously to galaxy and convert to one dataset, and this does not 
seem to be supported. Before starting to create a hack to make this 
work, which doesn't seem especially trivial to me, I'd like to know if I 
should instead use libraries. From what I've seen, libraries are not 
treated as datasets in Galaxy but rather contain datasets. If there was 
a tar all sets in library and import to history I'd be using that, but 
I've only encountered tar/zip sets and download locally which would be 
a bit of a workaround.


I haven't found much on this subject in the mailing list, has this 
functionality been requested before?


cheers,
jorrit boekel
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

 http://lists.bx.psu.edu/


Re: [galaxy-dev] Problem previewing a tool in the Toolshed

2012-02-29 Thread Greg Von Kuster
Hi Carlos,

You can certainly add support for a sqlite database datatype to your local 
galaxy instance.  As you say, it may be no more complex / fragile than h5 or 
other binary datatypes - I've not gone far enough down the analysis path to 
provide good reasons why it may or may not be reasonable, so perhaps I spoke 
too soon.  If you have questions about how to add support for new datatypes, 
see our wiki at http://wiki.g2.bx.psu.edu/Admin/Datatypes.

Thanks!

Greg Von Kuster


On Feb 29, 2012, at 11:59 AM, Carlos Borroto wrote:

 Hi Greg,
 
 Thanks for looking and resolving this issue. After deleting all the
 files in the repo and re-adding them, everything is working as
 expected.
 
 Please see my comments inline about the other two issues.
 
 On Tue, Feb 28, 2012 at 1:57 PM, Greg Von Kuster g...@bx.psu.edu wrote:
 Hi Carlos,
 
 I've uploaded a fix for the problem you saw when attempting to reset all 
 metadata on your cummerbund tool.  Thanks for reporting this issue.
 
 Looking at your change sets, it seems that you are attempting to use the 
 public tool shed hosted by Penn State as a source code repository for your 
 tool development efforts.  If so, this is not the intent the public tool 
 shed - it's intent is rather to share fully functional tools with others in 
 the Galaxy community (fully functional implies that the tools was 
 developed in an environment that included a Galaxy instance, and the tool 
 proved to be functional within the Galaxy instance before it was uploaded to 
 the tool shed).
 
 The tool shed inspects every change set and performs certain functions based 
 on the content of the change set.  For example, if a change set includes a 
 tool, an attempt to load the tool will be made to generate information about 
 the tool.  Data types included in a change set are processed as well.  
 Because of this, it is best to upload changes to the tool shed that contain 
 development efforts that are in a finished state.
 
 See my additional inline comments and questions in your message.
 
 Thanks!
 
 Greg Von Kuster
 
 On Feb 15, 2012, at 2:24 PM, Carlos Borroto wrote:
 
 Hi Greg,
 
 Thanks for your answer. Would be great to get the tool to preview
 correctly but is not a big deal.
 
 I'm having a few more problems. I'm getting this error from time to
 time when I do hg push or even when I delete all files from the
 toolshed and upload new ones:
 Version information for the tools included in the cummerbund
 repository is missing. Reset all of this repository's metadata in the
 tool shed, then set the installed tool versions from the installed
 repository's Repository Actions menu.
 
 
 The fix that I've pushed to the tool shed should hopefully resolve this 
 issue.
 
 
 
 Doing a Reset metadata in the toolshed doesn't solve this issue. I
 can't find how to do then set the installed tool versions from the
 installed repository's Repository Actions menu.
 
 I'm also having problem including a datatype with the tool. One of the
 outputs of the tool is a sqlite database. I have this
 datatypes_conf.xml:
 ?xml version=1.0?
 datatypes
  registration
datatype extension=sqlite type=galaxy.datatypes.binary:Binary
 mimetype=application/octet-stream subclass=True
 display_in_upload=true/
  /registration
 /datatypes
 
 Still sqlite doesn't appear as an option when I try to upload a file
 to Galaxy. The new datatype does appear if I choose the edit a dataset
 attributes.
 
 
 I'm  not quite sure what your intentions are here, but attempting to make a 
 Galaxy datatypes be a sqlite database sounds like it will be complex and 
 fragile,
 
 
 One of the steps for cummeRbund library is the creation of a sqlite
 database. Generating this database is by far the step taking most of
 the processing time. cummeRbund author made it possible to pass as an
 input a previously generated sqlite database, this greatly cuts the
 processing time for subsequent analysis of the same cuffdiff ouput. I
 don't see why having a sqlite binary data type would be different than
 let say BigBed, BAM or h5 binary data types. Could you please comment
 on why you think it would be complex and fragile?.
 
 
 Lastly, when I try to upload a sqlite database I get this error:
 An error occurred running this job: The uploaded binary file contains
 inappropriate content
 
 Uploading a sqlite database to the tool shed will certainly result in this 
 behavior as our code inspectors will not handle this types o content.
 
 
 Sorry I didn't explained myself clearly, I'm not uploading the sqlite
 database to the tool shed. I'm uploading it to a history so I can use
 it with my newly developed tool.
 
 Kind regards,
 Carlos
 
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/
 



Re: [galaxy-dev] HMMER wrappers

2012-02-29 Thread Peter Cock
On Wed, Feb 29, 2012 at 5:56 PM, Edward Kirton eskir...@lbl.gov wrote:
 hi, peter - i will fix the description and upload hmmsearch and infernal
 today.

Great.

Assuming hmmscan and hmmsearch have (almost) the same command
line API, there is something to be said for presenting them as one tool
in Galaxy, with a drop down selection between them (with help text
about which is recommend adapted from the HMMER blog post). One
could even have an automatic selection by a wrapper script based on
the number of query sequences and the number of HMMs. My thinking
here is the detail of hmmscan vs hmmsearch is purely an implementation
detail that the end user shouldn't have to worry about.

Or just duplicate most of the XML code and have two wrappers. But
as far as I know there isn't (yet) a nice way of reusing XML snippets
between tool wrappers... which would be handy.

Thanks,

Peter
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/


[galaxy-dev] en/disable field based on the state of checkbox/radiobutton

2012-02-29 Thread Keith Sheppard
Hello, From looking at the documentation for tool config syntax and I
wasn't able to spot a way to have a field enabled or disabled based on
the state of a radio button or checkbox. Is this possible? If I missed
the documentation please point me in the right direction.

I have two use cases for this: the first is that I want the user to be
able to either select from a group of preselected values (in my case
genome lengths) or enter their own value in a numeric field; the
second is that I'd like the user to be able to select from a data file
that has been stored on our server or a data file from their history.

Thank you, Keith
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/


Re: [galaxy-dev] HMMER wrappers

2012-02-29 Thread Edward Kirton
great suggestion; i'll make those changes

On Wed, Feb 29, 2012 at 10:05 AM, Peter Cock p.j.a.c...@googlemail.comwrote:

 On Wed, Feb 29, 2012 at 5:56 PM, Edward Kirton eskir...@lbl.gov wrote:
  hi, peter - i will fix the description and upload hmmsearch and infernal
  today.

 Great.

 Assuming hmmscan and hmmsearch have (almost) the same command
 line API, there is something to be said for presenting them as one tool
 in Galaxy, with a drop down selection between them (with help text
 about which is recommend adapted from the HMMER blog post). One
 could even have an automatic selection by a wrapper script based on
 the number of query sequences and the number of HMMs. My thinking
 here is the detail of hmmscan vs hmmsearch is purely an implementation
 detail that the end user shouldn't have to worry about.

 Or just duplicate most of the XML code and have two wrappers. But
 as far as I know there isn't (yet) a nice way of reusing XML snippets
 between tool wrappers... which would be handy.

 Thanks,

 Peter

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Problem previewing a tool in the Toolshed

2012-02-29 Thread Greg Von Kuster
Is your datatype lading into your Galaxy instance correctly (either when you 
start your Galaxy instance or when you install your tool from the tool shed)?  
If so, it should be displaying in the upload form.  What does your paster log 
say?


On Feb 29, 2012, at 1:06 PM, Carlos Borroto wrote:

 Hi Greg,
 
 I did follow that link and I think the datatypes_conf.xml in the tool
 repository is correctly written:
 ?xml version=1.0?
 datatypes
  registration
datatype extension=sqlite type=galaxy.datatypes.binary:Binary
 mimetype=application/octet-stream subclass=True
 display_in_upload=true/
  /registration
 /datatypes
 
 I thought by adding display_in_upload=true that would make the
 datatype to appear as an option when uploading a file, but this is not
 happening. Do I need to declare type as for example
 galaxy.datatypes.binary:Sqlite3 for this to work? If I have to, I'm
 guessing I would have to do what is explained here:
 http://wiki.g2.bx.psu.edu/Tool%20Shed#Including_proprietary_data_types_that_use_class_modules_contained_in_your_repository
 
 Thanks,
 Carlos
 
 On Wed, Feb 29, 2012 at 12:14 PM, Greg Von Kuster g...@bx.psu.edu wrote:
 Hi Carlos,
 
 You can certainly add support for a sqlite database datatype to your local 
 galaxy instance.  As you say, it may be no more complex / fragile than h5 or 
 other binary datatypes - I've not gone far enough down the analysis path to 
 provide good reasons why it may or may not be reasonable, so perhaps I spoke 
 too soon.  If you have questions about how to add support for new datatypes, 
 see our wiki at http://wiki.g2.bx.psu.edu/Admin/Datatypes.
 
 Thanks!
 
 Greg Von Kuster
 
 
 On Feb 29, 2012, at 11:59 AM, Carlos Borroto wrote:
 
 Hi Greg,
 
 Thanks for looking and resolving this issue. After deleting all the
 files in the repo and re-adding them, everything is working as
 expected.
 
 Please see my comments inline about the other two issues.
 
 On Tue, Feb 28, 2012 at 1:57 PM, Greg Von Kuster g...@bx.psu.edu wrote:
 Hi Carlos,
 
 I've uploaded a fix for the problem you saw when attempting to reset all 
 metadata on your cummerbund tool.  Thanks for reporting this issue.
 
 Looking at your change sets, it seems that you are attempting to use the 
 public tool shed hosted by Penn State as a source code repository for your 
 tool development efforts.  If so, this is not the intent the public tool 
 shed - it's intent is rather to share fully functional tools with others 
 in the Galaxy community (fully functional implies that the tools was 
 developed in an environment that included a Galaxy instance, and the tool 
 proved to be functional within the Galaxy instance before it was uploaded 
 to the tool shed).
 
 The tool shed inspects every change set and performs certain functions 
 based on the content of the change set.  For example, if a change set 
 includes a tool, an attempt to load the tool will be made to generate 
 information about the tool.  Data types included in a change set are 
 processed as well.  Because of this, it is best to upload changes to the 
 tool shed that contain development efforts that are in a finished state.
 
 See my additional inline comments and questions in your message.
 
 Thanks!
 
 Greg Von Kuster
 
 On Feb 15, 2012, at 2:24 PM, Carlos Borroto wrote:
 
 Hi Greg,
 
 Thanks for your answer. Would be great to get the tool to preview
 correctly but is not a big deal.
 
 I'm having a few more problems. I'm getting this error from time to
 time when I do hg push or even when I delete all files from the
 toolshed and upload new ones:
 Version information for the tools included in the cummerbund
 repository is missing. Reset all of this repository's metadata in the
 tool shed, then set the installed tool versions from the installed
 repository's Repository Actions menu.
 
 
 The fix that I've pushed to the tool shed should hopefully resolve this 
 issue.
 
 
 
 Doing a Reset metadata in the toolshed doesn't solve this issue. I
 can't find how to do then set the installed tool versions from the
 installed repository's Repository Actions menu.
 
 I'm also having problem including a datatype with the tool. One of the
 outputs of the tool is a sqlite database. I have this
 datatypes_conf.xml:
 ?xml version=1.0?
 datatypes
  registration
datatype extension=sqlite type=galaxy.datatypes.binary:Binary
 mimetype=application/octet-stream subclass=True
 display_in_upload=true/
  /registration
 /datatypes
 
 Still sqlite doesn't appear as an option when I try to upload a file
 to Galaxy. The new datatype does appear if I choose the edit a dataset
 attributes.
 
 
 I'm  not quite sure what your intentions are here, but attempting to make 
 a Galaxy datatypes be a sqlite database sounds like it will be complex and 
 fragile,
 
 
 One of the steps for cummeRbund library is the creation of a sqlite
 database. Generating this database is by far the step taking most of
 the processing time. cummeRbund author made it possible to pass as 

[galaxy-dev] Possible Galaxy memory leak?

2012-02-29 Thread Joshua Gross
Hi all--

Our group is running a local instance of Galaxy on a Linux box.  We have been 
noticing a memory issue, where if we leave the server running for a few days, 
soon all available memory (~8gb) will be used up to the point where the tools 
fail because they are unable to allocate new memory.

While we haven't done any rigorous testing, this issue seems to be independent 
of the specific tools we run, and actually seems to still appear if we do not 
run any tools at all.  The process python is what is taking up all the 
memory, and the issue is not instantaneous but happens over time.  Restarting 
the server frees the memory immediately.

Is this a known issue?  If so, is there a known fix for it?  Any insight on 
this would be much appreciated, as it is complicating our efforts to automate 
long work-flows.

Thank you so much for your time

Josh Gross, Western Washington University.
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Possible Galaxy memory leak?

2012-02-29 Thread John Chilton
We had intermittent issues like this for an embarrassingly long time
at MSI, but since we applied this patch
https://bitbucket.org/galaxy/galaxy-central/pull-request/36/fix-for-dynamic_optionspy
Galaxy has been running smoothly for weeks. Seems unlikely this is the
problem in your case (unless you have pulled in tools with make use of
dynamic options), but it something to consider.

-John

On Wed, Feb 29, 2012 at 2:08 PM, Joshua Gross gros...@students.wwu.edu wrote:
 Hi all--

 Our group is running a local instance of Galaxy on a Linux box.  We have
 been noticing a memory issue, where if we leave the server running for a few
 days, soon all available memory (~8gb) will be used up to the point where
 the tools fail because they are unable to allocate new memory.

 While we haven't done any rigorous testing, this issue seems to be
 independent of the specific tools we run, and actually seems to still appear
 if we do not run any tools at all.  The process python is what is taking
 up all the memory, and the issue is not instantaneous but happens over
 time.  Restarting the server frees the memory immediately.

 Is this a known issue?  If so, is there a known fix for it?  Any insight on
 this would be much appreciated, as it is complicating our efforts to
 automate long work-flows.

 Thank you so much for your time

 Josh Gross, Western Washington University.

 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/


[galaxy-dev] Potential issue with eggs ?

2012-02-29 Thread Michael Burrell (TOC)
Good evening all,

I am seeing the following issue when attempting to start galaxy.

Traceback (most recent call last):
  File ./scripts/paster.py, line 34, in module
command.run()
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py,
 line 84, in run
invoke(command, command_name, options, args[1:])
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py,
 line 123, in invoke
exit_code = runner.run(args)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py,
 line 218, in run
result = self.command()
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py,
 line 276, in command
relative_to=base, global_conf=vars)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py,
 line 313, in loadapp
**kw)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 204, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 224, in loadobj
global_conf=global_conf)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 248, in loadcontext
global_conf=global_conf)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 278, in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 413, in get_context
section)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 458, in _context_from_explicit
value = import_string(found_expr)
  File 
/home/home/galaxy/software/galaxy-central/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
 line 18, in import_string
return pkg_resources.EntryPoint.parse(x=+s).load(False)
  File /home/home/galaxy/software/galaxy-central/lib/pkg_resources.py, line 
1954, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File /home/home/galaxy/software/galaxy-central/lib/galaxy/web/buildapp.py, 
line 19, in module
from galaxy import config, jobs, util, tools
  File /home/home/galaxy/software/galaxy-central/lib/galaxy/jobs/__init__.py, 
line 4, in module
from galaxy import util, model
EOFError: EOF read where object expected
Removing PID file paster.pid

Would this suggest that the eggs are bad? What would be the best way to remedy 
the situation

Thanks

Michael.
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/