psitop 0.3.0a2 released
Chris Miles
compatibility with PSI 0.3b1.1.
http://pypi.python.org/pypi/psitop
Any issues, report them at http://bitbucket.org/chrismiles/psitop/issues/
Cheers,
Chris
Floris Bruynooghe
>
> I have released psitop 0.3.0a2. This has been updated to fix
> compatibility with PSI 0.3b1.1.
Nice work!
> Any issues, report them at
> http://bitbucket.org/chrismiles/psitop/issues/
Most of the process names turn into garbage after a few refreshes.
Oddly the top ~8 keep their names. I haven't looked in detail enough
to be able to report a useful bug tough...
I agree with you that the code to get the name of a process is pretty
ugly (tough some code in psitop could be simplified by using
getattr(p, 'rss', '?') for example). Did you ever think up something
to make this better and which would fit into psi?
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Chris Miles
On 25/06/2009, at 7:44 AM, Floris Bruynooghe wrote:
>> Any issues, report them at
>> http://bitbucket.org/chrismiles/psitop/issues/
>
> Most of the process names turn into garbage after a few refreshes.
> Oddly the top ~8 keep their names. I haven't looked in detail enough
> to be able to report a useful bug tough...
Really? What platform was that on? What version of Urwid?
It has been fine for me on OS X, OpenSolaris & Ubuntu 8.10 so far.
>
> I agree with you that the code to get the name of a process is pretty
> ugly (tough some code in psitop could be simplified by using
> getattr(p, 'rss', '?') for example). Did you ever think up something
> to make this better and which would fit into psi?
Not yet, which is why I haven't brought it up. Needs more thinking
time. I'll look at cleaning up that code with getattr() and see what
we end up with.
Cheers
Chris
Floris Bruynooghe
>
> On 25/06/2009, at 7:44 AM, Floris Bruynooghe wrote:
>
> >> Any issues, report them at
> >> http://bitbucket.org/chrismiles/psitop/issues/
> >
> > Most of the process names turn into garbage after a few refreshes.
> > Oddly the top ~8 keep their names. I haven't looked in detail enough
> > to be able to report a useful bug tough...
>
> Really? What platform was that on? What version of Urwid?
Ubuntu 9.04, urwid 0.9.8.4
> > I agree with you that the code to get the name of a process is pretty
> > ugly (tough some code in psitop could be simplified by using
> > getattr(p, 'rss', '?') for example). Did you ever think up something
> > to make this better and which would fit into psi?
>
> Not yet, which is why I haven't brought it up. Needs more thinking
> time. I'll look at cleaning up that code with getattr() and see what
> we end up with.
On Linux it's possible to get a .command wich is empty, but an
.accounting_name which is not. I think in that case .command might
have to be set to the accouting name, maybe in between square brackets
like ps does.
That should make .command useful on all platforms. But .command has
the arguments attached to it normally. Does it make any sense to make
.exe mandatory too? In that case it could be "[accounting_name]" too
if it's normally missing and os.path.basename(p.exe) would always give
you a sensible name without arguments.
What do you think?
Floris Bruynooghe
An alternative option is rename "accounting_name" into simply "name"
and make it obligatory. It would then contain the accounting name (in
square brackets if there is no .exe) and otherwise the basename of
.exe.
I'm not sure which of these two I'd prefer. Maybe the first since the
only way to know if .exe is usable is by testing it with
os.path.isabs() anyway. Or maybe even both.