David Shochat <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 26 Apr 2008 17:44:02 -0400:
> I have a suspicion that this has already come up (was it that long > thread about glib includes?), but here's the error I'm getting: > my-tree.cc: In member function ‘virtual void > pan::DataImpl::MyTree::set_filter(pan::Data::ShowType, const > pan::FilterInfo*)’: > my-tree.cc:99: error: ‘g_assert’ was not declared in this scope > > I see in my-tree.cc: > #include <glib/gmessages.h> // for g_assert But poking around, it looks > like g_assert is actually defined not in gmessages.h, but in > gtestutils.h. Making that substitution fixed it. > > Ok, it looks like Duncan at least ran into this: > http://lists.gnu.org/archive/html/pan-users/2008-03/msg00041.html (and > many others) > How do I figure out what glib version I have? Going by package listing, > it looks like maybe I have 2.16.3. 2.16.3 is AFAIK the newest glib, yes, so that's likely what you have on a brand new distribution version. And yes, your problem is indeed glib 2.16 related. I posted it on that thread but for convenience and in case you missed it, here's the bug with the updated patch. It should take care of the problem. Note that you may well need the gcc 4.3 patch as well if the shipped gcc is equally up to date. (Wow, they SURE make it hard to figure out what version of GCC it ships with. They talk about this and that and the other thing, but seem to be ashamed, for some reason, of actual version numbers on stuff that matters to folks already in the Linux community, like gcc, xorg, etc. Most announcements at least have a link to a list of apps and their versions. I couldn't even find that in their publicity, tho the beta as announced on LWN is said to carry gcc 4.2.3, not quite so new after all, if they didn't update from that.) glib 2.16 bug with patch (use the 2008-04-08 patch) http://bugzilla.gnome.org/show_bug.cgi?id=524620 gcc 4.3 bug with patch http://bugzilla.gnome.org/show_bug.cgi?id=524625 > Another issue I've noticed since upgrading to "hardy heron" is that > quitting from pan sometimes takes a long time (20 seconds or so). This > is independent of whether I use the version I compiled myself or the one > supplied by with Ubuntu (which is also 0.132). I've not the foggiest on that one. Of course, with a dual-dual-core Opteron 290 (2.8 GHz) system, 8 gigs memory, and 4-way kernel/md RAID-6 main system storage, it's quite likely I'd NOT notice such a slowdown... unless it was MAJOR. Does it happen if you switch groups, wait say 20-30 seconds without downloading or marking read, and /then/ quit pan? Switching groups causes pan to save the state on the group you are leaving, same as it would when you quit if it had unsaved group state at quit (tho a quit saves a few other things as well, accel mapping at least), so switching groups first, then quitting pan without doing anything to generate any group state changes in the new group, should allow you to figure out whether it's the group state save or the actual quit that's taking the time. If you had been in the same group for some time before quit and had a lot of unsaved state to save, particularly if your memory is low enough some of it may have to be paged back in from swap in ordered to save, then I can see it taking some time, sure. I dislike the possibility of a pan or system crash causing pan to forget where I was in a group -- it was happening pretty regularly at one point when I was running then still new and unstable xorg and KDE composite support, X and therefore pan would crash at of course less than the most convenient times =8^( -- so I've developed the habit of quickly changing out and back into a group periodically, if I'm doing a lot of work in it, and of always switching groups immediately before I leave pan for awhile, so here, pan very rarely has any group state info to update at quit. If that's what's slowing you down, that's another reason I'm not seeing it here. Particularly if it started happening exactly when you updated, especially if you run the distribution kernel (as opposed to building it yourself from kernel.org sources or the like) so it would have updated at the same time, double-check your hard drive drivers as well. Use hdparm -I /dev/<device> (this will work for both old hd/IDE devices and new SATA/sd devices, not sure about true SCSI if you have that) to get information about current settings directly off the device. Verify that DMA is active. What I'm thinking here is that with the upgrade, particularly if you changed kernel with it as you would if you use distribution supplied kernels, it may have changed the drivers you are using from the chipset specific ones, which normally automatically enable DMA, to the the generic ones, which won't. With DMA off your disk access will be much slower than normal, and disk access is already slow, so you don't need it even slower. If that's the case, I'd suggest you seek help in your distribution forums and/or file a bug, to get the right driver running and dma enabled once again. -- 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 Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
