Difficulties using <repeat> tagset with min attribute
by Cory Spencer
Hi all -
I've been trying to get the <repeat>...</repeat> tag working with a min attribute for some time now, though without any success. It works in other tools distributed with Galaxy, but when I attempt to use it in one of our custom tools, it dies with a "AttributeError: 'ExpressionContext' object has no attribute 'keys'" exception.
Can anybody offer any insight?
The full traceback is:
⇝ AttributeError: 'ExpressionContext' object has no attribute 'keys'
URL: http://localhost:8080/tool_runner?tool_id=scde-list-compare
Module weberror.evalexception.middleware:364 in respond view
>> app_iter = self.application(environ, detect_start_response)
Module paste.debug.prints:98 in __call__ view
>> environ, self.app)
Module paste.wsgilib:539 in intercept_output view
>> app_iter = application(environ, replacement_start_response)
Module paste.recursive:80 in __call__ view
>> return self.application(environ, start_response)
Module paste.httpexceptions:632 in __call__ view
>> return self.application(environ, start_response)
Module galaxy.web.framework.base:160 in __call__ view
>> body = method( trans, **kwargs )
Module galaxy.web.controllers.tool_runner:68 in index view
>> template, vars = tool.handle_input( trans, params.__dict__ )
Module galaxy.tools:1320 in handle_input view
>> state = self.new_state( trans )
Module galaxy.tools:1248 in new_state view
>> self.fill_in_new_state( trans, inputs, state.inputs )
Module galaxy.tools:1257 in fill_in_new_state view
>> state[ input.name ] = input.get_initial_value( trans, context )
Module galaxy.tools.parameters.grouping:100 in get_initial_value view
>> rval_dict[ input.name ] = input.get_initial_value( trans, context )
Module galaxy.tools.parameters.basic:1016 in get_initial_value view
>> return SelectToolParameter.get_initial_value( self, trans, context )
Module galaxy.tools.parameters.basic:785 in get_initial_value view
>> if self.need_late_validation( trans, context ):
Module galaxy.tools.parameters.basic:1022 in need_late_validation view
>> if super( ColumnListParameter, self ).need_late_validation( trans, context ):
Module galaxy.tools.parameters.basic:766 in need_late_validation view
>> for layer in context.itervalues():
Module UserDict:116 in itervalues view
>> for _, v in self.iteritems():
Module UserDict:109 in iteritems view
>> for k in self:
Module UserDict:96 in __iter__ view
>> for k in self.keys():
AttributeError: 'ExpressionContext' object has no attribute 'keys'
6 years, 9 months
Strange issue where the dataset reported in the bug report doesn't correspond to the current dataset
by Jean-Francois Payotte
Dear Galaxy mailing-list,
We are currently facing a strange issue with our local Galaxy installation
(distribution from Jan. 11 2013).
I'm going to try to describe the problem as much as I can, and feel free
to ask for more details if it can help in solving this issue.
So basically, we have a situation where (about half the time), when a job
ends in error, the error message (shown when clicking on the bug icon),
doesn't seem to be related to the dataset in error.
As this particular problem seem to be present only when datasets ends in
error, I created a simple python script which simply does 2 things:
It outputs the hostname to stdout (in order to investigate if the problem
is node-dependant)
It outputs the following message "This is an error message printed to
stderr", to stderr. (This is done in order to get only error datasets and
to investigate the before-mentioned issue.)
Here is the code of my python script:
import sys
import socket
def main():
print socket.gethostname()
sys.stderr.write('This is an error message printed to stderr\n')
if __name__ == '__main__':
main()
I ran this tool about 50 times and I looked at the error messages
displayed both in the preview section of the dataset (in the history), and
the error message displayed when clicking on the bug icon "view or report
this error".
About half the time, the results were as expected:
the dataset stdout would read the name of the node where the job was
executed
the dataset stderr would read: "This is an error message printed to
stderr"
and the error message displayed when clicking on the bug icon would be:
Dataset generation errors
Dataset 54: Test error
Tool execution generated the following error message:
This is an error message printed to stderr
The tool produced the following additional output:
some.server.name
However, the other half of the time, the error message shown in stderr
doesn't correspond to the error message displayed when clicking on the bug
icon:
the dataset stdout is still reading the name of the node
the dataset stderr is still reading "This is an error message printed to
stderr"
but the error message displayed when clicking on the bug icon would be
something like:
Dataset generation errors
Dataset 3: chrM.bed
Tool execution did not generate any error messages.
We can clearly see a discrepancy between the error message in stderr and
the error message of the bug report. Actually, the bug report is saying
that there is not any error and it makes reference to some "Dataset 3:
chrM.bed", even when the actual dataset is "Dataset 53: Test error". There
is absolutely no .bed file in my history and the dataset 3 actually reads
"Dataset 3: Test error". Some of the datasets mentioned in the faulty bug
reports seems to be really old datasets (like one year old).
So my question to you is, could this be related to some mix-up between
datasets ID? And how can I look this up.
I must say that at the moment, I have absolutely no idea how to solve this
issue.
Many thanks for your help!
Best regards,
Jean-François
6 years, 9 months
Conditional tool options based on input file format?
by Peter Cock
Dear all,
I've looked over the wiki and as far as I can see, 'when' tags used inside
'conditional' tags only work on another input variable's values.
I would like to be able to do is a conditional based on the file format
of an input file. For instance, a tool might take XML or tabular files,
and need to show additional parameters for one input type but not the
other.
Does this enhancement idea seem useful?
Peter
6 years, 9 months
user creation using API
by Hagai Cohen
Hi,
I would like to auto create users on my local Galaxy instance.
I saw that in the "create user" on the API, I should enable use_remote_user
(which as I understand means that I have to use Apache or nginx).
Is there another way besides using Apache to create users automatically?
Thanks,
Hagai
6 years, 9 months
ASN.1 (text and binary) formats in Galaxy & Tool Shed
by Peter Cock
Hello all,
Although they are these days also offering XML for many tools,
the NCBI still make heavy use of the older ASN.1 file format
(both as plain text and binary). This crops up in BLAST (e.g.
as the BLAST archive format, or as dustmasker output), in
the Entrez Utilities (e.g. for sequence data as an alternative
to GenBank for FASTA format etc, or pubmed, etc) and also
for 3D structures.
I think it could make sense to define generic 'asn1' and
'asn1-binary' formats in the Galaxy core (name suggestions
welcome), and even perhaps 'ncbi-asn1' and 'ncbi-asn1-binary'
too. Then ToolShed entries can define domain specific
subclasses. For instance, the BLAST+ wrapper could include
definitions for the dustmasker output, and perhaps the BLAST
archive format too. Separately anyone working with 3D
structures as ASN.1 could define another sub-format, etc.
I see this as a clear analogy to the assorted XML file formats
in existence - defined in Galaxy as subclasses of the core
XML format included with the Galaxy core.
Would a pull request implementing this be acceptable?
Peter
P.S. Does anyone know an authoritative source for the MIME
types used by the NCBI? Using the BLAST website they
offer plain text ASN.1 just as text/plain, likewise efetch also
seems to use text/plain for ASN.1 downloads. However I've
seen references to chemical/ncbi-asn1-ascii and
chemical/ncbi-asn1-binary mime-types mentioned, e.g.
http://www.ncbi.nlm.nih.gov/data_specs/asn/NCBI_all.asn
i.e. It appears that 3D structure NCBI ASN.1 files use
a well defined MIME type, while most NCBI ASN.1 text
files default to text/plain - which we can handle nicely in
Galaxy as subclasses.
6 years, 9 months
Adding data sources in the main galaxy instance
by Fingerman, Ian (NIH/NLM/NCBI) [E]
I have a question regarding data sources currently available on the main instance of Galaxy (https://main.g2.bx.psu.edu). How can one get added as a new data source? I work at the NCBI on the Epigenomics database (http://www.ncbi.nlm.nih.gov/epigenomics) . We currently hold a large volume of NGS data in the form of wig files, and some users have expressed interest in using Galaxy for data analysis. We provide an easy to use user interface for examining these data as seen here (http://www.ncbi.nlm.nih.gov/epigenomics/browse/) and currently host over 4200 data tracks.
I think it would useful if we could integrate Galaxy functionality into our resource. I also thing providing our resource as a "Data Source" would also be convenient for users less familiar with our database but are current Galaxy users.
I have been looking through the Galaxy wiki and I am struggling to find documentation that details step-by-step, what exactly needs to be done. One thing to note, I am not a developer, I'm the scientific lead for the project and my programming/developing skills are lacking. I was hoping someone could point me to thorough documentation mainly to pass on to developers on my team. I guess also understanding my options with regards to integrating or interfacing with Galaxy would be very valuable to me too.
Thank you for any help/suggestions you may have.
Ian
Ian Fingerman, Ph.D.
Staff Scientist
NIH/NLM/NCBI
Building 45, Room 4AN28D-29
45 Center Drive MSC-6510
Bethesda, MD 20894
Phone: (301) 496-6806
fingerma(a)ncbi.nlm.nih.gov
6 years, 9 months
Galaxy hg repository problem "abort: path ... traverses symbolic link"
by Peter Cock
Hi all,
I've got an hg puzzle, can anyone on the Galaxy team explain the
cause of this and what action I can take to avoid it?
Starting with a clean checkout,
$ hg clone https://bitbucket.org/galaxy/galaxy-central
warning: bitbucket.org certificate with fingerprint
24:9c:45:8b:9c:aa:ba:55:4e:01:6d:58:ff:e4:28:7d:2a:14:ae:3b not
verified (check hostfingerprints or web.cacerts config setting)
destination directory: galaxy-central
requesting all changes
adding changesets
adding manifests
adding file changes
added 8886 changesets with 33822 changes to 6914 files (+1 heads)
updating to branch default
4019 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd galaxy-central
$ hg branch
default
$ hg branches
default 8885:9852dd712f5c
stable 8880:8da37d3985ab
$ hg checkout stable
abort: path 'static/june_2007_style/Makefile' traverses symbolic link
'static/june_2007_style'
I was actually trying to checkout one of my own branches, having
setup the .hg/hgrc to include a link to my own fork on bitbucket.
Thanks!
Peter
6 years, 9 months
Speed up the galaxy
by 泽 蔡
Hi all,
How can I speed up the galaxy? Like how to use more cores and memeries.
6 years, 10 months
Puzzling test failure with data_column parameter
by Peter Cock
Hi all,
I'm working on a FASTA filter script, as per this email:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-November/003819.html
Current code here:
http://bitbucket.org/peterjc/galaxy-central/src/c3ac6d7a02f7/
I've added a basic test, but it won't run (see output below). I think
the interesting bit of the error output is this exception: cannot find
value/label "blastp_four_human_vs_rhodopsin.tabular" in list control,
coming from function set_form_control_value in the twill.utils module.
This is something to do with the columns parameter, a multiselect
option referencing the columns in this tabular file. Removing the
validator makes no difference. However, if I change the columns
parameter to a plain text parameter, the test passes:
$ hg diff
diff -r c3ac6d7a02f7 tools/fasta_tools/fasta_filter_by_id.xml
--- a/tools/fasta_tools/fasta_filter_by_id.xml Tue Nov 23 11:37:35 2010 +0000
+++ b/tools/fasta_tools/fasta_filter_by_id.xml Tue Nov 23 14:03:31 2010 +0000
@@ -4,9 +4,7 @@
<inputs>
<param name="input_fasta" type="data" format="fasta" label="FASTA
file to filter on the identifiers"/>
<param name="input_tabular" type="data" format="tabular"
label="Tabular file containing FASTA identifiers"/>
- <param name="columns" type="data_column" data_ref="input_tabular"
multiple="True" numerical="False" label="Column(s) containing FASTA
identifiers" help="Multi-select list - hold the appropriate key while
clicking to select multiple columns">
- <validator type="no_options" message="Pick at least one column"/>
- </param>
+ <param name="columns" type="text" label="Column(s) containing FASTA
identifiers" />
</inputs>
<outputs>
<data name="output_pos" format="fasta" label="With matched ID" />
I've tried searching the provided wrappers for similar examples (column
multi-select from a tabular file). I found filters/uniq.xml (works but uses
a bed file rather than a simple tabular file) and stats/cor.xml (needs R
and rpy which I don't have installed yet) which have tests, and finally
plotting/bar_chart.xml which has no unit tests.
Would someone familiar with the internals of the Galaxy tests and
how they set tool parameters be able to try reproducing this for me?
The branch has all the unit test files required, and there are no new
dependencies needed.
Thank you,
Peter
--
Here is the output (on Linux - other tests tried pass):
$ ./run_functional_tests.sh -id fasta_filter_by_id
...
nose.plugins.manager DEBUG 2010-11-23 13:59:32,958
DefaultPluginManager load plugin sqlalchemy =
sqlalchemy.test.noseplugin:NoseSQLAlchemy
nose.plugins.manager DEBUG 2010-11-23 13:59:32,961
DefaultPluginManager load plugin nosetestdiff =
nosetestdiff.plugin:NoseTestDiff
nose.plugins.manager DEBUG 2010-11-23 13:59:32,962
DefaultPluginManager load plugin nosehtml = nosehtml.plugin:NoseHTML
Filter sequences by ID ( fasta_filter_by_id ) > Test-1 ...
galaxy.tools.actions.upload_common INFO 2010-11-23 13:59:34,905 tool
upload1 created job id 1
galaxy.jobs DEBUG 2010-11-23 13:59:42,709 dispatching job 1 to local runner
galaxy.jobs INFO 2010-11-23 13:59:42,899 job 1 dispatched
galaxy.jobs.runners.local DEBUG 2010-11-23 13:59:43,213 executing:
python /home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmpOVlriT
1:/home/pjcock/repositories/galaxy-central/database/job_working_directory/1/dataset_1_files:/tmp/tmpu4uu_o/database/files/000/dataset_1.dat
galaxy.jobs.runners.local DEBUG 2010-11-23 13:59:44,033 execution
finished: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmpOVlriT
1:/home/pjcock/repositories/galaxy-central/database/job_working_directory/1/dataset_1_files:/tmp/tmpu4uu_o/database/files/000/dataset_1.dat
galaxy.jobs DEBUG 2010-11-23 13:59:44,414 job 1 ended
galaxy.tools.actions.upload_common INFO 2010-11-23 13:59:49,927 tool
upload1 created job id 2
galaxy.jobs DEBUG 2010-11-23 13:59:50,067 dispatching job 2 to local runner
galaxy.jobs INFO 2010-11-23 13:59:50,702 job 2 dispatched
galaxy.jobs.runners.local DEBUG 2010-11-23 13:59:52,059 executing:
python /home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmp6Z76yl
2:/home/pjcock/repositories/galaxy-central/database/job_working_directory/2/dataset_2_files:/tmp/tmpu4uu_o/database/files/000/dataset_2.dat
galaxy.jobs.runners.local DEBUG 2010-11-23 13:59:52,874 execution
finished: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmp6Z76yl
2:/home/pjcock/repositories/galaxy-central/database/job_working_directory/2/dataset_2_files:/tmp/tmpu4uu_o/database/files/000/dataset_2.dat
galaxy.jobs DEBUG 2010-11-23 13:59:53,420 job 2 ended
base.twilltestcase DEBUG 2010-11-23 13:59:53,747 In submit_form,
continuing, but caught exception: cannot find value/label
"blastp_four_human_vs_rhodopsin.tabular" in list control
base.twilltestcase DEBUG 2010-11-23 13:59:54,488 ## files diff on
/home/pjcock/repositories/galaxy-central/test-data/four_human_proteins_filter_a.fasta
and /tmp/tmpijWxYGfour_human_proteins_filter_a.fasta lines_diff=0,
found diff = 61
FAIL
======================================================================
FAIL: Filter sequences by ID ( fasta_filter_by_id ) > Test-1
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/pjcock/repositories/galaxy-central/test/functional/test_toolbox.py",
line 160, in test_tool
self.do_it( td )
File "/home/pjcock/repositories/galaxy-central/test/functional/test_toolbox.py",
line 101, in do_it
self.verify_dataset_correctness( outfile, hid=elem_hid,
maxseconds=testdef.maxseconds, attributes=attributes )
File "/home/pjcock/repositories/galaxy-central/test/base/twilltestcase.py",
line 656, in verify_dataset_correctness
raise AssertionError( errmsg )
AssertionError: History item 1 different than expected, difference (using diff):
--- local_file
+++ history_data
@@ -1,2 +1,61 @@
+>sp|Q9BS26|ERP44_HUMAN Endoplasmic reticulum resident protein 44
OS=Homo sapiens GN=ERP44 PE=1 SV=1
+MHPAVFLSLPDLRCSLLLLVTWVFTPVTTEITSLDTENIDEILNNADVALVNFYADWCRF
+SQMLHPIFEEASDVIKEEFPNENQVVFARVDCDQHSDIAQRYRISKYPTLKLFRNGMMMK
+REYRGQRSVKALADYIRQQKSDPIQEIRDLAEITTLDRSKRNIIGYFEQKDSDNYRVFER
+VANILHDDCAFLSAFGDVSKPERYSGDNIIYKPPGHSAPDMVYLGAMTNFDVTYNWIQDK
+CVPLVREITFENGEELTEEGLPFLILFHMKEDTESLEIFQNEVARQLISEKGTINFLHAD
+CDKFRHPLLHIQKTPADCPVIAIDSFRHMYVFGDFKDVLIPGKLKQFVFDLHSGKLHREF
+HHGPDPTDTAPGEQAQDVASSPPESSFQKLAPSEYRYTLLRDRDEL
+>sp|Q9NSY1|BMP2K_HUMAN BMP-2-inducible protein kinase OS=Homo sapiens
GN=BMP2K PE=1 SV=2
+MKKFSRMPKSEGGSGGGAAGGGAGGAGAGAGCGSGGSSVGVRVFAVGRHQVTLEESLAEG
+GFSTVFLVRTHGGIRCALKRMYVNNMPDLNVCKREITIMKELSGHKNIVGYLDCAVNSIS
+DNVWEVLILMEYCRAGQVVNQMNKKLQTGFTEPEVLQIFCDTCEAVARLHQCKTPIIHRD
+LKVENILLNDGGNYVLCDFGSATNKFLNPQKDGVNVVEEEIKKYTTLSYRAPEMINLYGG
+KPITTKADIWALGCLLYKLCFFTLPFGESQVAICDGNFTIPDNSRYSRNIHCLIRFMLEP
+DPEHRPDIFQVSYFAFKFAKKDCPVSNINNSSIPSALPEPMTASEAAARKSQIKARITDT
+IGPTETSIAPRQRPKANSATTATPSVLTIQSSATPVKVLAPGEFGNHRPKGALRPGNGPE
+ILLGQGPPQQPPQQHRVLQQLQQGDWRLQQLHLQHRHPHQQQQQQQQQQQQQQQQQQQQQ
+QQQQQQHHHHHHHHLLQDAYMQQYQHATQQQQMLQQQFLMHSVYQPQPSASQYPTMMPQY
+QQAFFQQQMLAQHQPSQQQASPEYLTSPQEFSPALVSYTSSLPAQVGTIMDSSYSANRSV
+ADKEAIANFTNQKNISNPPDMSGWNPFGEDNFSKLTEEELLDREFDLLRSNRLEERASSD
+KNVDSLSAPHNHPPEDPFGSVPFISHSGSPEKKAEHSSINQENGTANPIKNGKTSPASKD
+QRTGKKTSVQGQVQKGNDESESDFESDPPSPKSSEEEEQDDEEVLQGEQGDFNDDDTEPE
+NLGHRPLLMDSEDEEEEEKHSSDSDYEQAKAKYSDMSSVYRDRSGSGPTQDLNTILLTSA
+QLSSDVAVETPKQEFDVFGAVPFFAVRAQQPQQEKNEKNLPQHRFPAAGLEQEEFDVFTK
+APFSKKVNVQECHAVGPEAHTIPGYPKSVDVFGSTPFQPFLTSTSKSESNEDLFGLVPFD
+EITGSQQQKVKQRSLQKLSSRQRRTKQDMSKSNGKRHHGTPTSTKKTLKPTYRTPERARR
+HKKVGRRDSQSSNEFLTISDSKENISVALTDGKDRGNVLQPEESLLDPFGAKPFHSPDLS
+WHPPHQGLSDIRADHNTVLPGRPRQNSLHGSFHSADVLKMDDFGAVPFTELVVQSITPHQ
+SQQSQPVELDPFGAAPFPSKQ
+>sp|P06213|INSR_HUMAN Insulin receptor OS=Homo sapiens GN=INSR PE=1 SV=4
+MATGGRRGAAAAPLLVAVAALLLGAAGHLYPGEVCPGMDIRNNLTRLHELENCSVIEGHL
+QILLMFKTRPEDFRDLSFPKLIMITDYLLLFRVYGLESLKDLFPNLTVIRGSRLFFNYAL
+VIFEMVHLKELGLYNLMNITRGSVRIEKNNELCYLATIDWSRILDSVEDNYIVLNKDDNE
+ECGDICPGTAKGKTNCPATVINGQFVERCWTHSHCQKVCPTICKSHGCTAEGLCCHSECL
+GNCSQPDDPTKCVACRNFYLDGRCVETCPPPYYHFQDWRCVNFSFCQDLHHKCKNSRRQG
+CHQYVIHNNKCIPECPSGYTMNSSNLLCTPCLGPCPKVCHLLEGEKTIDSVTSAQELRGC
+TVINGSLIINIRGGNNLAAELEANLGLIEEISGYLKIRRSYALVSLSFFRKLRLIRGETL
-------------------- >> begin captured stdout << ---------------------
Uploaded file: four_human_proteins.fasta , ftype: fasta , extra:
{'ftype': 'fasta', 'value': 'four_human_proteins.fasta', 'children':
[]}
Uploaded file: blastp_four_human_vs_rhodopsin.tabular , ftype:
tabular , extra: {'ftype': 'tabular', 'value':
'blastp_four_human_vs_rhodopsin.tabular', 'children': []}
form 'tool_form' contains the following controls ( note the values )
control 0: <HiddenControl(tool_id=fasta_filter_by_id) (readonly)>
control 1: <HiddenControl(tool_state=800255c1626362313139396662383639346664316133316565303361646336323163663764636566333538623a376232323566356637303631363736353566356632323361323033303263323032323639366537303735373435663636363137333734363132323361323032323331323232633230323236333666366337353664366537333232336132303232366537353663366332323263323032323639366537303735373435663734363136323735366336313732323233613230323233323232376471002e)
(readonly)>
control 2: <SelectControl(input_fasta=[*1])>
control 3: <SelectControl(input_tabular=[*2])>
control 4: <SelectControl(columns=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])>
control 5: <SubmitControl(runtool_btn=Execute) (readonly)>
page_inputs (0) {'input_fasta': ['four_human_proteins.fasta'],
'columns': ['1'], 'input_tabular':
['blastp_four_human_vs_rhodopsin.tabular']}
--------------------- >> end captured stdout << ----------------------
-------------------- >> begin captured logging << --------------------
galaxy.tools.actions.upload_common: INFO: tool upload1 created job id 1
galaxy.jobs: DEBUG: dispatching job 1 to local runner
galaxy.jobs: INFO: job 1 dispatched
galaxy.jobs.runners.local: DEBUG: executing: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmpOVlriT
1:/home/pjcock/repositories/galaxy-central/database/job_working_directory/1/dataset_1_files:/tmp/tmpu4uu_o/database/files/000/dataset_1.dat
galaxy.jobs.runners.local: DEBUG: execution finished: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmpOVlriT
1:/home/pjcock/repositories/galaxy-central/database/job_working_directory/1/dataset_1_files:/tmp/tmpu4uu_o/database/files/000/dataset_1.dat
galaxy.jobs: DEBUG: job 1 ended
galaxy.tools.actions.upload_common: INFO: tool upload1 created job id 2
galaxy.jobs: DEBUG: dispatching job 2 to local runner
galaxy.jobs: INFO: job 2 dispatched
galaxy.jobs.runners.local: DEBUG: executing: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmp6Z76yl
2:/home/pjcock/repositories/galaxy-central/database/job_working_directory/2/dataset_2_files:/tmp/tmpu4uu_o/database/files/000/dataset_2.dat
galaxy.jobs.runners.local: DEBUG: execution finished: python
/home/pjcock/repositories/galaxy-central/tools/data_source/upload.py
/home/pjcock/repositories/galaxy-central
/home/pjcock/repositories/galaxy-central/datatypes_conf.xml
/tmp/tmp6Z76yl
2:/home/pjcock/repositories/galaxy-central/database/job_working_directory/2/dataset_2_files:/tmp/tmpu4uu_o/database/files/000/dataset_2.dat
galaxy.jobs: DEBUG: job 2 ended
base.twilltestcase: DEBUG: In submit_form, continuing, but caught
exception: cannot find value/label
"blastp_four_human_vs_rhodopsin.tabular" in list control
base.twilltestcase: DEBUG: ## files diff on
/home/pjcock/repositories/galaxy-central/test-data/four_human_proteins_filter_a.fasta
and /tmp/tmpijWxYGfour_human_proteins_filter_a.fasta lines_diff=0,
found diff = 61
--------------------- >> end captured logging << ---------------------
----------------------------------------------------------------------
Ran 1 test in 21.504s
FAILED (failures=1)
functional_tests.py INFO 2010-11-23 13:59:54,494 Shutting down
functional_tests.py INFO 2010-11-23 13:59:54,494 Shutting down
embedded web server
functional_tests.py INFO 2010-11-23 13:59:54,497 Embedded web server stopped
functional_tests.py INFO 2010-11-23 13:59:54,497 Shutting down app
galaxy.jobs INFO 2010-11-23 13:59:54,497 sending stop signal to worker thread
galaxy.jobs INFO 2010-11-23 13:59:54,498 job queue stopped
galaxy.jobs.runners.local INFO 2010-11-23 13:59:54,498 sending stop
signal to worker threads
galaxy.jobs.runners.local INFO 2010-11-23 13:59:54,498 local job runner stopped
galaxy.jobs INFO 2010-11-23 13:59:54,499 sending stop signal to worker thread
galaxy.jobs INFO 2010-11-23 13:59:54,499 job stopper stopped
functional_tests.py INFO 2010-11-23 13:59:54,499 Embedded Universe
application stopped
functional_tests.py INFO 2010-11-23 13:59:54,500 Cleaning up temporary
files in /tmp/tmpu4uu_o
galaxy.jobs INFO 2010-11-23 13:59:55,410 sending stop signal to worker thread
galaxy.jobs INFO 2010-11-23 13:59:55,411 job queue stopped
galaxy.jobs.runners.local INFO 2010-11-23 13:59:55,411 sending stop
signal to worker threads
galaxy.jobs.runners.local INFO 2010-11-23 13:59:55,411 local job runner stopped
galaxy.jobs INFO 2010-11-23 13:59:55,411 sending stop signal to worker thread
galaxy.jobs INFO 2010-11-23 13:59:55,412 job stopper stopped
'run_functional_tests.sh help' for help
Note: galaxy test framework uses tool_conf.xml.sample, not tool_conf.xml
6 years, 10 months
directory copies as zero-length file from job_working_directory?
by Nikhil Joshi
Hi all,
So I have a tool that I am writing a wrapper script for that produces a
directory of images as one of its outputs. This directory gets created
just fine in the job_working_directory, but then when the job finishes and
the contents of the job_working_directory are copied, the copy of the
images directory is a zero-length *file*. I seem to recall having this
problem before and finding a solution to it, but now I can't seem to find
it. Any ideas?
- Nik.
--
Nikhil Joshi
Bioinformatics Analyst/Programmer
UC Davis Bioinformatics Core
http://bioinformatics.ucdavis.edu/
najoshi -at- ucdavis -dot- edu
530.752.2698 (w)
6 years, 10 months
