Re: [galaxy-dev] problem with view of list collection in history view
Thanks for the report Alexander. Carl has fixed this problem in dev with https://github.com/galaxyproject/galaxy/pull/431. Thanks Carl! -John On Thu, Jun 25, 2015 at 7:11 PM, John Chilton jmchil...@gmail.com wrote: Conversation in IRC. tl;dr - it looks like it might be a GUI related problem since the API does contain all of the datasets. Carl - any chance you have an idea of what is going on here? 21:20 jmchilton avowinkel: is it possible there were duplicated identifiers (has your discover_datasets pattern changed from earlier) 21:21 jmchilton I'm leaning toward saying it is likely a backend problem - since explicit output collections are pretty new and you are the first person I can think of really exercising them strenuously 21:21 jmchilton One way to verify though is to check the API - if you just open localhost:port/api/histories in your browser - find the history id 21:21 jmchilton then open /api/histories/history_id/contents and then find the collection 21:22 jmchilton you should be able to open something like 21:22 jmchilton /api/histories/history_id/contents/collections/collection_id - which should show the individual datasets 21:23 avowinkel there are defenitely no duplicate designations - if thats the same like identifiers 21:23 avowinkel It's still discover_datasets pattern=__name_and_ext__ directory=splits / 21:27 jmchilton My next question would be (if you can verify it is a backend thing) - are the elements in the dataset - the hidden elements less than a certain HID - or are they random. 21:28 avowinkel via the api all 96 entries are in the collection 21:29 avowinkel with element_index's 0 to 95, in total 96 21:29 avowinkel in both lists 21:31 avowinkel biggest hid is 202 21:32 avowinkel the parent's list hid is always smaller than the containing element's hids 22:26 jmchilton so you are sure every element_index from 0 to 95 is represented? This being a GUI problem is really odd - but it seems like it probably is. I wonder if someone a div id is generated from the identifiers in such a way that one is duplicated. Seems unlikely 22:26 jmchilton Can you open your JavaScript console and see if there are any JavaScript errors/ 22:27 avowinkel well. I did grep element_index, I saw index 0 on the top, Index 95 on the bottom. and wc -l gives 96 - so yes. very sure 22:28 avowinkel and when I scan loosely through the list of greps, I don't see anything odd 22:29 avowinkel don't want to count from 0 to 95 ^^ 22:29 jmchilton :) 22:29 avowinkel for all the tests 22:30 jmchilton does that API response have a hidden field for the datasets? 22:31 avowinkel there is nothing in that file that matches hidden 22:31 avowinkel (in the history they are all hidden) 22:32 jmchilton I would open your web browser and check for javascript errors next 22:34 avowinkel nop. nothing (Firefox 34 - ubuntu biolinux) 22:34 jmchilton can you send me a screenshot of the expanded collection? 22:35 avowinkel the newest run has 69 entries in the history 22:36 avowinkel what part do you want screenshotted? 22:38 jmchilton When I open the list, I just can see 64 items. The opened list in the history panel 22:40 avowinkel http://snag.gy/2knoI.jpg 22:43 jmchilton are you hand counting these lists in the browswer then? 22:47 avowinkel yes, hand counting 22:50 jmchilton I'll ping carl about this - he is the GUI mastermind - he might have some clue 22:59 avowinkel jmchilton: http://pastebin.com/DcpF1QAU 22:59 mrscribe Title: [YAML] galaxy dataset_collection contents - Pastebin.com (at pastebin.com) 23:00 avowinkel don't get confused: On the picture is a different dataset. It doesn't have sample_ in the name 23:04 jmchilton yeah - that response looks perfectly fine - really odd -John On Thu, Jun 25, 2015 at 4:58 PM, Alexander Vowinkel vowinkel.alexan...@gmail.com wrote: Hi Team, my tool creates dynamically 96 datasets bundled into a list. In the history I can see the number 96 in the top as hidden datasets (6 shown, 96 hidden) When I open the list, I just can see 64 items. Now I run the job again and I have 96 more hidden items. I open the new list and can see 66 items in that new list. What is going on here? Is that just a visual bug? Or are my datasets affected? Thanks, Alexander PS: I use postgres ___ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all
[galaxy-dev] problem with view of list collection in history view
Hi Team, my tool creates dynamically 96 datasets bundled into a list. In the history I can see the number 96 in the top as hidden datasets (6 shown, 96 hidden) When I open the list, I just can see 64 items. Now I run the job again and I have 96 more hidden items. I open the new list and can see 66 items in that new list. What is going on here? Is that just a visual bug? Or are my datasets affected? Thanks, Alexander PS: I use postgres ___ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] problem with view of list collection in history view
Conversation in IRC. tl;dr - it looks like it might be a GUI related problem since the API does contain all of the datasets. Carl - any chance you have an idea of what is going on here? 21:20 jmchilton avowinkel: is it possible there were duplicated identifiers (has your discover_datasets pattern changed from earlier) 21:21 jmchilton I'm leaning toward saying it is likely a backend problem - since explicit output collections are pretty new and you are the first person I can think of really exercising them strenuously 21:21 jmchilton One way to verify though is to check the API - if you just open localhost:port/api/histories in your browser - find the history id 21:21 jmchilton then open /api/histories/history_id/contents and then find the collection 21:22 jmchilton you should be able to open something like 21:22 jmchilton /api/histories/history_id/contents/collections/collection_id - which should show the individual datasets 21:23 avowinkel there are defenitely no duplicate designations - if thats the same like identifiers 21:23 avowinkel It's still discover_datasets pattern=__name_and_ext__ directory=splits / 21:27 jmchilton My next question would be (if you can verify it is a backend thing) - are the elements in the dataset - the hidden elements less than a certain HID - or are they random. 21:28 avowinkel via the api all 96 entries are in the collection 21:29 avowinkel with element_index's 0 to 95, in total 96 21:29 avowinkel in both lists 21:31 avowinkel biggest hid is 202 21:32 avowinkel the parent's list hid is always smaller than the containing element's hids 22:26 jmchilton so you are sure every element_index from 0 to 95 is represented? This being a GUI problem is really odd - but it seems like it probably is. I wonder if someone a div id is generated from the identifiers in such a way that one is duplicated. Seems unlikely 22:26 jmchilton Can you open your JavaScript console and see if there are any JavaScript errors/ 22:27 avowinkel well. I did grep element_index, I saw index 0 on the top, Index 95 on the bottom. and wc -l gives 96 - so yes. very sure 22:28 avowinkel and when I scan loosely through the list of greps, I don't see anything odd 22:29 avowinkel don't want to count from 0 to 95 ^^ 22:29 jmchilton :) 22:29 avowinkel for all the tests 22:30 jmchilton does that API response have a hidden field for the datasets? 22:31 avowinkel there is nothing in that file that matches hidden 22:31 avowinkel (in the history they are all hidden) 22:32 jmchilton I would open your web browser and check for javascript errors next 22:34 avowinkel nop. nothing (Firefox 34 - ubuntu biolinux) 22:34 jmchilton can you send me a screenshot of the expanded collection? 22:35 avowinkel the newest run has 69 entries in the history 22:36 avowinkel what part do you want screenshotted? 22:38 jmchilton When I open the list, I just can see 64 items. The opened list in the history panel 22:40 avowinkel http://snag.gy/2knoI.jpg 22:43 jmchilton are you hand counting these lists in the browswer then? 22:47 avowinkel yes, hand counting 22:50 jmchilton I'll ping carl about this - he is the GUI mastermind - he might have some clue 22:59 avowinkel jmchilton: http://pastebin.com/DcpF1QAU 22:59 mrscribe Title: [YAML] galaxy dataset_collection contents - Pastebin.com (at pastebin.com) 23:00 avowinkel don't get confused: On the picture is a different dataset. It doesn't have sample_ in the name 23:04 jmchilton yeah - that response looks perfectly fine - really odd -John On Thu, Jun 25, 2015 at 4:58 PM, Alexander Vowinkel vowinkel.alexan...@gmail.com wrote: Hi Team, my tool creates dynamically 96 datasets bundled into a list. In the history I can see the number 96 in the top as hidden datasets (6 shown, 96 hidden) When I open the list, I just can see 64 items. Now I run the job again and I have 96 more hidden items. I open the new list and can see 66 items in that new list. What is going on here? Is that just a visual bug? Or are my datasets affected? Thanks, Alexander PS: I use postgres ___ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
