Greg; As you dug into, the javascript function should keep refreshing and checking the state until the information is available from the EC2 console, and then fill it in. This does work for me as intended on Firefox 9.0.1 and Chrome. It normally takes a minute or so for the server information to be available from Amazon.

Are you seeing the failure to refresh and fill in the information every time you use BioCloudCentral or intermittently? Do you have any javascript blockers or other magic running? Anything else that might help with reproducing this?

Thanks for letting us know about the problem and hopefully we can get it sorted out, Brad

Ok, I did some more investigating.

After I launched (5 minutes later if it matters), I opened up Firebug and ran "update_instance_state();" and it did fill in the information.

Maybe there's something wrong in the JS logic? Is it setting the state to running before it has the information?

Here's the javascript for easy reference:

<script> function update_instance_state() { $.get("/state", function(data) { console.log(data.instance_state); if (data.instance_state != '') { $('#inst_state').html(data.instance_state); } if (data.instance_state != 'running') { window.setTimeout(function(){update_instance_state()}, 5000); } else { $('#ssh_public_dns').html(data.public_dns); $('#nx_public_dns').html(data.public_dns); $('#cloud_url').html('<a href="http://' + data.public_dns + '/cloud" target="_blank">' + data.public_dns + '</a>'); } }); } $(document).ready(function() { update_instance_state(); }); </script>

Thanks,

Greg

On Thu, Jan 26, 2012 at 11:04 AM, mailing list margeemail@gmail.com wrote:

...

Hi guys,

