Re: [galaxy-dev] Including descriptions etc in extended BLAST+ tabular output
On Wed, Dec 4, 2013 at 4:21 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Mon, Dec 2, 2013 at 3:37 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Sun, Dec 1, 2013 at 7:10 PM, Björn Grüning bjoern.gruen...@pharmazie.uni-freiburg.de wrote: Great. I'll probably merge the c25 branch and push that to the Test Tool Shed next week (adding the descriptions as a new 25th column to the default extended tabular output). +1 Done, see this and the preceding commits: https://github.com/peterjc/galaxy_blast/commit/eb1e522a864e5274a2d274a49fcb15c313e93d69 And the Test Tool Shed repository has been updated: http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/8f9023b30384 We'll also be running this update locally for a little more testing, but I'd appreciate some of you also testing this, e.g. via the Test Tool Shed on your own local (development) Galaxy instances. If there are no problems, that can probably go out to the main Tool Shed by the end of the week. I pushed another update to the Test Tool Shed addressing a slight change in the autogenerated IDs used in the BLAST XML output, and an overlooked mention of 24 columns: http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/72170c3f515a The functional tests are passing on the Test Tool Shed, so before I push this to the main Tool Shed, any other comments? Feedback is still welcome, but I have now pushed this to the main Tool Shed as v0.0.22 of the BLAST+ wrappers, which targets BLAST+ 2.2.28: http://toolshed.g2.bx.psu.edu/view/devteam/ncbi_blast_plus/4c4a0da938ff (I realise now this ended up skipping v0.0.21 which updated the dependencies to wrap BLAST+ 2.2.27) Maybe with the next set of changes like pick-you-own columns I will bump the minor version number and call this v0.1.0 to avoid any possibly confusion between the wrapper version and the underlying BLAST+ version - good plan? After all, it will cause some slight breakage if trying to re-run old jobs due to the introduction of a conditional block for the output format. 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Including descriptions etc in extended BLAST+ tabular output
Il 2013-12-04 20:48 Jim Johnson ha scritto: On 12/4/13, 10:21 AM, Peter Cock wrote: On Mon, Dec 2, 2013 at 3:37 PM, Peter Cock p.j.a.c...@googlemail.com [1] wrote: On Sun, Dec 1, 2013 at 7:10 PM, Björn Grüning bjoern.gruen...@pharmazie.uni-freiburg.de [2] wrote: Great. I'll probably merge the c25 branch and push that to the Test Tool Shed next week (adding the descriptions as a new 25th column to the default extended tabular output). +1 Done, see this and the preceding commits: https://github.com/peterjc/galaxy_blast/commit/eb1e522a864e5274a2d274a49fcb15c313e93d69 [3] And the Test Tool Shed repository has been updated: http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/8f9023b30384 [4] We'll also be running this update locally for a little more testing, but I'd appreciate some of you also testing this, e.g. via the Test Tool Shed on your own local (development) Galaxy instances. If there are no problems, that can probably go out to the main Tool Shed by the end of the week. I pushed another update to the Test Tool Shed addressing a slight change in the autogenerated IDs used in the BLAST XML output, and an overlooked mention of 24 columns: http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/72170c3f515a [5] The functional tests are passing on the Test Tool Shed, so before I push this to the main Tool Shed, any other comments? I'll look at the pick-your-own column output for the next revision of the NCBI BLAST+ wrappers. I've been working on this using JJ's work on column picking in the BLAST XML to tabular tool - viewable here: https://github.com/jmchilton/galaxy_blast/commit/d79afc03522768323494818a40aac10513a6fa09 [6] See this branch updating and extending that work: https://github.com/peterjc/galaxy_blast/tree/blastxml_jj [7] I'm considering splitting the column picker into three, the standard 12 columns, the further 13 used in our extended 25 column output, and a third category for any other columns offered by BLAST+ (like the taxonomy columns added in BLAST+ 2.2.28). Here's a screenshot showing the column picker offering the 25 columns, split in two: Note that (following JJ's earlier work) these all include the column numbers as used in the standard 12 column BLAST tabular output, or our extended 25 column output. Note I would not intend to number the final set of extra columns. Do people think this is helpful, or potentially confusing (since the column numbering will change in a custom selection)? Peter Splitting into 3 sections seems like a good idea. That makes it easier to select groups of columns. I also think labeling the column options with the column number in the standard tabular outputs will be useful to users. I also like the splitting into 3 sections, but I think that the column numbering may be confusing and I would prefer it's not included. Nicola ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Including descriptions etc in extended BLAST+ tabular output
Peter Cock wrote: I've been working on this using JJ's work on column picking in the BLAST XML to tabular tool - viewable here: ... I'm considering splitting the column picker into three, the standard 12 columns, the further 13 used in our extended 25 column output, and a third category for any other columns offered by BLAST+ (like the taxonomy columns added in BLAST+ 2.2.28). Here's a screenshot showing the column picker offering the 25 columns, split in two: Note that (following JJ's earlier work) these all include the column numbers as used in the standard 12 column BLAST tabular output, or our extended 25 column output. Note I would not intend to number the final set of extra columns. Do people think this is helpful, or potentially confusing (since the column numbering will change in a custom selection)? Peter Jim Johnson wrote: Splitting into 3 sections seems like a good idea. That makes it easier to select groups of columns. I also think labeling the column options with the column number in the standard tabular outputs will be useful to users. Nicola Soranzo wrote: I also like the splitting into 3 sections, but I think that the column numbering may be confusing and I would prefer it's not included. Nicola So we have agreement on splitting the columns into three groups (standard 12, extended 13, and the rest), but not about if the first two batches should be numbered (as columns 1 to 25). Next I need to look at the missing columns, and ideally see which can be automatically extracted from the XML for the conversion tool... 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Per-tool overrides for environment variables (non-tool shed)?
Hi, Galaxy-Developers, I apologize if this question has been answered before; I'm trying to override a couple of environment variables on a per-tool level, for a tool that is not installed in the toolshed. I've read a post on the mailing list that suggests this is possible for tools installed from the toolshed ( http://dev.list.galaxyproject.org/environment-variables-and-paths-for-toolshed-tools-td4656231.html), however I am interested in doing this for a tool not installed from the toolshed, for example, the draw histogram tool. Basically, it appears at this point in time that I have to have multiple versions of R compiled to support our Galaxy instance. This stems from fragmented version support of different software components (for example the new version of the Bioconductor suite (used for CummeRbund) requires R 3.x, but the draw histogram function requires rpy, which isn't supported with R 3.x). For what it is worth, I did read about somebody who released a version of the draw histogram function that supports rpy2 ( http://dev.list.galaxyproject.org/rpy2-Core-Tools-td4659832.html), however I am asking this question regardless as I do not want to go through the exercise of testing the rpy2 core tools right now if it is not necessary. So, my question is this; is there a preferred way to handle per-tool overrides for environment variables such as $PATH or $RPATH, for tools *not* included in the tool shed, for example the draw histogram tool? It does not appear that these tools have a tool_dependencies.xml. I appreciate you taking the time to answer my question and wish you a wonderful day. Thank you, Dan Sullivan ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Galaxy code: data libraries
Hi John, It works very fine. Thank you again for your help, very useful :). Have a nice day, Mish From: mish...@hotmail.com To: chil...@msi.umn.edu Date: Mon, 2 Dec 2013 08:51:28 + CC: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Galaxy code: data libraries Hi John, Thank you very much for your reply! I will try this, and inform you if it works correctly. Thank you again, Mish Date: Thu, 28 Nov 2013 15:06:47 -0600 Subject: Re: [galaxy-dev] Galaxy code: data libraries From: chil...@msi.umn.edu To: mish...@hotmail.com CC: galaxy-dev@lists.bx.psu.edu I think the relevant piece of code is in templates/webapps/galaxy/ibrary/common/common.mako. The lines select name=link_data_only %if not link_data_only or link_data_only == 'copy_files': option value=copy_files selectedCopy files into Galaxy option value=link_to_filesLink to files without copying into Galaxy %else: option value=copy_filesCopy files into Galaxy option value=link_to_files selectedLink to files without copying into Galaxy %endif /select could probably be modified a few different ways. I have not really tried this but if you really do want to eliminate copying all together you can probably just replace it with: select name=link_data_only option value=link_to_files selectedLink to files without copying into Galaxy /select Alternatively, you could probably modify the default to be linking by replacing this with: select name=link_data_only %if link_data_only and link_data_only == 'copy_files': option value=link_to_filesLink to files without copying into Galaxy option value=copy_files selectedCopy files into Galaxy %else: option value=link_to_files selectedLink to files without copying into Galaxy option value=copy_filesCopy files into Galaxy %endif /select Hope this helps! -John On Thu, Nov 28, 2013 at 6:56 AM, Misharl mon mish...@hotmail.com wrote: Hi eveybody, Is there a way in the code of Galaxy, to force the users to use link to files without copying in Galaxy by hiding the copy files into Galaxy option in the interface, when they add datasets in their library? We want to avoid users to click on copy files into Galaxy by mistake. Thanks in advance to all Mish Hi everybody, In my lab, after upgrading our Galaxy instance to the latest version, we have a problem with displaying tabular files. Any idea from where the problem can come? Thanks in advance to all. Mish ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client.
[galaxy-dev] error with unicode output
I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 265, in literal return self.escape(o, self.encoders) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 203, in unicode_literal return db.literal(u.encode(unicode_literal.charset)) UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position 11: ordinal not in range(256) There is a set of files created in the job_working_directory that start with 'metadata_', some of which contain the unicode. Is there anything I can do to fix this? David Hoover Helix Systems Staff ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] error with unicode output
Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh https://bitbucket.org/ro6ert/galaxy-central-hbc/src/966e4a5fe4bc/tools/scde_pathprint/discard_stderr_wrapper.sh?at=default. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat$TMPFILE 2 = cat*-v* $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 265, in literal return self.escape(o, self.encoders) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 203, in unicode_literal return db.literal(u.encode(unicode_literal.charset)) UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position 11: ordinal not in range(256) There is a set of files created in the job_working_directory that start with 'metadata_', some of which contain the unicode. Is there anything I can do to fix this? David Hoover Helix Systems Staff ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] error with unicode output
David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 265, in literal return self.escape(o, self.encoders) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 203, in unicode_literal return db.literal(u.encode(unicode_literal.charset)) UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position 11: ordinal not in range(256) There is a set of files created in the job_working_directory that start with 'metadata_', some of which contain the unicode. Is there anything I can do to fix this? David Hoover Helix Systems Staff ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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
Re: [galaxy-dev] error with unicode output
Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 265, in literal return self.escape(o, self.encoders) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 203, in unicode_literal return db.literal(u.encode(unicode_literal.charset)) UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position 11: ordinal not in range(256) There is a set of files created in the job_working_directory that start with 'metadata_',
Re: [galaxy-dev] error with unicode output
My version is 11216:c458a0fe1ba8. Does this cover the commit? On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 265, in literal return self.escape(o, self.encoders) File build/bdist.linux-x86_64/egg/MySQLdb/connections.py, line 203, in unicode_literal return db.literal(u.encode(unicode_literal.charset)) UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position
Re: [galaxy-dev] error with unicode output
Looks to yes... % hg contains -c c458a0fe1ba8 e786022dc67ed918050bd81b9ac679ac958e4f75 lookup for revision 'e786022dc67ed918050bd81b9ac679ac958e4f75' yields changeset 10953:e786022dc67e true You could also verify lib/galaxy/jobs/__init__.py contains the import from galaxy.util import unicodify. -John On Thu, Dec 5, 2013 at 11:49 AM, David Hoover hoove...@helix.nih.gov wrote: My version is 11216:c458a0fe1ba8. Does this cover the commit? On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args)
Re: [galaxy-dev] error with unicode output
Right, nevermind, 'hg log' listed that changeset 10953:e786022dc67e. Changing DEFAULT_ENCODING to 'latin-1' in lib/galaxy/util/__init__.py worked. Do I need to alter ALL the MySQL tables to UTF-8, or just a selection of tables? Will future updates explicitly create new tables with CHARSET=utf-8, or do I need to reconfigure MySQL to have a new default? -- David On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) File build/bdist.linux-x86_64/egg/MySQLdb/cursors.py, line 158, in execute query = query % db.literal(args) File
Re: [galaxy-dev] Problem installing tool_ Galaxy local
Hi Valeria, Please always replay-all to keep email threads on the original list. Your setting for tool_dependency_dir should not be as you've stated: tool_dependency_dir = tool_dependencies It should be an actual path on your local file system, something like: tool_dependency_dir = ../tool_dependencies If you use the above setting, then Galaxy should create a directory named tool_dependency_dir at the same level in your local file system hierarchy as your Galaxy installation directory. I cannot guarantee that this change will solve your problem, but it will be a step in the right direction. After making this change, let us know if you still see problems. Greg Von Kuster On Dec 5, 2013, at 12:13 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, Unfortunately, it is not working...sorry bug you again. I know nothing about programming...this is what I have done: ( I have tried to follow http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies) In universe_wsgi.ini modified #tool_dependency_dir = None tool_dependency_dir = tool_dependencies In shell Valerias-MacBook-Pro:galaxy-dist vrparreira$ cd tool_dependencies Valerias-MacBook-Pro:tool_dependencies vrparreira$ mkdir smart Valerias-MacBook-Pro:tool_dependencies vrparreira$ cd Valerias-MacBook-Pro:~ vrparreira$ cd galaxy-dist Valerias-MacBook-Pro:galaxy-dist vrparreira$ sh run.sh --reload This is what I see on the shell (I am not sure that is necessary): 127.0.0.1 - - [05/Dec/2013:11:52:59 -0400] GET /admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d HTTP/1.1 200 - http://localhost:8080/admin_toolshed/browse_repositories?status=donemessage=You+can+now+attempt+to+install+the+repository+named+%3Cb%3Es_mart%3C%2Fb%3E+again.; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,026 Loading new tool panel section: S-MART tool_shed.util.shed_util_common DEBUG 2013-12-05 11:53:16,026 Adding new row (or updating an existing row) for repository 's_mart' in the tool_shed_repository table, status set to 'New'. tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,039 Appending to tool panel section: S-MART 127.0.0.1 - - [05/Dec/2013:11:53:15 -0400] POST /admin_toolshed/prepare_for_install HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:19 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:22 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:25 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:28 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:31 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:34 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:37 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:40 -0400] POST
Re: [galaxy-dev] error with unicode output
Fantastic! For this particular problem - I guess you don't strictly need to modify more than just job and maybe task tables. I suspect at some point there will be a non-latin-1 job parameter or history name or username, etc... that will result in a similar problem though - so if you could just make it all UTF-8 that would probably be ideal. -John On Thu, Dec 5, 2013 at 12:01 PM, David Hoover hoove...@helix.nih.gov wrote: Right, nevermind, 'hg log' listed that changeset 10953:e786022dc67e. Changing DEFAULT_ENCODING to 'latin-1' in lib/galaxy/util/__init__.py worked. Do I need to alter ALL the MySQL tables to UTF-8, or just a selection of tables? Will future updates explicitly create new tables with CHARSET=utf-8, or do I need to reconfigure MySQL to have a new default? -- David On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 475, in execute uow File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 59, in save_obj mapper, table, update) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements execute(statement, params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1449, in execute params) File build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql,
Re: [galaxy-dev] error with unicode output
John, I stopped galaxy, then ran ALTER DATABASE galaxydb DEFAULT CHARACTER SET = 'utf8', then ran ALTER TABLE `[table]` DEFAULT CHARACTER SET = 'utf8' on all the tables in galaxydb. After starting up galaxy and rerunning the jobs (using the unaltered version of lib/galaxy/util/__init__.py), the job failed with the same error. Can I configure the sqlalchemy connection to use utf8? Or must I reconfigure the entire server to use utf8? --David On Dec 5, 2013, at 1:32 PM, John Chilton wrote: Fantastic! For this particular problem - I guess you don't strictly need to modify more than just job and maybe task tables. I suspect at some point there will be a non-latin-1 job parameter or history name or username, etc... that will result in a similar problem though - so if you could just make it all UTF-8 that would probably be ideal. -John On Thu, Dec 5, 2013 at 12:01 PM, David Hoover hoove...@helix.nih.gov wrote: Right, nevermind, 'hg log' listed that changeset 10953:e786022dc67e. Changing DEFAULT_ENCODING to 'latin-1' in lib/galaxy/util/__init__.py worked. Do I need to alter ALL the MySQL tables to UTF-8, or just a selection of tables? Will future updates explicitly create new tables with CHARSET=utf-8, or do I need to reconfigure MySQL to have a new default? -- David On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly with no problems. A recent update broke the tool. The job runs but is unable to finish. Here is the error reported: Traceback (most recent call last): File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) File /spin1/users/galaxy/galaxy/lib/galaxy/jobs/__init__.py, line 1015, in finish self.sa_session.flush() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/scoping.py, line 114, in do return getattr(self.registry(), name)(*args, **kwargs) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1718, in flush self._flush(objects) File build/bdist.linux-x86_64/egg/sqlalchemy/orm/session.py, line 1789, in _flush flush_context.execute() File build/bdist.linux-x86_64/egg/sqlalchemy/orm/unitofwork.py, line 331, in execute rec.execute(self) File
Re: [galaxy-dev] phyloviz: save visualization error
Hello, Karen This is a bug and I wanted to let you know I'm looking into it now: https://trello.com/c/dzBmbyqF Sorry for the frustration and thanks for the report, Carl On Mon, Dec 2, 2013 at 6:23 PM, Karen Miga khm...@soe.ucsc.edu wrote: Hello, I am trying to use phyloviz on the cloud/Galaxy cloudman. Unfortunately, I am unable to save the visualization using the save/disk icon on the right hand side of the banner. Any help would be appreciated. Karen ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem installing tool_ Galaxy local
What happens if you choose Reset to install from the Repository Actions menu? You should be presented with a page that shows the repository as uninstalled, at which time you can attempt to install it again. On Dec 5, 2013, at 3:11 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, It did not work...This is what I see: This repository is not installed correctly (see the Repository installation error below). Choose Reset to install from the Repository Actions menu, correct problems if necessary and try installing the repository again. However, there no information regarding ti the error below. What is your suggestion? VP From: Greg Von Kuster g...@bx.psu.edu To: Valeria Parreira Pinto vparr...@uoguelph.ca Cc: galaxy-...@bx.psu.edu Dev galaxy-...@bx.psu.edu Sent: Thursday, December 5, 2013 1:19:59 PM Subject: Re: [galaxy-dev] Problem installing tool_ Galaxy local Hi Valeria, Please always replay-all to keep email threads on the original list. Your setting for tool_dependency_dir should not be as you've stated: tool_dependency_dir = tool_dependencies It should be an actual path on your local file system, something like: tool_dependency_dir = ../tool_dependencies If you use the above setting, then Galaxy should create a directory named tool_dependency_dir at the same level in your local file system hierarchy as your Galaxy installation directory. I cannot guarantee that this change will solve your problem, but it will be a step in the right direction. After making this change, let us know if you still see problems. Greg Von Kuster On Dec 5, 2013, at 12:13 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, Unfortunately, it is not working...sorry bug you again. I know nothing about programming...this is what I have done: ( I have tried to follow http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies) In universe_wsgi.ini modified #tool_dependency_dir = None tool_dependency_dir = tool_dependencies In shell Valerias-MacBook-Pro:galaxy-dist vrparreira$ cd tool_dependencies Valerias-MacBook-Pro:tool_dependencies vrparreira$ mkdir smart Valerias-MacBook-Pro:tool_dependencies vrparreira$ cd Valerias-MacBook-Pro:~ vrparreira$ cd galaxy-dist Valerias-MacBook-Pro:galaxy-dist vrparreira$ sh run.sh --reload This is what I see on the shell (I am not sure that is necessary): 127.0.0.1 - - [05/Dec/2013:11:52:59 -0400] GET /admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d HTTP/1.1 200 - http://localhost:8080/admin_toolshed/browse_repositories?status=donemessage=You+can+now+attempt+to+install+the+repository+named+%3Cb%3Es_mart%3C%2Fb%3E+again.; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,026 Loading new tool panel section: S-MART tool_shed.util.shed_util_common DEBUG 2013-12-05 11:53:16,026 Adding new row (or updating an existing row) for repository 's_mart' in the tool_shed_repository table, status set to 'New'. tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,039 Appending to tool panel section: S-MART 127.0.0.1 - - [05/Dec/2013:11:53:15 -0400] POST /admin_toolshed/prepare_for_install HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:19 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:22 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:25 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:28 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:31 -0400] POST
Re: [galaxy-dev] Problem installing tool_ Galaxy local
Click on the Admin option from the top menu bar, then click on the Mange installed tool shed repositories. The find the s_mart repository from that page and clck on it. The from the Repository Actions menu, select Reset to install or Repair repository if it is available. On Dec 5, 2013, at 4:08 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, I have done at least twice just to double check From Repository actions - reset to install This is what a I see: Monitor installing tool shed repositories Name Description Owner RevisionStatus s_martS-MART manages your RNA-Seq and ChIP-Seq data. It also produces many different plots to visualize your data.yufei-luo b6481845eb0d Error The page Monitor installing tool shed repositories status error... VP From: Greg Von Kuster g...@bx.psu.edu To: Valeria Parreira Pinto vparr...@uoguelph.ca Cc: galaxy-...@bx.psu.edu Dev galaxy-...@bx.psu.edu Sent: Thursday, December 5, 2013 3:45:04 PM Subject: Re: [galaxy-dev] Problem installing tool_ Galaxy local What happens if you choose Reset to install from the Repository Actions menu? You should be presented with a page that shows the repository as uninstalled, at which time you can attempt to install it again. On Dec 5, 2013, at 3:11 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, It did not work...This is what I see: This repository is not installed correctly (see the Repository installation error below). Choose Reset to install from the Repository Actions menu, correct problems if necessary and try installing the repository again. However, there no information regarding ti the error below. What is your suggestion? VP From: Greg Von Kuster g...@bx.psu.edu To: Valeria Parreira Pinto vparr...@uoguelph.ca Cc: galaxy-...@bx.psu.edu Dev galaxy-...@bx.psu.edu Sent: Thursday, December 5, 2013 1:19:59 PM Subject: Re: [galaxy-dev] Problem installing tool_ Galaxy local Hi Valeria, Please always replay-all to keep email threads on the original list. Your setting for tool_dependency_dir should not be as you've stated: tool_dependency_dir = tool_dependencies It should be an actual path on your local file system, something like: tool_dependency_dir = ../tool_dependencies If you use the above setting, then Galaxy should create a directory named tool_dependency_dir at the same level in your local file system hierarchy as your Galaxy installation directory. I cannot guarantee that this change will solve your problem, but it will be a step in the right direction. After making this change, let us know if you still see problems. Greg Von Kuster On Dec 5, 2013, at 12:13 PM, Valeria Parreira Pinto vparr...@uoguelph.ca wrote: Hi Greg, Unfortunately, it is not working...sorry bug you again. I know nothing about programming...this is what I have done: ( I have tried to follow http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies) In universe_wsgi.ini modified #tool_dependency_dir = None tool_dependency_dir = tool_dependencies In shell Valerias-MacBook-Pro:galaxy-dist vrparreira$ cd tool_dependencies Valerias-MacBook-Pro:tool_dependencies vrparreira$ mkdir smart Valerias-MacBook-Pro:tool_dependencies vrparreira$ cd Valerias-MacBook-Pro:~ vrparreira$ cd galaxy-dist Valerias-MacBook-Pro:galaxy-dist vrparreira$ sh run.sh --reload This is what I see on the shell (I am not sure that is necessary): 127.0.0.1 - - [05/Dec/2013:11:52:59 -0400] GET /admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d HTTP/1.1 200 - http://localhost:8080/admin_toolshed/browse_repositories?status=donemessage=You+can+now+attempt+to+install+the+repository+named+%3Cb%3Es_mart%3C%2Fb%3E+again.; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,026 Loading new tool panel section: S-MART tool_shed.util.shed_util_common DEBUG 2013-12-05 11:53:16,026 Adding new row (or updating an existing row) for repository 's_mart' in the tool_shed_repository table, status set to 'New'. tool_shed.util.tool_util DEBUG 2013-12-05 11:53:16,039 Appending to tool panel section: S-MART 127.0.0.1 - - [05/Dec/2013:11:53:15 -0400] POST /admin_toolshed/prepare_for_install HTTP/1.1 200 - http://localhost:8080/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed.g2.bx.psu.edu/repository_ids=613e73b56070623cchangeset_revisions=b6481845eb0d; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 127.0.0.1 - - [05/Dec/2013:11:53:19 -0400] POST /admin_toolshed/repository_installation_status_updates HTTP/1.1 200 -
Re: [galaxy-dev] error with unicode output
Hmmm... can you try adding ?charset=utf8 to your database connection string - that may fix the problem? If not - is there a way to tell if the actual columns have changed. Some comments on stackoverflow make it sound like the commands you listed will only affect new columns. Can you try the CONVERT TO CHARACTER SET. ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci; I don't think the problem is sqlalchemy right - this works for postgres and sqlite I believe - it is either that MySQL cannot store UTF-8 data in that column or there is a problem in the mysql connector. It is not clear to me where the problem is based on your stack trace and explanation. I would be happy to work around a limitation in the mysql connector by adding a config option to Galaxy if I were certain that there was a bug in the mysql connector. -John On Thu, Dec 5, 2013 at 12:55 PM, David Hoover hoove...@helix.nih.gov wrote: John, I stopped galaxy, then ran ALTER DATABASE galaxydb DEFAULT CHARACTER SET = 'utf8', then ran ALTER TABLE `[table]` DEFAULT CHARACTER SET = 'utf8' on all the tables in galaxydb. After starting up galaxy and rerunning the jobs (using the unaltered version of lib/galaxy/util/__init__.py), the job failed with the same error. Can I configure the sqlalchemy connection to use utf8? Or must I reconfigure the entire server to use utf8? --David On Dec 5, 2013, at 1:32 PM, John Chilton wrote: Fantastic! For this particular problem - I guess you don't strictly need to modify more than just job and maybe task tables. I suspect at some point there will be a non-latin-1 job parameter or history name or username, etc... that will result in a similar problem though - so if you could just make it all UTF-8 that would probably be ideal. -John On Thu, Dec 5, 2013 at 12:01 PM, David Hoover hoove...@helix.nih.gov wrote: Right, nevermind, 'hg log' listed that changeset 10953:e786022dc67e. Changing DEFAULT_ENCODING to 'latin-1' in lib/galaxy/util/__init__.py worked. Do I need to alter ALL the MySQL tables to UTF-8, or just a selection of tables? Will future updates explicitly create new tables with CHARSET=utf-8, or do I need to reconfigure MySQL to have a new default? -- David On Dec 5, 2013, at 12:32 PM, John Chilton wrote: Actually, can you verify that this commit https://bitbucket.org/galaxy/galaxy-central/commits/e786022dc67ed918050bd81b9ac679ac958e4f75 is in your distribution and if it is try changing: DEFAULT_ENCODING = 'utf-8' in lib/galaxy/util.py to DEFAULT_ENCODING = 'latin-1' If that works then - I can create a database_encoding_default option in universe_wsgi.ini and let you switch it to latin-1 instead of needing to patch Galaxy. Otherwise, setting the MySQL tables to be UTF-8 is probably the better approach - though again - backup and test before applying that change in production. Hope this helps, -John On Thu, Dec 5, 2013 at 11:17 AM, John Chilton chil...@msi.umn.edu wrote: David, Christian, Very sorry about this - this is probably related to fixing some other errors - http://dev.list.galaxyproject.org/Unicode-in-tool-stderr-crashing-galaxy-tt4661749.html#a4661750. I will try to look into this. Christian - what database are targeting? Is it MySQL as well? David - do you have a test setup you can hack on? I wonder if this would go away if you converted your tables to UTF-8. http://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8 That is not my official recommendation though - I need to do some more research first. -John On Thu, Dec 5, 2013 at 11:04 AM, Christian Hundsrucker christian.hundsruc...@fmi.ch wrote: Hi David, hi all! I have a similar/the same issue in another setting... galaxy/galaxy_dist/lib/galaxy/jobs/runners/local.py, line 116, in queue_job job_wrapper.finish( stdout, stderr, exit_code ) [...] galaxy/galaxy_dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.py, line 485, in _emit_update_statements [...] UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 134: ordinal not in range(256) I am integrating a set of R/Bioconductor modules into our local Galaxy instance. To do so, I use the discard_stderr_wrapper.sh. It worked fine until the recent update* As the error appears upon any R-output (via print, cat or error channel), I just set the option -v for the cat command in the discard_stderr_wrapper.sh: cat $TMPFILE 2 = cat -v $TMPFILE 2 as a temporary workaround. No idea if this is applicable in your case?! Cheers, Christian * changeset: 11219:5c789ab4144a branch: stable tag: tip On 05.12.2013 17:29, David Hoover wrote: I have installed the ngsplot galaxy tool from http://code.google.com/p/ngsplot. This tool creates a set of three pdf files. In older versions of Galaxy, the tool ran correctly
[galaxy-dev] How to get an API key during execution?
Hi,
I know that if I put :
${ __app__.model.User.get( $__user_id__ ).api_keys[0].key }
in my tools xml file I am able to get the current api key.
The xml calls my python script with this value, which i then use to execute
workflows via the API.
However, if this is value empty/blank is there a way I can generate an api key
it from within my python script. i.e. is there a method I can call which would
generate this for me?
Thanks
Neil
___
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/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
