Bug#840597: ITP: pyflame -- CPU profiler and flame graph tool for Python
Package: wnpp Severity: wishlist Owner: Evan Klitzke * Package name: pyflame Version : 1.1.0 Upstream Author : Evan Klitzke * URL : https://github.com/uber/pyflame * License : Apache2 Programming Lang: Python Description : CPU profiler and flame graph tool for Python Pyflame is a tool that uses the ptrace system call to analyze running Python processes and collect stack traces and generate flame graphs. It can be used as an alternative to, or alongside, existing Python profilers like cProfile. I am also the upstream author of Pyflame, and Pyflame is something I developed for my work at my job. It's already been packaged for Debian for our internal use, but I'd like ot contribute it to Debian proper. I'll have the time and resources to maintain this package because it will be part of my work at my job. This will be my first package in Debian and I may need some hand-holding through the process. I would very much like to eventually become a DM, and I hope this is the first package of many that I can help maintain. Therefore I will need a sponsor. One further note: Pyflame itself is written in C++, and can be built against Python2 or Python3. I'm not sure what the best way to package that is.
Bug#214083: Sort of applies to 4.0.3
I don't know a lot about how mouse handling is done in console applications, but this is definitely application-specific. The latest screen from unstable (4.0.3-0.3+b1) _will_ pass mouse clicks to links/elinks in gnome-terminal. It will not, however, pass mouse clicks to vim. For example, try opening a buffer in vim, and then entering :tabe some_new_file in command mode. This will bring up a small tab at the top of the terminal showing all of the vim tabs open. Outside of a screen environment, it is possible to click these tabs to switch buffers. Within screen, clicking the tabs produces no effects whatsoever. Likewise, it is not possible to use the mouse wheel to scroll through a text buffer in vim when vim is being run through screen. It seems to me that there must be (at least) two separate ways to do mouse events in a terminal, and screen is only handling one of them correctly. I think we need a console programming guru to come in and explain what is going on, and hopefully submit a patch so that screen can handle the broken cases correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
