Joe Zeff posted on Sun, 23 Aug 2009 23:52:52 -0700 as excerpted: > I'm a Fedora user, thankyouverymuch, but I did play around with that > recently. (Bad eyesight.) The screen magnifyier did too much and was > too unresponsive so I stopped, but it was still checked.
Ahha! > The issue with > forgetting which articles I'v read has cleared up, but I'm still waiting > for pan to finish exiting. (Ah, there; it's done now.) The file > keeping the data for the group is up to about 1.8 Meg by now; could that > be part of the problem? I know there's something in pan about deleting > the articles, but I haven't tried it yet. You're talking about the file(s) in the groups subdir? FWIW, while I'm running a bit better machine than many (older, but dual dual-core Opteron 290, so four cores, 2.8 GHz, 8 gigs RAM, 4-SATA-spindle Linux kernel/md RAID-6 main system), in my text instance (I make use of the PAN_HOME environmental var to point pan at different directories, thus different settings, cache, everything, for text, binaries, and test), I have the cache set to several gigs, expiration set to not expire at all, and track about two dozen groups. I have messages going back more than two years on my ISP's server, and of course use gmane.org to participate in various lists including this one, with messages (well, headers, I've not downloaded all the messages that far back) there going back as far as the group/list on gmane does, to 2000 in at least one case. For the text instance du says the cache dir is 325 MB (for perspective, pan's default max cache size is 10 MB, before it starts deleting old messages as soon as it can to get it back in range, and I run a dedicated partition of 12 gigs for my binary instance cache, naturally I've had it filled) and the groups dir is 26 MB. ls -lSh says the largest file in the groups dir is gmane.comp.kde.linux, at 6.3 MB. Assuming that's what you were referencing, your 1.8 meg file is thus small compared to what I've accumulated here. For settings, I have pan set NOT to download new headers at open or when I enter a group, and NOT to mark-all-read when I leave a group or exit. Given all the above, from a cold cache pan /does/ take some time, several minutes, to open -- nearly 100% i/o-wait time, BTW -- the disks aren't particularly fast even tho it's effectively two-way-data striped (plus two parity stripes). But I start pan with KDE so it's already going when I want to use it, so the startup time isn't /that/ big a deal the way I'm handling it now, even from cold-cache. However, once the data's in-cache (memory), if I close pan and open it again, it restarts almost immediately. Again, it's the slow disk i/o that's the startup bottleneck. However, once it's open, it runs quite well, and it closes pretty close to instantly. Thus, there's something wrong with your setup if it's taking that much time to close. You said the gnome accessibility agent was still running, right? You unchecked it, which presumably means it won't start again, but did you verify (running ps or top or whatever GUI task manager) that it was stopped? Also, once it's stopped, if pan was running, it might still take awhile that first time to close -- I don't know enough about what the interaction is there to know for sure. But, starting pan and then quitting, after the first time once the accessibility agent is stopped, should now be faster. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
