Hi Melissa,
Am 17.06.2014 01:07, schrieb Melissa Cline:
Hi folks,
Hopefully this is a quick question. I'm working on a set of tools that
will fire off a VM from within Galaxy and will then communicate with the
VM. The VM will create a local database.
Are we talking here about a local
Glad to see someone else is playing around with Mesos.
I have a mesos branch that is getting a little long in the tooth. I'd like
to get a straight job runner (non-LWR, with a shared file system) running
under mesos for Galaxy before I submit that work for a pull request.
The hackathon is only 12
Say option 3 is the way to go, would you say every new version of an R
package should be wrapped in a new galaxy package (and give them names
like matrixStats_0_10_0) or create one package (matrixStats) and
update that one if a new version is worth an update. In the first way
there would be an
Any plans to create a R 3.1.0 repository?
Thanks,
Stef
___
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:
Hi Stef,
for R packages we have a special installation routine that will
(hapefully) make your life easier.
I'm running into some difficulties on how to setup the installation
procedure for a galaxy tool which executes an R script and has certain
dependencies (mainly bioconductor packages).
Hi Stef,
fortunately it is way easier than that. Please have a look at the
setup_r_environment installation routine :)
Cheers,
Bjoern
Am 17.06.2014 11:07, schrieb Stef van Lieshout:
Say option 3 is the way to go, would you say every new version of an R
package should be wrapped in a new
Hi Bjoern,
That looks much better indeed ;) The only problem I still have then is
that I need R 3.1.0 for a bioconductor 2.14 package (have send a new
mailing list msg for that). Looking at the xml of other versions it's
not something I will easily do myself.
What will happen if I do not specify
Hi Stef,
Am 17.06.2014 15:40, schrieb Stef van Lieshout:
Hi Bjoern,
That looks much better indeed ;) The only problem I still have then is
that I need R 3.1.0 for a bioconductor 2.14 package (have send a new
mailing list msg for that). Looking at the xml of other versions it's
not something I
Bjoern and Dave,
That sounds great. Of course my next question will be how much is a
little bit ;) It just that I have to move on for now and make things at
least work, so I might try it with using the default R instance now, but
as soon as a 3.1.0 package is out I will definitely pick it up!
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit. For the gene bank links I guess
modifying the .loc file is the least bad way. Maybe it can be merged into
galaxy_blast, that would at least solve the interoperability problems.
Good thing to clarify: this is a tool-specific database, created by tools
that are running inside Galaxy but that should persist after the individual
tools are done with their execution.
On Mon, Jun 16, 2014 at 11:23 PM, Björn Grüning bjoern.gruen...@gmail.com
wrote:
Hi Melissa,
Am
Hi,
Am 17.06.2014 21:25, schrieb Melissa Cline:
Good thing to clarify: this is a tool-specific database, created by tools
that are running inside Galaxy but that should persist after the individual
tools are done with their execution.
Should it persist as output data or forever even if I
On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote:
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit.
Are you using the optional job splitting (parallelism) feature in Galaxy?
That seems to be me to be a good
Hi Björn,
The database should persist forever, even if the workflow is restarted.
I'm not sure about the distinction between forever and output data, but
the database should remain in place until the user takes specific action to
make it go away.
If you reload a tool, it will reload/extend the
On Tue, Jun 17, 2014 at 2:55 PM, Peter Cock p.j.a.c...@googlemail.com wrote:
On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote:
Too bad there aren't any really good options. I will use the environment
variable approach for the query size limit.
Are you using the optional
It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you!
However I am still having import issues. I am now getting the message:
Archive of repository package_bowtie_0_12_7 owned by devteam
Import failed: repository owner devteam does not have an account in this
Tool Shed.
This is on a
Hi
I have quite a strange issue. I have a local install of Galaxy setup. When I
type 'date' on my Ubuntu machine I get something like:
Wed Jun 18 09:25:22 EST 2014
When i then execute a job and look in the database at the create_time i.e.
# select create_time from job order by create_time;
Postgres generally stores datatime fields in GMT, and then translates them
to the local time zone when generating a query. Check the TimeZone variable
in your postgres.conf.
http://www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES
-Will
On Tue, Jun 17, 2014 at 4:29
Hello Will,
On Jun 17, 2014, at 6:06 PM, Will Holtz who...@lygos.com wrote:
It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you!
However I am still having import issues. I am now getting the message:
Archive of repository package_bowtie_0_12_7 owned by devteam
Import failed:
Thanks, but looking at /etc/postgresql/9.1/main/postgresql.conf i have the
following:
#timezone = '(defaults to server environment setting)'
#timezone_abbreviations = 'Default' # Select the set of available time zone
# abbreviations. Currently, there
20 matches
Mail list logo