You are not logged in.
send you a message on github on how to fix the output problem.
damned ! Read this too late.
This is much better:
import commands
status, output = commands.getstatusoutput(cmd)
Sorry for confusion.
Offline
I was going with kljohann's suggestion for the commands module. But then I found this:
Using the subprocess module is preferable to using the commands module. getstatusoutput() and getoutput() have been moved to the subprocess module.
So no go. Commands is generally considered depreciated. This code should just work if passed through 2to3.
Yannick_LM, your patch is good. But every call should be non-verbose. No need for the if block.
Last edited by keenerd (2009-05-05 22:57:17)
Offline
New features and bug fixes. Most of these were done to make "pacgraph -m arch-repo gimp" look good/run.
--noopts ignores the optional dependencies of packages.
The bug fix is a little weird. Somehow there are a lot of deps for Gimp that pacgraph does not find in the repos. Now those are filtered out, but it will also complain a lot. Better than throwing a stack trace, I guess.
Offline
My problem is fixed now thanks
Offline
Out of curiosity, what does it report?
This patch really shouldn't do anything. It just forces the package db to be consistent, which should always be the case by default. I think there is a deeper problem of misreading pacman's info.
Offline
Here's mine: http://phpurity.comze.com/images/pacgraph.png
What's GHC, anyway?
Offline
What's GHC, anyway?
To find out what anything is on your system:
pacman -Qs ghc
Offline
Aha, thank you. Apparently it's a Haskell compiler. What the hell did I install that for...
Offline
Aha, thank you. Apparently it's a Haskell compiler. What the hell did I install that for...
xmonad?
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
-- Antoine de Saint-Exupery
Offline
Great, that thing is very useful!
Is it somehow possible to make the number of dependencies or other stuff determine the font size instead of what I believe now to be the file size?
Offline
Correct, it currently uses package size. Switching font size to another parameter is easy.
I'd like to know a little more about your use case first. What would number of dependencies help you find?
You can try it youself by editing the pt_sizes function to look like this:
def pt_sizes(tree, min_pt=10, max_pt=100):
"size in length -> size in points"
sizes = [len(node.links) for p,node in tree.iteritems()]
min_s,max_s = min(sizes), max(sizes)
convert = lambda s: int((max_pt-min_pt)*(s-min_s)/(max_s-min_s) + min_pt)
for p, node in tree.iteritems():
tree[p].font_pt = convert(len(node.links))
return tree
Just two tweaks, changing node.size to len(node.links)
Offline
Is there a tool to permanently record application usage? Would be interesting a graph of apps used over a few months.
You need data (gather via cron+pacman maybe?) + Gapminder-like visualisation tool.
For upload check http://www.gapminder.org/upload-data/
Offline
Great, that thing is very useful!
Is it somehow possible to make the number of dependencies or other stuff determine the font size instead of what I believe now to be the file size?
I would also like this feature, say as a command line option.
It would be cool to have other types of centrality determine the font size as well, such as betweenness centrality, eigenvector centrality, etc. What can I say, I'm a graph theory nerd. I can take a shot at implementing these if anyone else is interested.
The use case is mostly curiosity, but it gives an idea of which packages are most vital to system functionality.
Also a man page would be nice.
Enough requests, thanks for the program, it's cool
Last edited by jowilkin (2009-05-10 06:19:26)
Offline
Pacgraph (git version) has Debian support. Kind of. It is completely untested. It parses the output of dpkg. Since I don't actually have Debian anywhere, fun things are guaranteed to happen on a real system.
I think the most likely point of failure will be for packages with so many deps that they span two lines. (Right now it will only read the first line.) It might also fail on the size parsing, especially if dpkg makes it human readable.
To try it, get the single pacgraph file from github and run
./pacgraph --mode=debian
Could someone with python/debian experience take it for a whirl? Thanks!
Last edited by keenerd (2009-05-24 02:42:01)
Offline
lovely app. freed up 450MB here.
thank you very much.
Offline
I really need to get mine on a T-shirt or something.This is a very cool utility.
Last edited by Chokkan (2009-05-24 12:42:20)
< Daenyth> tomkx: my girlfriend is linux
< Daenyth> srsly
< Daenyth> she loves the way I «make install»
< Daenyth> all her /dev entries are mode 7 for me
Offline
I thought about stuff like:
pacgraph -w | --weight
"evolution in a huge font, because it depens on ((many packages +1) * (many packages nothing else depends on + 1)+6)"
=> ok, me want claws mail with my xfce now!
pacgraph -e | --estimate_importance
"gstreamer has a big font size, as there are a lot of packages ((depending on it +1) / (doesn't depend on many +1)+6)"
=> that thing looks already important on my system, maybe I should read what it does and search for a video player that uses it too to replace xfmedia/xine
... or something much simpler than "my idea" (and how I tried to do that)... something that actually works... and finishes comparing packages to arrays and arrays to packages before half a day (Yes Sir, sure I can code a simple sorting algorithm for 10 items myself! But who'll pay for the Beowulf-Cluster to run it?).
Offline
... or something much simpler than "my idea" (and how I tried to do that)... something that actually works... and finishes comparing packages to arrays and arrays to packages before half a day
I don't quite follow your description. For the first (weight) you want to multiply the number of deps of package X by the number of deps of package X that are not used by anything else? Chain compression absorbs the latter into X. (After running the tree through compress_chains(), all remaining deps have multiple parents.) A minor tweak to compress_chains would let each package maintain a log of the dependencies it has absorbed. This would not impact running speed.
The second (importance) should be simple to implement. Required by over depends on, correct? So for package X it would look like len(X.inverse) / (len(X.links) + 1.0)
The +6 and whatnot isn't really needed since it all gets rescaled to the font limits. Also, the set() operations are much faster than manually comparing lists.
Offline
This a great app! Thanks - didn't really help me manage my system, but that's cause I already took a scapel to it yesterday
Some type of visualization of a package's importance would be great as well - but I think it should recurse a bit? kernel-headers (to me, at least) seems like a pretty important package, but just relying on the # of packages that depend on it (and those it requires) would put kernel-headers lower than glibc, in which I'd think the opposite should be true.
Though correct me if I'm wrong about this understanding. Maybe Arch installs don't need kernel-headers?
Offline
New version in the AUR.
Notable changes:
Big fixes to arch-repo mode. No longer produces a thousand lines of warnings. Xyne, this is approaching the features you requested.
Console mode, with --console. This runs VERY fast and does not make an SVG. Instead it prints out the total size of the system, and the toplevel packages you can safely remove (pacman -Rssc)
Default behavior of opt-deps has been changed. Now it ignores optional dependencies. You can bring it back with --opt-deps.
Even faster! Especially noticeable if you are loading the entire Arch repository.
Offline
I managed to scrape together a Debian system, twice removed. (Found an old Mint live CD.) So mode=debian now successfully finishes, though it does not handle "provides" so the graph is incomplete. Probably lots of similar little errors an apt eye could find.
Example: http://kmkeen.com/pacgraph/mint3.png (4Mb)
Offline
Minor updates...
New feature: "--rip", for debugging. This rips a copy of your local package repository to a textfile. If you don't like the way your system renders, send the textfile my way and I can add it to my testsuite.
More consistent theming between inkscape/imagemagick/cairo.
Offline
So I'm currently using this as my background,
and was thinking of writing a short script to be able to generate it and set it along the lines of
#!/bin/bash
cd /home/Bond
#probably a while loop or something ...
#do
pacgraph -b "#111111" -t "#ffffff" -d "#1793d1" -p 9 55
#scripting to detect if image meets resolution criteria
#done
# if image meets resolution criteria then
#if
# add extra pixels to edges to fit 1680x1050
#then set as wallpaper
feh --bg-scale /home/bond/pacgraph.png
#fi
any advice on what package to use to determine if the png file is say within 1300-1450 wide / 1000-1050 high pixels.
Offline
any advice on what package to use to determine if the png file is say within 1300-1450 wide / 1000-1050 high pixels.
You can use the identify program from the imagemagick package which outputs something like
$ identify image.png
image.png PNG 512x512 512x512+0+0 8-bit DirectClass 97kb
Last edited by kakTuZ (2009-07-05 10:54:49)
Offline
gen-pacgraph.pl
#!/usr/bin/perl
use strict;
use warnings;
chdir('/home/bond/.config/');
my $count = 0;
my $w = 0;
my $h = 0;
while ($count <= 45) {
(`pacgraph -s -b "#111111" -t "#ffffff" -d "#1793d1" -p 9 50`);
$w = (`identify -format "%[fx:w]" pacgraph.svg`);
$h = (`identify -format "%[fx:h]" pacgraph.svg`);
chomp($w);
chomp($h);
#print "$w $h \n";
if (($w > 1300) && ($w < 1450) && ($h > 950) && ($h < 1050))
{
$count = 50;
}
else
{
$count ++;
}
}
if ($count == 50)
{
my $neww = 1680-$w;
my $newh = 1050-$h;
my $execstr = "convert pacgraph.svg -bordercolor #111111" .
" -border " . $neww . "x" . $newh .
" -crop 1680x1050+" . $neww . "+" . $newh . " pacgraph.png";
#print "$execstr \n";
(`$execstr`);
unlink("pacgraph.svg");
(`feh --bg-scale /home/bond/.config/pacgraph.png`);
}
exit 0;
works quite well for me, gives adequate room on the right for my conky
could potentially use some code that if unsuccessful in finding the initial image meet resolution requirements, then try adjusting the font sizing down and up ...
Offline