[galaxy-dev] Bug with new tool? (cheetah + shell script issue?)
Hello,
When adding a new tool, we used a cheetah'ed shell script defined in the
configfiles tags of the tool's xml file. To get the absolute path of
an external script located in the tools directory, I used the following
code in the configfile script:
${ os.getcwd() }/${ $__app__.config.tool_path }/toolsubdir/scriptname.sh
When I tried the new tool, I got an error message. Here are the last lines:
File /g/funcgen/galaxy/lib/galaxy/tools/parameters/basic.py, line
681, in value_from_basic
if isinstance( value, dict ) and value[__class__] ==
UnvalidatedValue:
KeyError: '__class__'
Therefore I slightly modified the file basic.py. I replaced the line 681:
if isinstance( value, dict ) and value[__class__] == UnvalidatedValue:
by:
if isinstance( value, dict ) and getattr(value, __class__) ==
UnvalidatedValue:
and it works fine now.
I fail to see why the original code didn't work though.
Hope that helps.
Regards,
L-A
___
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] Restoring galaxy database return few empty tables.
Hello Nate, When restoring, I generally use the --disable-triggers, which instructs Postgres to ignore foreign key constraints. --nate Sorry for the relayed response from my side. As you suggested I tried with --disable-triggers option for restoring the database from the dump file, Apparently this returns some notice message associated with circular foreign-key constraints for few tables. Here are some notice messages: pg_dump: NOTICE: there are circular foreign-key constraints among these table(s): pg_dump: stored_workflow pg_dump: workflow pg_dump: You may not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints. pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem. and finally ended up with: pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem. pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 3075; 0 16650 TABLE DATA history_dataset_association galaxy pg_restore: [archiver (db)] COPY failed: ERROR: invalid byte sequence for encoding UTF8: 0xb9 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by client_encoding. CONTEXT: COPY history_dataset_association, line 8149 pg_restore: [archiver (db)] Error from TOC entry 3064; 0 16435 TABLE DATA job galaxy pg_restore: [archiver (db)] COPY failed: ERROR: invalid byte sequence for encoding UTF8: 0xb9 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by client_encoding. CONTEXT: COPY job, line 16578 WARNING: errors ignored on restore: 2 Based on the suggestions from the error and notice message first one seems to be not much harm to the database contents. I believe the second one points to some naming related thing, other than that I don't have much idea. According to the above suggestions I tried to load the dump files directly and it also ended up with error message. from the man page I understood that pg_restore will use the option --disable-triggers with --data-only dump. My issue is not yet solved, that is the 'job' table seems to be empty. Please let me know if I am doing something wrong. Here is my inputs, dumping table schema pg_dump --schema --create -F t --host MAN | pg_restore --dbname=galaxy -F t dumping table contents pg_dump --data-only --create -F t --host MAN | pg_restore --dbname=galaxy -F t --disable-triggers Many thanks for your suggestions, Vipin ___ 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] param type=float optional=true doesn't work
Hi, how do you make float parameter types fully optional? optional=true doesn't work. -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] API
Anyone know where i can get the galaxy API? Regards Fred ___ 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] Restoring galaxy database return few empty tables.
Hello Nate, Can you make sure that your dump was created with '-E UTF-8' flag? I didn't use any customized encoding for my dump, took the default one, I believe which is the database encoding. Also, in your old database server, use psql's '\l' command to show the encoding of your databases. My database encoding is SQL_ASCII thanks, Vipin ___ 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] API
Frederick, The API is distributed along with galaxy. To enable it, set the following in your universe_wsgi.ini: enable_api = True Once that's enabled, each user can create an API key using the API Keys option in the user menu of the main masthead. For additional information, see /scripts/api/README in your galaxy directory, or email back and I'll do what I can to help. -Dannon On May 12, 2011, at 2:08 PM, Frederick van Staden wrote: Anyone know where i can get the galaxy API? Regards Fred ___ 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/
Re: [galaxy-dev] interval format from pileup
Thanks for letting me know. I'm also forwarding this galaxy-dev, so the thread in complete. Thanks, anton Anton Nekrutenko http://nekrut.bx.psu.edu http://usegalaxy.org On May 12, 2011, at 2:30 PM, Katie Hyma wrote: Hi Anton, You're right, sorry for the false alarm. After a more careful inspection of my data I'm pleased to say that I was wrong and that everything with galaxy is fine, it turns out that the company that generated the previous data had generated the error; good think I checked those results, I had just assumed I that my analysis had the error! Katie On Thu, May 12, 2011 at 10:54 AM, Anton Nekrutenko an...@bx.psu.edu wrote: Katie: Filter pileup outputs 0-based coordinates if you use the Convert coordinates to intervals option. So the issue may be related to aaChanges tools. Can you give us a specific example, so we can track things down. Thanks! anton galaxy team Anton Nekrutenko http://nekrut.bx.psu.edu http://usegalaxy.org On May 12, 2011, at 10:37 AM, Katie Hyma wrote: Hi all, I ran into this problem, and thought others might run in to it as well: When using bowtie and samtools, positions are formatted with a 1-base offset, whereas interval format requires 0-base offset. Recently, I used the 'Filter pileup on coverage and SNPs' tool with the 'convert coordinates to intervals' option, and used the output with the 'aaChanges' tool to detect amino acid changes. In the aaChanges output there was an off-by-one discrepancy with a previous analysis, which brought this problem to my attention. Should the 'Filter pileup' tool be changed to produce output with 0-base offset when interval format is selected, since interval format is defined as having 0-base output? It seems that others might run into the same problem, and it would be an easy one to miss. Although the pileup format is now deprecated, the same problem might occur if/when the change to VCF format occurs, as it also uses 1-base offset. It also may be a problem for other tools that use interval format as an input, expecting a 0-based position. Best, Katie ___ 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/
Re: [galaxy-dev] param type=float optional=true doesn't work
On Thu, May 12, 2011 at 6:03 PM, Leandro Hermida wrote: Hi, how do you make float parameter types fully optional? optional=true doesn't work. -Leandro Sadly this is a known bug I reported some time ago: https://bitbucket.org/galaxy/galaxy-central/issue/403 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] galaxy with SGE cluster
I need some help in configuring galaxy with SGE scheduler using unified method. The galaxy is running on a system distinct from SGE scheduler install. The cluster nodes can access galaxy install, galaxy-tools and dataset files using NFS. I am not sure how drmaa works and how galaxy submits jobs to the cluster/scheduler. Do we need specify some type of connection string or ssh-config to connect with the cluster/scheduler? Does it need any configuration changes on the SGE scheduler side? Any explanation regarding this will be really helpful. -- Thanks, Shantanu. ___ 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/
