{"action":"created","issue":{"url":"https://api.github.com/repos/tqdm/tqdm/issues/287","repository_url":"https://api.github.com/repos/tqdm/tqdm","labels_url":"https://api.github.com/repos/tqdm/tqdm/issues/287/labels{/name}","comments_url":"https://api.github.com/repos/tqdm/tqdm/issues/287/comments","events_url":"https://api.github.com/repos/tqdm/tqdm/issues/287/events","html_url":"https://github.com/tqdm/tqdm/issues/287","id":182246085,"number":287,"title":"Questions on SO: pipe","user":{"login":"lrq3000","id":1118942,"avatar_url":"https://avatars.githubusercontent.com/u/1118942?v=3","gravatar_id":"","url":"https://api.github.com/users/lrq3000","html_url":"https://github.com/lrq3000","followers_url":"https://api.github.com/users/lrq3000/followers","following_url":"https://api.github.com/users/lrq3000/following{/other_user}","gists_url":"https://api.github.com/users/lrq3000/gists{/gist_id}","starred_url":"https://api.github.com/users/lrq3000/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lrq3000/subscriptions","organizations_url":"https://api.github.com/users/lrq3000/orgs","repos_url":"https://api.github.com/users/lrq3000/repos","events_url":"https://api.github.com/users/lrq3000/events{/privacy}","received_events_url":"https://api.github.com/users/lrq3000/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-10-11T12:04:14Z","updated_at":"2016-10-13T20:53:42Z","closed_at":null,"body":"* http://unix.stackexchange.com/questions/2577/how-can-i-move-files-and-view-the-progress-e-g-with-a-progress-bar\r\n* http://unix.stackexchange.com/questions/1537/measure-pipe-throughput-in-the-shell/1539#1539\r\n\r\nThe best alternative to tqdm pipe: https://github.com/Xfennec/progress\r\n\r\nFrom its readme:\r\n```\r\nHow does it work?\r\n\r\nIt simply scans /proc for interesting commands, and then looks at directories fd and fdinfo to find opened files and seek positions, and reports status for the largest file.\r\n\r\nIt's very light, and compatible with virtually any command.\r\n```\r\n\r\nBut it depends on ncurses and works only on Linux."},"comment":{"url":"https://api.github.com/repos/tqdm/tqdm/issues/comments/253635609","html_url":"https://github.com/tqdm/tqdm/issues/287#issuecomment-253635609","issue_url":"https://api.github.com/repos/tqdm/tqdm/issues/287","id":253635609,"user":{"login":"lrq3000","id":1118942,"avatar_url":"https://avatars.githubusercontent.com/u/1118942?v=3","gravatar_id":"","url":"https://api.github.com/users/lrq3000","html_url":"https://github.com/lrq3000","followers_url":"https://api.github.com/users/lrq3000/followers","following_url":"https://api.github.com/users/lrq3000/following{/other_user}","gists_url":"https://api.github.com/users/lrq3000/gists{/gist_id}","starred_url":"https://api.github.com/users/lrq3000/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lrq3000/subscriptions","organizations_url":"https://api.github.com/users/lrq3000/orgs","repos_url":"https://api.github.com/users/lrq3000/repos","events_url":"https://api.github.com/users/lrq3000/events{/privacy}","received_events_url":"https://api.github.com/users/lrq3000/received_events","type":"User","site_admin":false},"created_at":"2016-10-13T20:53:42Z","updated_at":"2016-10-13T20:53:42Z","body":"Hey Casper, good to see you back :)\r\n\r\nI see no issue in implementing a platform specific additional feature as long as it doesn't prevent the main feature, tqdm pipe, from being used on Windows. Also, if you use psutils for process monitoring, it might also work on Windows if psutils for windows are installed, so we might potentially find a way later on to port this kind of platform-specific code.\r\n\r\nAlso you come back at the right time: I was going to work on merging tqdm PRs this week-end, starting tomorrow, because I won't be able to get back to tqdm for a few weeks at least after this week-end. If you can check the PRs (tagged to-review), that would be great!\r\n\r\nMy plan was to first merge the bugfix PRs, or PRs adding small features to the core. Then release a new minor version of tqdm with these fixes. Then merge the new modular architecture, and then merge submodules PRs (after being rebased on the new modular architecture). Then we can release a new major version of tqdm. What do you think about it? I think it's the cleanest way to move to the new architecture, even if I will lose some time rebasing every submodules."}}
{"actor":{"display_login":"lrq3000"}}