Hi all - I'm running Galaxy on my Redhat linux cluster. When I run
cufflinks from the shell I get the error/warning:
cufflinks: /usr/lib64/libz.so.1: no version information available (required
by cufflinks)
but it still seems to run ok. It looks like Galaxy is choking on this. I
tried
However, when I tried to use the Edit Pages function, there is no Embed
Galaxy Object and Insert Link to Galaxy Object in the Page Editor. I
have set the enable_pages = True in universe_wsgi.ini.
Wonder what else can cause the problem?
Charlie,
This bug has been fixed in galaxy-central
It looks like the output only occurs when cufflinks can't run on the
provided dataset. I checked my inputs, and I think that is the
problem...its a sam file from bowtie, not from tophat, hence not a sorted
sam file. Perhaps this stderr message doesn't matter after all, its just
Hi Sarah,
I created your workflow on my Galaxy instance and was able to export it
successfully, so updating your Galaxy instance may solve your problem. If not,
let us know and we'll take a closer look.
Finally, please direct your questions to one of our mailing lists rather than
individual
Assaf,
Assuming cuffcompare generates a TMAP and REFMAP file for each input
file, does this mean the wrapper tool retrieves only the first and
second input files' TMAP and REFMAP files ?
Yes, this is the way it works currently. This is clearly problematic,
but it meets most users' needs
workflow whose download fails. I recreated
the workflow at the public instance at http://main.g2.bx.psu.edu and
shared it with you. There the download also fails for me.
Best regards,
Sarah
On 04/14/2011 02:55 PM, Jeremy Goecks wrote:
Sarah,
Can you make your server available to me
Paul,
Sorry for the slow reply. We've been discussing this issue internally:
For the project that I'm currently working on, I need to have a link to one
particular workflow appear in the Tools left-hand side panel/frame for every
user that logs in to Galaxy. They shouldn't have to import
Olen,
This is a runtime error, not an update error; it is occurring because we
mistakenly committed code that is not compliant with python 2.4
Here are your options to fix this error:
(1) update your python version from 2.4 to 2.5 or 2.6;
(2) update your installation from galaxy-central;
Hello,
This is a bug and has been fixed. I reran your analyses on our test server and
they completed successfully, so you should be good to go.
Best,
J.
On May 3, 2011, at 6:08 AM, shamsher jagat wrote:
Jeremy,
I have been trying to follow the steps in filtering Cufflink out put files
Sarah,
We recently updated the Cufflinks/compare/diff wrappers to be compatible with
v1.0.* ; the wrappers are available in galaxy-central and should be available
in galaxy-dist in the next couple weeks as we're planning another release soon.
New features in v1.0.* have not been implemented in
.
-gordon
Jeremy Goecks wrote, On 05/10/2011 09:02 AM:
We recently updated the Cufflinks/compare/diff wrappers to be compatible
with v1.0.* ; the wrappers are available in galaxy-central and should be
available in galaxy-dist in the next couple weeks as we're planning another
release soon
Assaf,
Thanks for the very helpful information. We largely sync our tool wrappers to
the tool version used on our public server. We're currently running v1.0.1 of
Cufflinks on main; hence, as you discovered, the wrappers are compatible with
that version of Cufflinks but (sadly) incompatible
Based on the naming convention of the other outputs (and the output files
from cuffdiff),
I think the label of the first one should be renamed to CDS Expression only
(assuming the relevant input file cds_exp.diff).
Correct. That said, I've been planning to reorder and rename the Cuffdiff
John,
Questions about local installs are best directed to galaxy-dev, so I've moved
the question to this list.
While executing cuffcompare, I encountered this error message:
Error running cuffcompare. [Errno 2] No such file or directory: 'cc_output'
I was practicing RNA-seq analysis
Matt,
I'm moving your Trackster question onto the galaxy-dev list:
one issue I keep running into is that it's not super clear how to go about
configuring the dynamic tracks you showed off in your talk.
Is there some guidance somewhere that I am missing on this? I confess my own
motive
Yes, all BAM fails are failing with the same error message. Before updating
my
instance I did not try to visualize through Trackster. Samtools path are
available to
Galaxy. I am not seeing any error/warning message in my log file.
Try this in the main interface:
(1) click the pencil
I recommend to use the repeat tag (see
http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax) around the
existing parameter to make it possible to select multiple files.
Sarah's suggestion is spot on. See the Cuffcompare wrapper for an example of
how to use this tag.
Gus, if you end
, 2011 at 8:51 AM, Jeremy Goecks jeremy.goe...@emory.edu
wrote:
I recommend to use the repeat tag (see
http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax) around the
existing parameter to make it possible to select multiple files.
Sarah's suggestion is spot on. See the Cuffcompare
Ilya,
Despite the wrapper version numbers (which I'll update shortly to avoid further
confusion), the current Cufflinks wrapper in both galaxy-central and
galaxy-dist supports Cufflinks v1.0.3 However, not all new options for v1.0.3
are implemented the current wrappers; should you decide to
It turns out there sort of is, extract/extract_genomic_dna.xml
However, as written it isn't clear to me how to make this work
with general tabular files, and how it would behave with proteins
(which in principle can be process the same way).
It also appears to insist on having both
Hi Ilya,
Thanks for the contribution; most of it has been committed in changeset
0ef81af1de09
A couple notes:
*I couldn't transplant your changes because your commit did not include recent
changes to the Cufflinks wrapper. It appears you didn't merge correctly with
the main repository at
Actual result: Red error against the gff file,
Unspecified genome build, click the pencil icon in the history item to
set the genome build
The fact I'm using a FASTA file from my history should mean the genome
build is irrelevant as that only applies to locally cached genomes
(right?).
Colin,
How is it possible to preinstall a reference genome for trackster (hg19)
within galaxy.
i tried to find a dedicated help page but could not find any. Could you
please link me to relevant information?
See the section titled 'Setup for local instances' on this page:
Great. Could you try that example on the latest galaxy-central please?
I have revision 06f0bca6de24 and get the following error using the
steps given earlier:
Traceback (most recent call last):
File
/home/pjcock/repositories/galaxy-central/tools/extract/extract_genomic_dna.py,
line
I think I've found another problem in exploring possible workarounds,
1. Goto http://usegalaxy.org (or a local Galaxy running galaxy-dist or
galaxy-central)
2. Import this GFF3 file,
ftp://ftp.ncbi.nih.gov/genomes/Bacteria/Nanoarchaeum_equitans_Kin4_M_uid58009/NC_005213.gff
3. Click on
Well, sort of. After converting that GFF3 file into BED, the strand column
isn't set in the metadata. That seems important!
We'll look into this.
Also a point of clarification, I had the wrong URL for the FASTA file.
This is the whole genome, although to actually proceed with this
However, the FASTA output uses different names because it embeds
the start/end co-ordindates as is. Thus using GFF3 features, the
sequence name includes _883_2691_ while using BED features the
same sequence has instead _882_2691_ for its name.
I propose this be harmonised by always using
Sorry -more questions - could you explain what the Interpret features
when possible setting in the Extract Genomic DNA is meant to do?
The tool's help text doesn't say anything (other than it is only for
GTF/GFF files).
In the NC_005213.1 example turning Interpret features when possible
on
One idea to address both of these issues is to embed the
original format in the fasta name so that it's clear whether
the coords are BED or GFF (e.g.
hg17_BED_chr1_147962192_147962580).
Or hg17_gtf_chr1_147962192_147962580 etc.
That certainly seems better than the current situation.
Hi Hans,
We haven't done much testing of Trackster with IE yet, and I wouldn't be
surprised if it's broken because IE doesn't follow standards in many important
areas. Trackster should work with Chrome, Safari, and Firefox in all cases.
We'll continue to work to improve Trackster functionality
The option to filter a BED file by the score in the visualization tool is
brilliant! There is just one draw back: you can only filter by integers.
Hence a score of 1.1 is the same as of score of 1.3.
How difficult would it be to change the code in order to allow floats for the
filter?
a problem as far as I have tested. We don’t want to have our code
base differ to much from galaxy-central.
Thanks,
Ilya
From: Jeremy Goecks [mailto:jeremy.goe...@emory.edu]
Sent: Wednesday, September 07, 2011 6:26 PM
To: Chorny, Ilya
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re
Hi Shaun,
I have built up a large collection of Galaxy data on my local account and I
am now finding the following operations very slow:
Showing saved histories
I just committed a fix in galaxy-central that should help out considerably:
Len,
This a beta feature with multiple usability issues. That said, it should work;
here's how:
Galaxy provides a URL when you export a history; take note of this URL as this
is the one that you'll when importing the link. If Galaxy doesn't provide a
link, update the history somehow (e.g.
Curt,
You are correct, this is a bug. It was fixed in this changeset:
https://bitbucket.org/galaxy/galaxy-central/changeset/ff7c8c0bef60
We'll be updating galaxy-dist in the next week and this change will be
available then.
Thanks,
J.
On Oct 5, 2011, at 5:54 PM, Curt Palm wrote:
I have
David,
Please direct questions about local installations to the galaxy-dev mailing
list (cc'd); there are a large number of experienced people of this list that
can likely help with this and similar questions.
Just a quick question about the compute infrastructure of the setup running
the
I made some changes to the cufflinks and tophat wrapper to pull gtf files
from an indexed loc file as opposed to from history. The diff’s are
attached. I made it an optional feature. Please let me know if this makes its
way into galaxy-central.
Ilya,
This looks like a good start. A
Shaun,
version_command is what you want:
version_commandtophat --version/version_command
A couple things to note:
*tool path isn't needed if the tool is in your galaxy user's path;
*your tool must have a --version command line option; if not, you'll
have to modify the
Hi Ross,
I checked the following:
wget link works, I can download the file. It's not saved as
Historyname.tar.gz but as export_archive?id=a69ee3e00cb4d02c. Anyway, I
can unpack the archive with tar xfvz.
hg head:
Änderung:5955:949e4f5fa03a
Marke: tip
Nutzer:
--
select id, state, command_line, stdout, stderr from job where
tool_id='__EXPORT_HISTORY__' order by id desc;
--
The query should actually be:
select id, state, command_line, stdout, stderr from job where
tool_id='__IMPORT_HISTORY__' order by id desc;
Thanks,
J.
David,
Wrapper supports v1.0.0 to v1.1.0
I'll update the wiki momentarily.
J.
On Nov 2, 2011, at 2:04 PM, David Hoover wrote:
What version of cufflinks do the current Galaxy wrappers support? The wiki
(http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Dependencies) says 1.0.1, but
our local
Chris,
The problem is likely a bug in the Cufflinks wrapper that was recently fixed in
galaxy-central:
https://bitbucket.org/galaxy/galaxy-central/changeset/ff7c8c0bef60
Try updating your Galaxy instance to include this changeset; if this doesn't
fix the problem, let us know.
Good luck,
J.
Nico,
Does this happen when publishing new histories or just for histories that have
been published previously?
If you're pulling from galaxy-central, you're running a very old version of
Galaxy. Currently tip is 6292:9b7d5c1c0be6 ; updating your instance to tip may
solve the problem as well.
- Postfach 10.2209
69102 Heidelberg, Germany
---
On 17 Nov 2011, at 14:59, Jeremy Goecks wrote:
Nico,
Does this happen when publishing new histories or just for histories that
have been published previously
Aurelien,
The particular behavior that you need isn't currently supported because the
value of from_work_dir isn't treated as a template. To work around this
limitation, you can do the move/copy operations in your tool wrapper; see the
wrappers for Bowtie and Sicer for examples on how to do
pas présenter, copier, distribuer ou utiliser le contenu
de ce message. Si ce courriel est reçu par erreur, veuillez nous en excuser,
veuillez détruire toutes copies de votre système nous informer à
supp...@dnalandmarks.ca.
From: Jeremy Goecks jeremy.goe...@emory.edu
To: Liisa Koski
Aurelien,
The particular behavior that you need isn't currently supported because the
value of from_work_dir isn't treated as a template. To work around this
limitation, you can do the move/copy operations in your tool wrapper; see
the wrappers for Bowtie and Sicer for examples on how to
Curtis,
[curtish@cheaha galaxy]$ find . -name *.py | xargs grep sam_fa_indices.loc
./tools/samtools/sam_pileup.py:seqFile = '%s/sam_fa_indices.loc' %
GALAXY_DATA_INDEX_DIR
...
./tools/ngs_rna/cufflinks_wrapper_without_gtf.py:
cached_seqs_pointer_file = os.path.join(
Hi Holger,
I went to the respective file and found that the line which defines
seq_file is commented out:
(l.38 in def check_seq_file())
## seq_file = %s/alignseq.loc % GALAXY_DATA_INDEX_DIR
This seems to be a bug in the current version of the file.
There is clearly something amiss. In
.
From: Jeremy Goecks jeremy.goe...@emory.edu
To: Liisa Koski liisa.ko...@dnalandmarks.ca
Cc: galaxy-dev@lists.bx.psu.edu
Date: 2011-11-28 14:46
Subject: Re: [galaxy-dev] Can't view data files from published
histories, only imported histories
Liisa,
I'm not able to reproduce
Hi David,
There should be additional information in the galaxy database about why the job
failed; take a look at stderr column of the failed job using some SQL like this:
--
select * from job where state='error' and tool_id='tophat' and stderr like
'%indexing reference%' order by id desc;
--
Lecturer in Virology
Room E49
Department of Cellular and Molecular Medicine,
School of Medical Sciences
University Walk,
University of Bristol
Bristol.
BS8 1TD
U.K.
Tel. +44 117 3312058
Fax. +44 117 3312091
d.a.matth...@bristol.ac.uk
On 5 Dec 2011, at 21:00, Jeremy Goecks
David,
What is the full stack trace that you're seeing? The stack trace is the text
below Traceback and identifies the exact location where the problem occurs.
Are you following these guidelines:
http://wiki.g2.bx.psu.edu/Admin/NGS%20Local%20Setup
for setting up large genomes in Galaxy?
Josh,
It appears that there are shell directories for the tools under
~/galaxy-dist/tools/ with basic wrapper scripts but without the corresponding
executables (very few that I've noticed have the tools already in them). Is
the intent to download the dependency tools and (building from
Alex,
I just implemented this functionality in galaxy-central changset 303741fda0ec
and documented it on the wiki.
https://bitbucket.org/galaxy/galaxy-central/changeset/303741fda0ec
http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax#A.3Coutputs.3E_tag_set
Best,
J.
Hi all,
by
I would like to modify Pages a lot. For example, I would like to create a
galaxy Page with rss-reader written in PHP (or javascript) in it.
I found where content is stored for Pages, but not the script who read this
content.
Pages uses the WYMEditor to render Pages:
,
Thank you for the link. I have already seen those files, but I was
hoping for written instructions and the files for the video tutorials.
Jeff
On 12/29/2011 09:19 AM, Jeremy Goecks wrote:
Jeff,
Here are some tutorials on basic NGS analyses in Galaxy:
http://main.g2.bx.psu.edu/u/james/p
Jeff,
Here are some tutorials on basic NGS analyses in Galaxy:
http://main.g2.bx.psu.edu/u/james/p/exercises
Best,
J.
On Dec 22, 2011, at 11:54 AM, Rosenfeld, Jeffrey wrote:
Hi,
I am trying to teach some people to use Galaxy, and I was looking
for a written tutorial that went
. Could you please guide me to
the link/webpage that talks about checking the job manually using
top/qstat/similar.
Happy New Year,
Bassam Tork.
On Thu, Dec 29, 2011 at 9:18 AM, Jeremy Goecks jeremy.goe...@emory.edu
wrote:
My idea was to pass all above including main.bash as parameters
The manual highly recommend postgresql, is there any critical point to
use it, instead of mysql? I am just more familiar with mysql. Thanks.
The Galaxy team has found that, when running Galaxy, postgres is more stable
and robust than mysql. Also, we use postgres ourselves, so it's
Efthymois,
You'll want to run Galaxy as a daemon process. Run
% sh run.sh --help
to get more information on running Galaxy as a daemon.
Also, please direct questions about running/configuring a local Galaxy instance
to galaxy-dev (cc'd) rather than galaxy-user, which is for tool and analysis
Ivan,
#if $__user_email__ ==
displayYou are not authorized to use this tool/display
#else
command interpreter=python
data_source.py $output $__app__.config.output_size_limit
/command
To make this approach work, the email check should go in the command tag.
More
Ivan,
tool name=UCSC Main id=ucsc_table_direct1 tool_type=data_source
descriptiontable browser/description
command interpreter=python
#if $__user_email__ ==
displayYou are not authorized to use this tool/display
#else
data_source.py $output
Good catch Jeroen. It's fixed on the development branch in changeset
0d1d62b8be2e
J.
On Jan 11, 2012, at 9:04 AM, J. F. J. Laros wrote:
Dear developers,
Subject: Minor issue - Confusion about public / user name.
Description:
When creating an account or managing user information, the
May you suggest me how to sketch a simple python script that prints in the
central section of the galaxy
window a message like you are not authorized to execute this tool ?
This isn't possible right now, hence my reference to the open Bitbucket issue
regarding this limitation.
The best you
Milos,
Can you share your history with me (Options - Share or Publish - share with a
user -- my email address) and I'll take a look.
Thanks,
J.
On Jan 16, 2012, at 12:46 PM, Milos Busarcevic wrote:
Hi,
I've got this message after trying to run Cufflinks on the Main instance:
Server
try to run cufflinks has changed into: Error executing tool: 'hg19'.
Thanks,
Milos
On Mon, Jan 16, 2012 at 7:21 PM, Jeremy Goecks jeremy.goe...@emory.edu
wrote:
Milos,
Can you share your history with me (Options - Share or Publish - share
with a user -- my email address) and I'll
Hans,
A couple questions:
(a) What browser/OS are you using when seeing this problem?
(b) Can you replicate this behavior on our public server?
A couple notes: depending on your Web server setup, it may be necessary to use
the packed Trackster script rather than the full one. Also, we're
it works fine on the public server
Good, this narrows down the problem to installing the -central script on your
instance b/c main's copy of the script is very similar to -central's.
what do you mean by packed Trackster script
All JavaScript files are compressed in
Brad,
But I think it might be a lot easier to manage if step names were based on
the titles of the history items instead of data 2 or whatever.
Has this been tried and rejected for some reason?
It's been tried and rejected because dataset names get very long and unwieldy.
E.g. Sam/Bam
Ususally the most important information is the first and last step
E.g.
The TopHat run should be called
TopHat on SOLiD 24A
The alignment stats should be
SAM/BAM Summary Metrics of Solid 24A
With the rest of the tools in the chain identified in the more information
box.
This would
Hi Shaun,
Restricting datasets to show only the first megabyte is a great idea when
dealing with large data files but sometimes I want to see the end of a file
to check it is complete or to check the progress of a running job. At the
moment I use the helper script to find the file on the
On Thu, Feb 9, 2012 at 11:27 PM, Andrew Warren anwar...@vbi.vt.edu wrote:
Hello,
I was recently adjusting advanced parameters when running Tophat in Galaxy
and noticed that when advanced parameters are used, every field is converted
and submitted as command line parameter to the tool at
Wouldn't it be better not to have the default value 40 (or 20) in the wrapper
at all? i.e. Leave it out, so that by default that argument isn't used, so
that
tophat uses the default it wants to use.
This would work but limits reproducibility and transparency because Galaxy
wouldn't have a
Holger,
Have you looked at how dynamic options work and whether they would be
sufficient for your use? See thefilter tag syntax for details:
http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax#A.3Cfilter.3E_tag_set
To specifically address your problem: can you determine the particular
Hello Joachim,
After a quick try with visualising track in Trackster (importing one
chromosome of hg19 - which did not succeed BTW), none of the tools in my
local galaxy appear to work.
What are the steps you're taking to produce this issue?
They all send this error message:
Error
This bug has been fixed in galaxy-central but, as per one of the threads you
found, has not made it to galaxy-dist yet.
Try this:
1. assuming you haven't made any changes to datatypes_conf.xml, copy
datatypes_conf.xml.sample to datatypes_conf.xml
2. visit the custom builds page (User tab --
with that user.
FYI, the reset of the datatypes_conf.xml did not do the trick: following
error appears on the custom builds page: NoConverterException: Conversion
from 'fasta' to 'len' not possible
Thanks,
Joachim
On 02/13/2012 06:02 PM, Jeremy Goecks wrote:
This bug has been fixed
So is the behavior of the optional=true tag that if the field form is left
empty for that parameter then it will not be passed to the tool?
Optional is enforced at the UI level; a wrapper can choose to handle optional
parameters differently.
I am wondering if a more sophisticated behavior
Alex,
Generally cPickle errors when loading summary trees are a result of indexing
gone bad.
Here are a couple notes that should save you some work:
*your bowtie indices and 2bit files do not need to be rebuilt; they are not
generating these errors;
*converting your SAM files to BAM may
Thon,
It seems that trackster does not know how to display INTERVAL files?
Is that true?
Yes, this is currently a limitation. However, most of the work is done that is
necessary to make this happen, so it should be done soon, definitely in the
next month or two.
Surely there is an easy way
Leandro,
refresh_on_change is used quite a bit throughout the tool UI and appears to
work fine both on a local instance and on the public instance. E.g. look at
Tophat and change settings from 'Use Defaults' to 'Full Parameter List' -- the
refresh_on_change works on reload the tool with more
Maybe we don't understand the feature in the documentation, but this
isn't the refresh_on_change functionality. In the Tophat tool XML
there are no refresh_on_change=true attributes, you are talking
about a conditional tag which when changing will refresh the page in
order to expose
Andrew,
You are correct. I've made this change in galaxy-central changeset 4d48285fcaa6
Thanks,
J.
On Mar 20, 2012, at 9:18 PM, Andrew Warren wrote:
Hello,
In the file lib/galaxy/tools/actions/__init__.py for the execute function of
the DefaultToolAction class line 198 has the following
A final pointer: to see tools that use dynamic options, take a look at Extract
GFF features and Filter GFF dataset by feature count
Good luck,
J.
On Mar 22, 2012, at 12:15 PM, Greg Von Kuster wrote:
It's always best to look at examples in the code base for technical details
like this rather
Greg,
1. The horizontal rule dividers specified by a - in the text have
disappeared.
Fixed in galaxy-central changeset cb5ff5b1bd67
2. Also I spotted a change where this ..
- line 1 of some bullets
- line 2 of some bullets
Following line.
.. lost the blank line after the line
Kory,
Cufflinks quantifies transcripts in parallel, and the inconsistencies that
you're seeing are likely the result of these processes finishing in different
order during different runs. To address this issue, you can use the Galaxy sort
tool.
Ultimately, this is not a Galaxy issue but an
Hi Todd,
[Not sure if this is better suited to galaxy-dev or -user, so I'm sending
to both].
galaxy-user is most appropriate for this question because it related to usage
of Galaxy; galaxy-dev is for local installation and tool development questions.
My question is - can I create a
Simon,
Error executing tool: (ProgrammingError) column params of relation job
does not exist
This is your problem.
This column should have been created in migration script 93, but for some
reason it wasn't. The first step is to determine if subsequent migration
scripts failed as well. Run
I’m good with everything except the output dir. I can’t figure out how to
pass that directory information from Galaxy to the RUM_runner.pl in such a
way that Galaxy will be able to subsequently capture the data. Does anybody
have any advice, or can someone point me towards an existing
Hi Naharajan,
My best guess is that you've found some bugs. Fortunately, they are likely
fixed in galaxy-central and will soon be available in galaxy-dist (we're
planning an update in the next couple days). Once galaxy-dist is updated,
please try updating your Galaxy instance and seeing if
% sh manage_db.sh downgrade 92
% sh manage_db.sh upgrade
The downgrade to 92 and upgrade created job.params.
This is progress. You should be able to run jobs again, yes?
Unfortunately, we are still getting errors about duplicate key values. The
debug output when I try to export a history
Alex,
It's not clear what the problem is. Trackster will handle an arbitrarily large
number of contigs (albeit somewhat clumsily). What contig annotation data are
you trying to preserve and/or provide access to?
J.
On Apr 19, 2012, at 11:30 AM, Oleksandr Moskalenko wrote:
I needed to add a
yes: standard output: Broken pip
yes: write error
I know what this means, generally, but not in the context of Galaxy. Is this
a telltale symptom, or is it too generic to say?
Hard to say, but it's coming from your script and is indeed causing your job to
fail. You might find it easier to
Hiral,
I've cc'd the Galaxy development mailing list, which includes folks with
experience in all areas of Galaxy. Can you be clear about what you're trying to
do and what approach you're taking? Once it's clear what the issue is, someone
can chime in with suggestions.
Best,
J.
On Apr 19,
Hi Xiangyu,
This question is best directed to the galaxy development list, which I've cc'd.
In general, to integrate a tool into Galaxy, you'll want to write a tool
wrapper:
http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax
and then upload it to the Galaxy toolshed:
Hi Todd,
History export is a beta feature and hasn't been fully tested yet. We'll look
into this, but it's difficult to diagnose a bug on a local instance. Can you
reproduce on either our main or test server?
Thanks,
J.
On Apr 25, 2012, at 8:08 PM, Todd Oakley wrote:
Hello,
I'd am
Either user can upload a spreadsheet for that or I shall provide a template
file to fill up the data. When I checked there is no provision for uploading a
speadsheet in my galaxy instance.
Two simple options:
(1) have users convert their spreadsheet data to csv/tabular format; Galaxy
Let me give an example of something that I do. I have the user select a file
after which I, using dynamic_options, extract the column names and present
those to the user with a select input parameter. With the selected column
name I then present a new select input parameter with all the
Sarah,
What tool was used to create the problematic dataset?
Thanks,
J.
On May 7, 2012, at 12:17 PM, Sarah Diehl wrote:
Hi all,
I get the following error when I try to export a specific history to file:
10.1.5.190 - - [07/May/2012:18:01:08 +0200] GET /history/export_archive
HTTP/1.1
1 - 100 of 349 matches
Mail list logo
