Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Marius van den Beek
@mvdbeek
like this is still going through the HTTP API ?
Vahid
@VJalili
correct
Marius van den Beek
@mvdbeek
then it should actually be caught
Vahid
@VJalili
caught in api/controller?
I think
I'm not entirely sure on this, I just recently looked into this for the py3 porting
sorry, gotta run
Vahid
@VJalili
good hint anyway, thanks.
Slugger70
@Slugger70

Hey there! I'm running Galaxy 18.05 on a server, I have a tool that creates some javascript html output which I have whitelisted. I still get

javascript is needed to display data.
If you try to view this data on galaxy please contact your administrator to authorise javascript or download the file to view.

If I donwload the file it displays no problem.. I checked the whitelist config file and the tool that produced it is listed there. FastQC works fine.

Nicola Soranzo
@nsoranzo
Does the tool id have "strange" characters?
Slugger70
@Slugger70
It has Capital letters and an underscore. "-" is in the name
And the tool id doesn't match the xml name.
Marius van den Beek
@mvdbeek
if you guys are ever debugging a bug that happens occasionally and you can't reproduce it by looping over the test it might be worth setting PYTHONHASHSEED to a couple of different values, and see if the error becomes reproducible. Definitely helped narrow down 2 bugs with random dictionary order
wish I'd known that months ago ...
scholtalbers
@scholtalbers
hey all I'm writing a test (as requested by @bgruening .. ;)) for bismark. The first tool of the bunch generates a qname_input_sorted.bam and the subsequent tools will require that as input. However, it seems galaxy will not accept this format for upload(?) - i.e. i don't know how to write a test that has this param: <param name="mapping_output" value="mapped_reads.bam" ftype="qname_input_sorted.bam"/> - the error message I get is: `An invalid option was selected for file_type qname_input_sorted please verify'
Marius van den Beek
@mvdbeek
yeah -- that's on purpose. set the uploaded filetype to qnamed_sorted.bam. qname_input_sorted.bam is for aligners that were run in galaxy and that output the reads in the order that they were read in. This isn't the official "SO:queryname", but qname_sorted.bam is compatible with qname_input_sorted.bam , so there will be no additional conversion
scholtalbers
@scholtalbers
so that would be the tool input parameter to accept format="qname_sorted.bam,qname_input_sorted.bam" or just format="qname_sorted.bam"? and for the test the input file will also be typed with format "qname_sorted.bam"?
Marius van den Beek
@mvdbeek
just qname_input_sorted.bam as parameter type (qname_sorted.bam subclasses qname_input_sorted.bam, so that would be the same as qname_sorted.bam,qname_input_sorted.bam). Correct, the test file should be qname_sorted.bam
it's a little tricky unfortunately, but that's the best that avoids unnecessary conversions while still being correct :/
scholtalbers
@scholtalbers
it is indeed, but thanks for the explanation - lets see if i can get the tests right
Marius van den Beek
@mvdbeek
in what sense ?
scholtalbers
@scholtalbers
ah sorry, still get the invalid input - just a sec and I can paste the error message
scholtalbers
@scholtalbers
u"An invalid option was selected for file_type, u'qname_sorted.bam', please verify."
Marius van den Beek
@mvdbeek
is that locally ?
(I think the PR might be missing a .shed.yml file, nothing got tested)
scholtalbers
@scholtalbers
yeah indeed, cause the other tests are not finished yet and should be throwing errors in any case
its not a new set of tools, they are existing, the shed.yml should not be updated?
Marius van den Beek
@mvdbeek
is ~/.planemo/gx_repo up to date ?
sometimes it get's stuck on an old galaxy -- just rm it and try again ?
scholtalbers
@scholtalbers
might be will try
Marius van den Beek
@mvdbeek
for me it fails like this:
---------------------- >> begin tool stdout << -----------------------
Deduplicating with: 'deduplicate_bismark -s submitted_reads.bam --bam'
Processing single-end Bismark output file(s) (SAM format):
submitted_reads.bam


If there are several alignments to a single position in the genome the first alignment will be chosen. Since the input files are not in any way sorted this is a near-enough random selection of reads.

Checking file >>submitted_reads.bam<< for signs of file truncation...

samtools view: writing to standard output failed: Broken pipe
samtools view: error closing standard output: -1

Output file is: submitted_reads.deduplicated.bam


Total number of alignments analysed in submitted_reads.bam:    554
Total number duplicated alignments removed:    50 (9.03%)
Duplicated alignments were found at:    44 different position(s)

Total count of deduplicated leftover sequences: 504 (90.97% of total)

skipping header line:    @HD    VN:1.0    SO:queryname
skipping header line:    @SQ    SN:chrY_JH584300_random    LN:182347
skipping header line:    @SQ    SN:chrY_JH584301_random    LN:259875
skipping header line:    @SQ    SN:chrY_JH584302_random    LN:155838
skipping header line:    @SQ    SN:chrY_JH584303_random    LN:158099
skipping header line:    @PG    ID:Bismark    VN:v0.19.1    CL:"bismark --bam --gzip --temp_dir /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpn4m609_i -o /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpn4m609_i/results --quiet --fastq -L 20 -D 15 -R 2 --un --ambiguous /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpe8nkca8w /private/var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpDiq_J8/files/000/dataset_2.dat"

----------------------- >> end tool stdout << ------------------------

---------------------- >> begin tool stderr << -----------------------

----------------------- >> end tool stderr << ------------------------

FAIL
which from the datatype perspective looks OK. might even just be an issue with how samtools view is used inside bismark
scholtalbers
@scholtalbers
yes thanks @mvdbeek it was the galaxy version
Marius van den Beek
@mvdbeek
cool, good luck!
scholtalbers
@scholtalbers
the failures now are probably from the missing expected outputs :)
thx for the patience - will have to continue this later
Marius van den Beek
@mvdbeek
sure, np
John Chilton
@jmchilton
@mvdbeek I have a worry that has been growing. Do you think auto-propagating the group:* tags is a mistake - because we are too aggressive with our tag propagation. The simplest way to think about it is a imagine a collection with two group tags in the HDAs, then you run a mapping step or something and resulting collection has those group tags on the HDCA itself. This so far is fine - the HDCA does have those groups so that sort of makes sense, then imagine running a structured_like tool on the result - the input to the tool is the HDCA - so every resulting HDA will get all the auto propagated tags (name tags and group tags). I think anyway. Can we do a better job auto propagating or do we just need to disable it or hide it behind a flag for 18.09? I was also contemplating group and autogroup tags - to the tool they could look the same but they'd behave different in this behavior
I'm ultimately nervous about committing to this behavior until we see it works for a broad range of workflows - maybe just sticking with your tagging tool for 18.09 is the way to go
Marius van den Beek
@mvdbeek
Going with the tagging tool / the apply rules tool sounds perfectly reasonable to me
for a first shot, that is
the concerns you have also apply to name tags, which already have this behavior, and for some scenarios like the one you described they just dont work
John Chilton
@jmchilton
is there a tweak to the propagation we can do to fix this all - like prevent collection contents from propagating up to HDCAs? Fixing nametags would probably fix group tags then also
Or do we just not have enough metadata to infer what should happen and we should give up
Marius van den Beek
@mvdbeek
It would always break down for scenarios where we don't know which tag should propagate. If you subtract input1 from input2 (we do that quite often with bedtools for instance) -- which tag should the output have ?
I think that depends on the context