When I launch using BioCloudCentral (http://biocloudcentral.herokuapp.com) I noticed it doesn't show my public DNS.  Even if I wait for a few minutes.

For the "Public IP (Cloudman Console)" table cell, it just shows blank, and for the SSH access area is just says "ssh ubuntu@"

It hasn't been a big deal because I just pull it from my EC2 console. But now I'm writing up some documentation for other researchers to use our application running on CloudMan, and it adds a lot of complexity to the documentation to tell them to log into the EC2 console, click on instances, copy the public DNS ...  It would be excellent if they could just click a link from the launch page!

Let me know if I can help with debugging.

Thanks again,

Greg

---

The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Hmm, I just launched again (I had Firebug enabled and JS started paused). When I unpaused it worked.

It's looking more and more like it's making a call to the GET URL too quickly and getting back some kind of bad value that's throwing off the javascript logic? Undefined? That's my best guess at this point.

-Greg

On Fri, Jan 27, 2012 at 7:51 AM, mailing list margeemail@gmail.com wrote:

Hi Brad,

I tried again just now.

I launched and left it alone for 5 minutes.  It said "not available" in the Instance State cell.  And nothing else happened.

Then I ran this in Firebug and it did fill in the proper information on the page:

...

...

...

update_instance_state();

GET http://biocloudcentral.herokuapp.com/state 200 OK                171ms undefined running

I'm not sure where that "undefined" is coming from.  Maybe that is part of the problem?  It seems like update_instance_state() isn't being run.

I don't have anything blocking JS.

Here's my system/browser info:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25

By the way, it might be a nice touch to put loading icons next to the cells in the table that will get updated.  There are some here: http://www.ajaxload.info/ The Javascript function could just remove or hide the icons once the final info is loaded.

-Greg

On Thu, Jan 26, 2012 at 9:03 PM, Brad Chapman chapmanb@50mail.com wrote:

...

Greg; As you dug into, the javascript function should keep refreshing and checking the state until the information is available from the EC2 console, and then fill it in. This does work for me as intended on Firefox 9.0.1 and Chrome. It normally takes a minute or so for the server information to be available from Amazon.

Are you seeing the failure to refresh and fill in the information every time you use BioCloudCentral or intermittently? Do you have any javascript blockers or other magic running? Anything else that might help with reproducing this?

Thanks for letting us know about the problem and hopefully we can get it sorted out, Brad

...

Ok, I did some more investigating.

After I launched (5 minutes later if it matters), I opened up Firebug and ran "update_instance_state();" and it did fill in the information.

Maybe there's something wrong in the JS logic?  Is it setting the state to running before it has the information?

Here's the javascript for easy reference:

<script>     function update_instance_state() {         $.get("/state",             function(data) {                 console.log(data.instance_state);                 if (data.instance_state != '') {                     $('#inst_state').html(data.instance_state);                 }                 if (data.instance_state != 'running') {

window.setTimeout(function(){update_instance_state()}, 5000);                 } else {                   $('#ssh_public_dns').html(data.public_dns);                   $('#nx_public_dns').html(data.public_dns);                   $('#cloud_url').html('<a href="http://' +                      data.public_dns + '/cloud" target="_blank">' +                      data.public_dns + '</a>');                 }             });     }     $(document).ready(function() {         update_instance_state();     });   </script>

Thanks,

Greg

On Thu, Jan 26, 2012 at 11:04 AM, mailing list margeemail@gmail.com wrote:

...

Hi guys,

When I launch using BioCloudCentral (http://biocloudcentral.herokuapp.com) I noticed it doesn't show my public DNS.  Even if I wait for a few minutes.

For the "Public IP (Cloudman Console)" table cell, it just shows blank, and for the SSH access area is just says "ssh ubuntu@"

It hasn't been a big deal because I just pull it from my EC2 console. But now I'm writing up some documentation for other researchers to use our application running on CloudMan, and it adds a lot of complexity to the documentation to tell them to log into the EC2 console, click on instances, copy the public DNS ...  It would be excellent if they could just click a link from the launch page!

Let me know if I can help with debugging.

Thanks again,

Greg

---

The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org.  Please keep all replies on the list by using "reply all" in your mail client.  For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Thanks for looking into it. I'm not sure what the issue is. If it works for everyone else, I guess that's good enough.

Thanks again,

Greg

On Mon, Jan 30, 2012 at 6:53 AM, Brad Chapman chapmanb@50mail.com wrote:

Greg; I've been looking into this and am unfortunately still not able to reproduce it. It seems like the setTimeout in the javascript code which calls the function until the state becomes 'running' is not being correctly run. There are some bugs out there with older versions of Firefox and Firebug:

http://code.google.com/p/fbug/issues/detail?id=3245

It might be worth upgrading and see if you still have any issues since it does seem to be working smoothly on current Firefox versions.

Hope this fixes it, Brad

...

Hmm, I just launched again (I had Firebug enabled and JS started paused).  When I unpaused it worked.

It's looking more and more like it's making a call to the GET URL too quickly and getting back some kind of bad value that's throwing off the javascript logic?  Undefined?   That's my best guess at this point.

-Greg

On Fri, Jan 27, 2012 at 7:51 AM, mailing list margeemail@gmail.com wrote:

...

Hi Brad,

I tried again just now.

I launched and left it alone for 5 minutes.  It said "not available" in the Instance State cell.  And nothing else happened.

Then I ran this in Firebug and it did fill in the proper information on the page:

...

...

...

update_instance_state();

GET http://biocloudcentral.herokuapp.com/state 200 OK                171ms undefined running

I'm not sure where that "undefined" is coming from.  Maybe that is part of the problem?  It seems like update_instance_state() isn't being run.

I don't have anything blocking JS.

Here's my system/browser info:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25

By the way, it might be a nice touch to put loading icons next to the cells in the table that will get updated.  There are some here: http://www.ajaxload.info/ The Javascript function could just remove or hide the icons once the final info is loaded.

-Greg

On Thu, Jan 26, 2012 at 9:03 PM, Brad Chapman chapmanb@50mail.com wrote:

...

Greg; As you dug into, the javascript function should keep refreshing and checking the state until the information is available from the EC2 console, and then fill it in. This does work for me as intended on Firefox 9.0.1 and Chrome. It normally takes a minute or so for the server information to be available from Amazon.

Are you seeing the failure to refresh and fill in the information every time you use BioCloudCentral or intermittently? Do you have any javascript blockers or other magic running? Anything else that might help with reproducing this?

Thanks for letting us know about the problem and hopefully we can get it sorted out, Brad

...

Ok, I did some more investigating.

After I launched (5 minutes later if it matters), I opened up Firebug and ran "update_instance_state();" and it did fill in the information.

Maybe there's something wrong in the JS logic?  Is it setting the state to running before it has the information?

Here's the javascript for easy reference:

<script>     function update_instance_state() {         $.get("/state",             function(data) {                 console.log(data.instance_state);                 if (data.instance_state != '') {                     $('#inst_state').html(data.instance_state);                 }                 if (data.instance_state != 'running') {

window.setTimeout(function(){update_instance_state()}, 5000);                 } else {                   $('#ssh_public_dns').html(data.public_dns);                   $('#nx_public_dns').html(data.public_dns);                   $('#cloud_url').html('<a href="http://' +                      data.public_dns + '/cloud" target="_blank">' +                      data.public_dns + '</a>');                 }             });     }     $(document).ready(function() {         update_instance_state();     });   </script>

Thanks,

Greg

On Thu, Jan 26, 2012 at 11:04 AM, mailing list margeemail@gmail.com wrote:

...

Hi guys,

When I launch using BioCloudCentral (http://biocloudcentral.herokuapp.com) I noticed it doesn't show my public DNS.  Even if I wait for a few minutes.

For the "Public IP (Cloudman Console)" table cell, it just shows blank, and for the SSH access area is just says "ssh ubuntu@"

It hasn't been a big deal because I just pull it from my EC2 console. But now I'm writing up some documentation for other researchers to use our application running on CloudMan, and it adds a lot of complexity to the documentation to tell them to log into the EC2 console, click on instances, copy the public DNS ...  It would be excellent if they could just click a link from the launch page!

Let me know if I can help with debugging.

Thanks again,

Greg

---

The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org.  Please keep all replies on the list by using "reply all" in your mail client.  For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Hello Vikram,

I just did a small test with one of the tools in this group with mm9 test data and the filter by species was fine. Perhaps something is not set up correctly? Or there is problem with a different tool (you didn't mention which in the set you were using, or I missed it!). Here is my test. If you can duplicate successfully, then maybe it will help you to determine where the problem is with your real data:

1 - Downloaded MAF data to my desktop from UCSC. Is small (1.7M), so I just used my browser and it was OK, but it is important to let it finish. http://hgdownload.cse.ucsc.edu/goldenPath/mm9/multiz30way/chrY.maf.gz

2 - Then again, since the file is smaller, just browser uploaded into Galaxy, setting the database as mm9. I could have also not set the database at upload and instead gone back and set the database using the "Edit Attributes" form (pencil icon) after upload completed.

3 - Obtained some sample interval data. Used "Get Data -> UCSC Main". From the mm9 database, RefSeq Genes track, limited to chrY, whole gene, BED format, sent to Galaxy. Double check metadata attributes. Since my data is from the UCSC Table browser, the defaults will be correct, but it is a good "best practice" to mention that it is usually worth a quick double check to confirm column assignments, datatype, and database assignments when using your own loaded/created data.

4 - tool: "Extract MAF blocks given a set of genomic intervals"

5 - set "Choose intervals:" to the dataset from step #4 and "MAF Source:" to "Alignments in Your History" then "Choose alignments:" as the dataset from step #2.

The list of species comes up under "Choose species:".

If you are still having problems after running this test, please feel free to send me a link to a shared history (use "Options -> Share or Publish", generate link, and email back directly to me, not to entire list). Please note which are the inputs if not obvious. Leave any error dataset in the history. In fact if there are any error datasets, you could use the green bug icon and submit the history that way and just mention in the but report comments that these are related questions.

Your question got a bit buried since it was sent as a reply to another thread. Next time, please send new questions as brand new questions, not as replies to prior questions with new subject lines. Helps greatly with tracking and such.

Hopefully this helps,

Best,

Jen Galaxy team

On 1/27/12 1:54 PM, Paralkar, Vikram wrote:

Hello,

In the "Fetch Alignments" section, it's currently possible to get only human-projected alignments (from 46-way multiZ (hg19) MAFs). Any way you could add the ability to choose mouse-projected alignments? I tried to do this by downloading the multiz30way (mm9) MAFs from the UCSC browser to my history and using it as the "Alignment from your history", but then I can't choose specific species from the 30 species list.

Any way you could add the ability to choose mouse-projected MAFs, and then choose specific species from it, just the way you currently have for human-projection. Thanks.

Vikram

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/