On Thu, Sep 26, 2013 at 9:10 PM, Greg Von Kuster wrote:
> James, it seems I was answering at the same time you were, so to highlight my
> comments to John, I'm just wondering how this will work for repositories in
> the tool shed that do not contain any tools, but just tool dependency
> definit
Simon,
What is the advantage of putting that XML definition in the tool shed?
It is not 100% true because of prior_install_required dependencies,
but for the most part sourcing/load the environment for tools is a
Galaxy problem, not so much a tool shed one. What if we did this
instead?
Add an opt
At Thu, 26 Sep 2013 22:03:09 -0400,
Greg Von Kuster wrote:
>
> Hi John,
>
> On Sep 26, 2013, at 9:15 PM, John Chilton wrote:
>
> > I was not even thinking we needed to modify the tool shed to implement
> > this. I was hoping (?) you could just modify:
>
> Nothing in the Tool Shed itself would
James, it seems I was answering at the same time you were, so to highlight my
comments to John, I'm just wondering how this will work for repositories in the
tool shed that do not contain any tools, but just tool dependency definitions
or complex repository dependency definitions.
Thanks,
Greg
Hi John,
On Sep 26, 2013, at 9:15 PM, John Chilton wrote:
> I was not even thinking we needed to modify the tool shed to implement
> this. I was hoping (?) you could just modify:
Nothing in the Tool Shed itself would be affected or require modification for
this new feature as this is completel
I was not even thinking we needed to modify the tool shed to implement
this. I was hoping (?) you could just modify:
lib/galaxy/tools/deps/__init__.py
to implement this. If some tool contains the tag
numpy
then if there is a manually installed tool_dependency in
`tool_dependency_dir/numpy/1.7
Hi John,
On Sep 26, 2013, at 5:27 PM, John Chilton wrote:
> My recommendation would be make the tool dependency install work on as
> many platforms as you can and not try to optimize in such a way that
> it is not going to work - i.e. favor reproduciblity over performance.
> If a system administ
Posting to galaxy-...@bx.psu.edu to give the question better exposure to
the development community.
Please _remove the galaxy-u...@bx.psu.edu mailing list from all replies_
- we want to avoid double posts.
For discussion of
local Galaxy instances and the Galaxy source code, please
use the Gala
My recommendation would be make the tool dependency install work on as
many platforms as you can and not try to optimize in such a way that
it is not going to work - i.e. favor reproduciblity over performance.
If a system administrator or institution want to sacrifice
reproduciblity and optimize sp
I could not find a "Galaxy version" in the application but speaking about
hg, it is Aug 19 (10411:c42567f43aa7).
Jan
2013/9/26 Martin Čech
> Jan,
>
> It works for me with the newest galaxy-central version. I registered new
> user without a problem having the pbkdf2 turned off.
>
> What version
> How are Galaxy histories shared amongst users?
My misunderstanding was that histories shared between users remain a single
entity. Prompted by your question I have now tried history sharing, and
see that the second user makes a distinct copy of the first user's history,
thus changing the history
Hi,
> Hi Bjoern,
>
> Is there anything else we (the Galaxy community) can do to help
> sort out the ATLAS installation problems?
Thanks for asking. I have indeed a few things I would like some
comments.
> Another choice might be to use OpenBLAS instead of ATLAS, e.g.
> http://stackoverflow.com/
I'm still not fully understanding your usage scenario.
> A simple example is the creation of a full history based log file.
I imagine that this would be an ideal use of the history API. Rather than
having tools log history, write a script that uses the API to generate a
history log.
> My more
well, I was just reading today's commits and I spotted: Nate's commit:
"Bugfix for tool-to-destination mapping, tool ids are lowercased but the
mapping id was not lowercased." - Changeset: 0b955e54451c
So I changed:
to
and it seems to work.
Regards, Hans-Rudolf
On 09/26/2013
Hi Carlos and John
Please allow me to pick up this thread.
I have been experimenting with this, but I cant get it to work. The
default destination is always used. Does it work for you, Carlos?
Regards, Hans-Rudolf
On 09/23/2013 03:32 AM, John Chilton wrote:
As your Galaxy instance becomes m
In case this will help, I have the framework implemented (and committed) for
handling pre-compioled binaries for tool dependencies for a supported set of
architectures. Dave B has updated a lot of tool dependency definitions on both
the test and main tool sheds to use this enhancement - those t
Hi Bjoern,
Is there anything else we (the Galaxy community) can do to help
sort out the ATLAS installation problems?
Another choice might be to use OpenBLAS instead of ATLAS, e.g.
http://stackoverflow.com/questions/11443302/compiling-numpy-with-openblas-integration
However, I think we build NumP
Ross, Peter,
Unfortunately, there are some issues with the automated testing
framework that I am working on resolving. I've created a Trello card to
track my progress:
https://trello.com/c/x8mx7HRB
--Dave B.
On 09/26/2013 06:47 AM, Ross wrote:
+1
I think it's been a problem with some o
Jan,
It works for me with the newest galaxy-central version. I registered new
user without a problem having the pbkdf2 turned off.
What version are you using now?
Martin
On Thu, Sep 26, 2013 at 4:02 AM, Jan Hapala wrote:
> Ahoj Martine,
>
> thanks for your response. That was a pretty stupid
Hi Rico,
Can you provide the specific GET request URL with which you encountered this
problem? There are very few GET requests when installing repositories from the
tool shed - the only one I can locate without a lot of digging is the
following, which I don't think is causing the problem.
# G
Great! Thanks!
Don't you ever sleep? It must be some un-allah-ly hour where you are.
On Thu, Sep 26, 2013 at 8:55 PM, Greg Von Kuster wrote:
> There seems to be issues with some repositories which we'll need to track
> down. However, I fixed some issues yesterday with styles in the tool shed
>
+1
I think it's been a problem with some of my repos for a while on test so
possible not related to blast_datatypes - I sent this privately about 2
weeks ago:
Ross
Sep 13 (13 days ago)
to Dave, Greg
Hey Dave - any thoughts on how to fix
http://testtoolshed.g2.bx.psu.edu/view/fubar/differential_c
On Tue, Sep 24, 2013 at 1:44 PM, Dave Bouvier wrote:
> Peter,
>
> The one on the main tool shed is due to an issue Greg and I are in the
> process of resolving. As soon as we've tested the fix, I'll schedule a
> re-test of that repository and update you on the status.
>
>--Dave B.
Looks to be
Hi Dannon, I am also using postgres 9.1.9 (from Ubuntu precise repository)
> $/usr/lib/postgresql/9.1/bin/postgres --version
> -> postgres (PostgreSQL) 9.1.9
> hg summary
> -> parent: 10411:c42567f43aa7 tip
./scripts/cleanup_datasets/pgcleanup.py -d -o1 -s 'delete_datasets'
> __load_config INFO
Ahoj Martine,
thanks for your response. That was a pretty stupid mistake, hard to notice
even though I program in Python.
However, this has not solved my problem, I get the same error. (I have also
made sure that it is in the right section.)
Jan
2013/9/25 Martin Čech
> Ahoj Honzo,
>
> Python
25 matches
Mail list logo
